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

Re: [Pharo-project] Old smalltalker is slightly lost

by Schwab,Wilhelm K

I respectfully disagree with the presumption that a morph subclass is desirable. It *might* be the correct solution, but IMHO, often one is better off with something knows how to draw on a canvas with an arbitrary resolution. One thing I actually miss from Windows is its printer device contexts. Yes, you may quote me in a registered letter to Bill Gates<g>. If you do, please tell him that I think pretty highly of COM too, but that he botched almost everything else, especially DCOM :) Back on topic, this is an old debate. In another Smalltalk that will remain nameless, it wasn't Moprhs, it was View subclasses. Same argument: follow Kent Beck's "lots of little pieces" advice, make something that draws on a canvas, and use it to create a morph or whatever else you want. Test using a bitmap (Form in Pharo) as I showed in my other message. Just my 2 asCents. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Ricardo Moran [richi.moran(a)gmail.com] Sent: Tuesday, December 13, 2011 3:49 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Old smalltalker is slightly lost Hi, You should make your own Morph subclass, override the #drawOn: method which receives a canvas as its parameter, and use this canvas to make your diagram. Then, if you want it to be inside a window, you can send #openInWindow to your morph instead of #openInWorld. A very simple example is attached. Open it by doing: ExampleMorph new openInWindow Best regards, Richo On Tue, Dec 13, 2011 at 1:59 PM, KasperOsterbye <kasper(a)itu.dk<mailto:kasper@itu.dk>> wrote: 15 years ago I did a lot in Smalltalk, and have done some recreational meta programming along the way. However, I now wanted to do something where I was in need of drawing a diagram with x and y axes on what I presume might be called a Canvas. I lack a simple tutorial to get me started. I have looked at many, but they seem to presume I want to draw on the world "openInWorld". I should like not to scatter my world with line fragments and points, but keep it inside a "normal" window with borders, a background color (i.e. not a see through window). I have gone dead in two approaches. First attempt is to use a SystemWindow, and then draw on the canvas I presume is there somewhere. I have just not been able to figure out how to find the canvas of that SystemWindow, nor what method presumeable does the painting. Second attempt is to use a SystemWindow, and then add (addMorph:) line and circle morphs for my diagram. But it seems something is missing in my understanding there as well. While it is fun that I can open circles and other stuff in "world", it is not what I need. Small hits or direct solutions more than welcome. -- Kasper -- View this message in context: http://forum.world.st/Old-smalltalker-is-slightly-lost-tp4191137p4191137.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 13, 2011

Re: [Pharo-project] Old smalltalker is slightly lost

by Schwab,Wilhelm K

Kasper, "Canvas" is a good name, and is (IMHO at least) exactly what want, on a bitmap, aka a Form. Look at Form class>>dotOfSize: for an example of drawing. #getCanvas produces what you want. My default image is littered with messages called #show, such as Form>>show | shell | shell := StandardWindow new. shell addMorph:( shell newImage:self ) fullFrame:(LayoutFrame fractions:(0@0 corner: 1@1)). shell openInWorld. With the above compiled in Form, you can use ( ColorForm dotOfSize:50 ) show. (note the use of ColorForm vs. Form) to display the dot in a window. Also, check out Painter (Archetype Polymorph Application) in http://book.pharo-project.org/book. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of KasperOsterbye [kasper(a)itu.dk] Sent: Tuesday, December 13, 2011 11:59 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Old smalltalker is slightly lost 15 years ago I did a lot in Smalltalk, and have done some recreational meta programming along the way. However, I now wanted to do something where I was in need of drawing a diagram with x and y axes on what I presume might be called a Canvas. I lack a simple tutorial to get me started. I have looked at many, but they seem to presume I want to draw on the world "openInWorld". I should like not to scatter my world with line fragments and points, but keep it inside a "normal" window with borders, a background color (i.e. not a see through window). I have gone dead in two approaches. First attempt is to use a SystemWindow, and then draw on the canvas I presume is there somewhere. I have just not been able to figure out how to find the canvas of that SystemWindow, nor what method presumeable does the painting. Second attempt is to use a SystemWindow, and then add (addMorph:) line and circle morphs for my diagram. But it seems something is missing in my understanding there as well. While it is fun that I can open circles and other stuff in "world", it is not what I need. Small hits or direct solutions more than welcome. -- Kasper -- View this message in context: http://forum.world.st/Old-smalltalker-is-slightly-lost-tp4191137p4191137.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 13, 2011

