- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo-min?

by John M McIntosh

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(a)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(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

May 27, 2009

Re: [Pharo-project] Pharo-min?

by Gary Chambers

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(a)acm.org> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, May 27, 2009 5:42 PM Subject: Re: [Pharo-project] Pharo-min? > dmason(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 27, 2009

Re: [Pharo-project] Pharo-min?

by Michael Rueger

dmason(a)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

May 27, 2009

Re: [Pharo-project] New Pharo based on core 10318 with antialiased fonts

by Lukas Renggli

>> Running the "Seaside-Tests-*" Tests gives 2 Errors in >> WAContinuationTest (#testNestedWhileTrue and #testWhileTrue) [...] > > I'll look at this as I have another application that uses Seaside > continuations and one of its tests fails too. Â May be related. Don't worry, these are the Seaside tests that assume the broken Smalltalk-80 blocks. I think the tests were removed from the latest code, if not they should. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

May 27, 2009

Re: [Pharo-project] New Pharo based on core 10318 with antialiased fonts

by dmason＠mason-rose.ca

> For Seaside 29, I've tested in newest 10318 (dev build from Damien). > [...] > Running the "Seaside-Tests-*" Tests gives 2 Errors in > WAContinuationTest (#testNestedWhileTrue and #testWhileTrue) [...] I'll look at this as I have another application that uses Seaside continuations and one of its tests fails too. May be related. ../Dave

May 27, 2009

[Pharo-project] Pharo-min?

by dmason＠mason-rose.ca

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

May 27, 2009

[Pharo-project] Issue 832

by Gary Chambers

Performance of UI seems poor after 832 integration. http://code.google.com/p/pharo/issues/detail?id=832 Regards, Gary

May 27, 2009

Re: [Pharo-project] New Pharo based on core 10318 with antialiased fonts

by Damien Cassou

On Wed, May 27, 2009 at 3:37 PM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > Yes, installing ECompletionOmniBrowser Â before OCompletion should do > the trick. Could you please check Romain and tell me so that I can update the script? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 27, 2009

[Pharo-project] OCompletion feedback

by Henrik Johansen

First let me say, I love OCompletion, first time I've found completion in Smalltalk actually helpful! Here's a few things I found a bit of though: - Font for OCompletion inherits ECompletion's behaviour of being hardcoded (O(X)MenuMorph class >>messageFont/titleFont), would it be possible to change them to one of the settable font-preferences? (Balloon-help font f.ex.) - Suggestions do not seem to be case-sensitive, even if you use uppercase in your writing. (writing f.ex. Ope lists open) - Words you've fully written are still included in suggestion list. (f.ex. open) - If a new character excludes items in the suggestion list, they are removed, but entries not in the OCompletion cache (but in the extended list) are not added to suggestions. - Type in enough characters to make the cached suggetions empty, and the extended list becomes unavailiable... - If I select to write out the entire message name (say openMenuFor: ), then hit space, the entry is not added to top of OCompletion suggestions for "open". - Two above aren't very annoying, but as far as I can tell, combined they mean the only way to add new items to the OCompletion cache is if you select it from the extended list. Cheers, Henry

May 27, 2009

Re: [Pharo-project] Pharo and XML

by Alexandre Bergel

Hi Torsten, The work done by Michael is excellent. The parser works pretty well, even on big XML files. There is currently no support for XPath unfortunately. Pastell by Giovanni is a first step, but most of the test are red. I plan to put some work on Pastell in a few days. We could do it together if you wish. XMLParserTest is a collection of simple and small tests that run out of the box. No need of external files as the XML testing package requires as far as I remember. Cheers, Alexandre On 27 May 2009, at 09:17, Torsten Bergmann wrote: > What's the status of XML support for pharo? Anyone tested if > old (squeak) parsers work and what about xpath? > > > @Alexandre: > Whats the reason to put class "XMLParserTest" (a unit test) > into the parser package instead of the XML testing package? > (see XML-Parser-AlexandreBergel.15.mcz on 'http://www.squeaksource.com/XMLSupport') > > Thx > T. > > > > > -- > Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + > Telefonanschluss fÃ¼r nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 27, 2009