October 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Can this be improved in Glamourous?

by Mariano Martinez Peck

On Sat, Oct 15, 2011 at 11:37 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Btw, you can download a ready-made image with the GlamorousToolkit from: > > http://ci.moosetechnology.org/job/glamorous-toolkit-latest-dev/lastSuccessf… > > Thanks. And why that one is not broken ? how do you load it ? > Cheers, > Doru > > > On 15 Oct 2011, at 23:32, Tudor Girba wrote: > > > Hi, > > > > On 15 Oct 2011, at 23:13, StÃ©phane Ducasse wrote: > > > >> > >> On Oct 15, 2011, at 10:58 PM, Tudor Girba wrote: > >> > >>> Hi, > >>> > >>> On 15 Oct 2011, at 22:36, Mariano Martinez Peck wrote: > >>> > >>>> Hi Tudor. Today I wanted to give it a try to 'GT-Inspector' > 'GT-Playground' hence I did: > >>> > >>> I am happy you decided to give them a try :). But, the Playground is > not yet ready :). > >>> > >>>> (ConfigurationOfGlamoroust project version: #bleedingEdge) load: > #('GT-Inspector' 'GT-Playground' ). > >>>> > >>>> In a Pharo 1.3 release. To my surprise, it took like half an hour to > install, and it even was broken because it installed a different version of > refactoring browser that is not working in 1.3. > >>> > >>> This is due to a broken ConfiguraitonOfRB. I would actually be very > interested in a fix in this area. > >> > >> what is broken? because I spent one full sprint to fix it. > > > > Actually it is not broken. Something else is broken by loading an older > version somewhere in the Moose configuration. I did not have time yet. > > > >>>> So..can I ask.. are all of those projects really needed just for 2 > simples things like a cool inspector and a cool workspace? > >>>> do you need Nile, Grease, RefactoringBrowser, EyeSee, Magritte ??? > >>>> can I somehow just load a minimal core for those things I need ? > >>> > >>> These projects are loaded by the full default ConfigurationOfGlamour. > The ConfigurationOfGlamour offers groups, but the GlamorousToolikt one does > not yet. If someone can tell me how to do something like this, I would be > happy to accommodate the solution. > >> > >> in the chapter on metacello groups are explained. I can send you the > latest version if you want. > > > > I know how they work. I was actually referring to the actual code :). It > is such a big mess to deal with the explosion of combinations. > > > > Doru > > > > > >>> Cheers, > >>> Doru > >>> > >>> > >>>> Thanks > >>>> > >>>> linear load : > >>>> linear load : baseline-0.1 [ConfigurationOfGlamoroust] > >>>> load : ConfigurationOfGlamour > >>>> atomic load : baseline-0.1 [ConfigurationOfGlamoroust] > >>>> linear load : default [ConfigurationOfGlamour] > >>>> load : ConfigurationOfEyeSee > >>>> linear load : default [ConfigurationOfGlamour] > >>>> load : ConfigurationOfGrease > >>>> linear load : default [ConfigurationOfGlamour] > >>>> load : ConfigurationOfMondrian > >>>> linear load : default [ConfigurationOfGlamour] > >>>> load : ConfigurationOfShout > >>>> atomic load : default [ConfigurationOfGlamour] > >>>> load : CollectionExtensions > >>>> load : Glamour-Announcements > >>>> load : Glamour-Helpers > >>>> load : Glamour-Core > >>>> load : Glamour-Presentations > >>>> load : Glamour-Browsers > >>>> load : Glamour-Tests-Core > >>>> load : Glamour-Morphic-Theme > >>>> load : Glamour-Examples > >>>> load : Glamour-Tools > >>>> load : Glamour-Morphic-Widgets > >>>> load : Glamour-Morphic-Renderer > >>>> load : Glamour-Tests-Morphic > >>>> linear load : default [ConfigurationOfMondrian] > >>>> load : ConfigurationOfProfStef > >>>> linear load : default [ConfigurationOfMondrian] > >>>> load : ConfigurationOfHealthReportProducer > >>>> linear load : default [ConfigurationOfMondrian] > >>>> load : ConfigurationOfShapeST80 > >>>> atomic load : default [ConfigurationOfMondrian] > >>>> atomic load : 0.2-baseline > [ConfigurationOfHealthReportProducer] > >>>> load : HealthReportProducer > >>>> load : CollectionExtensions > >>>> load : Nile-Base > >>>> load : Mondrian-ComplexShape > >>>> load : Mondrian-Core > >>>> load : Mondrian-Layouts > >>>> load : Mondrian-Help > >>>> load : Mondrian-Easel > >>>> load : Mondrian-Pharo-Tests > >>>> load : Mondrian-Shapes > >>>> load : Mondrian-Events > >>>> load : Mondrian-Visitor > >>>> load : Mondrian-Util > >>>> load : Mondrian-Normalizers > >>>> load : Mondrian-Example > >>>> load : Mondrian-ShapeVisitor > >>>> load : Mondrian-Pharo-Morphic > >>>> load : Mondrian-Tests > >>>> load : Mondrian-FADELayout > >>>> load : Glamour-Mondrian-Presentations > >>>> load : Glamour-Tests-Mondrian > >>>> atomic load : default [ConfigurationOfEyeSee] > >>>> load : EyeSee-Events > >>>> load : EyeSee-Axis > >>>> load : EyeSee-Tests-Core > >>>> load : EyeSee-Support > >>>> load : EyeSee-Core > >>>> load : Glamour-EyeSee-Presentations > >>>> load : Glamour-Tests-EyeSee > >>>> linear load : 1.0.6.1 [ConfigurationOfGrease] > >>>> load : ConfigurationOfRefactoringBrowser > >>>> linear load : 1.0.6.1 [ConfigurationOfGrease] > >>>> load : Grease-Slime-lr.13 > >>>> load : Magritte-Model > >>>> load : Magritte-Pharo-Model > >>>> load : Magritte-Morph > >>>> load : Glamour-Magritte-Presentations > >>>> load : Magritte-Tests-Model > >>>> load : GT-Playground > >>>> load : GT-Inspector > >>>> > >>>> -- > >>>> Mariano > >>>> http://marianopeck.wordpress.com > >>>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Every successful trip needs a suitable vehicle." > >>> > >>> > >>> > >>> > >>> > >> > >> > > > > -- > > www.tudorgirba.com > > > > "One cannot do more than one can do." > > > > > > > > -- > www.tudorgirba.com > > "Obvious things are difficult to teach." > > > > > -- Mariano http://marianopeck.wordpress.com

