August 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Discussion summary and milestones

by bryce＠kampjes.demon.co.uk

StÃ©phane Ducasse writes: > > >> The stack interpreter and closures are two distinct things: > >> closures are one things (some primitives, > >> some compiler changes). This we should integrate ASAP (then we can > >> port the newcompiler to emit this > >> closure code). So Closures is in milestone 1, definitely. > > It means that we should then produce our own VMs I imagine. So what > are the plans there? > - how do we generate them? Mathieu can build the mac one, bryce can > you build a linux one? I can build the Linux one. Though, if I'm to keep doing it for more than just one or two, I'd like to use the same VM as Exupery does. That may pose some problems with Eliot's stack work. The stack work would require a large amount of rework in Exupery to make it compatible, basically the same work Eliot did on the VM but redone inside Exupery. Given the gains advertised the stack work isn't worthwhile stopping Exupery 1.0 development to support. The closures work should be easier, just a few bytecodes, basically the same as adding proper support for the closure compiler. Though I'm not sure what the benefits of Eliot's work over the closure compiler are if you're going to use the NewCompiler. > - how do we keep the files (do we have to have our own svn)? > > May be we should do a call, stating that we would like to integrate > the primitives and closure code > into squeak but need vms support. Bryce

Aug. 31, 2008

[Pharo-project] About RSS links

by Stefan Schmiedl

Currently http://code.google.com/p/pharo/ tersely states Feeds * http://www.squeaksource.com/Pharo/feed.rss * http://www.squeaksource.com/PharoInbox/feed.rss Maybe somebody could add a few words explaining what's in these feeds and how they differ? Who's the audience? Thanks, s.

Aug. 31, 2008

[Pharo-project] Fwd: [squeak-dev] SqNumberParser refactoring

by StÃ©phane Ducasse

Begin forwarded message: > From: nicolas cellier <ncellier(a)ifrance.com> > Date: August 31, 2008 4:46:31 AM CEDT > To: squeak-dev(a)lists.squeakfoundation.org > Subject: [squeak-dev] SqNumberParser refactoring > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > SqNumberParser speed up has been introduced a little prematurely in > 3.10.1 image. I uploaded correction for a detail at http://bugs.squeak.org/view.php?id=6976 > > Now all the tests parsing gradual underflow Float should pass again > (round to the nearest Float as was the case before the speed up). > > That's quite some time i spent correcting my own bugs with this > SqNumberParser! > - http://bugs.squeak.org/view.php?id=6976 speed up (harvested in > 3.10.1) > introduced the bug described above > - http://bugs.squeak.org/view.php?id=6982 (not harvested) > had a typo > - http://bugs.squeak.org/view.php?id=3512 (harvested in 3.9) > introduced a bug in ScaledDecimal parsing > (see http://bugs.squeak.org/view.php?id=7169) > - http://bugs.squeak.org/view.php?id=6779 (in minor fix unstable 3.10) > duplicated this bug in another method > so did http://bugs.squeak.org/view.php?id=6982 > > Sorry for inconvenience (don't think any user but me bumped into > these problems however, given that Number readFrom: is far worse > w.r.t. nearest Float, and is still the official Number reader in the > image). > Sorry for flooding maintainers too (I think the impact is bigger). > > Looking at my own code i saw code duplications, not enough comment, > typos in comments. > Some will find that using inst var to save some of the parser state > is tricky, but that's another subject (Scanner and parser do the > same). This is the cost of efficiency. And that's why comments are > necessary. > > Anyway, i refactored a bit, cleaned duplications, added comments, > and added more speed again for LargeInteger using same kind of > divide and conquer trick as http://bugs.squeak.org/view.php?id=6887 > (more in another post) > > All my tests are green. Now, i have a problem for publishing in > mantis. Since the refactoring does interfere with a lot of already > published patches some harvested, some not, some on the way to be > harvested, It might create some problems for harvesters (load order > of Installer mantis ensureFix:). > > I like the small change sets for they can be adopted independantly > in several distributions, but there Monticello might be more > appropriated. > > What do you suggest? > > >

Aug. 31, 2008

[Pharo-project] Fwd: [squeak-dev] Number readFrom: can we remove some "accidental" features

by StÃ©phane Ducasse

