December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Cannot even browse a class in web image

by Lukas Renggli

> Hm, same image, same vm, no problem. No additional packages loaded. This only happens if you use a bitmap font. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 31, 2009

Re: [Pharo-project] Cannot even browse a class in web image

by Has van der Krieken

Hm, same image, same vm, no problem. No additional packages loaded. Regards, Has. 2009/12/31 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Issue: http://code.google.com/p/pharo/issues/detail?id=1724 > > Pharo image: pharo1.0-10502-rc1web09.12.2 > Pharo core version: 10502 > Virtual machine used: Squeak 4.2.2beta1U.app > Class browser used if applicable: O2PackageBrowserAdaptor. > > Steps to reproduce: > 1. Open a class browser > 2. Click on the class ByteArray from the package Collection-Arrayed > > 'MessageNotUnderstood: ByteSymbol>>hasWideCharacterFrom:to:' > > I attach PharoDebug.log > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 31, 2009

Re: [Pharo-project] Cannot even browse a class in web image

by Lukas Renggli

I've encountered and fixed that bug a long time ago in OB-Morphic in OBLazyListMorph>>display:atRow:on:. This is the same bug in O2-Morphic. Compare with "[Pharo-project] We need to do something, seriously!!!! [WAS] Fwd: Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols". Lukas 2009/12/31 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Issue: http://code.google.com/p/pharo/issues/detail?id=1724 > > Pharo image: pharo1.0-10502-rc1web09.12.2 > Pharo core version: 10502 > Virtual machine used: Squeak 4.2.2beta1U.app > Class browser used if applicable: O2PackageBrowserAdaptor. > > Steps to reproduce: > 1. Open a class browser > 2. Click on the class ByteArray from the package Collection-Arrayed > > 'MessageNotUnderstood: ByteSymbol>>hasWideCharacterFrom:to:' > > I attach PharoDebug.log > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 31, 2009

Re: [Pharo-project] I still don't understand how this work

by Lukas Renggli

> But.....this showed me several changes!!! > > I attach a picture. > > So....what's the problem here ? Looks like some other package (presumably O2-Standard) has overrides in OB-Standard. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 31, 2009

Re: [Pharo-project] 1.1 -- Inconsistent enumeration behavior of WeakKeyDictionary and subclasses

by StÃ©phane Ducasse

>> > I see the value in being able to choose both. WeakRegistry uses > #allAssociationsDo:, not #associationsDo:. Seems like it would be more > consistent to also have an #allDo: that includes values of collected > keys, and a #do: that does not. yes and a good method comment > >> >>> So I *think* this is an oversight, and is easy to fix by defining >>> WeakKeyDictionary>>do: in terms of self associationsDo:. >>> >>> But then there's the question of #size. The collection above answers 1 >>> to #size, which also seems wrong. >>> >> #size for weak key dict is non-deterministic. Because even if you want to know >> the exact number of elements, you will need to iterate over the >> collection, but then, >> iteration can trigger GC, and you have a big chances to answer wrong value. > > That seems reasonable, though there's no effort to even come close in size. > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 31, 2009

Re: [Pharo-project] Can't debug in 1.1

by StÃ©phane Ducasse

Probably the changes of Martin von Lowis. I imagine that when marcus is bad from holidays he can tell us more. Now I try to reproduce it in 11128. I put a self halt in a method and execute the method. And I got no problem. After I tried to select 'self halt' + doit in the debugger itself and it worked too. Did you have a way reproduce it systematically ? Stef On Dec 31, 2009, at 4:17 AM, Martin McClure wrote: > This one's pretty nasty. > > Symptom: > > The debugger in recent and current 1.1 images is completely broken. > > To reproduce (save your image first!): > > "self halt" doit. It goes into an infinite loop, and if there's a way to > get out of that without killing the VM I'd like to know about it. Alt-. > works, but just tries to open another debugger, which goes into another > infinite loop, etc. > > > > Cause: > > DebuggerMethodMap>MapCache is a WeakIdentityKeyDictionary, but it is > corrupt. It has an array of 22 nils, expired is 0, so it contains > nothing, but tally=16. > > This causes MapCache to lie about its size. > > This drives DebuggerMethodMap class>>cacheDebugMap:forMethod: into an > infinite loop, the whileTrue: condition is always true, it keeps trying > to remove non-existent elements to get the size to be less than 16 but > the size is always 16. > > I don't see any obvious code paths to get into this state. I suspect it > may have been left in this state when weak collections were updated with > the new code not too long ago. > > > Cure: > > In an inspector, set tally=0. Debuggers then work again. > > Not sure how to package this as a slice, so I'll leave the update to > someone else, and get back to hashing, which was hard when every > walkback froze my system :-) > > > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 31, 2009

