April 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 1.4] #14421

by Damien Cassou

On Wed, Apr 4, 2012 at 5:08 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > With renaming, people can load the official FS package easily, while we can > be very cautious with the code that is run on image startup and save. it makes sense. But how are you going to apply changes made in official FS to Pharo? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

April 4, 2012

Re: [Pharo-project] [Pharo 1.4] Please test!

by Hilaire Fernandes

Strange, an install of DrGeo then clean up, make this: (1 to: 1000) do: [:i |] displayingProgress: 'hello' with a remnant SystemProgressMoprh on the display. Was not occurring with previous version 1.3. I don't override anything there. Also clean up is not as good as before, cleaned image is still 22MB (in contrast to about 10MB with 1.3) Clean up script is as: cleanUpForRelease "self cleanUpForRelease" | oldDicts newDicts | MCHttpRepository clearPasswords. "trim MC ancestory information" MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. "delete logo" PolymorphSystemSettings showDesktopLogo: false. "delete ScriptLoader log" ScriptLoader resetLogStream. Smalltalk globals at: #SUnitUnloader ifPresent:[ :unloader | unloader new unloadAll ]. (MCPackage named: 'HelpSystem') unload. (MCPackage named: 'ToolBuilder-Morphic') unload. (MCPackage named: 'ToolBuilder-Kernel') unload. (MCPackage named: 'Deprecated12') unload. (MCPackage named: 'Deprecated13') unload. "shrink method dictionaries." Smalltalk garbageCollect. MethodDictionary rehashAll. (MCPackage named: 'HostMenus') unload. ScriptLoader new removeDejaVuFonts; cleanUpForRelease; flushCaches. (MCPackage named: ScriptLoader new theScriptLoaderPackageName) unload. ChangeSet removeChangeSetsNamedSuchThat: [ :each | true ]. ChangeSet resetCurrentToNewUnnamedChangeSet. RecentMessageList cleanUp. Smalltalk removeEmptyMessageCategories. Smalltalk garbageCollect Le 30/03/2012 09:26, Marcus Denker a Ã©crit : > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Dr. Geo -- http://www.drgeo.eu

April 4, 2012

Re: [Pharo-project] type-inference: it works!

by Frank Shearar