Re: [Pharo-project] Old smalltalker is slightly lost

by Ricardo Moran

Hi, You should make your own Morph subclass, override the #drawOn: method which receives a canvas as its parameter, and use this canvas to make your diagram. Then, if you want it to be inside a window, you can send #openInWindow to your morph instead of #openInWorld. A very simple example is attached. Open it by doing: > ExampleMorph new openInWindow Best regards, Richo On Tue, Dec 13, 2011 at 1:59 PM, KasperOsterbye <kasper(a)itu.dk> wrote: > 15 years ago I did a lot in Smalltalk, and have done some recreational meta > programming along the way. However, I now wanted to do something where I > was > in need of drawing a diagram with x and y axes on what I presume might be > called a Canvas. > > I lack a simple tutorial to get me started. I have looked at many, but they > seem to presume I want to draw on the world "openInWorld". I should like > not > to scatter my world with line fragments and points, but keep it inside a > "normal" window with borders, a background color (i.e. not a see through > window). > I have gone dead in two approaches. > > First attempt is to use a SystemWindow, and then draw on the canvas I > presume is there somewhere. I have just not been able to figure out how to > find the canvas of that SystemWindow, nor what method presumeable does the > painting. > > Second attempt is to use a SystemWindow, and then add (addMorph:) line and > circle morphs for my diagram. But it seems something is missing in my > understanding there as well. > > While it is fun that I can open circles and other stuff in "world", it is > not what I need. > > Small hits or direct solutions more than welcome. > > -- Kasper > > -- > View this message in context: > http://forum.world.st/Old-smalltalker-is-slightly-lost-tp4191137p4191137.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Dec. 13, 2011

Re: [Pharo-project] Message cascades: can they be always transformed into a sequence?

by Eliot Miranda

On Tue, Dec 13, 2011 at 6:45 AM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hi: > > I got a little problem with message cascades, and since I already missed a > few details the first time, I wonder whether I am overlooking something now > again. > > My question is, whether it is always possible to flatten a cascade into a > surrounding sequence of statements (method/block). > > I am introducing temporary variables for that, and am wonder whether there > could be anything I am overlooking with respect to the evaluation order. > Thus, are there constructs where I would change evaluation order by > pulling out normal sends and put the results into temporary variables? > No. Cascades are simply a syntactic sugar for binding to a temporary, so expr message1; ...; messageN is syntactic sugar for | t | ... t := expr. t message1. ... t messageN. The implementation simply creates an anonymous temporary on the stack and reads it using dup, effectively push expr, dup, send, dup, send, pop. > I obviously need to make sure that if I flatten them, that I order > receivers and arguments correctly. Is there anything else that could hinder > flattening? > > (Ah, and I am happy to ignore reflection, thisContext, or exceptions.) > > Here two examples: > ---> original: > testCascadedSends > | assoc | > assoc := Association key: #foo value: 0. > > assoc value: (1 + 2); > value: assoc value + 2; > value: assoc value + 5. > > self assert: 10 equals: assoc value. > > > testCascadedNotInSequence > | assoc | > assoc := Association key: #foo value: 0. > > assoc value: (assoc value: 1; > value: 2; > yourself). > > self assert: assoc equals: assoc value. > <--- > > ---> transformed: > testCascadedSends > | assoc t* | > assoc := Association key: #foo value: 0. > > assoc value: (1 + 2). > t1 := assoc value. > assoc value: t1 + 2. > t2 := assoc value. > assoc value: t2 + 5. > > self assert: 10 equals: assoc value. > > > testCascadedNotInSequence > | assoc t* | > assoc := Association key: #foo value: 0. > > assoc value: 1. > assoc value: 2. > t1 := yourself. > assoc value: t1. > > self assert: assoc equals: assoc value. > <--- > > > Thanks > 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 > > > -- best, Eliot

Dec. 13, 2011

Re: [Pharo-project] allSharedPools

by Mariano Martinez Peck

