python on the smalltalk VM

[David Simmons]

Hi Folks,

Let me clarify a few things (noting that similar information will be
available sometime next week on the new www.smallscript.net site
specifically on SmallScript and .NET).

o   SmallScript is a "superset" of existing dynamic language Smalltalk
dialects (not a subset as was commented in quoted pages from
SmalltalkConsulting). As was noted from the postings, SmallScript is not an
IDE. It is a new language that extends existing Smalltalk language
facilities. Its goals and technical foundations are derived from my
experience over the last 10 years in developing QKS Smalltalk, virtual
machines, cross platform frameworks, and (SmalltalkAgents) IDE technology.

o   SmallScript is *not* a superset (in any way) of existing Smalltalk
frameworks -- which is where the superset/subset confusion probably comes
from. It is a language and the required core/kernel framework to represent
the universal object model, the SmallScript language, and the facilities
needed to support the module linker/loader and compiler services.

o   The release date for a first public review version was changed from
December of 2000 to July of 2001.

o   Smalltalkers should think about SmallScript as being a modular Smalltalk
with many language extensions to support a wide range of features found in
other popular languages which are not typically found in Smalltalk dialects.
For those who have followed the evolution of QKS Smalltalk many of these
features will be familiar. Many of these extended features are just exposing
the AOS (Agents Object System) Platform's object model and metaprogramming
and reflection facilities.

o   The AOS Platform execution engine, core object-model/language
frameworks, and a corresponding SmallScript compiler will be free. The
Microsoft.NET platform version of the SmallScript compiler and related .NET
dynamic/scripting language libraries for .NET deployment will not be free.
The .NET version will be available in a bundle with Microsoft's Visual
Studio 7.

o   QKS will have other frameworks and probably one or more sets of tools
for working with SmallScript. The "free" vs "commercially sold and
maintained" status of these additional elements will be determined on a case
by case basis. My personal goal is to foster community growth of the basic
frameworks and services (including redundant/overlapping implementations).
QKS commercial focus is primarily on vertical frameworks / domain specific
frameworks (which may include the broad generic market for Microsoft.NET
tools).

o   The SmallScript language is layered on top of a (unnamed) declarative
XML language that reflects the AOS object model (basically it is simpler to
view the XML language as part of SmallScript). As such, other languages can
be implemented using the core frameworks parser and compilation frameworks.
Work is being done in this area for Scheme, Python, and interest has been
expressed for Basic, JScript/EcmaScript, and PHP. One of the notable
features of this facility is the ability to write methods directly in
SmallScript that consist of C, C++, and assembly -- hence there are *no*
primitives.

o   The AOS Platform (v4) is a small, shared library execution engine with a
hi-performance extensible jit architecture supporting a universal object
model. The AOS Platform (v4) will be available for Win32 x86, Linux x86, and
MacOSX PPC (other platforms are possible). The entire SmallScript system
including compiler and frameworks can be deployed as a single DLL (on Win32)
that is about 800kb that number includes its' 400kb or so of resources. The
execution architecture is designed to support adaptive installation so it
can be drag-installed or run directly without requiring any installation
procedure (it has a variety of features to support integration into COM and
automatic exposure of any class or object as a component -- theoretically
this should be mappable to CORBA as well).

The shared library model allows SmallScript code or similarly generated AOS
code modules to be executed inside of existing processes and automatically
integrates with the native pre-emptive threading model. Typical (total)
execution time from launch to exit (including simple script compilation and
execution) is on the order of 35-80ms depending on disk drive speed and
processor speed.  The smallest executable application one can produce using
SmallScript on Win32 is something on the order 60 or so bytes of x86 machine
code in the form of a couple kb .EXE file.

Typical asynchronous foreign function calling (in or out) is measured in
10's of millions of calls per/second including the dynamic/adaptive
marshalling and exception management for calling through mechanisms such as
COM/ActiveX, etc (which the JIT optimizes). The AOS platform's object model
supports dynamic languages and typing that includes a full type
architecture, concrete and abstract interfaces (mixins), namespaces,
closures, continuations, unified string/character model (for
NLS/Unicode/CodePages/etc), and multi-method dispatch (method selection
based on type overloading of arguments).

