May 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SLICE-RelicensingPart1

by Nicolas Cellier

Please remove the upper limit, I think this was a pre-internationalization method which should have been updated but was not because not used. For the lower limit, (CharacterTable at: anInteger + 1) in #value: already does the job of signalling the out of bound error, but yes, translation of the codePoint with this + 1 might be troubling. My POV is this one: Since #value: is responsible of possible mis-interpretation, #value: should handle disambiguation of the Error. That is a kind of encapsulation. I suggest error report be moved in #value:, not in every sender of #value: On the other hand, the test could eventually be omitted for efficiency reasons. Though, if efficiency really matters, I would rather see Character becoming immediate. Nicolas 2009/5/27 Alexandre Bergel <alexandre(a)bergel.eu>: > Yes, with a negative argument. > Adding the check: > Â (0 > integer or: [255 < integer]) > ifTrue: [self error: 'parameter out of range 0..255']. > is probably enough. > Alexandre > > > On 27 May 2009, at 08:27, Gabriel Cotelli wrote: > > The ANSI Specification doesn't mention anything about that the integer must > be in some range... the only thing that expects is that (Character > codePoint: x) codePoint = x .... > > anyway... I can add the verification... but that's not specified in the > ANSI... anybody knowns some senders of this? I checked Pharo-Dev and found > none.. maybe in the Web Image? > > Alexandre, how you obtain an error using value: ? given a negative argument? > I tried with values greater than 255 and works in my image... > > Tonight I check that > > 2009/5/27 Alexandre Bergel <Alexandre.Bergel(a)inria.fr> > I went through all the changes proposed by this slice. I am not sure how > should I review the code, but here is my try: > - the new version of Character class>>codePoint: anInteger seems to have a > different behavior: > The old (current) code is > codePoint: integer > "Return a character whose encoding value is integer." > #Fundmntl. > (0 > integer or: [255 < integer]) > ifTrue: [self error: 'parameter out of range 0..255']. > ^ CharacterTable at: integer + 1 > The new one is: > codePoint: anInteger > "Just for ANSI Compliance" > ^self value: anInteger > value: anInteger > "Answer the Character whose value is anInteger." > anInteger > 255 ifTrue: [^self basicNew setValue: anInteger]. > ^ CharacterTable at: anInteger + 1. > At the end an error is raised, but this is not the same. > Was this review useful? > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre BergelÂ Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre BergelÂ Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > 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] New Pharo based on core 10318 with antialiased fonts

by Nicolas Chillo

Hi. I recently download the new 10318 development image and it seems the OBTextSelection>>isClassNode MNU is not fixed yet. (See http://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008782.html) I just want to remind it for you to fix it because it would be a really pity to release a version with such a silly error. Thanks and excellent work. Nicolas On Wed, May 27, 2009 at 12:59 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > 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 > > _______________________________________________ > 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] Issue 832

by Schwab,Wilhelm K

Stef, That would be nice for a temporary measure at least, because the performance really has suffered. Assuming you roll back, would it be enough to update my 10303 image? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Wednesday, May 27, 2009 12:44 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Issue 832 Thanks for reporting. Henrik? I could rollback the changes. Stef On May 27, 2009, at 6:25 PM, Gary Chambers wrote: > Performance of UI seems poor after 832 integration. > > http://code.google.com/p/pharo/issues/detail?id=832 > > Regards, Gary > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ 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 StÃ©phane Ducasse

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(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. > > 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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 27, 2009

Re: [Pharo-project] Issue 832

by StÃ©phane Ducasse

Thanks for reporting. Henrik? I could rollback the changes. Stef On May 27, 2009, at 6:25 PM, Gary Chambers wrote: > Performance of UI seems poor after 832 integration. > > http://code.google.com/p/pharo/issues/detail?id=832 > > Regards, Gary > > _______________________________________________ > 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 and XML

by StÃ©phane Ducasse

The problem with the tests of mike is that they required external files and so I do not know if they were run. Stef On May 27, 2009, at 4:35 PM, Alexandre Bergel wrote: > 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 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