- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] Shootout benchmarking copied to ss3

by Nicolas Cellier

These benchmarks are good, so I took the port of Eliot from Cog VMMaker and made a package of its own. Since I cannot create a new project on squeaksource, I decided to try SS3. See http://ss3.gemstone.com/ss/Shootout.html/ http://ss3.gemstone.com/ss/Shootout.html/Wiki http://shootout.alioth.debian.org/u32/benchmark.php Nicolas

April 1, 2012

Re: [Pharo-project] Collection new printString make the image hanging

by StÃ©phane Ducasse

> > 13315 is very old. The current version is 13327... and your problem sounds like something we fixed a long time ago. +1 > > >> By evaluating some tests again the emergency evaluator pop up (Pharo doesn't like me lately :) ). >> This time at least I figure that some elements i use in the tests do not print properly: >> >> <error in printString: evaluate "collection printString" to debug> >> so if you do >> >> Collection new printString. >> >> the image seems to hang the only was to stop it is to do command period. >> >> In 1.4 at least the debugger pops up telling that "do:" should be implemented in a subclass. To make the image hang you should do >> > Collection is an abstract class and should not be instantiated. +1 > >> SequenceableCollection new printString. >> >> I don't know if those are suppose to be bugs or my inappropriate use of Collection and SequenceableCollection. I just reported. > > > SequencableCollection is an abstract class and should not be instantiated. + 1 > But that it freezes is strange, it should report an error as soon as a subclassresponsibility is encounterd (like Collection) Marcus we fixed that in 1.4. I'm not sure it was back ported to 1.3. Stef

April 1, 2012

Re: [Pharo-project] Collection new printString make the image hanging

by StÃ©phane Ducasse

On Mar 31, 2012, at 6:43 PM, Fabrizio Perin wrote: > Hi, > I was coding in > Pharo1.3 > Latest update: #13315 > > By evaluating some tests again the emergency evaluator pop up (Pharo doesn't like me lately :) ). > This time at least I figure that some elements i use in the tests do not print properly: > > <error in printString: evaluate "collection printString" to debug> > so if you do > > Collection new printString. this was fixed in 1.4 Now Collection is an abstract class so do not expect that instantiating make any sense. > > the image seems to hang the only was to stop it is to do command period. > > In 1.4 at least the debugger pops up telling that "do:" should be implemented in a subclass. To make the image hang you should do > > SequenceableCollection new printString. > > I don't know if those are suppose to be bugs or my inappropriate use of Collection and SequenceableCollection. I just reported. > > Cheers, > Fabrizio

April 1, 2012

Re: [Pharo-project] Collection new printString make the image hanging

by Marcus Denker

On Mar 31, 2012, at 6:43 PM, Fabrizio Perin wrote: > Hi, > I was coding in > Pharo1.3 > Latest update: #13315 > 13315 is very old. The current version is 13327... and your problem sounds like something we fixed a long time ago. > By evaluating some tests again the emergency evaluator pop up (Pharo doesn't like me lately :) ). > This time at least I figure that some elements i use in the tests do not print properly: > > <error in printString: evaluate "collection printString" to debug> > so if you do > > Collection new printString. > > the image seems to hang the only was to stop it is to do command period. > > In 1.4 at least the debugger pops up telling that "do:" should be implemented in a subclass. To make the image hang you should do > Collection is an abstract class and should not be instantiated. > SequenceableCollection new printString. > > I don't know if those are suppose to be bugs or my inappropriate use of Collection and SequenceableCollection. I just reported. SequencableCollection is an abstract class and should not be instantiated. But that it freezes is strange, it should report an error as soon as a subclassresponsibility is encounterd (like Collection) Marcus -- Marcus Denker -- http://marcusdenker.de

April 1, 2012

[Pharo-project] Collection new printString make the image hanging

by Fabrizio Perin

Hi, I was coding in Pharo1.3 Latest update: #13315 By evaluating some tests again the emergency evaluator pop up (Pharo doesn't like me lately :) ). This time at least I figure that some elements i use in the tests do not print properly: <error in printString: evaluate "collection printString" to debug> so if you do Collection new printString. the image seems to hang the only was to stop it is to do command period. In 1.4 at least the debugger pops up telling that "do:" should be implemented in a subclass. To make the image hang you should do SequenceableCollection new printString. I don't know if those are suppose to be bugs or my inappropriate use of Collection and SequenceableCollection. I just reported. Cheers, Fabrizio

April 1, 2012

[Pharo-project] [update 1.4] #14418

by Marcus Denker

14418 ----- Issue 5571: clean up #cleanUpForProduction a little more http://code.google.com/p/pharo/issues/detail?id=5571 Issue 5570: Strange deprecation http://code.google.com/p/pharo/issues/detail?id=5570 -- Marcus Denker -- http://marcusdenker.de

April 1, 2012

Re: [Pharo-project] Zodiac on Linux

by Marcus Denker

On Mar 31, 2012, at 4:10 PM, Sean P. DeNigris wrote: > > Sven Van Caekenberghe wrote >> >> It most certainly works on servers, for me, and for others. >> > > The Zodiac one-click works, just not the Jenkins vm. It seems to be an issue > with the ssl plugin built by Jenkins. When I copy the ssl plugin from the > Zodiac alpha one-click into the Jenkins Cog vm, it works. Yes, the SSL build is not yet working... Camillo and Igor changed the build that it compiles with SSL (and NativeBoost) by default, but it's not yet working completely (that's why it was not announced yet). Marcus -- Marcus Denker -- http://marcusdenker.de

April 1, 2012

Re: [Pharo-project] Zodiac on Linux

by Sven Van Caekenberghe

On 31 Mar 2012, at 16:09, Sean P. DeNigris wrote: > Sven Van Caekenberghe wrote >> >> It most certainly works on servers, for me, and for others. >> > > The Zodiac one-click works, just not the Jenkins vm. It seems to be an issue > with the ssl plugin built by Jenkins. When I copy the ssl plugin from the > Zodiac alpha one-click into the Jenkins Cog vm, it works. > > Sean I didn't know it was already being built/included (I knew it was coming). Thanks for reporting this. I did not yet test that vm myself. Sven

April 1, 2012

Re: [Pharo-project] Zodiac on Linux

by Sean P. DeNigris

Sven Van Caekenberghe wrote > > It most certainly works on servers, for me, and for others. > The Zodiac one-click works, just not the Jenkins vm. It seems to be an issue with the ssl plugin built by Jenkins. When I copy the ssl plugin from the Zodiac alpha one-click into the Jenkins Cog vm, it works. Sean -- View this message in context: http://forum.world.st/Zodiac-on-Linux-tp4521194p4521686.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 1, 2012

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

by Frank Shearar

On 30 March 2012 23:56, Francisco Garau <francisco.garau(a)gmail.com> wrote: > Another interesting read, is from Peter Ahe who applied the same sort of > analysis to the Resilient Smalltalk. > > http://tinyurl.com/cz9kslu > > I have some slides explaining my work. I can email them to you, if you > wish. That would be great! One thing I've not taken the time to figure out is the relationship (if any) between the approach in Concrete Type Inference and Olin Shivers et al's k-CFA approach. k-CFA is also an abstract interpreter, but I don't know if it's just same in the name, or how the two approaches differ. Shivers also uses variants of CFA for things like tracking garbage collection. A recent paper by Matt Might titled "Abstracting Abstract Machines (http://matt.might.net/papers/vanhorn2010abstract.pdf) covers the various uses to which CFA can be put. frank > Cheers, > Francisco > > > > 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. > > > > >> >> 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 >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> > >> >

March 31, 2012