Oct. 16, 2011

Re: [Pharo-project] Can this be improved in Glamourous?

by Mariano Martinez Peck

On Sat, Oct 15, 2011 at 11:32 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > On 15 Oct 2011, at 23:13, StÃ©phane Ducasse wrote: > > > > > On Oct 15, 2011, at 10:58 PM, Tudor Girba wrote: > > > >> Hi, > >> > >> On 15 Oct 2011, at 22:36, Mariano Martinez Peck wrote: > >> > >>> Hi Tudor. Today I wanted to give it a try to 'GT-Inspector' > 'GT-Playground' hence I did: > >> > >> I am happy you decided to give them a try :). But, the Playground is not > yet ready :). > >> > >>> (ConfigurationOfGlamoroust project version: #bleedingEdge) load: > #('GT-Inspector' 'GT-Playground' ). > >>> > >>> In a Pharo 1.3 release. To my surprise, it took like half an hour to > install, and it even was broken because it installed a different version of > refactoring browser that is not working in 1.3. > >> > >> This is due to a broken ConfiguraitonOfRB. I would actually be very > interested in a fix in this area. > > > > what is broken? because I spent one full sprint to fix it. > > Actually it is not broken. Something else is broken by loading an older > version somewhere in the Moose configuration. I did not have time yet. > > >>> So..can I ask.. are all of those projects really needed just for 2 > simples things like a cool inspector and a cool workspace? > >>> do you need Nile, Grease, RefactoringBrowser, EyeSee, Magritte ??? > >>> can I somehow just load a minimal core for those things I need ? > >> > >> These projects are loaded by the full default ConfigurationOfGlamour. > The ConfigurationOfGlamour offers groups, but the GlamorousToolikt one does > not yet. If someone can tell me how to do something like this, I would be > happy to accommodate the solution. > > > > in the chapter on metacello groups are explained. I can send you the > latest version if you want. > > I know how they work. I was actually referring to the actual code :). It is > such a big mess to deal with the explosion of combinations. > > Well, I guess that if you don't know then nobody knows. I mean, Moose is your project ;) you know better than us its dependencies. Cheers > Doru > > > >> Cheers, > >> Doru > >> > >> > >>> Thanks > >>> > >>> linear load : > >>> linear load : baseline-0.1 [ConfigurationOfGlamoroust] > >>> load : ConfigurationOfGlamour > >>> atomic load : baseline-0.1 [ConfigurationOfGlamoroust] > >>> linear load : default [ConfigurationOfGlamour] > >>> load : ConfigurationOfEyeSee > >>> linear load : default [ConfigurationOfGlamour] > >>> load : ConfigurationOfGrease > >>> linear load : default [ConfigurationOfGlamour] > >>> load : ConfigurationOfMondrian > >>> linear load : default [ConfigurationOfGlamour] > >>> load : ConfigurationOfShout > >>> atomic load : default [ConfigurationOfGlamour] > >>> load : CollectionExtensions > >>> load : Glamour-Announcements > >>> load : Glamour-Helpers > >>> load : Glamour-Core > >>> load : Glamour-Presentations > >>> load : Glamour-Browsers > >>> load : Glamour-Tests-Core > >>> load : Glamour-Morphic-Theme > >>> load : Glamour-Examples > >>> load : Glamour-Tools > >>> load : Glamour-Morphic-Widgets > >>> load : Glamour-Morphic-Renderer > >>> load : Glamour-Tests-Morphic > >>> linear load : default [ConfigurationOfMondrian] > >>> load : ConfigurationOfProfStef > >>> linear load : default [ConfigurationOfMondrian] > >>> load : ConfigurationOfHealthReportProducer > >>> linear load : default [ConfigurationOfMondrian] > >>> load : ConfigurationOfShapeST80 > >>> atomic load : default [ConfigurationOfMondrian] > >>> atomic load : 0.2-baseline > [ConfigurationOfHealthReportProducer] > >>> load : HealthReportProducer > >>> load : CollectionExtensions > >>> load : Nile-Base > >>> load : Mondrian-ComplexShape > >>> load : Mondrian-Core > >>> load : Mondrian-Layouts > >>> load : Mondrian-Help > >>> load : Mondrian-Easel > >>> load : Mondrian-Pharo-Tests > >>> load : Mondrian-Shapes > >>> load : Mondrian-Events > >>> load : Mondrian-Visitor > >>> load : Mondrian-Util > >>> load : Mondrian-Normalizers > >>> load : Mondrian-Example > >>> load : Mondrian-ShapeVisitor > >>> load : Mondrian-Pharo-Morphic > >>> load : Mondrian-Tests > >>> load : Mondrian-FADELayout > >>> load : Glamour-Mondrian-Presentations > >>> load : Glamour-Tests-Mondrian > >>> atomic load : default [ConfigurationOfEyeSee] > >>> load : EyeSee-Events > >>> load : EyeSee-Axis > >>> load : EyeSee-Tests-Core > >>> load : EyeSee-Support > >>> load : EyeSee-Core > >>> load : Glamour-EyeSee-Presentations > >>> load : Glamour-Tests-EyeSee > >>> linear load : 1.0.6.1 [ConfigurationOfGrease] > >>> load : ConfigurationOfRefactoringBrowser > >>> linear load : 1.0.6.1 [ConfigurationOfGrease] > >>> load : Grease-Slime-lr.13 > >>> load : Magritte-Model > >>> load : Magritte-Pharo-Model > >>> load : Magritte-Morph > >>> load : Glamour-Magritte-Presentations > >>> load : Magritte-Tests-Model > >>> load : GT-Playground > >>> load : GT-Inspector > >>> > >>> -- > >>> Mariano > >>> http://marianopeck.wordpress.com > >>> > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every successful trip needs a suitable vehicle." > >> > >> > >> > >> > >> > > > > > > -- > www.tudorgirba.com > > "One cannot do more than one can do." > > > > > -- Mariano http://marianopeck.wordpress.com

Oct. 16, 2011

Re: [Pharo-project] TWM doesn't work without keymappins and keymappings doesn't work

by Mariano Martinez Peck

Thanks Laurent. It is working. Maybe you can show the shortcuts lists from some menu or somewhere from TWM? otherwise none user will ever see it ... thanks! On Sun, Oct 16, 2011 at 2:49 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > On Sun, Oct 16, 2011 at 12:32 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Thanks Guille for the whole work :) >> >> Laurent: let me know when I can use TWM properly with this latest version >> of keymappings. >> > > > There's a new (development) version: > - package TWM split into several packages > - KeyMapping 2.0 > - TWM shortcut prefix is now Cmd+r (see TWMKeymapping class>>#shortcuts > for default shortcuts. Feel free to adapt and suggests better ones). > - You can load TWM without KeyMapping > using: ConfigurationOfTilingWindowManager loadDevelopmentWithoutKeyMapping. > > As a side note, this is the configuration I use in my Pharo images: > > Gofer it > squeaksource: 'TilingWindowManager'; > package: 'ConfigurationOfTilingWindowManager'; > load. > (Smalltalk at:#ConfigurationOfTilingWindowManager) loadDevelopment. > (Smalltalk at:#TWMUITheme) beCurrent. > TaskbarMorph showTaskbar: false. > TasklistMorph keepOpen: true. > (Smalltalk at:#TWMBar) perform: #showTWMBar: with: true. > > > Cheers, > > Laurent Laffont > > >> >> Thanks guys >> >> >> On Sun, Oct 16, 2011 at 10:11 AM, laurent laffont < >> laurent.laffont(a)gmail.com> wrote: >> >>> >>>>> >>>> OK so cmd+w is definitely not a good prefix for TWM shortcuts. Is cmd+m >>>> better ? >>>> >>>> >>> oups Cmd+m not a good idea :) I struggle to find a good prefix..... >>> >>> Laurent. >>> >>> >>> >>> >>> >>>> >>>> >>>>> So i installed TWM without keybinding but now I cannot open the >>>>>> settings window because keymappings is not load. >>>>>> >>>>>> Any solution? (install TWM without keymappings or fixing keymappings) >>>>>> >>>>> >>>>> I've done some fixes and improvements to keymapping, and I've created a >>>>> 2.0 version where: >>>>> >>>>> - the collisions below are fixed >>>>> - keymaps can be configured per morph instance too (not only per class, >>>>> as the former version) >>>>> - some little improvements and code cleaning >>>>> >>>> >>>> >>>> Thanks ! >>>> >>>> >>>> But those things I remarked of TWM should be reviewed :) >>>>> >>>>> Or you can Use twm without keymappings and I'll have no more feedback >>>>> :( >>>>> >>>> >>>> >>>> TWM without Keymapping is not really interesting. I will produce new >>>> versions of TWM. >>>> >>>> Laurent >>>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> thanks! >>>>>> >>>>> >>>>> Thank you :) >>>>> >>>>> Guille >>>>> >>>> >>>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > -- Mariano http://marianopeck.wordpress.com