On 4 April 2012 15:27, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> wrote: > aaaa, ok, you're right, there are extension methods that i forget. right? > Ill upload to ss3 later. Thanks :D. :) Just waiting for ss3 to recompute its indices or whatever, but I've pushed my two mczs up to the repository. frank > 2012/4/4 Frank Shearar <frank.shearar(a)gmail.com> >> >> Santiago, it looks like you don't have any of the Support stuff: there >> are no extensions to the parse nodes, so you can't use this out of the >> box as per Francisco's earlier examples: >> >> TiSystem current reset. >> string := '3 + 4'. >> Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. >> "=> return {<SmallInteger>} " >> >> (You can with mine, because I folded in both changesets.) >> >> frank >> >> On 4 April 2012 14:00, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> >> wrote: >> > I already upload it to ss3. >> > http://ss3.gemstone.com/ss/ConcreteTypeInference >> > >> > >> > >> > 2012/4/4 Frank Shearar <frank.shearar(a)gmail.com> >> >> >> >> On 4 April 2012 12:15, Francisco Garau <francisco.garau(a)gmail.com> >> >> wrote: >> >> > Hi Frank - I'd appreciate if you can send me those mcz - I am trying >> >> > to >> >> > figure out how Monticello works and that would be helpful. >> >> >> >> Attached! fbs.1 is the result of my loading your two changesets into a >> >> clean image and moving the -Support extensions to the *TypeInference >> >> category. (So for example all the #mirrorIn: implementations were in >> >> 'type inference' and are now in '*TypeInference' so that Monticello >> >> can recognise they're in the TypeInference package.) >> >> >> >> I didn't keep all the method changes to Set: if Sets need their >> >> behaviour adjusted, we should fix Set directly, rather than from this >> >> package. >> >> >> >> fbs.2 just adds the change I described earlier: I replaced "key class >> >> == Association" with "key isVariableBinding". >> >> >> >> One thing the package definitely needs is a large test suite :) That >> >> would also let someone assess whether they've hit a known limitation >> >> of the inference engine or a bug. For example, analysing 'n := 2. n >> >> log' told me that "UndefinedObject would not understand #contextTag" >> >> and I'm unsure why a MethodContext (the only implementor of >> >> #contextTag) would be involved in calculating a log. >> >> >> >> frank >> >> >> >> > As far as I remember one of the sources of imprecision in Squeak was >> >> > the >> >> > treatment of block variables or block arguments (can't remember >> >> > exactly), >> >> > which was in my to-do list that never got done. >> >> > >> >> > I know there has been work in the Compiler in Pharo and that block >> >> > and >> >> > Closures were a hot topic. Is that now fixed in Pharo? >> >> > >> >> > Sorry, if the above is a generic question. But I can't remember >> >> > exactly >> >> > what >> >> > was wrong with the blocks in Squeak. I did notice that the #isArg: >> >> > method >> >> > was removed in Pharo. >> >> > >> >> > Cheers, >> >> > Francisco >> >> > >> >> > PS: I am thinking in giving the Type Inference project a name: Telar >> >> > or >> >> > Tilar. >> >> > >> >> > Telar means Loom in Spanish and it gives the idea of the interwoven >> >> > data >> >> > and >> >> > control flow of Smalltalk (or any other OO language). >> >> > >> >> > I also just learn that Loom in Arabic is pronounced Nul or (Â Ø§ÙØµÙØ±Ø§) >> >> > >> >> > On 3 April 2012 21:56, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> >> >> >> >> >> On 30 March 2012 22:19, Frank Shearar <frank.shearar(a)gmail.com> >> >> >> wrote: >> >> >> > In case anyone's interested in the paper behind Francisco's work >> >> >> > (thanks Francisco!), you can find "Concrete Type Inference: >> >> >> > Delivering >> >> >> > Object Oriented Applications" here: >> >> >> > https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf >> >> >> > >> >> >> > Interestingly, typing 'Display boundBox' fails in Squeak trunk >> >> >> > because >> >> >> > "UndefinedObject won't understand #origin:corner:". Odd, since >> >> >> > evaluating same will happily return a Rectangle. I'll look into it >> >> >> > and >> >> >> > see what I can find. >> >> >> >> >> >> It turns out that in Pharo we use Association and in Squeak we use >> >> >> ReadOnlyVariableBinding; by changing VariableNode >> >> >> >> #isSharedVarNode >> >> >> to >> >> >> >> >> >> isSharedVarNode >> >> >> Â Â ^ self type = 4 and: [key isVariableBinding] >> >> >> >> >> >> TypeInference works in both! >> >> >> >> >> >> Now I have some mczs, but I don't have a place to publish them... >> >> >> >> >> >> frank >> >> >> >> >> >> > frank >> >> >> > >> >> >> > On 30 March 2012 14:33, Francisco Garau >> >> >> > <francisco.garau(a)gmail.com> >> >> >> > wrote: >> >> >> >> No unit tests, sorry... >> >> >> >> >> >> >> >> Is not profiling, it's abstract intrepretation using types >> >> >> >> instead >> >> >> >> of >> >> >> >> objects. >> >> >> >> >> >> >> >> - Francisco >> >> >> >> >> >> >> >> >> >> >> >> On 30 Mar 2012, at 15:15, Alexandre Bergel >> >> >> >> <alexandre.bergel(a)me.com> >> >> >> >> wrote: >> >> >> >> >> >> >> >> Hi Francisco, >> >> >> >> >> >> >> >> I've tried your implementation. It seems to work in Pharo 1.4. Do >> >> >> >> you >> >> >> >> have >> >> >> >> unit test somewhere? >> >> >> >> How does your profiler work? From what you have said in your >> >> >> >> email, >> >> >> >> it >> >> >> >> seems >> >> >> >> you are profiling the execution. Is that true? >> >> >> >> >> >> >> >> Cheers, >> >> >> >> Alexandre >> >> >> >> >> >> >> >> >> >> >> >> On 29 Mar 2012, at 18:47, Francisco Garau wrote: >> >> >> >> >> >> >> >> Load the attached ChangeSets: first Ti-Engine and then >> >> >> >> Ti-Support. >> >> >> >> >> >> >> >> You could then evaluate the below expressions -- watch the >> >> >> >> Transcript >> >> >> >> to see >> >> >> >> which methods are being analysed. >> >> >> >> >> >> >> >> TiSystem current reset. >> >> >> >> string := '3 + 4'. >> >> >> >> Compiler new analyze: string in: nil to: nil notifying: nil >> >> >> >> ifFail: >> >> >> >> [1]. >> >> >> >> "=> return {<SmallInteger>} " >> >> >> >> >> >> >> >> TiSystem current reset. >> >> >> >> string := 'Display boundingBox'. >> >> >> >> Compiler new analyze: string in: nil to: nil notifying: nil >> >> >> >> ifFail: >> >> >> >> [1]. >> >> >> >> "=> return {<Rectangle origin: <Point x: <SmallInteger> y: >> >> >> >> <SmallInteger>> >> >> >> >> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}" >> >> >> >> >> >> >> >> TiSystem current explore. >> >> >> >> >> >> >> >> >> >> >> >> Analysing 'Display boundingBox' shows a couple of surprises: >> >> >> >> >> >> >> >> The code never goes through the #new method (it creates objects >> >> >> >> using >> >> >> >> #basicNew and #@) >> >> >> >> Object code goes through Object>>value but knowing that the >> >> >> >> implementation >> >> >> >> just answers self, it could be easily optimised. >> >> >> >> >> >> >> >> >> >> >> >> I will try to package it more nicely under Monticello -- there >> >> >> >> are >> >> >> >> still a >> >> >> >> few rough edges that need to be polished before getting it to the >> >> >> >> same >> >> >> >> state >> >> >> >> it was in 2001... >> >> >> >> >> >> >> >> Cheers, >> >> >> >> Francisco >> >> >> >> <Ti-Engine.2.cs><Ti-Support.2.cs> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >> >> >> Alexandre BergelÂ Â http://www.bergel.eu >> >> >> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> > >> > >> >

April 4, 2012

Re: [Pharo-project] [update 1.4] #14421

by Marcus Denker

On Apr 4, 2012, at 5:05 PM, Damien Cassou wrote: > On Wed, Apr 4, 2012 at 4:47 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> (first one :) > > and good one. Thank you > The reason why we decided to rename FS is that it will be used very deeply in the system. e.g. reading startup scripts.... so it is not an external package and loading an new version of FS on top could have very bad effects. With renaming, people can load the official FS package easily, while we can be very cautious with the code that is run on image startup and save. Marcus -- Marcus Denker -- http://marcusdenker.de

April 4, 2012

Re: [Pharo-project] [update 1.4] #14421

by Damien Cassou

On Wed, Apr 4, 2012 at 4:47 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > (first one :) and good one. Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

April 4, 2012

Re: [Pharo-project] A test crashes (win32) cogvm

by Igor Stasenko

On 4 April 2012 05:19, Martin Dias <tinchodias(a)gmail.com> wrote: > I tried with latest Eliot vm and it's fine, no crash! > yep.. i know. But what is most interesting that those crashes happen only on windows VM since i using own VM daily on mac and having no any problems.. So, this is annoying :( -- Best regards, Igor Stasenko.

April 4, 2012

[Pharo-project] [update 1.4] #14421

by Esteban Lorenzano

14421 ----- Issue 5534: Do we rename/sync FS for 1.4? http://code.google.com/p/pharo/issues/detail?id=5534 (first one :)

April 4, 2012

Re: [Pharo-project] A test crashes (win32) cogvm

by Igor Stasenko

On 3 April 2012 19:24, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Tue, Apr 3, 2012 at 7:14 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> yes.. i had similar crashes.. and always involving the progress bar(s). >> but i was unable to find a fully reproducible case. :( >> > > now you have it :) > Thanks Martin for the report. I would like to help but until 14th I cannot > do ANYTHING else than my paper :( > we will do the merge with latest Eliot's update with Esteban.. and then i will check if it is still an issue. >> >> >> On 3 April 2012 16:31, Martin Dias <tinchodias(a)gmail.com> wrote: >> > Hi >> > >> > Almost 100% of the timesÂ (but not always)Â I run certain Fuel test, the >> > vm >> > crashes. The code related to such test has not changed for a long time, >> > so I >> > guess the problem appeared when I started to use the latest vm.Â I'd >> > thank a >> > lot some help on this issue. >> > >> > To reproduce, evaluate: >> > >> > (FLBenchmarksTest selector: #testNumberOfResults) run >> > >> > in: >> > - any of latest fuel images (por example, >> > >> > https://ci.lille.inria.fr/pharo/job/Fuel%20Pharo%201.4/284/artifact/Fuel.zip) >> > - using latest cog vm for win32 >> > (https://ci.lille.inria.fr/pharo/job/Cog-Win32/21/artifact/Cog.zip) >> > >> > >> > I attach dmps of crashes running in two computers, with both Pharo 1.3 >> > and >> > 1.4. >> > >> > >> > Thanks in advance. >> > MartÃn >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

April 4, 2012

Re: [Pharo-project] Fuel and Pharo Kernel

by Craig Latta

Hi-- > > I can not wait to see a Pharo image without the Compiler ;-) > > the dream will come true :) > Since 1998 I want that, it is cool to see the vision getting reality > because after we can do a lot more :) Just FYI, Spoon[1] has been like that for years. thanks, -C [1] http://thiscontext.wordpress.com -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 + 1 510 282 7468 + 1 250 607 7393

