January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Bug in FileSystem

by csrabak＠bol.com.br

But what if count makes handle pass over the end of the file? -- Cesar Rabak Em 07/01/2012 10:10, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: FSReadStream >> next: count | result | result := ByteArray new: count. handle at: position read: result startingAt: 1 count: count. position := position + 1. ^ result shouldn't be FSReadStream >> next: count | result | result := ByteArray new: count. handle at: position read: result startingAt: 1 count: count. position := position + count. ^ result At least with that (among some extensions) Fuel tests pass with FS :) Cheers -- Mariano http://marianopeck.wordpress.com

Jan. 10, 2012

Re: [Pharo-project] Most wanted programming language:

by Guido Stepken

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Smalltalk ... hmmm .... are Smalltalkers sure to realize whats ging on in the world? Have fun, Guido Stepken

Jan. 10, 2012

[Pharo-project] Optimisation / Simplification ...

by James Ladd

While implementing Redline Smalltalk it occurred to me that methods and blocks are the same things, making the use of blocks to represent methods a possible optimisation or simplification to the internal of any Smalltalk implementation. For example, at: key put: value <statements here> Is not that different to: at:put: [ :key :value | <statements here> ] Just saying.

Jan. 10, 2012

Re: [Pharo-project] NativeBoost and NBOpenGL on Mac?

by ncalexan

Lawson English-2 wrote > > I've had problems installing NativeBoost on Squeak, but it worked > reasonably well installing on a Mac. However, TestRunner failed while > running the callback tests. > > This may or may not have anything to do with trying to work with > NBOpenGL, which also installs fine on Pharo (but not squeak). > > Basically: GLViewportMorph new "useOwnForm: true;" openInWorld > > fails with Error: function unavailable > > It fails during this: hInst := NativeBoostWin32 getVMModuleHandle. > > which I assume means that Mac OS X is still not supported? > I believe there is an NBOpenGL-Mac package, but it doesn't yet create windows or integrate with Morphic. Lawson English-2 wrote > > Any workarounds available yet? I should point out that my little kludgey > youtube demo of integrating OpenGL and the squeak IDE has generated 10x > as many hits per day as the next most popular video in my tutorial > series on squeak. I should also point out that when I demo pier and > seaside I use Pharo and explicitly point out I'm using Pharo, so the > Pharo community might benefit quite a bit from me being able to use > NBOpenGL on the Mac... > I found that the NBOpenGL-Mac package didn't work for me. There is a special calling procedure that tries to store the OpenGL API function pointers in the indexed variables of a variableByteObject and then call those addresses, but this fails with stack alignment errors for me. I fixed this by using the default NB calling procedure rather than this special calling procedure. So there is hope. Nick -- View this message in context: http://forum.world.st/NativeBoost-and-NBOpenGL-on-Mac-tp4278813p4280623.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 10, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Henrik Johansen