Oct. 16, 2011

Re: [Pharo-project] Fwd: trying to understand loops in pharo

by Eliot Miranda

On Sun, Oct 16, 2011 at 10:09 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Well, the inlined to:do: doesn't behave the same as non inlined one: > > |result| > result := String new. > 1 to: 10 do: [:n | result := result, n printString, ' '] yourself. > > --> 1 > > The inlined byte code is explicitely returning nil (at byte 60) > > (Compiler new > compileNoPattern: '|result| > result := String new. > 1 to: 10 do: [:n | result := result, n printString, '' '']' > in: Object context: nil notifying: nil > ifFail: nil) generateWithTempNames. > > > 37 <40> pushLit: String > 38 <CC> send: new > 39 <68> popIntoTemp: 0 > 40 <76> pushConstant: 1 > 41 <69> popIntoTemp: 1 > 42 <11> pushTemp: 1 > 43 <24> pushConstant: 10 > 44 <B4> send: <= > 45 <AC 0D> jumpFalse: 60 > 47 <10> pushTemp: 0 > 48 <11> pushTemp: 1 > 49 <D2> send: printString > 50 <E1> send: , > 51 <23> pushConstant: ' ' > 52 <E1> send: , > 53 <68> popIntoTemp: 0 > 54 <11> pushTemp: 1 > 55 <76> pushConstant: 1 > 56 <B0> send: + > 57 <69> popIntoTemp: 1 > 58 <A3 EE> jumpTo: 42 > 60 <73> pushConstant: nil > 61 <7C> returnTop > > Which return value would be useful? > That's not the right question. IMO the compiler should answer the same result as the non-inlined one when the return value is asked for. Arguably the non-inline version needs to be commented to specify that it returns the value it does (in this case self), and that the compiler's optimiser reflects this. > > Nicolas > > 2011/10/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > A friend of mine ask me the following > > > > |result| > > result := String new. > > 1 to: 10 do: [:n | result := result, n printString, ' ']. > > I am trying to do or print this code. It prints 'nil' instead of a > > collection. Its an example from PBE book. > > do you know the reason? > > although this one's working: > > result := String new. > > (1 to: 10) do: [:n | result := result, n printString, ' ']. > > > > I checked the implementation > > Interval>>do: aBlock > > "Evaluate aBlock for each value of the interval. > > Implementation note: instead of repeatedly incrementing the value > > aValue := aValue + step. > > until stop is reached, > > We prefer to recompute value from start > > aValue := start + (index * step). > > This is better for floating points accuracy, while not degrading Integer > and > > Fraction speed too much. > > Moreover, this is consistent with methods #at: and #size" > > | aValue index size | > > index := 0. > > size := self size. > > [index < size] > > whileTrue: [aValue := start + (index * step). > > index := index + 1. > > aBlock value: aValue] > > > > Number>>to: stop do: aBlock > > "Normally compiled in-line, and therefore not overridable. > > Evaluate aBlock for each element of the interval (self to: stop by: 1)." > > | nextValue | > > nextValue := self. > > [nextValue <= stop] > > whileTrue: > > [aBlock value: nextValue. > > nextValue := nextValue + 1] > > > > any further idea than := value is different from value: > > Stef > > -- best, Eliot

