December 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Linux VM with IA32ABI plugin (Alien)

by Luc Fabresse

Effectively, I only tried with the squeak VM on linux. Sorry, I will also try with the cog one. Thanks Eliot! #Luc 2010/12/10 Eliot Miranda <eliot.miranda(a)gmail.com> > > > On Fri, Dec 10, 2010 at 2:49 AM, Luc Fabresse <luc.fabresse(a)gmail.com>wrote: > >> Hi all, >> >> I know that someone already manage to compile linux (squeak or cog) VM >> with Alien support (plugin I32ABI). >> Could someone, send me an already compiled VM? ;-) >> >> BTW, why the compiled linux VM available for download does not include >> this plugin? >> > > let me try again :) > > I'm pretty sure the plugin is present and internal in the Cog linux VM on > my site. > > cheers > Eliot > > >> Thanks, >> >> #Luc >> > >

Dec. 10, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Eliot Miranda

2010/12/10 Levente Uzonyi <leves(a)elte.hu> > On Fri, 10 Dec 2010, Eliot Miranda wrote: > > Hi Levente, >> >> 2010/12/9 Levente Uzonyi <leves(a)elte.hu> >> >> On Thu, 9 Dec 2010, StÃ©phane Ducasse wrote: >>> >>> It does! >>> >>>> It seems that you did not work in VW2.5 and 3.0 and when parcels >>>>>>>> arrived loading was realllllly a big difference >>>>>>>> I do not see why this would not the same with Fuel. >>>>>>>> >>>>>>>> >>>>>>> No I didn't, but the version number of VW is around 7.x now, so I >>>>>>> guess >>>>>>> the CPUs and VMs are now several times faster. Does it really matter >>>>>>> if it >>>>>>> takes 200ms or 20ms to load a package? >>>>>>> >>>>>>> >>>>>> When I load a package with MC so far I still notice it and I would not >>>>>> even think about it. >>>>>> It should load in a unnoticeable amount of time. >>>>>> >>>>>> >>>>> Do you think MC is "slow" because the Compiler is "slow"? >>>>> >>>>> >>>> not totally but I do not understand why this is obligatory to compile >>>> everything all the time. >>>> Then Opal will be slower than the old comcrapiler. >>>> >>>> >>>> I did a quick test where it took 4294ms to load RoelTyper + OCompletion >>> from disk (no socket creation, no network latency, etc). These packages >>> contain 790 methods. 5.1% of the total time was spent for compilation, >>> that's 219ms. The rest is used by other stuff like: >>> - loading the files from disk >>> - writing the source code to disk (sources/changes files) >>> - evaluating class side #initialize methods >>> - processing system change notifications >>> >>> Another 51ms was spent in creating 63 classes and 107ms to install the >>> CompiledMethods to the classes. So that's 219+51+107 = 377ms for creating >>> all classes and their methods. The rest is administration which can not >>> be >>> avoided by binary loading. >>> >>> Even if binary loading is 10x faster than compiling the code (which I >>> doubt), then you save 339ms. So it would take only 3917ms to load these >>> packages. That would save you 7.9% of the total time. >>> >>> >> One of the important features of the VW parcels work is that one does not >> write the source code to the changes file. Instead teh system has a >> SourceFileManager that works like a dictionary mapping file indices to >> source files, so instead of the two element SourceFileArray one has an >> arbitrarily large collection of files. When a parcel file is loaded its >> source file is added to the SFM which returns an index and then all the >> file >> pointers in the methods in the parcel are swizzled to refer to their >> sources' position in their files' index. We changed the format of file >> pointers so something resembling four floating-point formats so we can >> have >> lots of small files (more space for file indices) and a few large files >> (more space for file offsets) before one overflows into large integer file >> pointers. >> >> Now Igor's trailer work makes this approach feasible but one wouldn't need >> the funky floating-point format stuff because one could easily allocate, >> say, 5 bytes to the file pointer, two for the file index for a maximum of >> 64k source files, and 3 for the file offset for a maximum of 16m of source >> per parcel source file (I think splitting the 40 bits as 14:26 might be >> better but that's details). One needs to predetermine the size of the >> file >> pointer so that the trailer can be modified in place since changing the >> length of a trailer means allocating a new comp[iled method and that will >> be >> slow. >> >> If this approach is taken how much does that change your analysis? >> > > Writing the sources takes 1.6% of total time according to MessageTally. > Significant amount of time is spent in finalization (12.8%) and GCs (15%). > But note that MessageTally is not reliable nowadays. > > > >> Note that not writing source to the changes file has ancilliary benefits; >> change recovery is now not polluted with package loads and the changes >> file >> does not grow as packages are added, only as one's changes are made. >> Unloading a package doesn't leave garbage in the changes files. >> >> There are downsides. Deploying a development image means deploying all >> the >> associated parcel source files as well, and for this a >> platform-independent >> Filename abstraction really helps. >> > > Thanks for the explanation. I wonder how the previous versions of a method > can be found using parcels. > I hacked a dreadful implementation of overrides in vw3.0 and I don't think things are much better now. But in http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg17714.ht… sketched how I think it should be done: Maintain a global package load order (a stack of loaded packages, removing interior elements on unload). Maintain a dictionary from method reference to set of package/method pairs for each method that is overridden. When a package is removed search overrides and compute the overridden methods to be reinstalled, computing the uppermost method depending on the new package order. So to answer your question, one finds the previous versions directly in the overrides dictionary, and sorts the results according to the current package load order. best Eliot > > > Levente > > >> best >> Eliot >> >> >> >>> Levente >>> >>

