- Pharo-dev - lists.pharo.org

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

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

by Frank Shearar

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] type-inference: it works!

by Santiago Bragagnolo

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] [squeak-dev] new Cog VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2540/

by Igor Stasenko

On 4 April 2012 00:53, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > new Cog VMs inÂ http://www.mirandabanda.org/files/Cog/VM/VM.r2540/. > > Cog VM binaries as per VMMaker.oscog-eem.154/r2540. > > Fix bad conceptual bug with become on methods. Â Unlike full and incremental > GC, > the reference from a Cog method to its method object must not be remapped > since > they're two halves of the same object. > Ouch, that might be the cause of recent crash reports on Windoze. Need to merge & update builds to check :) > Fix FileStreamTest>testPositionPastEndIsAtEnd on unix & Mac OS. > > Merge Merge VMConstruction-Plugins-OSProcessPlugin-dtl.33's changes. > > Regenerate the apparently truncated nscogsrc ZipPlugin.c. > > Handle more libc variations for LD_LIBRARY_PATH in the unix launch scripts. > -- > best, > Eliot > > > > -- Best regards, Igor Stasenko.

April 4, 2012

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

by Frank Shearar

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