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

Re: [Pharo-project] [1.4] Doing a #condenseChanges in #14158

by Henrik Sperre Johansen

On 20.09.2011 21:32, Eliot Miranda wrote: > > > On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> > wrote: > > On 20.09.2011 14:49, Marcus Denker wrote: > > Hi, > > The .changes have gotten really large... (32MB...) > > So I will do a condense in the next update. > > NOTE: this will take quite some time to finish, so maybe wait > for a pre-built image or Jenkins... > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > > Noooooooooo, please please don't... > Method history is so much more useful than 20 extra MB's on my HD :S > > > This is /not/ a dichotomy. For my image I wrote a condenseSources > that preserves history. It edits out duplicates, and cuts off > branches in the history that lead nowhere. So at the end you get all > the versions of each method that are ancestors of the current version. > I can email you the code and you could consider making it the > default. Let me know. Can't speak for the others, but I would _very_ much appreciate that being the default. Cheers, Henry

Sept. 20, 2011

Re: [Pharo-project] Interesting expression...

by Henrik Sperre Johansen

On 20.09.2011 19:18, Igor Stasenko wrote: > On 20 September 2011 18:52,<csrabak(a)bol.com.br> wrote: >> Igor, >> >> I think you've half reason about the quality of the test, but in a dynamic language like Smalltalk there is no warranty string wouldn't be anything else than a String. . . >> > in theory , yes. But in practice it is different. > > The text displaying code is extremely "practical" one. Because it > should be fast. > And i don't see reason why it should accept anything else than strings there. IIRC, I've been bitten in the past with Text instances being passed to the rendering methods, not sure if the same holds true for the scanner... Cheers, Henry

Sept. 20, 2011

Re: [Pharo-project] [1.4] Doing a #condenseChanges in #14158

by StÃ©phane Ducasse

yes please send it. How do you determine ancestry? Stef On Sep 20, 2011, at 9:32 PM, Eliot Miranda wrote: > > > On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 20.09.2011 14:49, Marcus Denker wrote: > Hi, > > The .changes have gotten really large... (32MB...) > > So I will do a condense in the next update. > > NOTE: this will take quite some time to finish, so maybe wait for a pre-built image or Jenkins... > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > > Noooooooooo, please please don't... > Method history is so much more useful than 20 extra MB's on my HD :S > > This is /not/ a dichotomy. For my image I wrote a condenseSources that preserves history. It edits out duplicates, and cuts off branches in the history that lead nowhere. So at the end you get all the versions of each method that are ancestors of the current version. I can email you the code and you could consider making it the default. Let me know. > > > Cheers, > Henry > > > > > -- > best, > Eliot >

Sept. 20, 2011

[Pharo-project] Looking for a machine

by StÃ©phane Ducasse

Hi guys I'm checking our machines and I'm looking for the following one. W884943C1GN 00:23:6c:8d:16:c4 00:23:32:de:7c:da Gesvres MacBook Pro Unibody intel 15 Previously Simon Decembre 2008 - ebiscuss Leopard 4Gb inria RMOD Does anybody know where it is? Could you check the machines you see (this is not the one in the drawer room 117 I checked it). Stef

Sept. 20, 2011

Re: [Pharo-project] [1.4] Doing a #condenseChanges in #14158

by Eliot Miranda

On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > On 20.09.2011 14:49, Marcus Denker wrote: > >> Hi, >> >> The .changes have gotten really large... (32MB...) >> >> So I will do a condense in the next update. >> >> NOTE: this will take quite some time to finish, so maybe wait for a >> pre-built image or Jenkins... >> >> Marcus >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> Noooooooooo, please please don't... > Method history is so much more useful than 20 extra MB's on my HD :S > This is /not/ a dichotomy. For my image I wrote a condenseSources that preserves history. It edits out duplicates, and cuts off branches in the history that lead nowhere. So at the end you get all the versions of each method that are ancestors of the current version. I can email you the code and you could consider making it the default. Let me know. > > Cheers, > Henry > > -- best, Eliot

Sept. 20, 2011

Re: [Pharo-project] Should a serializer do something in particular with weak references?

by Schwab,Wilhelm K

