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

Re: [Pharo-project] Icon sets repo

by Bernardo Ezequiel Contreras

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] Small improvement for WriteStream >> nextPutAll:

by Nicolas Cellier

2012/1/9 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: > On 09.01.2012 00:18, Eliot Miranda wrote: >> >> >> >> On Sun, Jan 8, 2012 at 5:46 AM, Mariano Martinez Peck >> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> Â Â Hi guys. Some time ago Henry spot to us a small improvement for >> Â Â WriteStream >> nextPutAll: that we are using in Fuel, but I think >> Â Â it can be general. Henry comment was exactly: >> >> Â Â /Also: For variableBytes classes, if you rewrite: >> >> Â Â WriteStream >> Â Â nextPutAll: aCollection >> >> Â Â Â Â | newEnd | >> Â Â *collection class instSpec == aCollection class instSpec ifFalse:* >> >> Â Â Â Â Â Â [^ super nextPutAll: aCollection ]. >> >> Â Â Â Â newEnd := position + aCollection size. >> Â Â Â Â newEnd > writeLimit ifTrue: >> Â Â Â Â Â Â [self growTo: newEnd + 10]. >> >> Â Â collection replaceFrom: position+1 to: newEnd Â with: aCollection >> Â Â startingAt: 1. >> Â Â Â Â position := newEnd. >> >> Â Â Â Â ^ aCollection >> >> Â Â You can now pass all variableByte classes (Like ByteString) >> Â Â directly to a stream with a ByteArray collection, and the >> Â Â replaceFrom:to:with:/ >> Â Â /startingAt: primitive will work correctly, just like the file >> >> Â Â primitive does >> Â Â This means you don't need special Serializers for these either, >> using f.ex. clunky nextStringPutAll: methods with manual >> Â Â asByteArray conversions./ >> >> >> >> Â Â So...if you agree, I can commit the patch. >> >> >> Surely this will break special encoded strings where the encode/decode is >> done in at:/at:put:. Â Moving the bytes isn't safe in general. Â However, if >> the programmer knows they themselves can use next:putAll:startingAt: or some >> such. Â I don't think your suggestion is safe in general for WriteStream. >> Â Instead if Â next:putAll:startingAt: doesn't do the job invent some new >> protocol that will. > While analyzing the implications, I went to same conclusion as Eliot. I feel like he is right If we can just copy bytes uninterpreted, semantically it's a cast... While such trick might be inevitable at a few localizations, it does not look like a good thing to promote it as the default behaviour, see below > In principle I agree, though the only such case I can think of in an image > atm is the newly introduced: > wa := WordArray new: 2. > ws := wa writeStream. > ws nextPutAll: 1.0 > Sure, or ByteArray new writeStream nextPutAll: SmallInteger maxVal + 1. Our both examples seems a bit weird but perfectly intentional. But what if we wish to nextPutAll: self words, and #words answer a Float ? Whether intentional or not we can't tell... Such behavior might hide an error or at least delay it's discovery. Sacrificing least surprising principle for the sake of efficiency is a mistake. But I have a better argument, see below. > The string example in itself is rather theoretical, the "convention" is to > use ByteStrings for all encodings, and let the programmer fend for himself > when it comes to remembering which ByteStrings he's converted to which > encoding. > (A practice which, sadly, is only enabled by the collection class = > aCollection class check (the one in next:putAll:startingAt:), as > encoding/decoding a ByteString to a ByteString is much faster than the > equivalent operation resulting in a ByteArray... ) > So in practice, even the current class check does not protect against what > would be the common error. > Sure! We know what we want... - a ByteArray for holding codes, - an Encoder for producing these codes - and a Decoder for interpreting them. We trust this representation as a bit more safe and expressive because we can't mix anyByteArrayWhateverTheEncoding and aString together, and know exactly which form is encoded in which format (as long as we do not loose the associated codec)... We'll certainly encounter some performance bottlenecks like this in our way and be tempted to optimize... But our "optimization" is introducing exactly what we rejected: we can now write aString writeStream nextPutAll: anyByteArrayWhateverTheEncoding Horror! Having the current design broken shall not give us a licence to make it potentially worse ;) > Though, for a general, collection-agnostic approach which can still use > primitives between compatible classes, I guess giving the nextPutAll: > argument a say in what method is actually used to do a > next:putAll:startingAt: would be a better approach than simply removing the > check and crossing our fingers. :) > I didn't understand this sentence... You mean using explicitly an optimized method in the sender? Nicolas > Cheers, > Henry >

