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

Re: [Pharo-project] [COTDC] 57 - ColorMap

by laurent laffont

Thanks Fernando ! BitBlt examples are funny :) Laurent On Mon, May 2, 2011 at 11:13 PM, Fernando Olivero <fernando.olivero(a)usi.ch>wrote: > I'm a transformation of pixel values. I apply up to four masks and > shits to compute the transformed pixel value. > > I'm used when applying a BitBlt transfer, whenever pixels from a > source to a destination have diferent depths. For further information > refer to BitBlt class comments. > > To see me in action evaluate: BitBlt exampleColorMap > > Fernando > > On Mon, May 2, 2011 at 8:52 PM, laurent laffont > <laurent.laffont(a)gmail.com> wrote: > > Today: ColorMap > > > > Comment Of The Day Contest - One Day One Comment > > Rules: > > #1: Each day a not commented class is elected. Each day the best comment > > will be integrated with name of the author(s). > > #2: If you cannot comment it, deprecate it. > > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent > >

May 3, 2011

Re: [Pharo-project] Timespan #intersection: yields wrong result

by Johan Brichau

On 03 May 2011, at 20:44, Brent Pinkney wrote: > I wrote this Chronology stuff, so I can assure you that the behaviour is deliberate. You never want overlapping timespans. ever :) > > Let me know if you want some more details. Yes, please, because it's not making sense to me. I understand "overlapping timespans" as timespans that have a non-empty intersection, so I cannot follow that remark. The intersection of 2 timespans is implemented to be smaller (exactly one clockPrecision unit) than it really is? In the end, because I'm working with timespans in a scheduling application, I get funny gaps of a nanosecond between the timespans. Mind that I understand that timespans are left-closed right-open intervals. The point is that the "right end" is a nanosecond off after taking the intersection, imho. What is even funnier is that if you loop the script I sent, you eventually end up with an empty intersection... because it gets smaller all the time. So yes, I cannot understand that :-( Johan

May 3, 2011

Re: [Pharo-project] new Cog VMs uploaded

by Philippe Marschall

On 03.05.2011 19:51, Eliot Miranda wrote: > > > On Sun, May 1, 2011 at 4:38 AM, Philippe Marschall <kustos(a)gmx.net > <mailto:kustos@gmx.net>> wrote: > > On 29.04.2011 19:03, Eliot Miranda wrote: > > > > > > On Fri, Apr 29, 2011 at 9:04 AM, Philippe Marschall > <kustos(a)gmx.net > <mailto:kustos@gmx.net> > > <mailto:kustos@gmx.net > <mailto:kustos@gmx.net>>> wrote: > > > > On 27.04.2011 19 <tel:27.04.2011%2019> > <tel:27.04.2011%2019>:23, Eliot Miranda wrote: > > > Philippe, > > > > > > can you please profile before and after? This could > very well > > be to > > > do with the additional cost of shallowCopy for contexts, but > it is > > > inevitable that a correct implementation is going to be more > expensive > > > than the simple block-copy. The new implementation can be > optimized, > > > but we need to profile first to be sure we're tilting at the > relevant > > > windmill. > > > > > > What kind of profiling do you have in mind, MessageTally? > > > > > > Yes, that would be fine. Thanks! > > OK, there you go. As you'll see the runtime is about the same, that's > because we do more iterations in the same time. Also note the time we're > spending in WriteStream >> #nextPutAll: with interestingly has a > different growing behavior than WriteStream >> #nextPut: (only 25% vs > 100%). I already raised the issue once but people argued that the > current code is prefect. > > > Hmmm. GC behaviour is very different. Also requestContext Also shows > up in the 2382 profiles but not the 2370 traces. You'll need to dig a > little deeper to account for these differences. I guess they could well > be to do with the new (correct) MethodContext copying behaviour > retaining more state and hence stressing the GC more. What approach do you suggest should I take? Cheers Philippe

May 3, 2011

Re: [Pharo-project] add temp does not add the temp in 1.3 13179

by laurent laffont

http://code.google.com/p/pharo/issues/detail?id=3985 should reopen ? Laurent. On Tue, May 3, 2011 at 5:19 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > it does not work in OB in 1.3 nor in the plain default browser. > Now in plain 1.3-core it is working in the default browser. So this is > probably linked with a package loaded in the dev image. I was thinking OC? > > Stef > > > On May 3, 2011, at 2:30 PM, Johan Brichau wrote: > > > > > On 03 May 2011, at 10:14, Mariano Martinez Peck wrote: > > > >> aha.... I didn't try that ;) > >> So...in 1.2.1 adding from a browser does work, but not from the > debugger? > >> And in 1.3 none of them? > > > > > > I don't know about 1.3 but it's one of the things I started to notice > about 1.2.1 this week. > > In the browser, it works fine. > > >

May 3, 2011

Re: [Pharo-project] Timespan #intersection: yields wrong result

by Brent Pinkney

On Tuesday 03 May 2011 19:25:47 Johan Brichau wrote: > Hi, > > I traced a bug when working with timespans to the following issue illustrated in the code snippet below. > The last expression in the snippet yields false, although it should yield true (imho). > > |start end span| > start :=DateAndTime now. > end := start + 1 hour. > span := Timespan starting: start ending: end. > (span intersection: span) = span --> false > > I think that the intersection of a span with itself, should be itself. The origin of the problem is that Timespan>>intersection: creates a new timespan roughly as follows: > > Timespan starting: aBegin ending: self end. > > But Timespan>>end returns the end time of the timespan minus the clockprecision. As such, the intersecting span is a nanosecond shorter than the one we would expect. This eventually yields wrong results when working with timespans. > > The real question now is: should the implementation of Timespan>>intersection be changed -or- should Timespan>>end really return the (non-included) end time (that was passed when constructing it)? Hi, I wrote this Chronology stuff, so I can assure you that the behaviour is deliberate. You never want overlapping timespans. ever :) Let me know if you want some more details. Brent

