Future of Dolphin under .NET

Is there some discussion about how Dolphin will or could evolve under
.NET? I am wondering how Smalltalk fits in without changes to the
syntax and class framework. Can Dolphin run as a .NET application?
Will .NET be the only option under Windows at some point in the
future?

I was looking at Smallscript and the syntax sure looks different. It
almost looked procedural as opposed to message sends. Is that because
of .NET idiosyncracies?

Regards,

Costas

Costas,

There is previous discussion in the archives.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

<[hidden email]> wrote in message
news:[hidden email]...
> Is there some discussion about how Dolphin will or could evolve under
> .NET? I am wondering how Smalltalk fits in without changes to the
> syntax and class framework. Can Dolphin run as a .NET application?
> Will .NET be the only option under Windows at some point in the
> future?
>
> I was looking at Smallscript and the syntax sure looks different. It
> almost looked procedural as opposed to message sends. Is that because
> of .NET idiosyncracies?

Costas,

I suspect it is largely my fault that SmallScript samples you looked at,
appeared different.

In most of the SmallScript snippets or samples I have provided, the focus
was on illustrating new syntax or semantics that [in general] are only for
use in special scenarios.

There was little or no point in providing SmallScript samples of standard
Smalltalk usage -- since SmallScript is a superset of the Smalltalk language
people would have simply said "what's the big deal, I can do that in any
Smalltalk".

Smalltalk does not have a "pure" text form, other than SIF, for expressing
whole programs. To create an EXE, DLL with .NET characteristics, requires
some mechanism for declaring various configuration settings and attributes.
SmallScript adds a declarative (source text) layer to the object model which
enables one to define classes, methods, modules, resources, or custom [XML
style] elements. The source within a method body, however, can and typically
is written using only classic Smalltalk expressions.

Here would be a minimal script to build a Console App EXE:

    Compiler cmds: '-target:exe'.
    Module name: MyApp
    {
        Class-method [<$entrypoint>
        myAppsMain
            Transcript show: 'Hello World'; cr.
        ]
    }

You've probably seen terse (procedural-like) examples of this written as:

    Compiler cmds: '-t:exe'.
    Module name: MyApp.
    Function [<$entrypoint>
    myAppsMain
        stdout << 'Hello World`n'.
    ].

Both forms will result in "identical" behavior, assuming that, <Transcript>
has been mapped or aliased to <stdout> and that the #<< message is mapped to
#show: and/or #nextPutAll:. The "ANSI" Smalltalk module extension provides
these additional mappings, and can be accessed as follows:

    Compiler cmds: '-target:exe'.
    Requires module: ANSI. "or, alternately, Lang.Smalltalk.ANSI"
    Module name: MyApp
    {
        Class-method [<$entrypoint>
        myAppsMain
            Transcript show: 'Hello World'; cr.
        ]
    }

-----------
You would be hard pressed to write the above build-script for
consumption/processing by a classic Smalltalk environment. But, if you did,
it would look roughly like:

    "Get a compiler object"
    "Configure the compiler object to produce an EXE"
    "Load a package supporting ANSI extensions"
    "Declare a subclass of the <Module> class, called <MyApp>"
    "Declare a class method on <MyApp> with the following contents:"
        myAppsMain
            Transcript show: 'Hello World'; cr.
    "Instruct the compiler object to generate an EXE which only contains
     the elements necessary to execute #myAppsMain as the EXE's entrypoint"

Which would result in an standard COFF/EXE file whose size was "3.01 KB
(3,084 bytes)". This same code, with one addition to the compiler "cmds:
'-dotNet ...'" options, will generate an equivalent .NET [EXE] executable.
Noting that the "-dotNet" .NET code generation option is not available in
the technology preview versions of SmallScript which are publicly available.
-----------

Put another way, SmallScript is a superset of the Smalltalk language which
means that it will compile and process any "classic" Smalltalk expressions
you provide to its compiler. The declarative language system is built on top
of the dynamic MOP system, not the other way around. So [on its native VM]
you can dynamic transform or morph any object, class, etc using facilities
that exceed most classic Smalltalk object models.

SmallScript's object model is about as pure as it can get [often taking
things a good bit further than one finds in classic Smalltalk].

