January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Screenshot of Pharo windows

by Adrian Kuhn

Igor Stasenko <siguctua@...> writes: > Ctrl-click on Morph -> add Halo > then click Menu halo button (red one) and chose Export ... jpg, png, gif ,bmp. > It will store its 'screenshot' to that file. Thanks, that is genau what I was looking for! --AA

Jan. 20, 2010

Re: [Pharo-project] Question on recursive structures

by Tudor Girba

Hi, You can force an interrupt by CMD+i or CTRL+i (depending on the platform). Cheers, Doru On 20 Jan 2010, at 01:44, Viktor Kerkez wrote: > Hi, > > Since this is my first post on the list, first I want to thank you > all for the great job you're doing on Pharo :) It was a real > revelation when I discovered it :) > > Now to the question: > > I'm reading the Pharo by Example, and came to this part: > > The problem with deepCopy is that it will not terminate when applied > to a mutually recursive structure: > a1 := { 'harry' }. > a2 := { a1 }. > a1 at: 1 put: a2. > a1 deepCopy â! ... does not terminate! > > (Pharo actually get stuck at the step: a1 at: 1 put: a2. but that's > not the question :) ) > > 1. Isn't this behaviour (the complete environment get stuck and > there is no way to unfreeze it) considered a bug? I mean the > environment shouldn't let you shoot yourself in the foot (at least > not so easily). Actually the same behaviour can be created just > doing: [true] whileTrue: []... > > 2. Shouldn't Pharo recognize recursive structures in some way? > > > I'm asking because I'm coming from a Python world, which is very > similar to smalltalk in some manners and I'm trying to make a big > picture comparison in my head. > > 1. I know that this doesn't really compares to Pharo which is a > graphical environment, but in python you can always hit Ctrl-C and > break the statements that block... > > >>> while True: > ... pass > ... > ^CTraceback (most recent call last): > File "<stdin>", line 1, in <module> > KeyboardInterrupt > >>> > > Shouldn't the UI thread always be responsive? > > 2. And Python recognizes recursive structures: > > >>> a = [] > >>> a > [] > >>> a.append(5 > ... > KeyboardInterrupt > >>> a = [] > >>> a > [] > >>> a.append(5) > >>> a > [5] > >>> a.append(a) > >>> a > [5, [...]] > >>> a[0] > 5 > >>> a[1] > [5, [...]] > >>> a[1][1][1][1][0] > 5 > >>> > > > Don't get me wrong, I'm not trying to start a language war :) I > wouldn't got to page 171 if I'm not really interested in Smalltalk :- > D I'm just trying to get a clearer vision if these are some things > that are there for some reason (design decision), or they are just > not yet implemented, or they cannot be implemented for some other > reasons? > > Thank you in advance for your time :), > Viktor > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Jan. 20, 2010

[Pharo-project] Question on recursive structures

by Viktor Kerkez

Hi, Since this is my first post on the list, first I want to thank you all for the great job you're doing on Pharo :) It was a real revelation when I discovered it :) Now to the question: I'm reading the Pharo by Example, and came to this part: The problem with deepCopy is that it will not terminate when applied to a mutually recursive structure: a1 := { 'harry' }. a2 := { a1 }. a1 at: 1 put: a2. a1 deepCopy â! ... does not terminate! (Pharo actually get stuck at the step: a1 at: 1 put: a2. but that's not the question :) ) 1. Isn't this behaviour (the complete environment get stuck and there is no way to unfreeze it) considered a bug? I mean the environment shouldn't let you shoot yourself in the foot (at least not so easily). Actually the same behaviour can be created just doing: [true] whileTrue: []... 2. Shouldn't Pharo recognize recursive structures in some way? I'm asking because I'm coming from a Python world, which is very similar to smalltalk in some manners and I'm trying to make a big picture comparison in my head. 1. I know that this doesn't really compares to Pharo which is a graphical environment, but in python you can always hit Ctrl-C and break the statements that block... >>> while True: ... pass ... ^CTraceback (most recent call last): File "<stdin>", line 1, in <module> KeyboardInterrupt >>> Shouldn't the UI thread always be responsive? 2. And Python recognizes recursive structures: >>> a = [] >>> a [] >>> a.append(5 ... KeyboardInterrupt >>> a = [] >>> a [] >>> a.append(5) >>> a [5] >>> a.append(a) >>> a [5, [...]] >>> a[0] 5 >>> a[1] [5, [...]] >>> a[1][1][1][1][0] 5 >>> Don't get me wrong, I'm not trying to start a language war :) I wouldn't got to page 171 if I'm not really interested in Smalltalk :-D I'm just trying to get a clearer vision if these are some things that are there for some reason (design decision), or they are just not yet implemented, or they cannot be implemented for some other reasons? Thank you in advance for your time :), Viktor