May 3, 2011

Re: [Pharo-project] add temp does not add the temp in 1.3 13179

by Lukas Renggli

I can reproduce it everywhere, in Pharo 1.2 and 1.3. I don't think it has anything to do with Shout or eCompletion. It looks like the problem is that the new text editor that doesn't consequently reuse the same Text object but instead creates new ones. The method #compile:classified:withStamp:notifying:logSource: depends on the fact that this is always the same Text instance, even after editing. Luckily we can fix that easily, but there might be other subtle bugs lingering around: TClassAndTraitDescription>>compile: text classified: category withStamp: changeStamp notifying: requestor logSource: logSource | methodAndNode | methodAndNode := self compile: text asString classified: category notifying: requestor trailer: self defaultMethodTrailer ifFail: [^nil]. logSource ifTrue: [ " replace 'text' with 'methodAndNode node sourceText' " self logMethodSource: methodAndNode node sourceText forMethodWithNode: methodAndNode inCategory: category withStamp: changeStamp notifying: requestor. ]. self addAndClassifySelector: methodAndNode selector withMethod: methodAndNode method inProtocol: category notifying: requestor. self instanceSide noteCompilationOf: methodAndNode selector meta: self isClassSide. ^ methodAndNode selector On 3 May 2011 17:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > it does not work in OB in 1.3 nor in the plain default browser. > Now in plain 1.3-core it is working in the default browser. So this is probably linked with a package loaded in the dev image. I was thinking OC? > > Stef > > > On May 3, 2011, at 2:30 PM, Johan Brichau wrote: > >> >> On 03 May 2011, at 10:14, Mariano Martinez Peck wrote: >> >>> aha.... I didn't try that ;) >>> So...in 1.2.1 adding from a browser does work, but not from the debugger? >>> And in 1.3 none of them? >> >> >> I don't know about 1.3 but it's one of the things I started to notice about 1.2.1 this week. >> In the browser, it works fine. > > > -- Lukas Renggli www.lukas-renggli.ch