Many of SmallScript's syntax extensions exist specifically to enable
expression of "type" information, or "procedural" constructs to support
transparency and interop with foreign languages and external object models.
In that respect, they are necessary to provide transparent COM and .NET
interop with code/components/programs written in other languages.
====

People have already written tools for exporting SmallScript's text based
source forms from just about every popularly used Smalltalk dialect
available today. People have also written scripts/modules for compiling just
about every popular Smalltalk SIF form within SmallScript.

====

I certainly have a lot of respect for and greatly like the Dolphin product
family. It has been my stated goal to try and assist Smalltalk's success in
the .NET marketplace. That extends to collaborating and or supporting
various vendors, within some well defined business arrangement, in their
efforts to integrate with .NET.

====

If you have a specific .NET [or COM] related example of code you would like
to see written in a classic Smalltalk source style, please reply to this
forum and let me know.

-- Dave S. [www.smallscript.org]

>
> Regards,
>
> Costas

David,

I really did not study Smallscript beyond a cursory look. But it did
throw me off seing new syntax that  seemed foreign to Smalltalk.
Forgive me if I am a little confused.

I am assuming that since Smallscript must play with Visual Studio.NET
rules, you need to add the extra compiler/runtime "directives" for
lack of a better term, in the language itself. And I guess this fits
in with the compile/link/run philosophy of VS.

