From: Conrad Schneiker Date: 2001-04-24T14:11:25+09:00 Subject: [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" wrote in message > news:k1e2i3t4h5r6a7y-D8B8D8.09114419042001@news... > > In article , "Chris > > Gonnerman" wrote: > > > > > ----- Original Message ----- > > > From: "Andrew Dalke" > > > 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 > > > > > > 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. > > > > -- > > -- Conrad Schneiker (This note is unofficial and subject to improvement without notice.)