- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Cleaning up SmartRefStream use

by Henrik Sperre Johansen

On 13.12.2011 15:35, Schwab,Wilhelm K wrote: > Henry, > > Of course the old data do no know how to turn themselves into the > current format. But they do/should carry with them version > information (can be as simple as an integer bumped with each change); > the system uses that to tell which incremental reshapes to apply. It > works like a charm. > > Putting the conversion methods in the deserializer is _possible_, but > it becomes a huge mess over time, risks collisions, complicates > packaging for everything that uses it, and the code is FAR better > placed in the classes that are changing over time. The latter becomes > really obvious when one starts to use proxies. > > Bill Then we agree on all points, I just misread what you'd written :) Cheers, Henry > > > > ------------------------------------------------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Henrik > Sperre Johansen [henrik.s.johansen(a)veloxit.no] > *Sent:* Tuesday, December 13, 2011 5:55 AM > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] Cleaning up SmartRefStream use > > On 11.12.2011 19:50, Schwab,Wilhelm K wrote: >> When I last looked at SmartReferenceStream, it did two things that >> were bad: >> >> >> (2) reshape code was placed in SRS itself, not in the class that is >> changing shape. The thing that is being deserialized (which is when >> problems become apparent) should be in charge of the change. It >> simplifies both packaging (fewer loose methods to consider, and >> reduced opportunity for name collisions) and it also helps with using >> proxies for special circumstances. >> > I'm not sure I understand/agree with what you are saying. > What has been serialized is (almost) always an older version than what > you are loading into, in which case I can't really see how it can > answer the question "How do I turn into the current version?" correctly. > Maybe there needs to be a split? Serialized version knows how to > install itself as older versions (incase that's what you load into), > while the image takes care if version in memory is newer than serialized? > > TBH, I also feel it's better to put the "import old versions" > functionality as methods on the class itself rather than have an > omnipotent materializer with special methods for installing all > versions of all known classes in the system, I mean, exactly in the > serializer/materializer do you intend to put such logic for custom > user classes? > > Cheers, > Henry >

Dec. 13, 2011

Re: [Pharo-project] Help: Zodiac secure server.

by Sven Van Caekenberghe

Hi Prasad, On 13 Dec 2011, at 04:35, Prasad Khurd wrote: > Hello Sven, > using the key-cert.pem didn't help... I used firefox as client. Attached is the walkback and the key-cert.pem. > > I used ZdcSecureSocketStreamTests>>testPlain to conclude SqueakSSL.so was not loading in Fedora 14(test failed) but did in Ubuntu 10.10(test passed). Is that sufficient a test? I will try your suggestion too next time. > > thanks and regards, > Prasad I implemented my own version of an HTTPS server called ZnSecureServer (in the package 'Zinc-Zodiac' in http://www.squeaksource.com/ZincHTTPComponents) and I got it working (more or less) on the latest Ubuntu with both Firefox and curl as clients (Google Chrome did not work) and your certificate. You have to accept the security exception for the self signed certificate in FF or use the -k option for curl. Error handling is not good yet, you might have to restart the server. There was indeed still an error in ZnSecureSocketStream>>#accept as I expected. So use the very latest versions. (ZnSecureServer on: 1443) certificate: '/home/sven/ssl/key-cert.pem'; logToTranscript; start; yourself. https://localhost:1443 Disclaimer: this is an experimental proof of concept. Let me know how it goes. Regards, Sven

Dec. 13, 2011

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

by Henrik Sperre Johansen

On 13.12.2011 17:59, KasperOsterbye 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 Try MemoryMonitor from squeaksource, it includes a very simple and elegant graphing morph. Best one I know of at least. http://squeaksource.com/MemoryMonitor/ Cheers, Henry

Dec. 13, 2011

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