I would hope that a Smalltalk workspace oriented IDE (such as
Dolphin's) would be able to  make  .NET specifics transparent.  Which
is really my question. Can a living  environment such as Smalltalk's
be made to create CRL bytecodes or would there be a need to make a
Smalltalk VM on top of CRL?

Regards,

Costas

"Costas" <[hidden email]> wrote in message
news:[hidden email]...
There are significant technical challenges, within the .NET CLR/CLI/EE
model, for being able to support interactive development [changing classes,
add/remove/replace methods] within a single live running application.

One can readily write and design code, and then produce a .NET binary
assembly (modules) for use in executing such an application. But the idea of
actually having a "live" [self modifying application] environment like we
are used to in Smalltalk, is difficult to impossible in the current versions
of .NET.

Separate from the interactive aspect, is your question about whether it is
possible to write pure classic Smalltalk code for transparently accessing a
multi-threaded, statically verified opcode (IL) based strong, statically
typed common language runtime model without its own completing but distinct
core common language frameworks.

Without building type-system facilities and language declaration extensions
into Smalltalk, it is not possible to make the [full featured]
bridging/linking aspects of .NET transparent, just as it is not possible to
make the "transparent" for COM, or calling to C/DLL's etc.

At some level, fundamentally, there is information that .NET requires in an
generated assembly, and it is incumbent on a [Smalltalk program] consumer of
standard .NET assemblies to be capable of reading and processing similar
information.

What you see in SmallScript, is highly transparent because the basic object
model of SmallScript intrinsically supports type information and custom
annotations. Which means that it can transparently map Smalltalk to and from
typed [COM or .NET] libraries with custom attributes. The type information
you have typically seen in SmallScript examples are illustrating the kind of
code the type-library/reflection.metadata tools could generate for you.

Most of the examples you have seen were hand written methods for directly
exposing Smalltalk methods to the external world (foreign function
interface/FFI), or vice versa, the direct accessing of foreign functions
within DLL's such as operating system Kernel32.DLL and the like.

An IDE shell and browser tool could hide all the rich declarative mechanisms
for integrating Smalltalk/SmallScript with external code and object model
systems. But SmallScript the language still has to have the declarative
mechanisms for textual-source code so that the compiler can understand what
it needs to generate for bridging those worlds.

Put another way, any Smalltalk implementation will need some mechanism to
declare and describe foreign data structures and to handle marshalling of
objects to-and-from such structures.

SmallScript happens to have those facilities built directly as extensions
into the language and the execution machinery to enable automatic
marshalling and hi-performance cross-language interop.

Which, in turn, enables one to write (and deploy) simple scripts via an
ordinary text editor, with the ability to expose Smalltalk to, or access
from Smalltalk, any Windows, COM, or .NET facility with a few lines of code.

-- Dave S. [www.smallscript.org]

>
> Regards,
>
> Costas

"David Simmons" <[hidden email]> wrote in message
news:qSgG8.67885$UV4.86335@rwcrnsc54...
> ...
> Here would be a minimal script to build a Console App EXE:
>...[ hello world snipped]
> Which would result in an standard COFF/EXE file whose size was "3.01 KB
> (3,084 bytes)"

Dave, while not wishing to diminish the truly awesome achievement that
Smallscript represents, to put this into some perspective I think it should
be pointed out that this executable relies on a largish runtime support
library (combined VM and compiled class library); in the 800-900Kb range I
believe you have said recently. As a reference point (and bringing this back
to topic for this newsgroup) Dolphin XPs console HelloWorld sample can
either be compiled into an executable of around 168Kb plus a 225Kb VM, or to
an executable that *includes* the runtime support library (in this case just
a VM) of around 330Kb.

An interesting experiment in Dolphin would be to use its plugin/Active-X DLL
technology to create a runtime support library (this time a VM and
pre-compiled image), and deploy minimal executables consisting of not much
more than binary packages. This would, I suspect, produce very similar sizes
to those for the Smallscript exe/AOS dll combination.

I think what this all shows is that the argument about traditional Smalltalk
systems being "monolithic" may very well have some weight, but that
arguments based on the size of the resulting executables (not that I think
you are attempting to make such an argument here) are a bit weak.

I suspect, though I have not measured it, that Smalltalk MT is capable of
producing by far the smallest deployed application sizes if we include the
runtime support library.

> You would be hard pressed to write the above build-script for
> consumption/processing by a classic Smalltalk environment. But, if you
did, entrypoint"
>

I really don't think it would be that hard to write a Dolphin console
application that was able to act as a Smalltalk scripting engine using
traditional chunk format files. It certainly would not be as powerful (or
fast) as Smallscript, but it could be done. As for writing the final step,
well personally I would rather deploy my applications from within the IDE.

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:acidcn$pvps3$[hidden email]... should
> be pointed out that this executable relies on a largish runtime support
> library (combined VM and compiled class library); in the 800-900Kb range I
> believe you have said recently.

That is very true. For the native AOS system, one needs to have installed or
included a single AOS.DLL runtime file which [for technology preview builds
w/interim extra info] is in the 1.4MB range. It is expected that the final
GA versions will be around a 1MB uncompressed file; compressed form is
roughly 500kb [and equivalent library compression could be built into the VM
itself].

On the .NET platform, Microsoft has conveniently provided the 20-80MB shared
runtime elements. Just as Java provided a <g> similarly "small" shared
runtime pieces.

The point, of my "script" example, was to illustrate the size and
compactness for creating and distributing an application or component as
either source or binary composed of a single file.

Where optionally, the runtime+compiler+library DLL may be bundled as a
second file of such a distribution. The associated
runtime+compiler+libraries piece compresses in typical zip/cab scenarios to
roughly 500kb and only needs to be obtained or installed once. If we
feel/find that this may be too large a distribution we can reduce it, or we
can provide a stub-downloader which would obtain the VM DLL on demand, if it
was not already present.

> As a reference point (and bringing this back
> to topic for this newsgroup) Dolphin XPs console HelloWorld sample can
> either be compiled into an executable of around 168Kb plus a 225Kb VM, or
to
> an executable that *includes* the runtime support library (in this case
just
> a VM) of around 330Kb.

I assume that the 225Kb VM is shared by all executables and/or that one
produces?

I.e.,

Project A: Produces an EXE

Unrelated Project B: Produces and EXE

Unrelated Project C: Produces a COM DLL

All three share the 225Kb VM file.

>
> An interesting experiment in Dolphin would be to use its plugin/Active-X
DLL
> technology to create a runtime support library (this time a VM and
> pre-compiled image), and deploy minimal executables consisting of not much
> more than binary packages. This would, I suspect, produce very similar
sizes
> to those for the Smallscript exe/AOS dll combination.

Indeed. This is something you and I have chatted about. It is the mechanism
behind SmallScript's modular component architecture.

>
> I think what this all shows is that the argument about traditional
Smalltalk
> systems being "monolithic" may very well have some weight, but that
> arguments based on the size of the resulting executables (not that I think
> you are attempting to make such an argument here) are a bit weak.
>
> I suspect, though I have not measured it, that Smalltalk MT is capable of
> producing by far the smallest deployed application sizes if we include the
> runtime support library.

Perhaps.

But, when I last looked at MT, it does so by sacrificing capabilities for
providing a feature complete Smalltalk "language" implementation. For
various reasons, that was something I felt was the opposite of what was
needed in a common dynamic language runtime VM.

If the ~1MB runtime size of our shared common dynamic language runtime VM
turns out to be larger than desireable, we may opt to provide the option of
"pre-jitting" the opcodes into native machine code for a particular CPU/OS
[as MT does]. Followed by a tree-shaking to extract only the "used" elements
within the common library.

I can certainly understand why other dialects like MT and possibly Dolphin
might have decided that such a deployment packaging mode is the right choice
for their product offerings. It was the original approach behind QKS's MacOS
SmalltalkAgents system.

If we felt such an deployment option was needed for SmallScript we could
drastically reduce the Smalltalk runtime size to somewhere in the range of
100Kb or less [i.e., basically a GC and some core-services]. Such a
deployment option would sacrifice the availability of the compiler, general
scripting, and a rich [guaranteed to be available] shared runtime library.
It would produce pre-jitted exe/dll programs that would be perhaps 2X larger
for the same code in comparison to non-pre-jitted ones we make today. But
would also be distinctly larger for having to include the non-shareable
pre-jitted library elements they required -- and that could typically be a
couple of hundred kb.

The deployment issues are primarily a decision based on comparing
download/file sizes for roughly 500kb one-time download with the ability to
run scripts and deploy small components and executables. It is an issue of
whether or not there should be a "core" rich shared runtime library that
allows production of very small exe's or dlls. Or, aternatively, a minimal
shared runtime library that requires "each" deployed DLL's and EXE's package
to contain or be bundled with the equivalent "core" runtime elements.

As I mentioned above, we could extend the facilities of our current system
to provide the alternative form of pre-jitting and tree-shaking [technically
this is the approach I came from in designing QKS' original Smalltalk
systems].


In designing SmallScript I intentionally opted for the former with the idea
that obtaining [and update management of] a ~1MB runtime library+scripting
system "once" was the preferred scenario with EXE's and DLL's being a few Kb
in size. As opposed to a scenario where the runtime library was 100Kb or so,
but where each of the resultant EXE's and DLL's were a couple hundred Kb in
size, and were not capable of being dynamically patched and updated to
reflect schema/class-method changes.

Assuming the above scenario, one can pretty quickly see a break-even point
between the two deployment approaches.

    1MB (once)   10-80kb (per deployed program/component)
 VS
    200Kb (once/maybe) + 100-300kb (per deployed program/component)

A purely seat of the pants discussion shows a break even at roughly 4-5
(programs or components). Noting that this is really and Apple and Oranges
comparison since this does not account for the fact that the 1MB runtime
includes the compiler and scripting libraries, Which means that it also
supports deployment or localized build from scripts which are typically
smaller than 10K.

Trading opcodes for native x86 for Win32 machine code did not seem to be a
desirable cross-platform goal. It is in direct opposition to principles
behind a shared runtime-architecture that ensures a rich common library.

I.e., we could throw out the compiler, the jitter(s), the rich shared
library. Resulting in runtime piece which would "not" allow general
scripting or modularized extensions with schema migration. And, that is,
again, in opposition to basic dynamic language (and Smalltalk) principles.

If (down the road) SmallScript offered such an option, the 100kb or so
runtime would just be bundled directly into the produced EXE or DLL
similarly to what I did on the original QKS Smalltalk for MacOS. And,
ironically, this is how I did the original SmallScript [circa 1999/2000]
bootstrap builds which were roughly 300kb in size for everything. Allowing
deployment, as I did on the MacOS product, of a single executable/binary
file. When I originally developed QKS's Mac product it was deployed [circa
1993] on a single floppy containing everything [gui, browser system,
libraries, interpreter VM, etc].

