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

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

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

by Fabrizio Perin

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] [Pharo 1.4] Please test!

by laurent laffont

Hi, ProfStef and TWM load successfully, all tests green. Laurent On Fri, Mar 30, 2012 at 9:26 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > > You can download the lastest 1.4 here for testing: > > > https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/lastSucces… > > And a first version of the one-click here: > > > https://ci.lille.inria.fr/pharo/job/Pharo%20One%20Click%20image/lastSuccess… > > > > > -- > Marcus Denker -- http://marcusdenker.de > > >

April 4, 2012

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

by Marcus Denker

On Apr 4, 2012, at 1:16 PM, Francisco Garau 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. > > 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? > Pharo integrates the work of Eliot Miranda on block closures... this means that blocks are real closures. The compiler is right now the old Smalltalk-80 compiler implementation, but this will change eventually. > > > PS: I am thinking in giving the Type Inference project a name: Telar or Tilar. > sounds good. Marcus -- Marcus Denker -- http://marcusdenker.de

April 4, 2012

Re: [Pharo-project] http://ss3.gemstone.com/ is EXTREMELY slow?

by Benjamin

It's the goal :) Ben On Apr 4, 2012, at 1:46 PM, Esteban Lorenzano wrote: > hope you are using Spec :) > > On Apr 4, 2012, at 1:10 PM, Benjamin wrote: > >> We are right now doing an experiment which consists in the rewrite of MCBrowser and friends. >> >> >> I hope we will get something cleaner and clearer :) >> >> Ben >> >> On Apr 4, 2012, at 12:55 PM, Guillermo Polito wrote: >> >>> >>> >>> On Wed, Apr 4, 2012 at 3:25 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: >>> >>> Am 2012-04-03 um 22:57 schrieb Guillermo Polito: >>> >>> > >>> > >>> > On Tue, Apr 3, 2012 at 10:49 PM, Tobias Pape <Das.Linux(a)gmx.de> wrote: >>> > >>> > Am 2012-04-03 um 20:24 schrieb phil(a)highoctane.be: >>> > >>> > > And the version pushed will be +1 each time isn't it? >>> > > >>> > > How do I put the same version to two places? >>> > >>> > when you commit a version, you get a window with several options, eg, >>> > browse â¦ diffâ¦ etc. The last is âcopyâ >>> > click on it and you can copy the very same version to >>> > different repos. This does not work with the âsaveâ button in >>> > the working copy overview. >>> > âsaveâ -> commit >>> > âcopyâ -> push. >>> > >>> > Hey, I'd vote for changing the buttons' labels! >>> >>> problematic. >>> for âsaveâ, ok. >>> but âcopyâ is just that; >>> only the version selected gets transferredâ¦ >>> >>> But it is not clear if it is copy to or copy from. >>> Also save may be commit & push, because it does that. >>> >>> Introducing the terms from other tools like git/mercurial/svn may betray the origins of monticello, but It'll make it clearer to newcomers, and for me because I'm kind of stupid some times. >>> >>> I'm now reading the context menu of repositories: >>> >>> #(('Open repository' #openRepository) >>> ('Edit repository info' #editRepository) >>> ('Add to package...' #addRepositoryToPackage) >>> ('Remove repository' #removeRepository) >>> ('Load repositories' #loadRepositories) >>> ('Save repositories' #saveRepositories) >>> ('Flush cached versions' #flushAllCaches)) >>> >>> What does load repositories or save repositories, or flush cached versions mean? >>> >>> >>> Best >>> -tobias >>> >> >

April 4, 2012

Re: [Pharo-project] http://ss3.gemstone.com/ is EXTREMELY slow?

by Esteban Lorenzano

hope you are using Spec :) On Apr 4, 2012, at 1:10 PM, Benjamin wrote: > We are right now doing an experiment which consists in the rewrite of MCBrowser and friends. > > > I hope we will get something cleaner and clearer :) > > Ben > > On Apr 4, 2012, at 12:55 PM, Guillermo Polito wrote: > >> >> >> On Wed, Apr 4, 2012 at 3:25 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: >> >> Am 2012-04-03 um 22:57 schrieb Guillermo Polito: >> >> > >> > >> > On Tue, Apr 3, 2012 at 10:49 PM, Tobias Pape <Das.Linux(a)gmx.de> wrote: >> > >> > Am 2012-04-03 um 20:24 schrieb phil(a)highoctane.be: >> > >> > > And the version pushed will be +1 each time isn't it? >> > > >> > > How do I put the same version to two places? >> > >> > when you commit a version, you get a window with several options, eg, >> > browse â¦ diffâ¦ etc. The last is âcopyâ >> > click on it and you can copy the very same version to >> > different repos. This does not work with the âsaveâ button in >> > the working copy overview. >> > âsaveâ -> commit >> > âcopyâ -> push. >> > >> > Hey, I'd vote for changing the buttons' labels! >> >> problematic. >> for âsaveâ, ok. >> but âcopyâ is just that; >> only the version selected gets transferredâ¦ >> >> But it is not clear if it is copy to or copy from. >> Also save may be commit & push, because it does that. >> >> Introducing the terms from other tools like git/mercurial/svn may betray the origins of monticello, but It'll make it clearer to newcomers, and for me because I'm kind of stupid some times. >> >> I'm now reading the context menu of repositories: >> >> #(('Open repository' #openRepository) >> ('Edit repository info' #editRepository) >> ('Add to package...' #addRepositoryToPackage) >> ('Remove repository' #removeRepository) >> ('Load repositories' #loadRepositories) >> ('Save repositories' #saveRepositories) >> ('Flush cached versions' #flushAllCaches)) >> >> What does load repositories or save repositories, or flush cached versions mean? >> >> >> Best >> -tobias >> >

April 4, 2012

[Pharo-project] Type Inference

by Santiago Bragagnolo

Hi all! I'm pushing type inference (call-graph) into GSoC this year. I really believe that the future of our development applications and optimizations comes from this side. The main idea resides in two aspects: * enhance inference, allowing complex inference * building a queryable call graph, that allows to get type and flow information for a given expression. Well, here is the gsoc project: http://gsoc2012.esug.org/projects/type-inference And here is the base proyect ( Francisco Garau's tesis ) http://ss3.gemstone.com/ss/ConcreteTypeInference I started to work on the project by analyzing the behavior and am currently trying to improve the detection algorithm loops, but you can still downloading the code and trying somethings like 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>>>}" That's all right now. Cheers.

April 4, 2012