Dec. 10, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Levente Uzonyi

On Fri, 10 Dec 2010, Mariano Martinez Peck wrote: >> If this approach is taken how much does that change your analysis? >>> >> > >> But note that MessageTally is not reliable nowadays. >> >> >> > Why ? since when ? It's like this since a long time, but it seems to be worse with Cog. See http://bugs.squeak.org/view.php?id=7515 for details. Levente > > > > > >> >>> Note that not writing source to the changes file has ancilliary benefits; >>> change recovery is now not polluted with package loads and the changes >>> file >>> does not grow as packages are added, only as one's changes are made. >>> Unloading a package doesn't leave garbage in the changes files. >>> >>> There are downsides. Deploying a development image means deploying all >>> the >>> associated parcel source files as well, and for this a >>> platform-independent >>> Filename abstraction really helps. >>> >> >> Thanks for the explanation. I wonder how the previous versions of a method >> can be found using parcels. >> >> >> Levente >> >> >>> best >>> Eliot >>> >>> >>> >>>> Levente >>>> >>> >

Dec. 10, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Mariano Martinez Peck

> If this approach is taken how much does that change your analysis? >> > > But note that MessageTally is not reliable nowadays. > > > Why ? since when ? > >> Note that not writing source to the changes file has ancilliary benefits; >> change recovery is now not polluted with package loads and the changes >> file >> does not grow as packages are added, only as one's changes are made. >> Unloading a package doesn't leave garbage in the changes files. >> >> There are downsides. Deploying a development image means deploying all >> the >> associated parcel source files as well, and for this a >> platform-independent >> Filename abstraction really helps. >> > > Thanks for the explanation. I wonder how the previous versions of a method > can be found using parcels. > > > Levente > > >> best >> Eliot >> >> >> >>> Levente >>> >>

Dec. 10, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Levente Uzonyi

