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

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

by StÃ©phane Ducasse

cool Stef On Mar 30, 2012, at 12:47 AM, 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 #@) how do you see that with the explorer? > â¢ 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>

March 30, 2012

Re: [Pharo-project] Emergency evaluator pops up on red tests

by StÃ©phane Ducasse

did you try to run on single test manually Test debug:#l';l;k;lk;l2 Stef On Mar 30, 2012, at 1:28 PM, Fabrizio Perin wrote: > Hi, > I loaded all my stuff in the latest moose based on 1.4. > All the tests of my PetitPHPParser are red. When I click on one red method the emergency evaluator pops up. > > To reproduce it: > 1- grab the latest MooseJee from the ci: > http://ci.moosetechnology.org/job/moose-latest-dev/ > > 2- load the petit php parser: > Gofer new > squeaksource: 'PetitPHPParser'; > package: 'ConfigurationOfPetitPHPParser'; > load. > (Smalltalk at: #ConfigurationOfPetitPHPParser) perform: #loadDefault. > > 3- Run the tests of the php parser and click on any red method. > > How can I debug the problem? Any suggestions on how to proceed? > > Thanks, > Fabrizio >

March 30, 2012

Re: [Pharo-project] do we condense changes and declare 1.4 alpha -> 1.4 release ?

by StÃ©phane Ducasse

On Mar 29, 2012, at 10:17 PM, csrabak(a)bol.com.br wrote: > Wouldn't the natural pace of the Things require to declare it 1.4 beta, first? No :) Stef > > I'm for condensing and releasing. > > -- > Cesar Rabak > > > Em 29/03/2012 15:12, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: > Hi > > do we condense changes and declare 1.4 alpha -> 1.4 release ? > > Stef > > >

March 30, 2012

[Pharo-project] Emergency evaluator pops up on red tests

by Fabrizio Perin

Hi, I loaded all my stuff in the latest moose based on 1.4. All the tests of my PetitPHPParser are red. When I click on one red method the emergency evaluator pops up. To reproduce it: 1- grab the latest MooseJee from the ci: http://ci.moosetechnology.org/job/moose-latest-dev/ 2- load the petit php parser: Gofer new squeaksource: 'PetitPHPParser'; package: 'ConfigurationOfPetitPHPParser'; load. (Smalltalk at: #ConfigurationOfPetitPHPParser) perform: #loadDefault. 3- Run the tests of the php parser and click on any red method. How can I debug the problem? Any suggestions on how to proceed? Thanks, Fabrizio

March 30, 2012

Re: [Pharo-project] vm crash - code snippet provided

by Francisco Garau

No problem I read your reply several times but couldn't make much sense of it... - Francisco On 30 Mar 2012, at 11:54, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 27 March 2012 19:52, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 26 March 2012 01:54, Francisco Garau <francisco.garau(a)gmail.com> wrote: >>> It's used to "animate" the morphs, apparently. >>> >>> The crash happens quite easily by dragging a big window out of the screen >>> (to the left). You either get a debugger or the vm crashes. >>> >>> I just want to point out that before the VM crashes, there is a bug in >>> Smalltalk-land; an Number is appearing where a Point is expected. >>> >> >> Yeah.. i am aware of that. >> It looks like i should spend some time and fix my precious demo to >> check bounds before blindly copying bits from opengl buffer to >> Display. >> I described the problem in previous discussion, and i know what >> exactly should be done... but i haven't time to address that.. i have >> more important things to do. >> >> Just want to repeat again: That demo was just for the DEMO purposes.. >> it was not designed for general purpose.. >> It would be nice if someone could spend time improving it and getting >> rid of obvious mistakes, like missed range checking. >> >> But till then, take it with grain and salt. >> > > ooops.. sorry.. just found that i posted this reply in different , > unrelated topic. > :) > >>> - Francisco >> >> >> -- >> Best regards, >> Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko. >

March 30, 2012

Re: [Pharo-project] vm crash - code snippet provided

by Igor Stasenko

On 27 March 2012 19:52, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 March 2012 01:54, Francisco Garau <francisco.garau(a)gmail.com> wrote: >> It's used to "animate" the morphs, apparently. >> >> The crash happens quite easily by dragging a big window out of the screen >> (to the left). You either get a debugger or the vm crashes. >> >> I just want to point out that before the VM crashes, there is a bug in >> Smalltalk-land; an Number is appearing where a Point is expected. >> > > Yeah.. i am aware of that. > It looks like i should spend some time and fix my precious demo to > check bounds before blindly copying bits from opengl buffer to > Display. > I described the problem in previous discussion, and i know what > exactly should be done... but i haven't time to address that.. i have > more important things to do. > > Just want to repeat again: That demo was just for the DEMO purposes.. > it was not designed for general purpose.. > It would be nice if someone could spend time improving it and getting > rid of obvious mistakes, like missed range checking. > > But till then, take it with grain and salt. > ooops.. sorry.. just found that i posted this reply in different , unrelated topic. :) >> - Francisco > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