No dispute. But that misses the point of the script example.

Which is that in roughly

>
> Regards
>
> Blair
>
>
>

Frack. Fat fingers sent this before I was finished writing this.

... See the bottom of the previous message ...

"David Simmons" <[hidden email]> wrote in message
news:fucH8.65855$L76.95088@rwcrnsc53... contains
> > >      the elements necessary to execute #myAppsMain as the EXE's
> > entrypoint"
> > >
> >
> > I really don't think it would be that hard to write a Dolphin console
> > application that was able to act as a Smalltalk scripting engine using
> > traditional chunk format files. It certainly would not be as powerful
(or
> > fast) as Smallscript, but it could be done. As for writing the final
step,
> > well personally I would rather deploy my applications from within the
IDE.
>
> No dispute. But that misses the point of the script example.
>

Which is that in roughly 8 lines of code, within a single deployable file:

    Compiler cmds: '-target:exe'.
    Module name: MyApp
    {
        Class-method [<$entrypoint>
        myAppsMain
            Transcript show: 'Hello World'; cr.
        ]
    }

One can write and deploy an entire executable program using SmallScript's
source format [which is semantically just XML and therefore extensible].

Being able to write programs this easily in a pure text file form is what
scripting is about.

Obviously one can already produce Dolphin or VW headless VM (EXE or DLL)
deployment forms. But beyond that, there is a need to extend the language
source form to allow writing such a script. Which was the "real" point of
the example. Where the extensible scripting language already contains the
facilities to manage typical scripting and application building scenarios.
But, in classic Smalltalk, such a facility does not currently exist.

