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

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

by csrabak＠bol.com.br

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. . . 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.

Sept. 20, 2011

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

by Henrik Sperre Johansen

On 20.09.2011 15:39, Marcus Denker wrote: > On Sep 20, 2011, at 3:29 PM, Henrik Sperre Johansen wrote: > >> On 20.09.2011 15:26, Lukas Renggli wrote: >>>> Performant method history browsing from Monticello repositories is never >>>> going to be a reality. >>>> I'd gladly give 100 â¬ (or a beer, whichever is preferred) to someone who can >>>> prove me wrong :) >>> It is reality since 3+ years in Monticello 2. >>> >>> Lukas >>> >> Monticello 2 != Monticello, sadly > > But if it works since 3 years, why don't we use it and retire Monticello 1? > > Marcus > Effort? I wouldn't mind switching as soon as someone: - Rewrites the update process - Writes a translator for MC1 -> MC2 repositories - Figures out how/if we support loading code from/to MC1/MC2 without users getting confused - Makes sure the tools are at least as good, and don't rely on frameworks not in Core There's sure to be more things which needs doing, some of the ones listed above may already have been done? I know next to nothing about MC2 other than it being a complete rewrite with incompatible format and better granularity... Cheers, Henry

Sept. 20, 2011

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

by Gary Chambers

Perhaps a semi-condense that keeps the last two or three? Regards, Gary ----- Original Message ----- From: "Henrik Sperre Johansen" <henrik.s.johansen(a)veloxit.no> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, September 20, 2011 1:53 PM Subject: Re: [Pharo-project] [1.4] Doing a #condenseChanges in #14158 > 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 > > Cheers, > Henry >

Sept. 20, 2011

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

by Alexandre Bergel

If you remain with a low number of flat polygons, then it is not indispensable to use hardware for rendering. Alexandre On 20 Sep 2011, at 09:09, Marcus Denker wrote: > > 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. >> > But without hardware rendering support? > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 20, 2011

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

by Marcus Denker

On Sep 20, 2011, at 3:29 PM, Henrik Sperre Johansen wrote: > On 20.09.2011 15:26, Lukas Renggli wrote: >>> Performant method history browsing from Monticello repositories is never >>> going to be a reality. >>> I'd gladly give 100 â¬ (or a beer, whichever is preferred) to someone who can >>> prove me wrong :) >> It is reality since 3+ years in Monticello 2. >> >> Lukas >> > Monticello 2 != Monticello, sadly But if it works since 3 years, why don't we use it and retire Monticello 1? Marcus -- Marcus Denker -- http://marcusdenker.de

Sept. 20, 2011

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

by Henrik Sperre Johansen

On 20.09.2011 15:26, Lukas Renggli wrote: >> Performant method history browsing from Monticello repositories is never >> going to be a reality. >> I'd gladly give 100 â¬ (or a beer, whichever is preferred) to someone who can >> prove me wrong :) > It is reality since 3+ years in Monticello 2. > > Lukas > Monticello 2 != Monticello, sadly Cheers, Henry

Sept. 20, 2011

[Pharo-project] [update 1.4] #14158

by Marcus Denker

14158 ----- Issue 4833: Pharo Kernel patches http://code.google.com/p/pharo/issues/detail?id=4833 -- Marcus Denker -- http://marcusdenker.de

Sept. 20, 2011

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

by Sven Van Caekenberghe

On 20 Sep 2011, at 15:20, Henrik Sperre Johansen wrote: > Performant method history browsing from Monticello repositories is never going to be a reality. > I'd gladly give 100 â¬ (or a beer, whichever is preferred) to someone who can prove me wrong :) Where you live beers are quite expensive ;-) ! Both points are valid: .changes files that are too big are not very good, having method history of methods is important. Maybe someone should try to find out how many identical entries there are in the current ? It could well be that there are a lot of those due to the way integrations are done ? Sven

Sept. 20, 2011

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

by Lukas Renggli

> Performant method history browsing from Monticello repositories is never > going to be a reality. > I'd gladly give 100 â¬ (or a beer, whichever is preferred) to someone who can > prove me wrong :) It is reality since 3+ years in Monticello 2. Lukas -- Lukas Renggli www.lukas-renggli.ch

Sept. 20, 2011

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

by Henrik Sperre Johansen

On 20.09.2011 15:05, Marcus Denker wrote: > On Sep 20, 2011, at 2:54 PM, Henrik Sperre Johansen 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 > > Ok, so lets postpone... but we really need to think hard how this is sustainable. > > I have the impression that the current source management system needs some > real improvement soon. > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > Can only speak from personal experience... When encountering a bug in some recently changed method, your only chance is manually diff each package from around the changeset timestamp, and you'll hopefully be able to link it to the issue that prompted the change... Now imagine this when there are nothing but most recent versions in the .cs, and some syntactic changes were made after that which actually introduced the bug? Yup, (imho) condensing changes make linking method changes back to the issues which prompted them practically impossible. (and before that, it's still a PITA) Performant method history browsing from Monticello repositories is never going to be a reality. I'd gladly give 100 â¬ (or a beer, whichever is preferred) to someone who can prove me wrong :) Cheers, Henry

Sept. 20, 2011