Oct. 16, 2011

Re: [Pharo-project] Fwd: trying to understand loops in pharo

by Schwab,Wilhelm K

I usually run a little on the cowardly side and try to avoid depending on most-recently-evaluated behavior, because it is easy to break it in subsequent revision. However, I *think* that the value of the most-recently-evaluated expression is what one expects in situations like this. #inject:into: is where I typically encounter it. HTH, Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Sunday, October 16, 2011 1:09 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: trying to understand loops in pharo Well, the inlined to:do: doesn't behave the same as non inlined one: |result| result := String new. 1 to: 10 do: [:n | result := result, n printString, ' '] yourself. --> 1 The inlined byte code is explicitely returning nil (at byte 60) (Compiler new compileNoPattern: '|result| result := String new. 1 to: 10 do: [:n | result := result, n printString, '' '']' in: Object context: nil notifying: nil ifFail: nil) generateWithTempNames. 37 <40> pushLit: String 38 <CC> send: new 39 <68> popIntoTemp: 0 40 <76> pushConstant: 1 41 <69> popIntoTemp: 1 42 <11> pushTemp: 1 43 <24> pushConstant: 10 44 <B4> send: <= 45 <AC 0D> jumpFalse: 60 47 <10> pushTemp: 0 48 <11> pushTemp: 1 49 <D2> send: printString 50 <E1> send: , 51 <23> pushConstant: ' ' 52 <E1> send: , 53 <68> popIntoTemp: 0 54 <11> pushTemp: 1 55 <76> pushConstant: 1 56 <B0> send: + 57 <69> popIntoTemp: 1 58 <A3 EE> jumpTo: 42 60 <73> pushConstant: nil 61 <7C> returnTop Which return value would be useful? Nicolas 2011/10/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > A friend of mine ask me the following > > |result| > result := String new. > 1 to: 10 do: [:n | result := result, n printString, ' ']. > I am trying to do or print this code. It prints 'nil' instead of a > collection. Its an example from PBE book. > do you know the reason? > although this one's working: > result := String new. > (1 to: 10) do: [:n | result := result, n printString, ' ']. > > I checked the implementation > Interval>>do: aBlock > "Evaluate aBlock for each value of the interval. > Implementation note: instead of repeatedly incrementing the value > aValue := aValue + step. > until stop is reached, > We prefer to recompute value from start > aValue := start + (index * step). > This is better for floating points accuracy, while not degrading Integer and > Fraction speed too much. > Moreover, this is consistent with methods #at: and #size" > | aValue index size | > index := 0. > size := self size. > [index < size] > whileTrue: [aValue := start + (index * step). > index := index + 1. > aBlock value: aValue] > > Number>>to: stop do: aBlock > "Normally compiled in-line, and therefore not overridable. > Evaluate aBlock for each element of the interval (self to: stop by: 1)." > | nextValue | > nextValue := self. > [nextValue <= stop] > whileTrue: > [aBlock value: nextValue. > nextValue := nextValue + 1] > > any further idea than := value is different from value: > Stef