On Jan 9, 2012, at 11:00 50PM, Nicolas Cellier wrote: > 2012/1/9 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> On Mon, Jan 9, 2012 at 1:16 PM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >>> >>> Ok guys....what about the following: >>> >>> stronglyPointsTo: anObject >>> >>> "Answers true if the garbage collector would fail to collect anObject >>> because I hold a reference to it, or false otherwise" >>> >>> (self instVarsInclude: anObject) >>> ifTrue: [ >>> self class isWeak ifFalse: [ ^true ]. >>> 1 to: self class instSize do: [ :i | >>> (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. >>> ^false ] >>> ifFalse: [ ^self class == anObject and: [ self class isCompact not >>> ] ] >> >> >> Named inst vars in weak arrays are strong references. So the above looks >> wrong to me. Its more like this: >> >> 1 to: self class instSize do: >> [:i| (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. >> self class isWeak ifFalse: >> [1 to: self basicSize do: >> [:i| (se;f basicAt: i) == anObject ifTrue: [ ^true ] ]. >> ^false >> > > > But instVarIncludes: does walk over all the indexed slots, not just > the inst vars (yeah, the name does not tell) > > 1 to: self class instSize do: > [:i| (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. > 1 to: self basicSize do: > [:i| (self basicAt: i) == anObject ifTrue: [ ^true ] ]. > ^false > > So I think this part of the method works... > > Only the class test looks strange, (WeakArray new) does point strongly > to its class like Henrik mentioned with his (WeakArray with: > WeakArray) joke - or I didn't understand ;) Yes, that was my point, sorry for the murkiness with which I tried to make it. In Levente's code: anObject instVarsInclude: itsClass -> true class is weak -> true ref in weak slot -> true And all of a sudden, you don't pointTo: your class anymore just because you have it in a weak slot. (The test would fail) Cheers, Henry

Jan. 9, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Nicolas Cellier

2012/1/9 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Mon, Jan 9, 2012 at 1:16 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> Ok guys....what about the following: >> >> stronglyPointsTo: anObject >> >> Â Â Â "Answers true if the garbage collector would fail to collect anObject >> because I hold a reference to it, or false otherwise" >> >> Â Â Â (self instVarsInclude: anObject) >> Â Â Â Â Â Â ifTrue: [ >> Â Â Â Â Â Â Â Â Â self class isWeak ifFalse: [ ^true ]. >> Â Â Â Â Â Â Â Â Â 1 to: self class instSize do: [ :i | >> Â Â Â Â Â Â Â Â Â Â Â Â (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. >> Â Â Â Â Â Â Â Â Â ^false ] >> Â Â Â Â Â Â ifFalse: [ ^self class == anObject and: [ self class isCompact not >> ] ] > > > Named inst vars in weak arrays are strong references. Â So the above looks > wrong to me. Its more like this: > > Â Â 1 to: self class instSize do: > Â Â Â Â [:i|Â (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. > Â Â self class isWeak ifFalse: > Â Â Â Â [1 to: self basicSize do: > Â Â Â Â Â Â [:i| (se;f basicAt: i)Â == anObject ifTrue: [ ^true ] ]. > Â Â ^false > But instVarIncludes: does walk over all the indexed slots, not just the inst vars (yeah, the name does not tell) 1 to: self class instSize do: [:i| (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. 1 to: self basicSize do: [:i| (self basicAt: i) == anObject ifTrue: [ ^true ] ]. ^false So I think this part of the method works... Only the class test looks strange, (WeakArray new) does point strongly to its class like Henrik mentioned with his (WeakArray with: WeakArray) joke - or I didn't understand ;) We could also add a self basicSize = 0 ifTrue: [^true] before any iteration, but better use new primitive indeed... Nicolas > This should be a primitive. Â I believe Levente's primitive is even more > useful and equivalent to > > Â Â 1 to: self class instSize do: > Â Â Â Â [:i|Â (self instVarAt: i) == anObject ifTrue: [ ^i ] ]. > Â Â self class isWeak ifFalse: > Â Â Â Â [1 to: self basicSize do: > Â Â Â Â Â Â [:i| (se;f basicAt: i)Â == anObject ifTrue: [ ^i + self class > instSize ] ]. > Â Â ^0 > >> >> >> pointsTo: anObject >> Â Â Â "Answers true if I hold a reference to anObject, or false otherwise" >> >> Â Â Â ^ (self instVarsInclude: anObject) >> Â Â Â Â Â Â or: [ ^self class == anObject and: [ self class isCompact not ] ] >> >> >> And then, from the the tracing pointer stuff (such as #pointersToExcept:) >> we use #stronglyPointsTo >> >> do you agree? >> >> >> >> On Mon, Jan 9, 2012 at 9:55 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >>> >>> >>> >>> On Mon, Jan 9, 2012 at 12:47 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >>> wrote: >>>> >>>> >>>> >>>> On Mon, Jan 9, 2012 at 12:38 PM, Henrik Johansen >>>> <henrik.s.johansen(a)veloxit.no> wrote: >>>>> >>>>> >>>>> On Jan 9, 2012, at 8:46 06PM, Levente Uzonyi wrote: >>>>> >>>>> > On Mon, 9 Jan 2012, Mariano Martinez Peck wrote: >>>>> > >>>>> >>> >>>>> >>>>> >>>>> >>>>> So..I am puzzle again. I said "In which scenario can Â Â (self >>>>> >>>> instVarsInclude: anObject) Â answer true, but the loop false? " >>>>> >>>> you answered: "The scenario happens when the receiver has weak >>>>> >>>> slots and >>>>> >>>> the argument is referenced from one of those weak slots, but not >>>>> >>>> from the >>>>> >>>> other slots." >>>>> >>>> Imagine the receiver has a weak slot XXX that points to anObject. >>>>> >>>> So (self >>>>> >>>> instVarsInclude: anObject) answers true. Â How can the loop answer >>>>> >>>> false >>>>> >>>> without a GC? >>>>> >>>> why would XXX stop pointing to anObject if there is not GC in the >>>>> >>>> middle ? >>>>> >>>> >>>>> >>> >>>>> >>> The loop doesn't iterate over the indexable slots, only named ones. >>>>> >>> >>>>> >>> >>>>> >> grrr you are right! >>>>> >> >>>>> >> Ok, so I finally got it. So previously pointersTo: would answer true >>>>> >> even >>>>> >> if the slots were weak. Now it would answer false, and that's why >>>>> >> you have >>>>> >> changed the method comment. >>>>> >> Now I am thinking if this should be the default behavior of >>>>> >> #pointsTo:. If >>>>> >> I just read the selector #pointsTo: Â I would guess weak references >>>>> >> are also >>>>> >> taken into account. Â So that's why I am not completely sure. Aren't >>>>> >> there >>>>> >> any other impact of the system because of this change? >>>>> >> what about having #stronglyPointsTo: with this new version and have >>>>> >> another >>>>> >> one #pointsTo: which considers weak also? >>>>> >> does it make sense? Â or it is better to directly avoid weak by >>>>> >> defualt in >>>>> >> #pointsTo? >>>>> > >>>>> > I wasn't sure about this, that's why it's not in Squeak yet. Ignoring >>>>> > weak references is okay as long as these methods are only used for pointer >>>>> > tracing. >>>>> > >>>>> > >>>>> > Levente >>>>> >>>>> Even with a good comment, the naming starts to make little sense, imhoâ¦ >>>>> Does an object having weak slots mean it no longer pointsTo: the >>>>> objects in those slots? >>>>> >>>>> Sadly, I have no better succinct suggestions. :/ >>>>> >>>>> Also, what happens when an object holds its (non-compact) class in a >>>>> weak slot? >>>>> >>>>> In other words, is: >>>>> >>>>> wa := WeakArray new: 1. >>>>> wa at: 1 put: WeakArray. >>>>> self assert: (wa pointsTo: WeakArray). >>>>> >>>>> a valid test? >>>> >>>> >>>> It is vacuous, since WeakArray is referred to indirectly from the roots >>>> via Smalltalk and so will not go away. Â The following is not a valid test >>>> because there could be a GC in between the at:put: and the assert:. >>>> >>>> | o oh | >>>> wa := WeakArray new: 1. >>>> o := Object new. >>>> oh := o hash. >>>> wa at: 1 put: o. >>>> o := nil. >>>> self assert: (wa at: 1) hash = oh >>>> >>>> but 99 times out of a hundred it'll pass :) >>> >>> >>> and it can better be written >>> >>> | oh | >>> wa := WeakArray new: 1. >>> oh := (wa at: 1 put: Object new) hash. >>> self assert: (wa at: 1) hash = oh >>> >>>> >>>> Weak arrays are tricky beasts. Â To me, it doesn't matter that when used >>>> on WeakArray pointsTo: or instVarsIncludes: or whatever produce results that >>>> may be invalid at some subsequent time. Â The same is true for e.g. a normal >>>> Array that could be updated in some other thread. Â It does mater that at the >>>> point when an inst var is queried these methods/primitives answer the right >>>> answer. Â Writing valid tests that verify these answers is another matter >>>> entirely. Â Don't let the perfect be the enemy of the good. >>>> >>>>> >>>>> >>>>> Cheers, >>>>> Henry >>>> >>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >>>> >>> >>> >>> >>> -- >>> best, >>> Eliot >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > best, > Eliot >

Jan. 9, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Eliot Miranda

On Mon, Jan 9, 2012 at 1:16 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Ok guys....what about the following: > > stronglyPointsTo: anObject > > "Answers true if the garbage collector would fail to collect anObject > because I hold a reference to it, or false otherwise" > > (self instVarsInclude: anObject) > ifTrue: [ > self class isWeak ifFalse: [ ^true ]. > 1 to: self class instSize do: [ :i | > (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. > ^false ] > ifFalse: [ ^self class == anObject and: [ self class isCompact not > ] ] > Named inst vars in weak arrays are strong references. So the above looks wrong to me. Its more like this: 1 to: self class instSize do: [:i| (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. self class isWeak ifFalse: [1 to: self basicSize do: [:i| (se;f basicAt: i) == anObject ifTrue: [ ^true ] ]. ^false This should be a primitive. I believe Levente's primitive is even more useful and equivalent to 1 to: self class instSize do: [:i| (self instVarAt: i) == anObject ifTrue: [ ^i ] ]. self class isWeak ifFalse: [1 to: self basicSize do: [:i| (se;f basicAt: i) == anObject ifTrue: [ ^i + self class instSize ] ]. ^0 > > pointsTo: anObject > "Answers true if I hold a reference to anObject, or false otherwise" > > ^ (self instVarsInclude: anObject) > or: [ ^self class == anObject and: [ self class isCompact not ] ] > > > And then, from the the tracing pointer stuff (such as #pointersToExcept:) > we use #stronglyPointsTo > > do you agree? > > > > On Mon, Jan 9, 2012 at 9:55 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> On Mon, Jan 9, 2012 at 12:47 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: >> >>> >>> >>> On Mon, Jan 9, 2012 at 12:38 PM, Henrik Johansen < >>> henrik.s.johansen(a)veloxit.no> wrote: >>> >>>> >>>> On Jan 9, 2012, at 8:46 06PM, Levente Uzonyi wrote: >>>> >>>> > On Mon, 9 Jan 2012, Mariano Martinez Peck wrote: >>>> > >>>> >>> >>>> >>>>> >>>> >>>>> So..I am puzzle again. I said "In which scenario can (self >>>> >>>> instVarsInclude: anObject) answer true, but the loop false? " >>>> >>>> you answered: "The scenario happens when the receiver has weak >>>> slots and >>>> >>>> the argument is referenced from one of those weak slots, but not >>>> from the >>>> >>>> other slots." >>>> >>>> Imagine the receiver has a weak slot XXX that points to anObject. >>>> So (self >>>> >>>> instVarsInclude: anObject) answers true. How can the loop answer >>>> false >>>> >>>> without a GC? >>>> >>>> why would XXX stop pointing to anObject if there is not GC in the >>>> middle ? >>>> >>>> >>>> >>> >>>> >>> The loop doesn't iterate over the indexable slots, only named ones. >>>> >>> >>>> >>> >>>> >> grrr you are right! >>>> >> >>>> >> Ok, so I finally got it. So previously pointersTo: would answer true >>>> even >>>> >> if the slots were weak. Now it would answer false, and that's why >>>> you have >>>> >> changed the method comment. >>>> >> Now I am thinking if this should be the default behavior of >>>> #pointsTo:. If >>>> >> I just read the selector #pointsTo: I would guess weak references >>>> are also >>>> >> taken into account. So that's why I am not completely sure. Aren't >>>> there >>>> >> any other impact of the system because of this change? >>>> >> what about having #stronglyPointsTo: with this new version and have >>>> another >>>> >> one #pointsTo: which considers weak also? >>>> >> does it make sense? or it is better to directly avoid weak by >>>> defualt in >>>> >> #pointsTo? >>>> > >>>> > I wasn't sure about this, that's why it's not in Squeak yet. Ignoring >>>> weak references is okay as long as these methods are only used for pointer >>>> tracing. >>>> > >>>> > >>>> > Levente >>>> >>>> Even with a good comment, the naming starts to make little sense, imhoâ¦ >>>> Does an object having weak slots mean it no longer pointsTo: the >>>> objects in those slots? >>>> >>>> Sadly, I have no better succinct suggestions. :/ >>>> >>>> Also, what happens when an object holds its (non-compact) class in a >>>> weak slot? >>>> >>>> In other words, is: >>>> >>>> wa := WeakArray new: 1. >>>> wa at: 1 put: WeakArray. >>>> self assert: (wa pointsTo: WeakArray). >>>> >>>> a valid test? >>>> >>> >>> It is vacuous, since WeakArray is referred to indirectly from the roots >>> via Smalltalk and so will not go away. The following is not a valid test >>> because there could be a GC in between the at:put: and the assert:. >>> >>> | o oh | >>> wa := WeakArray new: 1. >>> o := Object new. >>> oh := o hash. >>> wa at: 1 put: o. >>> o := nil. >>> self assert: (wa at: 1) hash = oh >>> >>> but 99 times out of a hundred it'll pass :) >>> >> >> and it can better be written >> >> | oh | >> wa := WeakArray new: 1. >> oh := (wa at: 1 put: Object new) hash. >> self assert: (wa at: 1) hash = oh >> >> >>> Weak arrays are tricky beasts. To me, it doesn't matter that when used >>> on WeakArray pointsTo: or instVarsIncludes: or whatever produce results >>> that may be invalid at some subsequent time. The same is true for e.g. a >>> normal Array that could be updated in some other thread. It does mater >>> that at the point when an inst var is queried these methods/primitives >>> answer the right answer. Writing valid tests that verify these answers is >>> another matter entirely. Don't let the perfect be the enemy of the good. >>> >>> >>>> >>>> Cheers, >>>> Henry >>>> >>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >> >> >> -- >> best, >> Eliot >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

Jan. 9, 2012

Re: [Pharo-project] Icon sets repo

by Guillermo Polito

http://www.squeaksource.com/ExternalIconFamily.html To download it you have to evaluate this: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfExternalIconFamily'; load. (Smalltalk globals classNamed: 'ConfigurationOfExternalIconFamily') perform: #load. and download Filesystem: Gofer it squeaksource: 'fs'; package: 'ConfigurationOfFilesystem'; load. (Smalltalk globals classNamed: 'ConfigurationOfFilesystem') perform: #load. Cheers, Guille On Mon, Jan 9, 2012 at 6:09 PM, Bernardo Ezequiel Contreras < vonbecmann(a)gmail.com> wrote: > where's Fernando's icon importer?? > > > On Mon, Jan 9, 2012 at 6:06 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi! >> >> today, searching for icons for the DBXBrowser, I imported FamFamFam silk >> and mini icons (16x16), which have Creative Commons License, with Fernando >> Olivero's icon importer. >> >> I created a public read/write repository for saving icon sets, if anyone >> wants to use them or contribute, it's here: >> http://www.squeaksource.com/Icons >> >> Cheers, >> Guille >> > >

Jan. 9, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Mariano Martinez Peck

Ok guys....what about the following: stronglyPointsTo: anObject "Answers true if the garbage collector would fail to collect anObject because I hold a reference to it, or false otherwise" (self instVarsInclude: anObject) ifTrue: [ self class isWeak ifFalse: [ ^true ]. 1 to: self class instSize do: [ :i | (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. ^false ] ifFalse: [ ^self class == anObject and: [ self class isCompact not ] ] pointsTo: anObject "Answers true if I hold a reference to anObject, or false otherwise" ^ (self instVarsInclude: anObject) or: [ ^self class == anObject and: [ self class isCompact not ] ] And then, from the the tracing pointer stuff (such as #pointersToExcept:) we use #stronglyPointsTo do you agree? On Mon, Jan 9, 2012 at 9:55 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Mon, Jan 9, 2012 at 12:47 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> On Mon, Jan 9, 2012 at 12:38 PM, Henrik Johansen < >> henrik.s.johansen(a)veloxit.no> wrote: >> >>> >>> On Jan 9, 2012, at 8:46 06PM, Levente Uzonyi wrote: >>> >>> > On Mon, 9 Jan 2012, Mariano Martinez Peck wrote: >>> > >>> >>> >>> >>>>> >>> >>>>> So..I am puzzle again. I said "In which scenario can (self >>> >>>> instVarsInclude: anObject) answer true, but the loop false? " >>> >>>> you answered: "The scenario happens when the receiver has weak >>> slots and >>> >>>> the argument is referenced from one of those weak slots, but not >>> from the >>> >>>> other slots." >>> >>>> Imagine the receiver has a weak slot XXX that points to anObject. >>> So (self >>> >>>> instVarsInclude: anObject) answers true. How can the loop answer >>> false >>> >>>> without a GC? >>> >>>> why would XXX stop pointing to anObject if there is not GC in the >>> middle ? >>> >>>> >>> >>> >>> >>> The loop doesn't iterate over the indexable slots, only named ones. >>> >>> >>> >>> >>> >> grrr you are right! >>> >> >>> >> Ok, so I finally got it. So previously pointersTo: would answer true >>> even >>> >> if the slots were weak. Now it would answer false, and that's why you >>> have >>> >> changed the method comment. >>> >> Now I am thinking if this should be the default behavior of >>> #pointsTo:. If >>> >> I just read the selector #pointsTo: I would guess weak references >>> are also >>> >> taken into account. So that's why I am not completely sure. Aren't >>> there >>> >> any other impact of the system because of this change? >>> >> what about having #stronglyPointsTo: with this new version and have >>> another >>> >> one #pointsTo: which considers weak also? >>> >> does it make sense? or it is better to directly avoid weak by >>> defualt in >>> >> #pointsTo? >>> > >>> > I wasn't sure about this, that's why it's not in Squeak yet. Ignoring >>> weak references is okay as long as these methods are only used for pointer >>> tracing. >>> > >>> > >>> > Levente >>> >>> Even with a good comment, the naming starts to make little sense, imhoâ¦ >>> Does an object having weak slots mean it no longer pointsTo: the objects >>> in those slots? >>> >>> Sadly, I have no better succinct suggestions. :/ >>> >>> Also, what happens when an object holds its (non-compact) class in a >>> weak slot? >>> >>> In other words, is: >>> >>> wa := WeakArray new: 1. >>> wa at: 1 put: WeakArray. >>> self assert: (wa pointsTo: WeakArray). >>> >>> a valid test? >>> >> >> It is vacuous, since WeakArray is referred to indirectly from the roots >> via Smalltalk and so will not go away. The following is not a valid test >> because there could be a GC in between the at:put: and the assert:. >> >> | o oh | >> wa := WeakArray new: 1. >> o := Object new. >> oh := o hash. >> wa at: 1 put: o. >> o := nil. >> self assert: (wa at: 1) hash = oh >> >> but 99 times out of a hundred it'll pass :) >> > > and it can better be written > > | oh | > wa := WeakArray new: 1. > oh := (wa at: 1 put: Object new) hash. > self assert: (wa at: 1) hash = oh > > >> Weak arrays are tricky beasts. To me, it doesn't matter that when used >> on WeakArray pointsTo: or instVarsIncludes: or whatever produce results >> that may be invalid at some subsequent time. The same is true for e.g. a >> normal Array that could be updated in some other thread. It does mater >> that at the point when an inst var is queried these methods/primitives >> answer the right answer. Writing valid tests that verify these answers is >> another matter entirely. Don't let the perfect be the enemy of the good. >> >> >>> >>> Cheers, >>> Henry >>> >> >> >> >> -- >> best, >> Eliot >> >> > > > -- > best, > Eliot > > -- Mariano http://marianopeck.wordpress.com

Jan. 9, 2012

Re: [Pharo-project] Icon sets repo

by StÃ©phane Ducasse

Thanks Guillermo! I prefer them over the eclipse license. Stef On Jan 9, 2012, at 10:06 PM, Guillermo Polito wrote: > Hi! > > today, searching for icons for the DBXBrowser, I imported FamFamFam silk and mini icons (16x16), which have Creative Commons License, with Fernando Olivero's icon importer. > > I created a public read/write repository for saving icon sets, if anyone wants to use them or contribute, it's here: http://www.squeaksource.com/Icons > > Cheers, > Guille

Jan. 9, 2012