[ruby-talk:14138] Re: python on the smalltalk VM

FYI: Thought this might be of interest to the JRuby and Ruby/GUI folks.

What caught my eye was:

> > 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}

Can anyone shed light on the last sentence?

David Simmons wrote:
> 
> 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@1m2a3c4.5c6o7m> wrote in message
> news:k1e2i3t4h5r6a7y-D8B8D8.09114419042001@news...
> > In article <[e-mail]>, "Chris
> > Gonnerman" <[e-mail]> wrote:
> >
> > > ----- Original Message -----
> > > From: "Andrew Dalke" <[e-mail]>
> > > 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>


-- 
Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)