Begin forwarded message: > From: nicolas cellier <ncellier(a)ifrance.com> > Date: August 31, 2008 2:13:10 AM CEDT > To: squeak-dev(a)lists.squeakfoundation.org > Subject: [squeak-dev] Number readFrom: can we remove some > "accidental" features > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > > Strangely, Squeak Number class>>#readfrom: used to accept non > Smalltalk syntax like: > (Number readFrom: '.2') -> 0.2 . > (Number readFrom: '2.e3') -> 2000.0 . > > (See http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/103137.ht…) > > Don't know if accidental or on purpose, but to me, this is wrong and > I did not implement this behavior in SqNumberParser because there is > no such official Smalltalk syntax to my knowledge. > > Up to any one to accept an alternate number syntax by subclassing > SqNumberParser. > > Now I see that Dave Lewis (dtl) asserted this feature: > > testAsNumberWithSuperfluousDecimalPoint > | sd | > sd _ '123.s2' asNumber. > self assert: ScaledDecimal == sd class. > self assert: sd scale == 2. > self assert: '123.00s2' = sd printString. > > I'd like to remove this feature. > Is it ok? > > >

Aug. 31, 2008

Re: [Pharo-project] Discussion summary and milestones

by StÃ©phane Ducasse

>> The stack interpreter and closures are two distinct things: >> closures are one things (some primitives, >> some compiler changes). This we should integrate ASAP (then we can >> port the newcompiler to emit this >> closure code). So Closures is in milestone 1, definitely. It means that we should then produce our own VMs I imagine. So what are the plans there? - how do we generate them? Mathieu can build the mac one, bryce can you build a linux one? - how do we keep the files (do we have to have our own svn)? May be we should do a call, stating that we would like to integrate the primitives and closure code into squeak but need vms support. Stef

Aug. 31, 2008

Re: [Pharo-project] Discussion summary and milestones

by StÃ©phane Ducasse

yes this was the idea On Aug 30, 2008, at 5:27 PM, Hilaire Fernandes wrote: > 2008/8/30 Marcus Denker <denker(a)iam.unibe.ch>: > >>> For milestone 2 >>> ------------------- >>> - GTK binding >> >> Optional or replacing morphic? > > > Don't run too fast to kill Morphic. > There are a lot of value in Morphic and GTK+ is not a replacement for > it, more an alternative for different purpose. > Sure it need clean up. > > Hilaire > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 31, 2008

Re: [Pharo-project] Discussion summary and milestones

by StÃ©phane Ducasse

>> > > The stack interpreter and closures are two distinct things: closures > are one things (some primitives, > some compiler changes). This we should integrate ASAP (then we can > port the newcompiler to emit this > closure code). So Closures is in milestone 1, definitely. > > The stack-stuff is an interpreter that uses the C-Stack. This is not > yet released (10-20% faster the current vm). > It will be released soon, thus it likely can be in milestone 1, too. Ok I was confused. >> For milestone 2 >> ------------------- >> - GTK binding > > Optional or replacing morphic? I do not think that it is resonnable to replace morphic. because morphic (a clean version is still important for lot of people). Stef

Aug. 31, 2008

Re: [Pharo-project] Discussion summary and milestones

by Gwenael Casaccio

On 30 Aug 2008, at 18:35, Serge Stinckwich wrote: > 2008/8/30 Hilaire Fernandes <hilaire(a)ofset.org>: >> 2008/8/30 Marcus Denker <denker(a)iam.unibe.ch>: >> >>>> For milestone 2 >>>> ------------------- >>>> - GTK binding >>> >>> Optional or replacing morphic? >> >> >> Don't run too fast to kill Morphic. >> There are a lot of value in Morphic and GTK+ is not a replacement for >> it, more an alternative for different purpose. > > And with the work of Gary, Morphs are looking much better ;-) > GTK is great have to better acceptance by non-smalltalkers but it's a > bit premature to switch to GTK. > I have discussed with Gary and may be he will port the Squeak canvas to support the cairo canvas so it will be possible to have Gtk and Morphs Gwenael Casaccio

Aug. 30, 2008

Re: [Pharo-project] Discussion summary and milestones

by Serge Stinckwich

2008/8/30 Hilaire Fernandes <hilaire(a)ofset.org>: > 2008/8/30 Marcus Denker <denker(a)iam.unibe.ch>: > >>> For milestone 2 >>> ------------------- >>> - GTK binding >> >> Optional or replacing morphic? > > > Don't run too fast to kill Morphic. > There are a lot of value in Morphic and GTK+ is not a replacement for > it, more an alternative for different purpose. And with the work of Gary, Morphs are looking much better ;-) GTK is great have to better acceptance by non-smalltalkers but it's a bit premature to switch to GTK. -- Serge Stinckwich Smalltalkers do: [:it | All with: Class, (And love: it)] http://blog.doesnotunderstand.org/

Aug. 30, 2008

Re: [Pharo-project] Discussion summary and milestones

by Hilaire Fernandes

2008/8/30 Marcus Denker <denker(a)iam.unibe.ch>: >> For milestone 2 >> ------------------- >> - GTK binding > > Optional or replacing morphic? Don't run too fast to kill Morphic. There are a lot of value in Morphic and GTK+ is not a replacement for it, more an alternative for different purpose. Sure it need clean up. Hilaire

Aug. 30, 2008