Good question. I *think* the answer is to take the referenced objects across as one normally would, and then wrap them in a weak collection (if that is what was serialized). If one had only a weak collection holding the objects, they will be short-lived. However, something like a registry should be able to save/re-loaded, probably much like Dolphin's STBProxies: the effect of serializing the weak collection includes running some code to recreate conditions as needed. Looking forward to a lively debate... 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: Tuesday, September 20, 2011 1:38 PM To: Pharo Development Subject: [Pharo-project] Should a serializer do something in particular with weak references? Hi guys. Martin and I were discussing whether we should do something in particular in Fuel with Weak references, such as WeakArray. Should we serialize it the same way we serialize all objects, or should we do something special? what could be the impact of materializing such weak references in a new image for example? Thanks your sharing your thoughts. -- Mariano http://marianopeck.wordpress.com

Sept. 20, 2011

Re: [Pharo-project] [1.4] Doing a #condenseChanges in #14158

by StÃ©phane Ducasse

Henrik veronica and andy are working on ring for that providing an infrasturcture to support history browsing:) Now Veronica could need some inputs: - could you write some typical scenario you would like to get solved? I personally want to see the senders in the past and compare then with the current version :) - Veronica could need some help to write more tests and build a nice infrastructure so if some smart people would like to help I'm sure we could do something quite nice. Stef >> The .changes have gotten really large... (32MB...) >> >> So I will do a condense in the next update. >> >> NOTE: this will take quite some time to finish, so maybe wait for a pre-built image or Jenkins... >> >> Marcus >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> > Noooooooooo, please please don't... > Method history is so much more useful than 20 extra MB's on my HD :S > > Cheers, > Henry >

Sept. 20, 2011

Re: [Pharo-project] what are the frameworks to develop 3d interactive world like codecity in Pharo

by StÃ©phane Ducasse

Ok what is your experience with lumiere? I would like to see if we can have Plotz or another solution to display metrics in Moose. Stef On Sep 20, 2011, at 1:53 PM, Alexandre Bergel wrote: > I think that recoding a 3d engine is easier and much less frustrating that making Pharo talk to OpenGl. I am not aware of the last progresses made on that front, but I burnt 1 student on this. > > Codecity visualizations are not complex, it is just a matter of displaying triangles and multiplying matrixes. A student here learnt Smalltalk that way: > http://bergel.eu/download/papers/Jaca11a-Klotz.pdf > > Cheers, > Alexandre > > On 20 Sep 2011, at 08:45, StÃ©phane Ducasse wrote: > >> Hi guys >> >> we would like to propose a fun project and the idea would be to build a little codecity. >> Now what are the frameworks to develop 3d interactive world in Pharo? >> >> - Lumiere? >> - opengl binding? >> >> Stef > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Sept. 20, 2011

[Pharo-project] Should a serializer do something in particular with weak references?

by Mariano Martinez Peck

Hi guys. Martin and I were discussing whether we should do something in particular in Fuel with Weak references, such as WeakArray. Should we serialize it the same way we serialize all objects, or should we do something special? what could be the impact of materializing such weak references in a new image for example? Thanks your sharing your thoughts. -- Mariano http://marianopeck.wordpress.com

Sept. 20, 2011

Re: [Pharo-project] Interesting expression...

by Igor Stasenko

On 20 September 2011 18:52, <csrabak(a)bol.com.br> wrote: > Igor, > > I think you've half reason about the quality of the test, but in a dynamic language like Smalltalk there is no warranty string wouldn't be anything else than a String. . . > in theory , yes. But in practice it is different. The text displaying code is extremely "practical" one. Because it should be fast. And i don't see reason why it should accept anything else than strings there. > > Em 19/09/2011 12:28, Igor Stasenko < siguctua(a)gmail.com > escreveu: > displayScannerFor: para foreground: foreColor background: backColor > ignoreColorChanges: shadowMode > Â "Fixed to answer a MultiDisplayScanner when the paragraph is any kind of > Â MultiNewParagraph (rather than an instance of the one class) or the paragraph > Â text string is a WideString." > > Â ((para isKindOf: MultiNewParagraph) or: [para text string isByteString > Â or: [para text string isWideString]]) > > > > this one is quite interesting, for what kind of strings in pharo a > given expression yields false? > > Â string isByteString or: [ string isWideString] > > ? > > > i think this code could be rewritten to > > true ifTrue: [ > Â ... > > ]. > > > -- > Best regards, > Igor Stasenko. > > > > -- Best regards, Igor Stasenko.

Sept. 20, 2011