- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.3] #13328

by Marcus Denker

13328 ----- Issue 5579: Another Zn Update http://code.google.com/p/pharo/issues/detail?id=5579 -- Marcus Denker -- http://marcusdenker.de

April 4, 2012

Re: [Pharo-project] [ANN] new stable version of omnibrowser

by StÃ©phane Ducasse

fabrizio did you try nautilus ? Stef On Apr 4, 2012, at 2:24 PM, Fabrizio Perin wrote: > Thanks really a lot for this, > I was trying to find sometime to do it myself. I'm finishing to setup a local Jenkins build to load Moose together with OB. Manually it work. I will report any unusual behaviour. > > Cheers, > Fabrizio > > 2012/4/2 Guillermo Polito <guillermopolito(a)gmail.com> > I fixed some usages of deprecated code, and now it loads and works at first in the latest -hopefully and almost released- Pharo 1.4 > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfOmniBrowser'; > load. > > (ConfigurationOfOmniBrowser > project version: #stable) load: #( 'Dev' 'Dev Tests'). > > This scripts installs OmniBrowser + OCompletion + Refactoring Browser > > Please test :) > > Guille >

April 4, 2012

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

by StÃ©phane Ducasse

I loved that one :) Your first integration :) Supercool. Stef On Apr 4, 2012, at 4:47 PM, Esteban Lorenzano wrote: > 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

[Pharo-project] Limit of the #become:

by Mariano Martinez Peck

Hi guys. I noticed that there is a limit in the number of objects you can become. In my case, I am becoming 2312157 objects. So..I don't expect that the become works. I imagine that it was not designed for so many objects in mind ;) However, what I would really understand is where is the limitation and the reason. And of course, if someone already knows which is the real number limit. Otherwise, I will do a kind of binary search and discover it. If you want to reproduce it: | dict | dict := Dictionary new. 2312157 timesRepeat: [ dict at: Object new put: Object new ]. 3 timesRepeat: [Smalltalk garbageCollect]. dict keys elementsForwardIdentityTo: dict values. throws a #primitiveFailed. Thanks, -- Mariano http://marianopeck.wordpress.com

April 4, 2012

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

by Marcus Denker

On Apr 4, 2012, at 5:27 PM, Damien Cassou wrote: > 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? > That is the question.... but people where very upset about having an "optional" package in Pharo that they wanted to load themselves.. you can not have everything. Marcus -- Marcus Denker -- http://marcusdenker.de

April 4, 2012

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

by Marcus Denker

On Apr 4, 2012, at 5:23 PM, Hilaire Fernandes wrote: > > > Also clean up is not as good as before, cleaned image is still 22MB (in > contrast to about 10MB with 1.3) > This is strange... ScriptLoader new cleanUpForProduction generates a 8.4 MB Image... What you should check is that #cleanUpForProduction changes a bit, it is much simpler now (I move more stuff to the #cleanUp: methods and we cleaned up the image in general a little): cleanUpForProduction "self new cleanUpForProduction" "trim MC ancestory information" MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. "delete logo" PolymorphSystemSettings showDesktopLogo: false. "unload packages" Smalltalk globals at: #SUnitUnloader ifPresent:[ :unloader | unloader new unloadAll ]. (MCPackage named: 'HelpSystem-Core') unload. (MCPackage named: 'FixUnderscores') unload. (MCPackage named: 'Deprecated14') unload. self cleanUpForRelease. (MCPackage named: self theScriptLoaderPackageName) unload. Smalltalk cleanUp: true except: #() confirming: false. Smalltalk garbageCollect. -- Marcus Denker -- http://marcusdenker.de

April 4, 2012

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