On Tue, Dec 13, 2011 at 5:01 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr > wrote: > This is a pity that allSharedPools does not return an ordered unique > collection. > > Class>>allSharedPools > "Answer a Set of the pools the receiver shares, including those > defined > in the superclasses of the receiver." > | aSet | > ^self superclass == nil > ifTrue: [self sharedPools copy] > ifFalse: [aSet := self superclass allSharedPools. > aSet addAll: self sharedPools. > aSet] > > since sharedPools returns now an orderedCollection I doubt that the > uniqueness will the guaranteed. > > I have just tested, and of course, it includes duplicates. Why not a simply: Class>>allSharedPools "Answer a Set of the pools the receiver shares, including those defined in the superclasses of the receiver." | aSet | ^(self superclass == nil ifTrue: [self sharedPools copy] ifFalse: [aSet := self superclass allSharedPools. aSet addAll: self sharedPools. aSet]) asSet ? BTW, why it does a copy ? > > Behavior>>allSharedPools > "Answer a Set of the names of the pools (Dictionaries or SharedPool > subclasses) that the receiver and the receiver's ancestors share." > > ^superclass allSharedPools > > I think it answers a list of SharedPool subclasses, not names. > Now on a metaclass we will climb up the inheritance chain for nothing so I > would define allSharedPools as follows > > ClassDescription>>allSharedPools > "Answer a Set of the pools the receiver shares, including those > defined > in the superclasses of the receiver." > > ^ OrderedCollection new > > Tell me what you think? > > Stef > -- Mariano http://marianopeck.wordpress.com

Dec. 13, 2011

Re: [Pharo-project] sharedPools

by Mariano Martinez Peck