March 30, 2012

Re: [Pharo-project] direct object manipulation

by Igor Stasenko

On 29 March 2012 20:02, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> AthensCairoSurfaceExamples example1. complains that the function is not available. The error has been raised by NBFFICallout. >>> Is there something obvious I am missing? >>> >> did you installed cairo library (32bit)? >> it is separate step. >> >> sudo port install cairo +universal > > I didn't, but wait. What does this intall? Why not to simply package the libraries with the VM? because it is a third-party library. To me, your proposal sounds similar to "why not simply package Operating System libraries with the VM". Because in this case you need cairo. But in case of OpenGL, you will need opengl libs.. so "package everything" goes nowhere. > I tried once to use port/fink and I broke the internal of OSX, after having downloaded 500 Mb. > i know that using external libs sometimes is painful. But this is like that. And we're not alone with these problems. I think there's many other software which have to deal with it. Another solution is to implement everything by own :) > Alexandre > -- Best regards, Igor Stasenko.

March 30, 2012

Re: [Pharo-project] moving a ChangeSet into Monticello

by phil＠highoctane.be

This link may help: Monticello <https://gforge.inria.fr/frs/download.php/27018/Monticello.pdf> It is part of Pharo by Example version 2 (out one of these days...) I picked it from http://pharobyexample.org/ KR Phil 2012/3/30 Guillermo Polito <guillermopolito(a)gmail.com> > Hi! > > Monticello works with packages. So if you want to save your things > separately, you have to have different packages :). > So, import your changesets into different categories, and then in the mc > browser create one package for each category. > > And that should do it. > > Guille > > > On Fri, Mar 30, 2012 at 11:06 AM, Francisco Garau < > francisco.garau(a)gmail.com> wrote: > >> Sorry for the basic question about Monticello. >> >> I have 3 ChangeSets which I'd prefer to keep separate -- how can I put >> them into a central code repository? >> >> I've found no easy way of telling Monticello to read an existing >> ChangeSet. >> >> Any hint is appreciated. >> >> - Francisco >> > > -- Philippe Back "Helping you hit the top 3 outcomes you really want to achieve" Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges

March 30, 2012

Re: [Pharo-project] moving a ChangeSet into Monticello

by Guillermo Polito

Hi! Monticello works with packages. So if you want to save your things separately, you have to have different packages :). So, import your changesets into different categories, and then in the mc browser create one package for each category. And that should do it. Guille On Fri, Mar 30, 2012 at 11:06 AM, Francisco Garau <francisco.garau(a)gmail.com > wrote: > Sorry for the basic question about Monticello. > > I have 3 ChangeSets which I'd prefer to keep separate -- how can I put > them into a central code repository? > > I've found no easy way of telling Monticello to read an existing > ChangeSet. > > Any hint is appreciated. > > - Francisco >

March 30, 2012

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

by Guillermo Polito

For OB, there is an stable version published with the metacello configuration. But it is not receiving a constant manteinance. For Nautilus, you will also find an stable metacello configuration, and currently there is work on it to enhance it and make it work in the current pharo images. On Fri, Mar 30, 2012 at 10:53 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > No, no problem. Just that my 1.3 OneClick defaulted to OB. > OB is way better for working with code when compared to the default thing. > What should I look for? Nautilus? OB? All this looks like a tad confusing. > > > 2012/3/30 Guillermo Polito <guillermopolito(a)gmail.com> > >> >> >> On Fri, Mar 30, 2012 at 10:15 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: >> >>> The browser is looking weird. >>> Which one is it? No OB package view anymore? >>> >> >> It is the default System Browser, no OB. You can donwload OB by yourself >> using the ConfigurationOfOmniBrowser from MetacelloRepository. >> >> Ask if you need help :). >> >> Guille >> >> >>> >>> >>> 2012/3/30 Marcus Denker <marcus.denker(a)inria.fr> >>> >>>> >>>> >>>> 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 >>>> >>>> >>>> >>> >>> >>> -- >>> Philippe Back >>> "Helping you hit the top 3 outcomes you really want to achieve" >>> >>> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: >>> phil(a)highoctane.be | Web: http://philippeback.eu | Blog: >>> http://philippeback.be >>> >>> High Octane SPRL >>> rue cour Boisacq 101 >>> 1301 Bierges >>> >>> >> > > > -- > Philippe Back > "Helping you hit the top 3 outcomes you really want to achieve" > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: > http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > >

March 30, 2012