Oct. 16, 2011

Re: [Pharo-project] Fwd: trying to understand loops in pharo

by Nicolas Cellier

Well, the inlined to:do: doesn't behave the same as non inlined one: |result| result := String new. 1 to: 10 do: [:n | result := result, n printString, ' '] yourself. --> 1 The inlined byte code is explicitely returning nil (at byte 60) (Compiler new compileNoPattern: '|result| result := String new. 1 to: 10 do: [:n | result := result, n printString, '' '']' in: Object context: nil notifying: nil ifFail: nil) generateWithTempNames. 37 <40> pushLit: String 38 <CC> send: new 39 <68> popIntoTemp: 0 40 <76> pushConstant: 1 41 <69> popIntoTemp: 1 42 <11> pushTemp: 1 43 <24> pushConstant: 10 44 <B4> send: <= 45 <AC 0D> jumpFalse: 60 47 <10> pushTemp: 0 48 <11> pushTemp: 1 49 <D2> send: printString 50 <E1> send: , 51 <23> pushConstant: ' ' 52 <E1> send: , 53 <68> popIntoTemp: 0 54 <11> pushTemp: 1 55 <76> pushConstant: 1 56 <B0> send: + 57 <69> popIntoTemp: 1 58 <A3 EE> jumpTo: 42 60 <73> pushConstant: nil 61 <7C> returnTop Which return value would be useful? Nicolas 2011/10/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > A friend of mine ask me the following > > |result| > result := String new. > 1 to: 10 do: [:n | result := result, n printString, ' ']. > I am trying to do or print this code. It prints 'nil' instead of a > collection. Its an example from PBE book. > do you know the reason? > although this one's working: > result := String new. > (1 to: 10) do: [:n | result := result, n printString, ' ']. > > I checked the implementation > Interval>>do: aBlock > "Evaluate aBlock for each value of the interval. > Implementation note: instead of repeatedly incrementing the value > aValue := aValue + step. > until stop is reached, > We prefer to recompute value from start > aValue := start + (index * step). > This is better for floating points accuracy, while not degrading Integer and > Fraction speed too much. > Moreover, this is consistent with methods #at: and #size" > | aValue index size | > index := 0. > size := self size. > [index < size] > whileTrue: [aValue := start + (index * step). > index := index + 1. > aBlock value: aValue] > > Number>>to: stop do: aBlock > "Normally compiled in-line, and therefore not overridable. > Evaluate aBlock for each element of the interval (self to: stop by: 1)." > | nextValue | > nextValue := self. > [nextValue <= stop] > whileTrue: > [aBlock value: nextValue. > nextValue := nextValue + 1] > > any further idea than := value is different from value: > Stef