what a coincidence....since yesterday I have problems when swapping in classes I swapped out and used SharedPools...I am still searching the bug :( > TraitBehavior>>sharedPools > ^ Dictionary new > > oops! I would be good to have polymorphic results! > I will return ^ OrderedCollection new > And put a comment (I guess) that Traits DO NOT accept sharedPools but this method is here in order to talk polymorphically with traits/classes when doing things like #allBehaviorsDo: #allClassesAndTraits..etc.... if this is not correct...then why not to remove this method ? > > Now I'm not sure if it makes sense (but this is probably better) that > RBClass returns also a polymorphic results. > I have the impression that we get an orderedCollection too. > > RBClass>>sharedPools > ^ self allPoolDictionaryNames collect: [ :each | Smalltalk globals > at: each asSymbol ifAbsent: [ Dictionary new ] ] > > Ring seems to miss sharedPools. > > > > Stef > -- Mariano http://marianopeck.wordpress.com

Dec. 13, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Mariano Martinez Peck

On Tue, Dec 13, 2011 at 8:44 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Mariano, > > On Tue, Dec 13, 2011 at 12:37 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Tue, Dec 13, 2011 at 8:43 AM, Michael Roberts <mike(a)mjr104.co.uk>wrote: >> >>> Hi Mariano, when I read this thread I was a bit confused that you wanted >>> an IdentitySet that used #hash. From that statement it sounded like you >>> just wanted a Set. This would allow any object to define its own hash and >>> importantly what equality means with #=. So if you want to delegate that to >>> the object use a Set. >>> >>> >> No, I cannot use a Set because I cannot have repetitions. This that I am >> asking is what we do in Fuel serializer while traversing the object graph. >> Each analyzed object is put in an IdentityDictionary (but the question is >> the same for IdentitySet) as key. To avoid cycles, I need to put each >> object only once. Since graphs can be very big, such dict could have lots >> of objects. >> >> >>> However as the thread has gone on perhaps you want the identity >>> relationship but you just wanted a bigger identity hash space? >>> >> >> Yes, exactly. I were thinking if there could be a way (maybe...that's why >> I am asking) of improve its performance considering that I could have much >> more objects than 2^13. In other words, I wanted to see if I could avoid >> colisions. >> > > You can assume that certain properties of objects will not change during > serialization, for example the class of objects, the basic size of objects. > So you can construct a valid extended identity hash from these properties. > For example > > fuelSerializationHash > ^self identityHash + (self class identityHash bitShift: 12) + (self > basicSize bitShift: 24) > > Thanks!!! that's exactly what I wanted to try :) > In general this idea may not work because of meta-primitives like > changeClassTo:, which would change the hash. But in Fuel's case I think > it's safe to assume that objects won't change class or size during > serialization. > Exactly :) Moreoever, if objects change their state or shape, or, in other words, in the graph changes while we are in the middle of the serialization, we will be screw anyway....whether the hash has changed or not :) I will see what is worst, if the colisions or having to send 2 times #identityHash and 1 #basicSize. Thanks! > > HTH > > > >> >> >>> >>> IdentitySets are fast because they bypass any delegation. Once you have >>> seen the object in your traversal (common usage pattern) that's it. You >>> grab it's identity which is a pretty low level thing to do. >>> >> >> Ok...it is a tradeoff. If I use #identityHash it is fast because there is >> no delegation and it is almost an immediate primitive. But I gues it will >> be slow if there are lots of colisions. Not using #identityHash but >> something else maybe could decrease maybe the amount of colisions, but >> maybe with the delegation it will gets slower. >> >> I will try with Levente idea of what it is done in SystemTracer: use as a >> hash the identityHash of the object mixed with the identityHash of its >> class. Maybe that decreases the colisions and at the same time I don't pay >> delegation (#class is special bytecode, so nothing, and ok..there are 2 >> sends to #identityhash but I don't thinnk it is that much). >> >> Anyway, thanks for the interesting post, I always learn :) >> >> >>> >>> As for what happens with collections who knows. Depends. Relying on >>> identity set semantics for a collection is easy. Set semantics is not so. >>> Remember that both hash and equals are important to know if the set already >>> contains the element. Depending on the collection implementation both of >>> these could be composite in terms of the parts. Who knows where you end or >>> how long it takes. I.e. if it is a function of the size of the collection >>> and further collections are composite.... >>> >>> >> yes... >> >> >>> Cheers >>> Mike >>> >>> >>> >>> On Tuesday, December 13, 2011, Carlo <snoobabk(a)yahoo.ie> wrote: >>> > Hi Mariano >>> > I'm no expert either ;) >>> > Without having access to the exact code it would look like either you >>> have a collection that references itself (which would break all collection >>> implementations) or maybe the tests have just slowed down to the point >>> where you think it's 'crashed'. >>> > Do you have anymore info or perhaps which methods you changed on >>> IdentitySet? >>> > Cheers >>> > Carlo >>> > On 13 Dec 2011, at 1:57 AM, Mariano Martinez Peck wrote: >>> > >>> > >>> > On Tue, Dec 13, 2011 at 12:32 AM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >> >>> >> >>> >> On Mon, Dec 12, 2011 at 1:56 PM, Carlo <snoobabk(a)yahoo.ie> wrote: >>> >>> >>> >>> Hi >>> >>> Wouldn't the fact that you use hash cause potential loops now? e.g. >>> collection refers to another object that refers to first collection. --> >>> aCollection>>hash references an item which causes this current collection's >>> hash to be called again? >>> >> >>> >> Hi Carlo. I am still newbie with Collections but I think I am having >>> exactly that problem. During my tests, it loops in Collection >> #hash >>> when sending #hash to its elements. >>> >> Sorry, but I couldn't undertand what is the cause of the problem? >>> why it doesn't work while it does using #identityHash? could you elaborate? >>> >> >>> > >>> > Well, now I understood, and I understand also why it doesn't happen >>> with #identityHash. But what happens then with regular Dictionaries using >>> #hash? why it doesn't happen there? >>> > >>> >> >>> >> thanks >>> >> >>> >>> >>> >>> identityHash is deterministic in this case. >>> >>> Does this help? >>> >>> Cheers >>> >>> Carlo >>> >>> On 12 Dec 2011, at 10:58 AM, Mariano Martinez Peck wrote: >>> >>> Hi guys. I hope this is not a very stupid question. Background: in >>> Fuel we have a IdentityDictionary where we put each of the objects we find >>> while traversing the graph. We need to use IdentitySet because we cannot >>> have repetitions (and to avoid loops) so we NEED to use #==. In such >>> dictionary we put ALL objects of the graph, so it can be very big. Since >>> IdentitySet uses #identityHash, it means it will be using those ONLY 12 >>> bits in the object header. It means that we have 2^12 = 4096 different >>> values. >>> >>> >>> >>> Question: having explained the previous, I wanted to be able to use >>> #hash rather than #identityHash since several classes implement #hash and >>> hence I thought that using #hash I could have less colisions and hence a >>> better performance. I tried to make a subclass of IdentitySet that uses >>> #hash rather than #identityHash but my image freezes. I also tried >>> something like: >>> >>> >>> >>> set := PluggableSet new. >>> >>> set hashBlock: [ :elem | elem hash ]. >>> >>> set equalBlock: [ :a :b | a == b ]. >>> >>> >>> >>> But it doesn't work either. I works with simple tests in a workspace >>> but when I run the full tests of Fuel, it enters in a loop in the method >>> #hash of Collection.. >>> >>> >>> >>> Anyway, my question is, should that work? if not, what is the exact >>> reason? >>> >>> >>> >>> Thanks in advance, >>> >>> >>> >>> -- >>> >>> Mariano >>> >>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Mariano >>> >> http://marianopeck.wordpress.com >>> >> >>> > >>> > >>> > >>> > -- >>> > Mariano >>> > http://marianopeck.wordpress.com >>> > >>> > >>> > >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > best, > Eliot > > -- Mariano http://marianopeck.wordpress.com

Dec. 13, 2011

Re: [Pharo-project] Startup Preferences

by Benjamin

Guys, I am ok for any proposition but please try to find only one together :) some of you are for ~/.config/pharo/bla others for ~/.pharo/bla some of you are for multi location, other for only one. Personally I am for ~/.pharo and for multi locations :) Waiting for your arguments ;) Ben On Dec 13, 2011, at 5:57 PM, Camillo Bruni wrote: > Cool, > > For me the default config dir is still in "~/.pharo/" so that would be cool if added... > > cami > > On 2011-12-13, at 11:37, Benjamin wrote: > >> New version: >> >> Now there is a hierarchy for the setting file >> >> - first it lloks in the image diretory for st files >> - if none is found, it looks into >> ~/.config/pharo/${VERSION} >> - if none is found it looks into >> ~/.config/pharo/general >> >> We could also add a look into >> ~/.pharo/ >> >> >> >> Gofer new >> squeaksource: 'StartupPreferences'; >> package: 'StartupPreferences'; >> load. >> >> Ben >> >> On Dec 1, 2011, at 6:50 PM, StÃ©phane Ducasse wrote: >> >>> me too. >>> >>> Stef >>> >>> On Dec 1, 2011, at 6:38 PM, Camillo Bruni wrote: >>> >>>> Yeah I would really love to see this. >>>> >>>> maybe with a fixed lookup chain >>>> >>>> 1. Settings from the Image directory/startup.st >>>> 2. Settings from ~/.pharo/$VERSION/startup.st >>>> 3. Settings from ~/.pharo/startup.st >>>> >>>> cami >>>> >>> >>> >> > >