The closest one comes to what the SmallScript source form is offering, is to
use Smalltalk code as the scripting language, and write "scripts" in a
modified "SIF" format that can trigger code execution.

That's why, at Smalltalk Solutions 2002, I was asked by Alan Knight if it
made sense for VW to adopt a syntactically similar source form to
SmallScript's for use in just such headless Smalltalk scripting scenarios.

There are separate issues for scripting relating to the time it takes to
start-up, compile, execute, and shutdown a scripting engine. These are also
issues that SmallScript's system addresses, but which are currently too slow
in some other full EXE based Smalltalk's. The requirement here is to be
capable of processing and running scripts in times that are well under a
second and typically are measured in 10's of milliseconds.

I have not examined Dolphin 5 to see how it fares in this area, but I
suspect that unlike its contemporaries, it is quite fast at the start-up,
compile, execute, shutdown cycle.

-- Dave S. [www.smallscript.org]

"David Simmons" <[hidden email]> wrote in message
news:fucH8.65855$L76.95088@rwcrnsc53...
Yup. It's the same argument between whether to link against any DLL or to do
a static link.

It's interesting to note that statically linked option has been (and is
still I would guess, since I last used it in my youth) prevalent on Unix.
This might be because dynamic linking technology arrived late on that
platform, but has always been an integral part of Windows, but it is also
because it is simply more reliable in practice. I don't think we need to go
over all the arguments for and against dynamic linking in detail, but it
seems to basically boil down to a stability vs flexibility. There can be no
little doubt that a statically compiled executable will in practive be (a)
larger, and (b) more likely to continue to work over time as new
applications are installed. On the other hand one loses the ability to
update pieces of it. I think the latter capability definitely has merit in
an inherently robust dynamic/reflexive system like Smalltalk where one can
accomodate change, but in the static binary world of most compiled modules
replacing DLLs just tends to break old programs, and typically one has
little in the way of testing capability to give one any confidence that this
will not be so. For these reasons, though we still support the separate VM
based deployment mode and will continue to do so, we have made "ToGo"
(standalone .EXEs) the default, and even considered removing the option from
the UI to easily switch between ToGo and shared VM modes.

>
> >
> > An interesting experiment in Dolphin would be to use its plugin/Active-X
> DLL
> > technology to create a runtime support library (this time a VM and
> > pre-compiled image), and deploy minimal executables consisting of not
much
> > more than binary packages. This would, I suspect, produce very similar
> sizes
> > to those for the Smallscript exe/AOS dll combination.
>
> Indeed. This is something you and I have chatted about. It is the
mechanism
> behind SmallScript's modular component architecture.
>

