[Pharo-project] Pharo-min?
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
dmason@mason-rose.ca 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
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" <m.rueger@acm.org> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, May 27, 2009 5:42 PM Subject: Re: [Pharo-project] Pharo-min?
dmason@mason-rose.ca 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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, dmason@mason-rose.ca 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 <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
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, dmason@mason-rose.ca 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
dmason＠mason-rose.ca -
Gary Chambers -
John M McIntosh -
Michael Rueger -
Stéphane Ducasse