Oct. 16, 2011

[Pharo-project] [update 1.4] #14198

by StÃ©phane Ducasse

14198 ----- - better unsubscribe for SystemAnnouncer - removing support for pre methodReference list.... so long time ago.

Oct. 16, 2011

[Pharo-project] [update 1.4] #14197

by StÃ©phane Ducasse

14197 ----- - Issue 4905: Clean SystemAnnouncement private/public. - Issue 4912: Float infinity and Float nan should print themselves. Float are self evaluating finally.

Oct. 16, 2011

[Pharo-project] Fwd: trying to understand loops in pharo

by StÃ©phane Ducasse

A friend of mine ask me the following > |result| > result := String new. > 1 to: 10 do: [:n | result := result, n printString, ' ']. > > I am trying to do or print this code. It prints 'nil' instead of a collection. Its an example from PBE book. > do you know the reason? > > although this one's working: > > result := String new. > (1 to: 10) do: [:n | result := result, n printString, ' ']. I checked the implementation Interval>>do: aBlock "Evaluate aBlock for each value of the interval. Implementation note: instead of repeatedly incrementing the value aValue := aValue + step. until stop is reached, We prefer to recompute value from start aValue := start + (index * step). This is better for floating points accuracy, while not degrading Integer and Fraction speed too much. Moreover, this is consistent with methods #at: and #size" | aValue index size | index := 0. size := self size. [index < size] whileTrue: [aValue := start + (index * step). index := index + 1. aBlock value: aValue] Number>>to: stop do: aBlock "Normally compiled in-line, and therefore not overridable. Evaluate aBlock for each element of the interval (self to: stop by: 1)." | nextValue | nextValue := self. [nextValue <= stop] whileTrue: [aBlock value: nextValue. nextValue := nextValue + 1] any further idea than := value is different from value: Stef