Andy has talked about doing it for ages. Of course when he talks about doing
something rather than doing it anyway, it usually means he wants me to do it
instead :-). To get an idea of sizes our current plugin DLL (non-operational
since Microsoft withdrew support for the Netscape plugin API, but
nevertheless the nearest thing we have to a runtime support library that
could run minimal .exes) is 1091Kb. This includes the VM (i.e. it is an
image deployed in ToGo mode) and about 800 odd classes that make up the
complete base class hierarchy, MVP framework, COM/Active-X framework,
Sockets, ODBC, and a few other bits and pieces. The console hello world
package is about 709 bytes in binary form (1301 bytes if code signing is
used), so I would imagine it could be built into a very small .EXE when
combined with a little launching logic.

> > [blair wrote]
> > I suspect, though I have not measured it, that Smalltalk MT is capable
of
> > producing by far the smallest deployed application sizes if we include
the
> > runtime support library.
>
> Perhaps.
>
> But, when I last looked at MT, it does so by sacrificing capabilities for
> providing a feature complete Smalltalk "language" implementation. For
> various reasons, that was something I felt was the opposite of what was
> needed in a common dynamic language runtime VM.

That was also my feeling originally, but it may no longer be a fair
judgement. I agree with the sentiment, however.

>
> If the ~1MB runtime size of our shared common dynamic language runtime VM
> turns out to be larger than desireable, we may opt to provide the option
of
> "pre-jitting" the opcodes into native machine code for a particular CPU/OS
> [as MT does]. Followed by a tree-shaking to extract only the "used"
elements
> within the common library.

Right, but in that case your challenge is to better the Dolphin sizes (since
I know you like a challenge, and I'm pretty sure that you can).

> [re: Compiled binaries]
>...Such a
> deployment option would sacrifice the availability of the compiler,
general
> scripting, and a rich [guaranteed to be available] shared runtime library.

That need not necessarily be so at all. One could presumably choose to
deploy the compiler and any other bits. Certainly one could do that in
Dolphin. In effect that is precisely what the plugin DLL is, and it could be
deployed in executable form to act as a scripting engine or whatever, so I
don't see that you would have any difficulty doing the same.

> It would produce pre-jitted exe/dll programs that would be perhaps 2X
larger
> for the same code in comparison to non-pre-jitted ones we make today. But
> would also be distinctly larger for having to include the non-shareable
> pre-jitted library elements they required -- and that could typically be a
> couple of hundred kb.

Nevertheless I would urge you to consider it. Our experience has been that
our users are most interested in creating a simple and reliable installation
that includes everything that is needed, preferably as a single .EXE file.
One can understand this: The reality of Windows is that it is around in very
diverse configurations and god knows what will be on the end user machines.
Furthermore end-users will certainly install more software and this tends to
break other applications with external dependencies.

>
> The deployment issues are primarily a decision based on comparing
> download/file sizes for roughly 500kb one-time download with the ability
to
> run scripts and deploy small components and executables. It is an issue of
> whether or not there should be a "core" rich shared runtime library that
> allows production of very small exe's or dlls. Or, aternatively, a minimal
> shared runtime library that requires "each" deployed DLL's and EXE's
package
> to contain or be bundled with the equivalent "core" runtime elements.

I disagree. I would say that the primary decision is simplicity and
reliability of installation for the end-user, at least that is what most of
our developers seem to want. If you could guarantee that your runtime would
be on the end-user's machines then the keeping it separate would indeed be
preferable, but even then you would have versioning issues. In reality
unless Microsoft ship a DLL as part of the OS (or as part of IE, which I
understand is Spanish for "operating system upgrade" :-)) then there will be
a lot of "important" users without it on their machines. This even goes for
the C runtime libraries so there's not much hope for less, er, mainstream
languages. One has only to look at the problems one has with different
versions of the Java VM and class libraries to see that this approach is
very problematical in practice, particularly if the technology is
fundamentally new (or unstable) and is updated very rapidly.

>
> As I mentioned above, we could extend the facilities of our current system
> to provide the alternative form of pre-jitting and tree-shaking
[technically
> this is the approach I came from in designing QKS' original Smalltalk
> systems].
>

Why go for static compilation alone?