** The comments on the compilation of large Smalltalk images are based on
numbers taken from builds of the kernel system and auxilliary modules. The
SmallScript compilation+module build rate is somewhere around 1 million
lines per minute; numbers are significantly higher for just processing
object model code or generating parse trees for syntax coloring. The
SmallScript compiler is written in (itself) SmallScript.

-- Dave Simmons
QKS Smalltalk - SmallScript

"Keith Ray" <k1e2i3t4h5r6a7y at 1m2a3c4.5c6o7m> wrote in message
news:k1e2i3t4h5r6a7y-D8B8D8.09114419042001 at news...
> In article <mailman.987684754.31126.python-list at python.org>, "Chris
> Gonnerman" <chris.gonnerman at usa.net> wrote:
>
> > ----- Original Message -----
> > From: "Andrew Dalke" <dalke at acm.org>
> > Subject: python on the smalltalk VM
> >
> >
> > >
http://www.smalltalkconsulting.com/html/SmalltalkSolutions2001%232.html
> >
> > This URL appears dead to me... is there an alternate location?
>
> I don't have a problem loading the URL
> <http://www.smalltalkconsulting.com/html/SmalltalkSolutions2001%232.html>
>
> Here is a snippet from that page:
>
> After the break I attended the Building COM and .NET in SmallScript  by
> David Simmons for a few minutes
>
> About 70 people in attendence. Standing room only.
>
> David talked about his Smallscript goals, he then launched into an
> explanation of how Smallscript is build by showing us the source code.
> If you were a Microsoft developer this would have been very interesting,
> and it is interesting to see how it all interfaced to the existing MS
> framework for development.
>
> David's take is that Smalltalk is built wrong for scripting, it has a
> monolithic image. It really should be a bunch of Smalltalk pieces.
> Smallscript isn't a Smalltalk traditional image. It's the best features
> of the language but changed for doing scripting.
>
> SmallScript is small, it is free, it's not an IDE. It's a compiler and
> execution engine. Someone else needs to build an IDE and frameworks, QKS
> may build a simple IDE but these aren't an important part of their
> research. Smallscript like all scripting languages is text based just
> tackle it with your emac editor.
>
> Someone asked what is the revenue model for QKS?
> It's not tools (We all know that today, look around how many tools
> companies are there?)
> Consulting is a big part
> Microsoft is a big part.
> Python is a big part for the execution engine, this is a new area. The
> Smalltalk VM runs Python 10 to 100x faster. {JMM I should point out the
> Perl and Python folks are working toward having/wanting/needing a
> universal VM}
>
> SmallScript is subset of Smalltalk dialects, not of the frameworks. You
> can migrate frameworks, and it has a lot of features for foreign
> function interoperability.
>
> David then moved on within his slides and talked about the files you
> need to support Smallscript. The point being there are only a few small
> files required.
>
> He then brought up the VisualStudio project for building this and
> explained how the VM starts and worked us thru what happens when the VM
> launches. The execution path is very short and took about 85ms on this
> machine, thus 12 executions a second. A more optimized VM, this was a
> test VM, would run faster. However David pointed out on a heavier loaded
> machine you could have at least a 30ms variation in startup times
> because of system load. But the key point here was that you can run a
> lot of individual scripts per second if required.
>
> Later at lunch David pointed out that perhaps it wasn't clear in the
> presentation that the entire image is built from the class definitions
> at startup, there is NO image. It's all built from the definitions
> really really fast. On termination a module can decide if it must save a
> persistent state, which could be loaded on restarting. In fact If I
> recall correctly he say that a rather large smalltalk image would be
> built by the engine in less than 6 seconds. From nothing to a known
> state on each startup, this is a important concept.
>
> On-ware to DLL hell, well maybe not. .Net get out of this problem
> domain. Components are self describing and have versioning which allows
> you to resolve all the requirements to run an application and to move
> things around without harming the application. Smallscript allows you to
> build small DLLS which are compiled very quickly. Smallscript takes the
> strengths of Smalltalk, it's a simple grammar it's untyped. And it's
> easy to refactor and change versus C or C++. In Smalltalk it was hard to
> deal with the outside, handing a Smalltalk object to an external DLL
> is/was an adventure. In .Net it just gets passed, no wrapping or
> marshalling etc.
>
> Alas at this point I had an errand to run.
>
> --
>        <http://homepage.mac.com/keithray/resume.html>