Oct. 16, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by StÃ©phane Ducasse

On Oct 16, 2011, at 4:05 PM, Schwab,Wilhelm K wrote: > Stef, Mariano, > > There are obvious advantages to a development phase during which serialized streams are at risk. At some point, I suspect Fuel will have to take the reading of old streams as a nearly sacred obligation. Otherwise, it sounds like a cheap horror movie series: "Fuel II: Your data go in, but they don't come out." With Fuel II no zombies :) Fuel III the zombies are dead again :) > I am using humor to make a point, not to ridicule you. I read the paper, and learned a LOT. Please see my post from yesterday referring to Dolphin's #environment. You might be able to simply facade old formats into a coherent backwardly-compatible whole. Without some attention to that, there are going to be projects that will not adopt Fuel. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] > Sent: Sunday, October 16, 2011 9:03 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] When will Fuel file format stabilize? > > On Sun, Oct 16, 2011 at 3:01 PM, Mariano Martinez Peck <marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>> wrote: > > > On Sun, Oct 16, 2011 at 2:03 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: > Mariano I think that the point that Philippe (our national butcher) is trying to make is the following: > If by design a serializer takes the perspective that it will be able to load old formats and ensure > evolution all the time then you have a really cool serializer. > > Yes, I know. The problem is if it is worth it. The effort of providing such feature could be too much in compare to just load a previous version, materialize, load new version, and serialize again. > > > Now why in fuel it is not possible to have > FuelMaterializer load: aFile > > load using the default = current format > > > FuelMaterializer load: aFile asOfVersion: 1.4 > Of course this can be much slower but when you want to load data of the past you are just happy that this is > working. > > So would not be possible to > milestone formats > get the default working fast > get old version loading slowler but loading. > > > It sounds easy, but at least from what I can see this is very complicated. > Do you know a serializer that support this? Lets clarify with an example: > > > (of course, without putting all along the code IFs like (version > 2) ifTrue: [blabla] ) > > > I serialize graph X with Fuel 1.4 in Pharo 1.1. > Then I am in Pharo 1.3 with Fuel 1.7 and I want to materialize X. Fuel 1.4 doesn't load anymore in Pharo 1.3, so you have to use Fuel 1.7. > So you want to be able to take Fuel 1.7 and materialize X "using version 1.4" without even loading 1.4 (because it doesn't load) ? > > Thanks > > > Because then we get a win win situation. > Stef > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com > >

Oct. 16, 2011