Jan. 9, 2012

[Pharo-project] Icon sets repo

by Guillermo Polito

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 Eliot Miranda

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

Jan. 9, 2012

Re: [Pharo-project] Cog+linux: external module not found

by Schwab,Wilhelm K

It is common to discuss something before creating tracker entries, and I DID state what I think is wrong and proposed a solution. I've asked for a debate on the merits of the idea, aka, looking for the library where #moduleName says to look, respecting the behavior of dlopen on Ubuntu. I spent significant time researching this behavior, and have tried to share what I believe it all says we should be doing. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Monday, January 09, 2012 3:36 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Cog+linux: external module not found On 09 Jan 2012, at 20:06, Schwab,Wilhelm K wrote: > I think you have the situation very much in reverse. You are flying off the handle, not me. > > Cog deserves better than to ignore feedback from motivated users. Motivated users deserve better than to be insulted for their efforts to improve it. Pharo, Squeak, Cog, Seaside, and most other Smalltalk software on SqueakSource is open source, written almost exclusively by people in their free time. And although most of them will try to help the users of their software the best they can, they cannot and should not do just anything unless they want to. The relation between open source authors and their users should be mutually productive. Using software and giving feedback if one thing, but it is not enough. It can't be one way all the time. I might be wrong, but I fail to find - any issues you put in the issue tracker(s) - any issues you solved - any open source software you published on SqueakSource or anywhere else - any blog post or web pages with documentation, tutorials, .. that you wrote I hope you get the point: there are many more ways to contribute than what you are doing now. Pharo and other projects need all the help they can get, give back to the community, we are all using software written by others in the same spirit, it is only fair to honor these contributions. My 2c, Sven

Jan. 9, 2012

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

by Levente Uzonyi

On Mon, 9 Jan 2012, Henrik Johansen 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? Since #pointsTo: doesn't use primitive 132 directly, it's only used from the pointer tracing tools, which shouldn't really follow weak references. > Does an object having weak slots mean it no longer pointsTo: the objects in those slots? If you mean "points to", then no. :) > > 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? Yes, because its class pointer points to its class (this sounds funny :)). Levente > > Cheers, > Henry >

Jan. 9, 2012

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

by Eliot Miranda

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 :) 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

Jan. 9, 2012

Re: [Pharo-project] Smalltalk/Pharo User Group in Madrid

by StÃ©phane Ducasse

Let us know how we can help you. Stef > > Hi all, > > I'm interested in organizing a Smalltalk/Pharo User Group in Madrid. If any member of the list is algo interested and lives in the Madrid area, please contact me. > > Thanks, > > Rafael Luque

Jan. 9, 2012

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

by Henrik Johansen

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? Cheers, Henry

Jan. 9, 2012

Re: [Pharo-project] Cog+linux: external module not found

by Sven Van Caekenberghe

On 09 Jan 2012, at 20:06, Schwab,Wilhelm K wrote: > I think you have the situation very much in reverse. You are flying off the handle, not me. > > Cog deserves better than to ignore feedback from motivated users. Motivated users deserve better than to be insulted for their efforts to improve it. Pharo, Squeak, Cog, Seaside, and most other Smalltalk software on SqueakSource is open source, written almost exclusively by people in their free time. And although most of them will try to help the users of their software the best they can, they cannot and should not do just anything unless they want to. The relation between open source authors and their users should be mutually productive. Using software and giving feedback if one thing, but it is not enough. It can't be one way all the time. I might be wrong, but I fail to find - any issues you put in the issue tracker(s) - any issues you solved - any open source software you published on SqueakSource or anywhere else - any blog post or web pages with documentation, tutorials, .. that you wrote I hope you get the point: there are many more ways to contribute than what you are doing now. Pharo and other projects need all the help they can get, give back to the community, we are all using software written by others in the same spirit, it is only fair to honor these contributions. My 2c, Sven

Jan. 9, 2012