Re: [Pharo-project] Beginner question :) search and replace in String

by StÃ©phane Ducasse

Adrian this is fun because I was looking for the same recently and it worked like a charm with me. I retried and it worked on both 1.1 11128 and 1.0 rc On Dec 31, 2009, at 1:04 AM, Adrian Kuhn wrote: > Method finder does not find a method for > > 'foobarqux' . 'bar' . 'XYZ' . 'fooXYZqux' > > and stupid me couldn't find a method on String either. > > How to get this done? > > +10 internets for solution with regex. > > --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 31, 2009

Re: [Pharo-project] I still don't understand how this work

by StÃ©phane Ducasse

strange. Stef > So....what's the problem here ? > > 2) In addition, after doing this, the MC Browser showed the package OB-Standard as dirty...but this was not done at the beggining! > > > Sorry, I am very frustated today :( Just relax. :) May be we should work on a chapter on SmallLint together :)

Dec. 31, 2009

Re: [Pharo-project] [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )

by StÃ©phane Ducasse

>> I imagine that this gives an historical view to the question and I thanks >> you because we will probably clean it. > > Stef, > > Thanks for providing this historical background. It's an interesting story > and helps understanding for those of us who did not have an office near by :) I'm a bit sad that google attracted nathanael because he had plenty of other cool ideas. But we cannot redo the history. So head to the future :) Stef

Dec. 31, 2009

Re: [Pharo-project] 1.1 -- Inconsistent enumeration behavior of WeakKeyDictionary and subclasses

by Igor Stasenko

2009/12/31 Martin McClure <martin(a)hand2mouse.com>: > Igor Stasenko wrote: >> 2009/12/31 Martin McClure <martin(a)hand2mouse.com>: >>> If you run this in 1.1: >>> >>> | dict | >>> dict := WeakKeyDictionary new. >>> dict at: 'foo' copy put: 'bar'. >>> Smalltalk garbageCollect. >>> dict associationsDo: [:assoc | self halt]. >>> dict do: [:val | self halt] >>> >>> >>> It stops in the second halt, but not the first. >>> >>> This is because #associationsDo: does not include associations whose >>> keys have been GCed, but #do: *does* include values whose corresponding >>> keys have been GCed. >>> >>> This behavior seems inconsistent, and not particularly useful, and also >>> seems to contradict the comments by the author in the Squeak bug from >>> 2007, from which I'd think that #do: would not include the value which >>> it currently does. >>> >> It is useful in terms, that sometimes you don't want to see the >> objects which GCed, >> but sometimes do. See how WeakRegistry using this. >> The lack of ephemerons support in VM, forcing us to deal with such >> things manually. > > I see the value in being able to choose both. WeakRegistry uses > #allAssociationsDo:, not #associationsDo:. Seems like it would be more > consistent to also have an #allDo: that includes values of collected > keys, and a #do: that does not. > Well, let first take in account that Dictionary is not well consistent with Collection protocol. For instance, if #add: expects association, then one could say, that Dictionary is a Collection of associations. But if you try pass association to #includes: , or observe what objects iterated in #do: you'll find out that its not. And so, if you treat a dictionary as a collection of values, indexed by associated keys, then from this POV, a #do: behavior in weak dict is consistent with Collection protocol. But #associationsDo: will not report same number of entries, since some of them having invalid (nil) keys. >> >>> So I *think* this is an oversight, and is easy to fix by defining >>> WeakKeyDictionary>>do: in terms of self associationsDo:. >>> >>> But then there's the question of #size. The collection above answers 1 >>> to #size, which also seems wrong. >>> >> #size for weak key dict is non-deterministic. Because even if you want to know >> the exact number of elements, you will need to iterate over the >> collection, but then, >> iteration can trigger GC, and you have a big chances to answer wrong value. > > That seems reasonable, though there's no effort to even come close in size. > I don't think that #size having any value for weak key dicts at all, since there is no strict guarantees at any point of time, that collection will have same number of elements as few cycles before. So, measuring size of weak dict is pointless, and existing simply to conform with Collection protocol. > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Dec. 31, 2009