Dec. 13, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Eliot Miranda

Hi Mariano, On Tue, Dec 13, 2011 at 12:37 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Dec 13, 2011 at 8:43 AM, Michael Roberts <mike(a)mjr104.co.uk>wrote: > >> Hi Mariano, when I read this thread I was a bit confused that you wanted >> an IdentitySet that used #hash. From that statement it sounded like you >> just wanted a Set. This would allow any object to define its own hash and >> importantly what equality means with #=. So if you want to delegate that to >> the object use a Set. >> >> > No, I cannot use a Set because I cannot have repetitions. This that I am > asking is what we do in Fuel serializer while traversing the object graph. > Each analyzed object is put in an IdentityDictionary (but the question is > the same for IdentitySet) as key. To avoid cycles, I need to put each > object only once. Since graphs can be very big, such dict could have lots > of objects. > > >> However as the thread has gone on perhaps you want the identity >> relationship but you just wanted a bigger identity hash space? >> > > Yes, exactly. I were thinking if there could be a way (maybe...that's why > I am asking) of improve its performance considering that I could have much > more objects than 2^13. In other words, I wanted to see if I could avoid > colisions. > You can assume that certain properties of objects will not change during serialization, for example the class of objects, the basic size of objects. So you can construct a valid extended identity hash from these properties. For example fuelSerializationHash ^self identityHash + (self class identityHash bitShift: 12) + (self basicSize bitShift: 24) In general this idea may not work because of meta-primitives like changeClassTo:, which would change the hash. But in Fuel's case I think it's safe to assume that objects won't change class or size during serialization. HTH > > >> >> IdentitySets are fast because they bypass any delegation. Once you have >> seen the object in your traversal (common usage pattern) that's it. You >> grab it's identity which is a pretty low level thing to do. >> > > Ok...it is a tradeoff. If I use #identityHash it is fast because there is > no delegation and it is almost an immediate primitive. But I gues it will > be slow if there are lots of colisions. Not using #identityHash but > something else maybe could decrease maybe the amount of colisions, but > maybe with the delegation it will gets slower. > > I will try with Levente idea of what it is done in SystemTracer: use as a > hash the identityHash of the object mixed with the identityHash of its > class. Maybe that decreases the colisions and at the same time I don't pay > delegation (#class is special bytecode, so nothing, and ok..there are 2 > sends to #identityhash but I don't thinnk it is that much). > > Anyway, thanks for the interesting post, I always learn :) > > >> >> As for what happens with collections who knows. Depends. Relying on >> identity set semantics for a collection is easy. Set semantics is not so. >> Remember that both hash and equals are important to know if the set already >> contains the element. Depending on the collection implementation both of >> these could be composite in terms of the parts. Who knows where you end or >> how long it takes. I.e. if it is a function of the size of the collection >> and further collections are composite.... >> >> > yes... > > >> Cheers >> Mike >> >> >> >> On Tuesday, December 13, 2011, Carlo <snoobabk(a)yahoo.ie> wrote: >> > Hi Mariano >> > I'm no expert either ;) >> > Without having access to the exact code it would look like either you >> have a collection that references itself (which would break all collection >> implementations) or maybe the tests have just slowed down to the point >> where you think it's 'crashed'. >> > Do you have anymore info or perhaps which methods you changed on >> IdentitySet? >> > Cheers >> > Carlo >> > On 13 Dec 2011, at 1:57 AM, Mariano Martinez Peck wrote: >> > >> > >> > On Tue, Dec 13, 2011 at 12:32 AM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >> >> >> >> >> On Mon, Dec 12, 2011 at 1:56 PM, Carlo <snoobabk(a)yahoo.ie> wrote: >> >>> >> >>> Hi >> >>> Wouldn't the fact that you use hash cause potential loops now? e.g. >> collection refers to another object that refers to first collection. --> >> aCollection>>hash references an item which causes this current collection's >> hash to be called again? >> >> >> >> Hi Carlo. I am still newbie with Collections but I think I am having >> exactly that problem. During my tests, it loops in Collection >> #hash >> when sending #hash to its elements. >> >> Sorry, but I couldn't undertand what is the cause of the problem? why >> it doesn't work while it does using #identityHash? could you elaborate? >> >> >> > >> > Well, now I understood, and I understand also why it doesn't happen >> with #identityHash. But what happens then with regular Dictionaries using >> #hash? why it doesn't happen there? >> > >> >> >> >> thanks >> >> >> >>> >> >>> identityHash is deterministic in this case. >> >>> Does this help? >> >>> Cheers >> >>> Carlo >> >>> On 12 Dec 2011, at 10:58 AM, Mariano Martinez Peck wrote: >> >>> Hi guys. I hope this is not a very stupid question. Background: in >> Fuel we have a IdentityDictionary where we put each of the objects we find >> while traversing the graph. We need to use IdentitySet because we cannot >> have repetitions (and to avoid loops) so we NEED to use #==. In such >> dictionary we put ALL objects of the graph, so it can be very big. Since >> IdentitySet uses #identityHash, it means it will be using those ONLY 12 >> bits in the object header. It means that we have 2^12 = 4096 different >> values. >> >>> >> >>> Question: having explained the previous, I wanted to be able to use >> #hash rather than #identityHash since several classes implement #hash and >> hence I thought that using #hash I could have less colisions and hence a >> better performance. I tried to make a subclass of IdentitySet that uses >> #hash rather than #identityHash but my image freezes. I also tried >> something like: >> >>> >> >>> set := PluggableSet new. >> >>> set hashBlock: [ :elem | elem hash ]. >> >>> set equalBlock: [ :a :b | a == b ]. >> >>> >> >>> But it doesn't work either. I works with simple tests in a workspace >> but when I run the full tests of Fuel, it enters in a loop in the method >> #hash of Collection.. >> >>> >> >>> Anyway, my question is, should that work? if not, what is the exact >> reason? >> >>> >> >>> Thanks in advance, >> >>> >> >>> -- >> >>> Mariano >> >>> http://marianopeck.wordpress.com >> >>> >> >>> >> >> >> >> >> >> >> >> -- >> >> Mariano >> >> http://marianopeck.wordpress.com >> >> >> > >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > >> > >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

Dec. 13, 2011

Re: [Pharo-project] [Vm-dev] OSS sound plugin.

by Krishsmalltalk

Yes I can have it working albeit with some hacks... For ubuntu base Can post some notes on it thru when I can present it sensibly... Hacks are to do with some flags that I just plain commented out... Will need to chk more if I can fix whatever it is more reliably Works with vm sound OSS plugin, Sudhakar krishnamachari Extn 91-40403012 Cell 9902104814 On Dec 13, 2011, at 5:14 PM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > It doesn't seem like it was done... I can't manage to get sound to work in > Linux and the OSS plugin is not there. > > Anyone succeeded? > > -- > View this message in context: http://forum.world.st/OSS-sound-plugin-tp3357110p4190128.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 13, 2011