On Fri, 10 Dec 2010, Eliot Miranda wrote: > Hi Levente, > > 2010/12/9 Levente Uzonyi <leves(a)elte.hu> > >> On Thu, 9 Dec 2010, StÃ©phane Ducasse wrote: >> >> It does! >>>>>>> It seems that you did not work in VW2.5 and 3.0 and when parcels >>>>>>> arrived loading was realllllly a big difference >>>>>>> I do not see why this would not the same with Fuel. >>>>>>> >>>>>> >>>>>> No I didn't, but the version number of VW is around 7.x now, so I guess >>>>>> the CPUs and VMs are now several times faster. Does it really matter if it >>>>>> takes 200ms or 20ms to load a package? >>>>>> >>>>> >>>>> When I load a package with MC so far I still notice it and I would not >>>>> even think about it. >>>>> It should load in a unnoticeable amount of time. >>>>> >>>> >>>> Do you think MC is "slow" because the Compiler is "slow"? >>>> >>> >>> not totally but I do not understand why this is obligatory to compile >>> everything all the time. >>> Then Opal will be slower than the old comcrapiler. >>> >>> >> I did a quick test where it took 4294ms to load RoelTyper + OCompletion >> from disk (no socket creation, no network latency, etc). These packages >> contain 790 methods. 5.1% of the total time was spent for compilation, >> that's 219ms. The rest is used by other stuff like: >> - loading the files from disk >> - writing the source code to disk (sources/changes files) >> - evaluating class side #initialize methods >> - processing system change notifications >> >> Another 51ms was spent in creating 63 classes and 107ms to install the >> CompiledMethods to the classes. So that's 219+51+107 = 377ms for creating >> all classes and their methods. The rest is administration which can not be >> avoided by binary loading. >> >> Even if binary loading is 10x faster than compiling the code (which I >> doubt), then you save 339ms. So it would take only 3917ms to load these >> packages. That would save you 7.9% of the total time. >> > > One of the important features of the VW parcels work is that one does not > write the source code to the changes file. Instead teh system has a > SourceFileManager that works like a dictionary mapping file indices to > source files, so instead of the two element SourceFileArray one has an > arbitrarily large collection of files. When a parcel file is loaded its > source file is added to the SFM which returns an index and then all the file > pointers in the methods in the parcel are swizzled to refer to their > sources' position in their files' index. We changed the format of file > pointers so something resembling four floating-point formats so we can have > lots of small files (more space for file indices) and a few large files > (more space for file offsets) before one overflows into large integer file > pointers. > > Now Igor's trailer work makes this approach feasible but one wouldn't need > the funky floating-point format stuff because one could easily allocate, > say, 5 bytes to the file pointer, two for the file index for a maximum of > 64k source files, and 3 for the file offset for a maximum of 16m of source > per parcel source file (I think splitting the 40 bits as 14:26 might be > better but that's details). One needs to predetermine the size of the file > pointer so that the trailer can be modified in place since changing the > length of a trailer means allocating a new comp[iled method and that will be > slow. > > If this approach is taken how much does that change your analysis? Writing the sources takes 1.6% of total time according to MessageTally. Significant amount of time is spent in finalization (12.8%) and GCs (15%). But note that MessageTally is not reliable nowadays. > > Note that not writing source to the changes file has ancilliary benefits; > change recovery is now not polluted with package loads and the changes file > does not grow as packages are added, only as one's changes are made. > Unloading a package doesn't leave garbage in the changes files. > > There are downsides. Deploying a development image means deploying all the > associated parcel source files as well, and for this a platform-independent > Filename abstraction really helps. Thanks for the explanation. I wonder how the previous versions of a method can be found using parcels. Levente > > best > Eliot > > >> >> Levente >

Dec. 10, 2010

Re: [Pharo-project] Where does Regex-Core and friends live

by Dale Henrichs