May 3, 2011

[Pharo-project] [update 1.3] #13181

by Marcus Denker

13181 ----- Issue 4158: Delete SystemWindow>>convertAlignment Issue 4129: #assert:equals: is the opposite as expected Issue 4077: Dictionary at:ifPresent: performance issues on Cog VM -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 3, 2011

Re: [Pharo-project] new Cog VMs uploaded

by Eliot Miranda

On Sun, May 1, 2011 at 4:38 AM, Philippe Marschall <kustos(a)gmx.net> wrote: > On 29.04.2011 19:03, Eliot Miranda wrote: > > > > > > On Fri, Apr 29, 2011 at 9:04 AM, Philippe Marschall <kustos(a)gmx.net > > <mailto:kustos@gmx.net>> wrote: > > > > On 27.04.2011 19 <tel:27.04.2011%2019>:23, Eliot Miranda wrote: > > > Philippe, > > > > > > can you please profile before and after? This could very well > > be to > > > do with the additional cost of shallowCopy for contexts, but it is > > > inevitable that a correct implementation is going to be more > expensive > > > than the simple block-copy. The new implementation can be > optimized, > > > but we need to profile first to be sure we're tilting at the > relevant > > > windmill. > > > > > > What kind of profiling do you have in mind, MessageTally? > > > > > > Yes, that would be fine. Thanks! > > OK, there you go. As you'll see the runtime is about the same, that's > because we do more iterations in the same time. Also note the time we're > spending in WriteStream >> #nextPutAll: with interestingly has a > different growing behavior than WriteStream >> #nextPut: (only 25% vs > 100%). I already raised the issue once but people argued that the > current code is prefect. > Hmmm. GC behaviour is very different. Also requestContext Also shows up in the 2382 profiles but not the 2370 traces. You'll need to dig a little deeper to account for these differences. I guess they could well be to do with the new (correct) MethodContext copying behaviour retaining more state and hence stressing the GC more. > > Cheers > Philippe >

May 3, 2011

[Pharo-project] Fwd: [Pharo-users] [update 1.3] #13180

by Marcus Denker

Begin forwarded message: > From: Marcus Denker <marcus.denker(a)inria.fr> > Date: May 3, 2011 7:40:01 PM GMT+02:00 > To: A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> > Subject: [Pharo-users] [update 1.3] #13180 > Reply-To: A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> > > 13180 > ----- > > Issue 4075: when you execute a script in headless mode, doesnt quit > Issue 4144: MessageSet buildWith: is unused and can be removed > Issue 4128: update links of Announcements help > Issue 4120: CrLfFileStream needs to be moved to Compatibility package > Issue 4149: Fix a deprecation in SHParserST80 (fixed by undeprecated) > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 3, 2011

[Pharo-project] Timespan #intersection: yields wrong result

by Johan Brichau

Hi, I traced a bug when working with timespans to the following issue illustrated in the code snippet below. The last expression in the snippet yields false, although it should yield true (imho). |start end span| start :=DateAndTime now. end := start + 1 hour. span := Timespan starting: start ending: end. (span intersection: span) = span --> false I think that the intersection of a span with itself, should be itself. The origin of the problem is that Timespan>>intersection: creates a new timespan roughly as follows: Timespan starting: aBegin ending: self end. But Timespan>>end returns the end time of the timespan minus the clockprecision. As such, the intersecting span is a nanosecond shorter than the one we would expect. This eventually yields wrong results when working with timespans. The real question now is: should the implementation of Timespan>>intersection be changed -or- should Timespan>>end really return the (non-included) end time (that was passed when constructing it)? I sent this email to bugs(a)chronos-st.org, but a discussion here probably will not hurt either. Best regards Johan Brichau

May 3, 2011