Sorry if this is seen as off-topic, as I realize the goal is to get
Pharo-1.0 out the door, but I'm evaluating Pharo as the base for a potentially huge application. I'm interested in building a minimum image from a Pharo-core base. This image would have: - no GUI/mouse/keyboard. The only interface would be via network connections. - no processes/interrupts. The network send/receive would be synchronous via a plugin. - no timer. The date/time would be via a plugin on demand. - no fallback debugger. Any error fallback would log a message and abort via a plugin. - possibly a minimal interpreter that didn't include any support for those unavailable features. (The only value in this would be smaller size and hopefully something more comprehensible for code auditing purposes.) Why bother with Squeak/Pharo/Smalltalk at all, some may ask? I need a very reliable, *very* efficient, *very* powerful deployment platform, and at the same time a *very* powerful development environment so we can stay nimble. The proposed alternative is Java, which meets the points except on efficiency and development fronts. I've also been involved in a somewhat similar-scale project in the past, but the overwhelm of 100+k lines of Java code really bogged us down in the end. I'll look at GNU Smalltalk too, for deployment, but I'd *really* like to be running the identical code in development, test and production. Any gotchas? Any suggestions/hints? Just to tweak your interest further, the deployment platform would be z/OS running on IBM big iron! ../Dave _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
[hidden email] wrote:
> I'm interested in building a minimum image from a Pharo-core base. This > image would have: > > - no GUI/mouse/keyboard. The only interface would be via network connections. > > - no processes/interrupts. The network send/receive would be synchronous via a plugin. > > - no timer. The date/time would be via a plugin on demand. > > - no fallback debugger. Any error fallback would log a message and abort via a plugin. > > - possibly a minimal interpreter that didn't include any support for > those unavailable features. (The only value in this would be smaller > size and hopefully something more comprehensible for code auditing > purposes.) Part of this is already covered by Pavel's minimal morphic/image work. - no timer there is a difference between date/time and the delay/timing framework in the VM. Removing the latter could be "interesting" Everything else you could basically do by creating new Socket classes, changing default error handling etc. Although I'm not quite sure what you would gain from not using the green threads in Squeak/Pharo? Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Maybe Pharo 2.0 could be refactored like this, enough to do to get to V 1.0
though ;-) Regards, Gary ----- Original Message ----- From: "Michael Rueger" <[hidden email]> To: <[hidden email]> Sent: Wednesday, May 27, 2009 5:42 PM Subject: Re: [Pharo-project] Pharo-min? > [hidden email] wrote: > >> I'm interested in building a minimum image from a Pharo-core base. This >> image would have: >> >> - no GUI/mouse/keyboard. The only interface would be via network >> connections. >> >> - no processes/interrupts. The network send/receive would be synchronous >> via a plugin. >> >> - no timer. The date/time would be via a plugin on demand. >> >> - no fallback debugger. Any error fallback would log a message and abort >> via a plugin. >> >> - possibly a minimal interpreter that didn't include any support for >> those unavailable features. (The only value in this would be smaller >> size and hopefully something more comprehensible for code auditing >> purposes.) > > Part of this is already covered by Pavel's minimal morphic/image work. > > - no timer > there is a difference between date/time and the delay/timing framework > in the VM. Removing the latter could be "interesting" > > Everything else you could basically do by creating new Socket classes, > changing default error handling etc. > Although I'm not quite sure what you would gain from not using the green > threads in Squeak/Pharo? > > > Michael > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Dave Mason-3
I have to ask how big an image/vm footprint?
You should consider the work Craig Latta is doing. 10 years back I build some VMs for Dan who supplied some mini images that targeted a total ram memory foot print of 1MB for the image and the VM. On 27-May-09, at 9:33 AM, [hidden email] wrote: > Sorry if this is seen as off-topic, as I realize the goal is to get > Pharo-1.0 out the door, but I'm evaluating Pharo as the base for a > potentially huge application. -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Dave Mason-3
Dave I will not say the same as john.
I know that people at IBM run Squeak (full environemnt in MVC in 1.7 mb). Now from a pharo perspective we would be **really** interested to integrate changes that you would provide to make the shrinking. Ideally I would like to have a core without compiler and just the core and a loading of byte code. So any step in that direction is of interest for us. Stef On May 27, 2009, at 6:33 PM, [hidden email] wrote: > Sorry if this is seen as off-topic, as I realize the goal is to get > Pharo-1.0 out the door, but I'm evaluating Pharo as the base for a > potentially huge application. > > I'm interested in building a minimum image from a Pharo-core base. > This > image would have: > > - no GUI/mouse/keyboard. The only interface would be via network > connections. > > - no processes/interrupts. The network send/receive would be > synchronous via a plugin. > > - no timer. The date/time would be via a plugin on demand. > > - no fallback debugger. Any error fallback would log a message and > abort via a plugin. > > - possibly a minimal interpreter that didn't include any support for > those unavailable features. (The only value in this would be smaller > size and hopefully something more comprehensible for code auditing > purposes.) > > Why bother with Squeak/Pharo/Smalltalk at all, some may ask? I need a > very reliable, *very* efficient, *very* powerful deployment platform, > and at the same time a *very* powerful development environment so we > can > stay nimble. The proposed alternative is Java, which meets the points > except on efficiency and development fronts. I've also been > involved in > a somewhat similar-scale project in the past, but the overwhelm of > 100+k > lines of Java code really bogged us down in the end. I'll look at GNU > Smalltalk too, for deployment, but I'd *really* like to be running the > identical code in development, test and production. > > Any gotchas? Any suggestions/hints? > > Just to tweak your interest further, the deployment platform would be > z/OS running on IBM big iron! > > ../Dave > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |