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

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

by Francisco Garau

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? 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] http://ss3.gemstone.com/ is EXTREMELY slow?

by Benjamin

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 Santiago Bragagnolo

+1 to change labels 2012/4/4 Guillermo Polito <guillermopolito(a)gmail.com> > > > 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 Guillermo Polito

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] [Jenkins] Matrix build for tests and vm

by StÃ©phane Ducasse

really exciting. Software engineering in action with imagination :) Stef On Apr 4, 2012, at 9:22 AM, Marcus Denker wrote: > Hi, > > Christophe changed the Jenkins setup related to testing in a very nice way: > > -> first the current pharo 1.4 is updated to the latest. (as it used to be) > -> new: then we have a Matrix job for running tests on all plattforms. > This is one project, but it spawns test runs on all plattforms (Linux and Mac for now). > https://ci.lille.inria.fr/pharo/view/Build%20pipeline/job/Pharo%201.4%20Tes… > > -> Only if this build is green, it triggers all depending builds. > > see > > https://ci.lille.inria.fr/pharo/view/Build%20pipeline/ > > > The matrix is used already for other things > -> build of Cog: > https://ci.lille.inria.fr/pharo/job/Cog-VM/ > win, linux, mac > -> Testing Cog > https://ci.lille.inria.fr/pharo/job/Cog-VM%20tests/ > (not yet windows) > > This allows us to radically simplify the Jenkins setup and trigger actions > when *all* plattforms are in a good state. > > This will allow us, for example, to automatically update the VM that is used > for running builds and tests or that is packaged in the one-click. > > TODO > -> fix 1.4 so that passing a script to the image works on Windows > -> configure to run tests on windows > -> One-Click build for 1.4 and 1.3 > -> ..... > > So we are getting somewhere! I am sure that 1.5 will be the first Pharo where we > build *the artefact of release* completely automatically and tested from the first > change onwards. > > And this then forms a strong basis that we can build on top. > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > >

April 4, 2012

Re: [Pharo-project] SMark

by Stefan Marr

Hi Martin: On 03 Apr 2012, at 21:50, Martin Dias wrote: > I like SMark, so I am evaluating how straightforward would be to move Fuel benchmark suite. A couple of questions: > > 1) I had some undeclared references, no problem? > HeadlessSave class>>run: (RVMOperations is Undeclared) > ScriptStarter class>>transportersForFileOutMenu (Transporter is Undeclared) That's not a problem, both are RoarVM related and not necessary for you. [HeadlessSave was meant to make sure that no random processes are in the image anymore before it is saved. The RVMOperations thing I put in was probably for debugging. #transportersForFileOutMenu is something we use to better manage the fileouts with git. Also not relevant for you. Will try to clean these up soon.] > 2) Can I run benchmarks in headless mode using ScriptStarter? How can I try HelloWorld script? I couldn't figure out. Try: /.../../../cog -headless my.image SMarkHarness --help The class comment should also give you an idea how to use it, I hope. The HelloWorld is used similarly: /.../../../cog -headless my.image HelloWorld something something... ScriptStarter registers itself in the startUp handler chain and will try to figure out whether the first argument is a class name, and then perform #run: on the class. You might need to disable the file loader that is normally in your Pharo image. These two are not compatible unfortunately. Good luck Stefan PS: You are the second user for SMark as far as I know. So, please report any rough edges and missing documentation :) Reinout is more lucky, since he is sitting just in the next office ;) > > > Thanks, > MartÃn -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

April 4, 2012

Re: [Pharo-project] Fuel and Pharo Kernel

by Marcus Denker

On Apr 4, 2012, at 9:14 AM, StÃ©phane Ducasse wrote: >> >> >> I do strongly recommend to add Fuel very early in the development of >> 1.5 into the basic kernel packages. > > :) > Marcus added in the todo (BTW he should invite to the todo board we are just opening) to handle the old reference streamâ¦. :) The planning board will be public eventually... first we should finish 1.4. Marcus -- Marcus Denker -- http://marcusdenker.de

April 4, 2012

[Pharo-project] [Jenkins] Matrix build for tests and vm

by Marcus Denker

Hi, Christophe changed the Jenkins setup related to testing in a very nice way: -> first the current pharo 1.4 is updated to the latest. (as it used to be) -> new: then we have a Matrix job for running tests on all plattforms. This is one project, but it spawns test runs on all plattforms (Linux and Mac for now). https://ci.lille.inria.fr/pharo/view/Build%20pipeline/job/Pharo%201.4%20Tes… -> Only if this build is green, it triggers all depending builds. see https://ci.lille.inria.fr/pharo/view/Build%20pipeline/ The matrix is used already for other things -> build of Cog: https://ci.lille.inria.fr/pharo/job/Cog-VM/ win, linux, mac -> Testing Cog https://ci.lille.inria.fr/pharo/job/Cog-VM%20tests/ (not yet windows) This allows us to radically simplify the Jenkins setup and trigger actions when *all* plattforms are in a good state. This will allow us, for example, to automatically update the VM that is used for running builds and tests or that is packaged in the one-click. TODO -> fix 1.4 so that passing a script to the image works on Windows -> configure to run tests on windows -> One-Click build for 1.4 and 1.3 -> ..... So we are getting somewhere! I am sure that 1.5 will be the first Pharo where we build *the artefact of release* completely automatically and tested from the first change onwards. And this then forms a strong basis that we can build on top. Marcus -- Marcus Denker -- http://marcusdenker.de

April 4, 2012

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

by StÃ©phane Ducasse

On Apr 4, 2012, at 8:21 AM, Torsten Bergmann wrote: >> Torsten now the NewEcompletion should work. > > Yes, works for me now. Thanks! > > Using "Tools" -> "ConfigurationBrowser" you can > now also easily load the new Seaside 3.0.7 as well. > > No manual typing of Gofer scripts - just click, > load and run. Cool! And soon we want to get all the metacelloRepository config to be loaded, tests run because I always hate catalog of half working projects. Soon we will announce something cool to that respect. :) Stef > > Thanks > T. > -- > NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! > Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a >

April 4, 2012

Re: [Pharo-project] Fuel and Pharo Kernel

by StÃ©phane Ducasse

On Apr 3, 2012, at 10:42 PM, Martin Dias wrote: > Nice :) > > FuelPackageLoader is a functional prototype but needs many improvements. I am elaborating a proposal for GSoC, with features like: > > basic: > - emulate ClassBuilder (implies replacing it for something less monolithic): > - validating the class definition > - modifying an existent class > - recompiling methods (superclass change tolerance) > - mutating existing instances to the new format > - registering the class as a global > - send notifications > - more > - handle dependencies > - good migration support > - visual tool: integrate with Gofer or Monticello? martin writing a new class builder is indeed a really nice and great ideas. > > extra: > - run pre and post scripts (to avoid compilation the scripts should be fully serialized, not just the source code) > - new extension operations: add trait, add variable. > - clean uninstall: if an extension method overwrote an existing one, then it should be restored when package uninstalled (I think in VW is like this). > - ? > > Some items require community discussion, especially the extra ones. Also, I'm not sure what should be in the scope of GSoC. > > Cheers, > MartÃn > > On Tue, Apr 3, 2012 at 5:19 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > On Tue, Apr 3, 2012 at 7:36 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > > > > > On Tue, Apr 3, 2012 at 6:39 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > > wrote: > >> > >> Hi, > >> > >> I tried the Fuel with Pharo Kernel and... it works well. > > > > > > I am really happy to hear that. > > > >> > >> It needs only > >> very few modifications (removing of some dependencies). > > > > > > Right now I am extremelly busy, but in 2 ways I can spend some time in Fuel. > > If you think that some of these dependencies removal could be applied > > directly to Fuel core, please let us know. > > Hm, I used packages from the Fuel CI image. As I see some things were > changed. For the start, Fuel extensions of classes CharacterBlock and > MetacelloGoferLoad should not be in the basic package. > > > > >> > >> But the really > >> great thing is that the FLPackageLoader seems to work quite well too. > > > > > > Awesome. > > > >> > >> I do strongly recommend to add Fuel very early in the development of > >> 1.5 into the basic kernel packages. > > > > > > Indeed. That was the idea for 1.4 but we didn't have time. > > > >> > >> I can not wait to see a Pharo > >> image without the Compiler ;-) > >> > > > > In fact that was one of the things Stef had in mind when he decided to > > support and push Fuel. Because RMOD is working in boostrap and related works > > where you would like to boostrap and grow without a compiler ;) > > I know, but I expected that package loading in Fuel has much wider > dependencies and that it will require a lot of next work. > > -- Pavel > > > > > > > >> > >> -- Pavel > >> > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > >

April 4, 2012