Jan. 20, 2010

Re: [Pharo-project] O2: tester wanted!

by Mariano Martinez Peck

On Tue, Jan 19, 2010 at 11:03 PM, Alexandre Bergel < alexandre.bergel(a)inria.fr> wrote: > Dear All, > > For people who do not know, O2 is the browser David has implemented in > the last few years. It replaces class-categories on the left-hand side > pane with a list of packages. We are still away from having packages > as real first class entities, but this is a good step toward. Note > that some people find O2 a bit slower than other available code > browsers. > > David and I spent some time on fixing O2. O2 has now no dependencies > to OB anymore. > We would like that people try it and submit bug reports on the google > bug tracker. In a fresh 10505, you can load O2 by evaluating: > > Gofer new squeaksource: 'MetacelloRepository'; package: > 'ConfigurationOfO2'; load. (Smalltalk at: #ConfigurationOfO2) perform: > #loadDefault > > Yes, but be aware that that piece of code load only the core, as you can see here: group: 'default' with: #('Core' ); group: 'Core' with: #( 'OmniBrowser2' 'O2-Standard' 'O2-Morphic' 'O2-Enhancements' ); group: 'Dev' with: #( 'Core' 'O2-Refactory' 'OCForO2' ); As I remember, most of the problems of O2 were sometimes related to the integration to RB. So, if you really want to tests it, please, test it using the RB: ((Smalltalk at: #ConfigurationOfO2) project version: '1.0') load: 'Dev' As I already said to Alexandre and David in private, I will put O2 again in the next image. So, it would be cool if it is tested "completely". > O2 does not need OB whatsoever. O2 loads in a Core (I tried in a > 11165). Before and after loading O2, running OB tests give "548 run, > 547 passes, 1 failures" [*]. > > Yes, if someone can help with that failure would be cool, I have already reported it. > Cheers, > Alexandre > > [*] the test have been loaded using (ConfigurationOfOmniBrowser > project version: '1.1') load: 'Dev Tests' > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 19, 2010

Re: [Pharo-project] O2: tester wanted!

by StÃ©phane Ducasse

Thanks this is good. And yes I did not make any progress on the package rewrite. Doing too much pharo cleaning and project writing. Stef On Jan 19, 2010, at 11:03 PM, Alexandre Bergel wrote: > Dear All, > > For people who do not know, O2 is the browser David has implemented in > the last few years. It replaces class-categories on the left-hand side > pane with a list of packages. We are still away from having packages > as real first class entities, but this is a good step toward. Note > that some people find O2 a bit slower than other available code > browsers. > > David and I spent some time on fixing O2. O2 has now no dependencies > to OB anymore. > We would like that people try it and submit bug reports on the google > bug tracker. In a fresh 10505, you can load O2 by evaluating: > > Gofer new squeaksource: 'MetacelloRepository'; package: > 'ConfigurationOfO2'; load. (Smalltalk at: #ConfigurationOfO2) perform: > #loadDefault > > O2 does not need OB whatsoever. O2 loads in a Core (I tried in a > 11165). Before and after loading O2, running OB tests give "548 run, > 547 passes, 1 failures" [*]. > > Cheers, > Alexandre > > [*] the test have been loaded using (ConfigurationOfOmniBrowser > project version: '1.1') load: 'Dev Tests' > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 19, 2010

[Pharo-project] O2: tester wanted!

by Alexandre Bergel

Dear All, For people who do not know, O2 is the browser David has implemented in the last few years. It replaces class-categories on the left-hand side pane with a list of packages. We are still away from having packages as real first class entities, but this is a good step toward. Note that some people find O2 a bit slower than other available code browsers. David and I spent some time on fixing O2. O2 has now no dependencies to OB anymore. We would like that people try it and submit bug reports on the google bug tracker. In a fresh 10505, you can load O2 by evaluating: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfO2'; load. (Smalltalk at: #ConfigurationOfO2) perform: #loadDefault O2 does not need OB whatsoever. O2 loads in a Core (I tried in a 11165). Before and after loading O2, running OB tests give "548 run, 547 passes, 1 failures" [*]. Cheers, Alexandre [*] the test have been loaded using (ConfigurationOfOmniBrowser project version: '1.1') load: 'Dev Tests' -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 19, 2010

[Pharo-project] [update 1.1] #11172

by StÃ©phane Ducasse

while browsing the trunk of squeak I found some simple fixes.... 11172 ----- - SelectionMenu fix - moving some temp assignment outside blocks (nice squeak) Stef

Jan. 19, 2010

[Pharo-project] about fast lineDo and...

by StÃ©phane Ducasse

Hi nicolas I saw that you commit some speed up for lineending to the squeaktrunk and I would love to have them since in moose we are computing a lot LOC :) By any chance could we get the same in pharo? Else I will harvest them. Stef

Jan. 19, 2010

[Pharo-project] [update 1.1] #11169

by StÃ©phane Ducasse

11169 ----- - Issue 1736: Faster Exception Handling (better for JIT) part one 11170 ----- - Issue 1736: Faster Exception Handling (better for JIT) part Two, three and four a note for historians: since we cannot save the image after loading part two and should load part three and four, I shortcut scriptLoader and just loaded the three versions of the packages one after the others and I could save. [update 1.1] #11171 11171 ----- - syncing correctly packages version in scriptLoader let me know if you get problems. I will work soon on the buffered file stream Stef

Jan. 19, 2010

Re: [Pharo-project] [update 1.1] #11167

by Mariano Martinez Peck

On Tue, Jan 19, 2010 at 9:40 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Mariano, > > I was wondering whether you have a script for Pharo-Dev based on 11167. > > No. Several reasons: 1) The PharoCore 1.1 is not even so stable...imagine a dev 2) The PharoDev 1.0 are not even so stable...imagine a dev 1.1 3) Some external tools do not work in Core 1.1 and maintainers won't make them work until 1.0 is finished and 1.1 is almost finished/stable (I think). However, if you want to do it by yourself and give it a shut, you can try loading the ConfgurationOfPharo and see what happens. The script you have it the image I prepared, but anyway, it is a simple as this: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPharo'; load. ((Smalltalk at: #ConfigurationOfPharo) project version: '1.0-rc2.10505.2') load. Gofer new squeaksource: 'ImageForDevelopers'; package: 'ImageForDevelopers-pharo'; load. > Cheers, > Alexandre > > > On 19 Jan 2010, at 15:08, Mariano Martinez Peck wrote: > > > 945 has to be in 1.0 also. > > > > On Tue, Jan 19, 2010 at 7:06 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr > > > wrote: > > > > 11167 > > ----- > > > > - Issue 945: Annoying bug: > > UndefinedObject(Object)>>doesNotUnderstand: #mimeTypes > > -polymorph updates > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 19, 2010