- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Just starting out

by Steve Taylor

On 03/05/11 16:18, Torsten Bergmann wrote: > http://omasko.wordpress.com/2011/05/02/just-starting-out I just read the article and it mentioned that Cincom aren't allowing downloads of VisualWorks Non Commercial, but are insisting that you ask for a CD to be mailed. Very strange behaviour for the internet age of instant gratification. Steve

May 3, 2011

Re: [Pharo-project] new Cog VMs uploaded

by Eliot Miranda

On Tue, May 3, 2011 at 11:57 AM, Philippe Marschall <kustos(a)gmx.net> wrote: > 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? > I have no idea. You could try and break down the various activities and benchmark them separately I suppose. You could look at the profiles you're already generating in higher resolution to see where the time is going. You could also try and extract the SystemProfiler from OpenQwaq, which will run on Cog, and is better than MessageTally. Andreas wrote it to get around some of MessageTally's limitations. It should hopefully show primitives quite accurately. HTH Eliot > > Cheers > Philippe > > >

May 3, 2011

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

by StÃ©phane Ducasse

BTW johan did you also check aconcagua? Stef On May 3, 2011, at 7:25 PM, 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)? > > 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

Re: [Pharo-project] Pharocast ContactManager using SandstoneDb

by laurent laffont

On Tue, May 3, 2011 at 10:09 PM, Doug Edmunds <dougedmunds(a)gmail.com> wrote: > Hello, > > I took the ContactManager code from your Pharocast at > http://www.pharocasts.com/2011/02/pharo-gui-with-polymorph.html > and modified it to run with SandstoneDb, using the ideas from > > http://www.pharocasts.com/2010/04/sandstonedb-simple-activerecord-style.html > > Go ahead and use it for a future Pharocast if you want, or figure out > some place to put it. > > Because Contact is an SDActiveRecord, the database is constructed from > the SandstoneDb records: > > Contacts class >>database > |db| > db := Contact findAll asOrderedCollection. > ^ db > > and so it is portable, so long as the Contacts records are put in the > correctly named Pharo subdirectory. > > > Opening the ContactListEditor uses an initialization which is supposed > to avoid the need to close/reopen Pharo after creating the Contacts class. > > Tested on Pharo 1.3 using SandstoneDb-RamonLeon.135.mcz > > Thanks a lot Doug. May be the next step would be to create a ConfigurationOfContactManager :) Laurent > > -- Doug Edmunds >

May 3, 2011

[Pharo-project] [COTDC] 58 - TextPrinter

by laurent laffont

Today: TextPrinter 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] [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