I've looked over the tests and it looks like all of the match operations ultimately end up running against a stream, so the fact that the tests pass on GemStone indicates that the stream behavior is pretty well covered ... so no obvious holes in the test suite.. Dale On 12/09/2010 01:41 PM, Dale Henrichs wrote: > On 12/09/2010 10:39 AM, StÃ©phane Ducasse wrote: >>>> >>> I'm interested in terms of maintaining Pharo compatibility ... many of the GLASS developers develop in Pharo and deploy in GemStone and I am trying to get in the habit of using the same packages that are loaded into Pharo (where possible/practical) so that the bugfixes and updates can be shared without too much trouble ... >> >> Dale >> >> we are interested in making sure that the package loads well in Glass. >> I hope that we will simplify clean the system another couple of times to arrive to a nicer version. >> Adding tests is also a good way to support such effort. >> >> Stef > > Stef, > > The packages loaded (except for the two compile errors .. I'll check a > fix in for those) and all tests ran clean ... I will probably spend some > time with regex and streams to validate GemStone's Ansi streams and will > add tests if the coverage is lacking in that area ... > > Dale >

Dec. 10, 2010

Re: [Pharo-project] Ideas for HelpSystem

by StÃ©phane Ducasse

thanks for the pointer On Dec 10, 2010, at 7:40 PM, laurent laffont wrote: > A year ago I've done this to learn http://magaloma.seasidehosting.st/ > > (newbie) code is here http://www.squeaksource.com/SimpleWebDoc.html > > I won't touch it because I work on other stuff but feel free to try and ask..... > > Laurent > > > On Fri, Dec 10, 2010 at 6:42 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I would really to have that for pharo. Anybody looking for a small project with a big impact on the community? > > > On Dec 10, 2010, at 5:17 PM, Damien Pollet wrote: > > > Hi all, > > > > The Ruby guys have a really nifty tool for code documentation (mainly > > per-class, per-method etc, but README files are used as well and can > > serve for tutorials). It's called Yard: http://yardoc.org/ > > > > Typically it's used to generate documentation, like javadoc, but it > > can run as a web server with all the documentation of installed Ruby > > packages (see http://www.rubyinside.com/the-3-step-guide-to-slick-local-documentation-for… > > ) > > > > -- > > Damien Pollet > > type less, do more [ | ] http://people.untyped.org/damien.pollet > > > > >

Dec. 10, 2010

Re: [Pharo-project] Issue 3400 in pharo: doubled '.' at end of line in RxParserTest>>#test and #testTranlsatingMatchesUsing not portable

by pharo＠googlecode.com

Updates: Status: Fixed Comment #1 on issue 3400 by da...(a)teleport.com: doubled '.' at end of line in RxParserTest>>#test and #testTranlsatingMatchesUsing not portable http://code.google.com/p/pharo/issues/detail?id=3400 fix is in the PharoInbox... Name: Regex-Tests-Core-DaleHenrichs.3 Author: DaleHenrichs Time: 10 December 2010, 11:04:41 am UUID: 57f003b7-7e1f-4aa5-bd92-7749ba5f4a66 Ancestors: Regex-Tests-Core-StephaneDucasse.2

Dec. 10, 2010

[Pharo-project] Issue 3400 in pharo: doubled '.' at end of line in RxParserTest>>#test and #testTranlsatingMatchesUsing not portable

by pharo＠googlecode.com

Status: Started Owner: da...(a)teleport.com Labels: Milestone-1.2 New issue 3400 by da...(a)teleport.com: doubled '.' at end of line in RxParserTest>>#test and #testTranlsatingMatchesUsing not portable http://code.google.com/p/pharo/issues/detail?id=3400 attempting to load Regex-Tests-Core-StephaneDucasse.2 into GemStone results in compile errors. should be able to remove the offending periods with little impact ... I'll check in an update package shortly

Dec. 10, 2010

Re: [Pharo-project] Ideas for HelpSystem

by laurent laffont

A year ago I've done this to learn http://magaloma.seasidehosting.st/ (newbie) code is here http://www.squeaksource.com/SimpleWebDoc.html I won't touch it because I work on other stuff but feel free to try and ask..... Laurent On Fri, Dec 10, 2010 at 6:42 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > I would really to have that for pharo. Anybody looking for a small project > with a big impact on the community? > > > On Dec 10, 2010, at 5:17 PM, Damien Pollet wrote: > > > Hi all, > > > > The Ruby guys have a really nifty tool for code documentation (mainly > > per-class, per-method etc, but README files are used as well and can > > serve for tutorials). It's called Yard: http://yardoc.org/ > > > > Typically it's used to generate documentation, like javadoc, but it > > can run as a web server with all the documentation of installed Ruby > > packages (see > http://www.rubyinside.com/the-3-step-guide-to-slick-local-documentation-for… > > ) > > > > -- > > Damien Pollet > > type less, do more [ | ] http://people.untyped.org/damien.pollet > > > > >

Dec. 10, 2010