>
> In designing SmallScript I intentionally opted for the former with the
idea
> that obtaining [and update management of] a ~1MB runtime library+scripting
> system "once" was the preferred scenario with EXE's and DLL's being a few
Kb
> in size. As opposed to a scenario where the runtime library was 100Kb or
so,
> but where each of the resultant EXE's and DLL's were a couple hundred Kb
in
> size, and were not capable of being dynamically patched and updated to
> reflect schema/class-method changes.
>

As I say, I don't see that the latter need be precluded, in those cases
where it is wanted. It certainly need not be in a Dolphin app., though
obviously one needs to ship more runtime support to enable it.

> Assuming the above scenario, one can pretty quickly see a break-even point
> between the two deployment approaches.
>...

Yes, if the decision were purely based on the total file size.

> > ...[blair wrote]
> > I really don't think it would be that hard to write a Dolphin console
> > application that was able to act as a Smalltalk scripting engine using
> > traditional chunk format files. It certainly would not be as powerful
(or
> > fast) as Smallscript, but it could be done. As for writing the final
step,
> > well personally I would rather deploy my applications from within the
IDE.
I don't think it does miss the point because:
a) It isn't, to my mind, a scripting example, the end goal being the
deployment of an executable.
b) It would certainly not be such an elegant solution as your declarative
form, but one could feed a chunk script into the hypothetical Dolphin
scripting engine and have it deploy the a .EXE formed from the binary
representation of the loaded code and a small launcher stub.

If I'm understanding you correctly your point is that this capability does
not exist in the language, though it could exist in the library.

>
> The closest one comes to what the SmallScript source form is offering, is
to
> use Smalltalk code as the scripting language, and write "scripts" in a
> modified "SIF" format that can trigger code execution.

Well a chunk format script is not a declarative program form, and not
therefore particularly amenable to examination as a "model", but it could
certainly be used for scripting in the sense that it provides forms for
description of code and the ability to evaluate arbitrary expressions. Also
SIF _is_ a declarative program form, albeit one that looks unlikely to ever
be much used. As SIF includes the ability to support initializers, and it is
in any case extensible, I would have thought one could write scripts in it.

>
> That's why, at Smalltalk Solutions 2002, I was asked by Alan Knight if it
> made sense for VW to adopt a syntactically similar source form to
> SmallScript's for use in just such headless Smalltalk scripting scenarios.

I think it would make sense if there were a standard declarative form, which
was what SIF was supposed to be. I suppose the reason SIF never took off was
because it missed the XML bandwagon, and also of course because of
not-invented-here. We should perhaps pursue the adoption of AML as a
standard source form for Smalltalk, though I foresee total refusal from some
quarters, and from this quarter a reluctance to accept to many syntax
extensions :-).

>
> There are separate issues for scripting relating to the time it takes to
> start-up, compile, execute, and shutdown a scripting engine. These are
also
> issues that SmallScript's system addresses, but which are currently too
slow
> in some other full EXE based Smalltalk's. The requirement here is to be
> capable of processing and running scripts in times that are well under a
> second and typically are measured in 10's of milliseconds.
>
> I have not examined Dolphin 5 to see how it fares in this area, but I
> suspect that unlike its contemporaries, it is quite fast at the start-up,
> compile, execute, shutdown cycle.

My 7Mb development image loads in 156mS on my (admittedly very fast)
machine. To be clear this is the time taken to reconstruct the ObjectMemory
from the disk image, rather than the actual start up time for the
development image which is hard to measure. A little 500Kb Smalltalk
calculator app. (which is a mini-scripting engine in that it compiles and
runs Smalltalk expressions) will do the complete cycle in well under 100mS.
If anything the problem using Dolphin as a scripting engine would be the
speed of the compiler rather than the image load time.

What I'm trying to do here, Dave, is not just argue with you for the hell of
it (though it's fun, and I come from an argumentative family :-)). I cannot
leave unchallenged any assertion that a traditional Smalltalk system
fundamentally could not be used as a scripting engine, because it arrant
nonsense, but I'm more interested in getting to the crux of what *is* really
different and what *is* really great about Smallscript, one aspect of which
I think you touched on, but it remains rather nebulous for me, even if not
for others.

Regards

Blair