- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] SVN vs Git for the cogvm

by Igor Stasenko

On 3 May 2011 17:42, Torsten Bergmann <astares(a)gmx.de> wrote: >>if so, the merge will always be more complicated and the differences >>will be more and more... > > The more you branch/fork/clone the more you have to manage. Does switching > Â to SVN with one "trunk" help? Sorry couldnt resist ;) I disagree. Process management lies in social plane. To my own experience it is completely orthogonal to what tools we using. > > Bye > T. > -- > NEU: FreePhone - kostenlos mobil telefonieren und surfen! > Jetzt informieren: http://www.gmx.net/de/go/freephone > > -- Best regards, Igor Stasenko AKA sig.

May 3, 2011

[Pharo-project] [OT] Meeting in Europe

by Torsten Bergmann

>eastern Europe Didnt know that Europe is that small, could you be more exact about country/place. Bye T. -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

May 3, 2011

[Pharo-project] [OT] Meeting in Europe

by HernÃ¡n Morales Durand

Hi all, Sorry for the OT, I'm during this month in eastern Europe, if someone would like to meet and talk about the Smalltalk world just write me here or by private e-mail. Cheers, -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

May 3, 2011

[Pharo-project] SVN vs Git for the cogvm

by Torsten Bergmann

>if so, the merge will always be more complicated and the differences >will be more and more... The more you branch/fork/clone the more you have to manage. Does switching to SVN with one "trunk" help? Sorry couldnt resist ;) Bye T. -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

May 3, 2011

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

by StÃ©phane Ducasse

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