April 4, 2012

Re: [Pharo-project] type-inference: it works!

by Santiago Bragagnolo

aaaa, ok, you're right, there are extension methods that i forget. right? Ill upload to ss3 later. Thanks :D. 2012/4/4 Frank Shearar <frank.shearar(a)gmail.com> > Santiago, it looks like you don't have any of the Support stuff: there > are no extensions to the parse nodes, so you can't use this out of the > box as per Francisco's earlier examples: > > TiSystem current reset. > string := '3 + 4'. > Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1]. > "=> return {<SmallInteger>} " > > (You can with mine, because I folded in both changesets.) > > frank > > On 4 April 2012 14:00, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> > wrote: > > I already upload it to ss3. > http://ss3.gemstone.com/ss/ConcreteTypeInference > > > > > > > > 2012/4/4 Frank Shearar <frank.shearar(a)gmail.com> > >> > >> On 4 April 2012 12:15, Francisco Garau <francisco.garau(a)gmail.com> > wrote: > >> > Hi Frank - I'd appreciate if you can send me those mcz - I am trying > to > >> > figure out how Monticello works and that would be helpful. > >> > >> Attached! fbs.1 is the result of my loading your two changesets into a > >> clean image and moving the -Support extensions to the *TypeInference > >> category. (So for example all the #mirrorIn: implementations were in > >> 'type inference' and are now in '*TypeInference' so that Monticello > >> can recognise they're in the TypeInference package.) > >> > >> I didn't keep all the method changes to Set: if Sets need their > >> behaviour adjusted, we should fix Set directly, rather than from this > >> package. > >> > >> fbs.2 just adds the change I described earlier: I replaced "key class > >> == Association" with "key isVariableBinding". > >> > >> One thing the package definitely needs is a large test suite :) That > >> would also let someone assess whether they've hit a known limitation > >> of the inference engine or a bug. For example, analysing 'n := 2. n > >> log' told me that "UndefinedObject would not understand #contextTag" > >> and I'm unsure why a MethodContext (the only implementor of > >> #contextTag) would be involved in calculating a log. > >> > >> frank > >> > >> > As far as I remember one of the sources of imprecision in Squeak was > the > >> > treatment of block variables or block arguments (can't remember > >> > exactly), > >> > which was in my to-do list that never got done. > >> > > >> > I know there has been work in the Compiler in Pharo and that block and > >> > Closures were a hot topic. Is that now fixed in Pharo? > >> > > >> > Sorry, if the above is a generic question. But I can't remember > exactly > >> > what > >> > was wrong with the blocks in Squeak. I did notice that the #isArg: > >> > method > >> > was removed in Pharo. > >> > > >> > Cheers, > >> > Francisco > >> > > >> > PS: I am thinking in giving the Type Inference project a name: Telar > or > >> > Tilar. > >> > > >> > Telar means Loom in Spanish and it gives the idea of the interwoven > data > >> > and > >> > control flow of Smalltalk (or any other OO language). > >> > > >> > I also just learn that Loom in Arabic is pronounced Nul or ( Ø§ÙØµÙØ±Ø§) > >> > > >> > On 3 April 2012 21:56, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> >> > >> >> On 30 March 2012 22:19, Frank Shearar <frank.shearar(a)gmail.com> > wrote: > >> >> > In case anyone's interested in the paper behind Francisco's work > >> >> > (thanks Francisco!), you can find "Concrete Type Inference: > >> >> > Delivering > >> >> > Object Oriented Applications" here: > >> >> > https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf > >> >> > > >> >> > Interestingly, typing 'Display boundBox' fails in Squeak trunk > >> >> > because > >> >> > "UndefinedObject won't understand #origin:corner:". Odd, since > >> >> > evaluating same will happily return a Rectangle. I'll look into it > >> >> > and > >> >> > see what I can find. > >> >> > >> >> It turns out that in Pharo we use Association and in Squeak we use > >> >> ReadOnlyVariableBinding; by changing VariableNode >> #isSharedVarNode > >> >> to > >> >> > >> >> isSharedVarNode > >> >> ^ self type = 4 and: [key isVariableBinding] > >> >> > >> >> TypeInference works in both! > >> >> > >> >> Now I have some mczs, but I don't have a place to publish them... > >> >> > >> >> frank > >> >> > >> >> > frank > >> >> > > >> >> > On 30 March 2012 14:33, Francisco Garau <francisco.garau(a)gmail.com > > > >> >> > wrote: > >> >> >> No unit tests, sorry... > >> >> >> > >> >> >> Is not profiling, it's abstract intrepretation using types instead > >> >> >> of > >> >> >> objects. > >> >> >> > >> >> >> - Francisco > >> >> >> > >> >> >> > >> >> >> On 30 Mar 2012, at 15:15, Alexandre Bergel < > alexandre.bergel(a)me.com> > >> >> >> wrote: > >> >> >> > >> >> >> Hi Francisco, > >> >> >> > >> >> >> I've tried your implementation. It seems to work in Pharo 1.4. Do > >> >> >> you > >> >> >> have > >> >> >> unit test somewhere? > >> >> >> How does your profiler work? From what you have said in your > email, > >> >> >> it > >> >> >> seems > >> >> >> you are profiling the execution. Is that true? > >> >> >> > >> >> >> Cheers, > >> >> >> Alexandre > >> >> >> > >> >> >> > >> >> >> On 29 Mar 2012, at 18:47, Francisco Garau wrote: > >> >> >> > >> >> >> Load the attached ChangeSets: first Ti-Engine and then Ti-Support. > >> >> >> > >> >> >> You could then evaluate the below expressions -- watch the > >> >> >> Transcript > >> >> >> to see > >> >> >> which methods are being analysed. > >> >> >> > >> >> >> TiSystem current reset. > >> >> >> string := '3 + 4'. > >> >> >> Compiler new analyze: string in: nil to: nil notifying: nil > ifFail: > >> >> >> [1]. > >> >> >> "=> return {<SmallInteger>} " > >> >> >> > >> >> >> TiSystem current reset. > >> >> >> string := 'Display boundingBox'. > >> >> >> Compiler new analyze: string in: nil to: nil notifying: nil > ifFail: > >> >> >> [1]. > >> >> >> "=> return {<Rectangle origin: <Point x: <SmallInteger> y: > >> >> >> <SmallInteger>> > >> >> >> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}" > >> >> >> > >> >> >> TiSystem current explore. > >> >> >> > >> >> >> > >> >> >> Analysing 'Display boundingBox' shows a couple of surprises: > >> >> >> > >> >> >> The code never goes through the #new method (it creates objects > >> >> >> using > >> >> >> #basicNew and #@) > >> >> >> Object code goes through Object>>value but knowing that the > >> >> >> implementation > >> >> >> just answers self, it could be easily optimised. > >> >> >> > >> >> >> > >> >> >> I will try to package it more nicely under Monticello -- there are > >> >> >> still a > >> >> >> few rough edges that need to be polished before getting it to the > >> >> >> same > >> >> >> state > >> >> >> it was in 2001... > >> >> >> > >> >> >> Cheers, > >> >> >> Francisco > >> >> >> <Ti-Engine.2.cs><Ti-Support.2.cs> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> >> >> Alexandre Bergel http://www.bergel.eu > >> >> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> > >> > > > > > > >

April 4, 2012