November 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3363 in pharo: #isSafeVM calls deprecated method

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3363 by marcus.denker: #isSafeVM calls deprecated method http://code.google.com/p/pharo/issues/detail?id=3363 12266

Nov. 30, 2010

Re: [Pharo-project] Issue 3191 in pharo: SparseLargeArray

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3191 by marcus.denker: SparseLargeArray http://code.google.com/p/pharo/issues/detail?id=3191 12266

Nov. 30, 2010

[Pharo-project] Issue 3363 in pharo: #isSafeVM calls deprecated method

by pharo＠googlecode.com

Status: Fixed Owner: marcus.denker Labels: Milestone-1.2 New issue 3363 by marcus.denker: #isSafeVM calls deprecated method http://code.google.com/p/pharo/issues/detail?id=3363 fix attached Attachments: AllocationTest-isSafeVM.st 572 bytes

Nov. 30, 2010

[Pharo-project] [update 1.2] #12265

by Marcus Denker

12265 ----- Issue 3354: Clean of RecentMessageList Issue 3338: could not parse a <historical> time stamp Issue 3291: Missing text field with completion Issue 3356: AllocationTest>>#isSafeVM -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Nov. 30, 2010

[Pharo-project] Issue 3362 in pharo: Another fix for MethodReference

by pharo＠googlecode.com

Status: Fixed Owner: Benjamin.VanRyseghem.Pharo New issue 3362 by Benjamin.VanRyseghem.Pharo: Another fix for MethodReference http://code.google.com/p/pharo/issues/detail?id=3362 RecentMessageList need an accessor to classSymbol to be able to change the reference when a class is renamed Attachments: AnotherMethodReferenceFix.1.cs 912 bytes

Nov. 30, 2010

Re: [Pharo-project] Issue 3356 in pharo: AllocationTest>>#isSafeVM

by pharo＠googlecode.com

Updates: Status: Closed Labels: Milestone-1.2 Comment #3 on issue 3356 by marcus.denker: AllocationTest>>#isSafeVM http://code.google.com/p/pharo/issues/detail?id=3356 (No comment was entered for this change.)

Nov. 30, 2010

Re: [Pharo-project] NewInspector does not work well with delegated collections

by jaayer

---- On Tue, 30 Nov 2010 02:45:31 -0800 StÃ©phane Ducasse wrote ---- >what we learned in the story is that the newinspector is too intrusive and that we should make sure that we limit the api to be used when building >introspective tools. >This is also why we will remove it from the next pharo-dev >Stef I didn't put this in my initial post, but the problem is even worse with collections like OrderedCollection, which reimplements NewInspector messages like #collect:displayingProgress: and #withIndexCollect:displayingProgress: because the implementations it inherits from SequenceableCollection use #at:put: rather than #add: to build a copy of the receiver. If you try to create your own OrderedCollection class by subclassing SequenceableCollection and forwarding to OrderedCollection, unless you forward the NewInspector messages too, in addition to the "Elements" tab not working, exceptions will be thrown. >On Nov 29, 2010, at 9:38 PM, jaayer wrote: > >> Enclosed is a fileout of a sample collection named DelegatedSet that works by delegating to an instance of Set stored in an instance variable. It implements the basic protocol Collection requires, including #add:, #remove:ifAbsent: and #do: as well as some additional messages, all through delegation. Create an instance of it and then inspect that instance with NewInsepctor, and you will notice the "Elements" item does not work. Nothing happens when you click it. To inspect the elements, you need to click "set," the instance variable containing the Set, and then inspect that object further. Apparently, unless you override one or more messages under the extension category *Newinspector, NewInspector will not know how to inspect your collection properly. Worse, as soon as you do implement those methods, unless you change their category, they will now be considered part of the *Newinspector package rather than the package your collection belongs to and will not be saved along with the collection. >> >> I think at a minimum, any collection understanding #do: and #size should be inspectable by NewInspector. > > >

Nov. 30, 2010

Re: [Pharo-project] Changesets with LF/CRLF instead of CR?

by Stefan Marr

Hi: On 30 Nov 2010, at 13:56, Schwab,Wilhelm K wrote: > A possible wrinkle: what about using Linux to write a file for a Windows user? That is why I proposed to use MultiByteFileStream LineEndDefault. There are methods in MultiByteFileStream to set it explicitly. So, it could be either set in a save dialog, or a user preference somewhere, I guess. Best regards Stefan PS: The file stream should be initialized on creation with MultiByteFileStream LineEndDefault, otherwise it is not thread/RoarVM-safe... > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Stefan Marr [pharo(a)stefan-marr.de] > Sent: Tuesday, November 30, 2010 7:13 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Changesets with LF/CRLF instead of CR? > > Hello: > > On 30 Nov 2010, at 09:20, StÃ©phane Ducasse wrote: > >> as a general principle, I'm open to change for the better :) >> Now how much? >> - cost to do > Cleaning it up completely does not looks like a simple/localized change to a single method. > > There are 'aFileStream cr' message sends all over the place, which from my perspective are wrong in the sense that they are not platform independent. I guess the best way would be to have something like 'aFileStream nl' or 'lineEnd' instead. Where nl/lineEnd uses MultiByteFileStream LineEndDefault. > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Nov. 30, 2010

Re: [Pharo-project] Issue 3291 in pharo: Missing text field with completion

by pharo＠googlecode.com

Updates: Status: Closed Comment #6 on issue 3291 by marcus.denker: Missing text field with completion http://code.google.com/p/pharo/issues/detail?id=3291 12265

Nov. 30, 2010

Re: [Pharo-project] Issue 3338 in pharo: could not parse a '<historical>' time stamp

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3338 by marcus.denker: could not parse a '<historical>' time stamp http://code.google.com/p/pharo/issues/detail?id=3338 already in 12265

Nov. 30, 2010