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

Re: [Pharo-project] Fuel for Squeak stupid questions

by Edgar J. De Cleene

On 10/9/12 4:00 AM, "Max Leske" <maxleske(a)gmail.com> wrote: > I guess, your idea was to not use optimized encoding, right? > But that would have meant to serialize an extra DateAndTime object. So I > hacked together this quick fix (see attachment) that simply encodes another > int32 on the stream with the offset. The materialization method took care of > creating a new DateAndTime object anyway. > > With the fix, the Date tests pass. > > Cheers, > Max Max: With your changes the test still fails in Squeak. Very thanks for for show where the problem could be, I try see Date and Timespan implementations Edgar

Oct. 9, 2012

Re: [Pharo-project] Global session object?

by Igor Stasenko

On 9 October 2012 13:21, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 09.10.2012 04:30, Igor Stasenko wrote: >> >> On 8 October 2012 17:12, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> On 08.10.2012 16:35, Igor Stasenko wrote: >>> >>> On 8 October 2012 13:41, Henrik Sperre Johansen >>> <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> On 08.10.2012 13:25, Igor Stasenko wrote: >>> >>> On 8 October 2012 13:06, Henrik Sperre Johansen >>> <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> On 08.10.2012 13:03, Henrik Sperre Johansen wrote: >>> >>> >>> IMO, lazily checking whether the image has been restarted whenever you >>> want to do something stinks. >>> Registering to be notified when image starts/stops is a lot better. >>> >>> Not to mention, less error-prone. >>> Miss one session check that the current session is the right one >>> somewhere... and everything might blow up if that is the first piece of >>> functionality used. >>> >>> True. >>> I did not said that my method should replace old. Sometimes lazy >>> initialization is not what you want. >>> But having no way to perform lazy initialization is even worse. >>> >>> Ah, I just objected to the notion that startup lists inherently stinks, >>> and >>> took the diametrical view for the sake of argument :) >>> Yes, lazy initialization has its uses too, but some guidelines/advice* on >>> when to what those uses are, and when you'd use startUp: registration >>> instead, is needed I think. >>> >>> Notice; in most cases where such cleanup at startup is needed (sockets, >>> window handles, etc.), additional cleanup is needed when the object goes >>> out >>> of scope during regular use, and so a registry usually exist. >>> >> I will put some more reasons for the sake of discussion & learning. >> >> 1. during startup, you have to be very careful about dependencies >> between services, >> the errors like using uninitialized service(s) makes image >> unrecoverable (because VM crashing). >> For example , putting 'Transcript show: ' before freetype initialized >> may kill an image, >> beyond the point of recovery. > > WTF? > Dependencies amongst services is one thing, but process interaction during > startup/shutdown should *not* be a source of problems. > (I assume show: triggers an invalidateRect:, which pokes the UI thread to do > an update. Otherwise, show: somehow triggers a UI update directly, which is > a bug) > I mean, if the snapshot isn't the sole running process/ running at highest > priority, all manner of strange things could potentially happen, both > during/after shutdown and before/during startup. > Remember lately people was reporting problems because they were doing image snapshot in background process? I guess we should use fork during snapshot to ensure there's no chance for scheduler to interfere. But this is just one thing.. The problem is that the bugs like that will keep popping out over and over again, which will require fixes over and over again. While i would prefer having code which is resilient to such stupid bugs, and don't needs to be modified that often. >> The hardest part in it, that since >> everything is late bound, it sometimes really hard to put >> initialization in right order. And loading any new code in image will >> also contribute to chaos >> of interdependencies, unless all developers know that they should not >> use facility A before facility B is properly initialized. And the only >> way to do it is to add own checks and one more #startup method, >> which 'enabling' your service after all dependencies initialized. >> But the problem is that the longer chain of initialization gets, the >> more chances that something will go wrong (as well as getting lost in >> order of dependencies). > > > When it comes to inter-dependent services; there's rarely dependencies > between those dealing with cleanup of external resources. > Startup services dependent on these, and eachother, sure. > Again, is startUp: and the startup list the right/best abstractions? Perhaps > not. Perhaps a DSL to declare dependencies would be nice, but then you're > quickly moving into metacello-style complexity instead. > and that's why i use session-change detection in my code. Then dependents of my service don't needs to be hard-coupled with it, and can use it at any moment. >> >> 2. garbage collection. Yes, you can walk over weak registry to >> invalidate all handles before they having >> any chance to be used. Unless during startup, you losing sole >> reference to object in registry and then VM triggers GC _before_ >> entering your startup code. As result , finalization code will attempt >> to free non-existing resources.. Which in most cases also leads to VM >> crash. >> >> So, i would not agree that using lazy-initialization & check before >> use is more error prone than startup :) > > How would this ever happen in normal uses? > Does the snapshot primitive not run a GC before saving the image state? it does, but that doesn't matters. I talking about what happens at boot time, during startup phase: some code runs _before_ reaching your startup code, which invalidates all external handles. And that code may: - lose the last reference to your object(s) - trigger GC unless you make your invalidation code to run first, things like that could happen. (but then someone else would also like to run his own code first, and we start over again ;) ). > In which case, you'd have to explicitly dereference things that is supposed > to be cleaned up as a later part of startup, and then trigger a GC... > Maybe it's just me, but I'd characterize that as an edge case that can be > classified under PEBKAC rather than the process itself being error-prone. > What is PEBKAC? That's the problem: exactly because it is an edge case. Because since everyone assumes that "this cannot normally happen", when it happens, you are helpless, because you would never think that problem in that place and will look into something unrelated, means that bugs of such kinds will be very hard to reproduce and fix. Answering your question, how this could happen.. a simplest example which comes into my mind is semaphores: imagine that you have process which waits on semaphore. And it could happen that process stack will hold a sole reference to your object, which represents an external resource. Now, it could also happen that semaphore which blocking process belongs to service which will be initialized first during image startup phase. And initialization of this service can simply drop the reference to that semaphore in order to replace it with fresh one.. (and this is not extremely rare , if you look into image, many services doing like that). And then GC triggers, and the old semaphore and the process which was waiting on it will be collected, and as result, losing last strong reference to the object which represents your external resource, registered in weak registry. The next thing which happens is running finalization process which will try to finalize non-existing external resource. > Cheers, > Henry -- Best regards, Igor Stasenko.

Oct. 9, 2012

Re: [Pharo-project] Global session object?

by Henrik Sperre Johansen

On 09.10.2012 04:30, Igor Stasenko wrote: > On 8 October 2012 17:12, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 08.10.2012 16:35, Igor Stasenko wrote: >> >> On 8 October 2012 13:41, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> wrote: >> >> On 08.10.2012 13:25, Igor Stasenko wrote: >> >> On 8 October 2012 13:06, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> wrote: >> >> On 08.10.2012 13:03, Henrik Sperre Johansen wrote: >> >> >> IMO, lazily checking whether the image has been restarted whenever you >> want to do something stinks. >> Registering to be notified when image starts/stops is a lot better. >> >> Not to mention, less error-prone. >> Miss one session check that the current session is the right one >> somewhere... and everything might blow up if that is the first piece of >> functionality used. >> >> True. >> I did not said that my method should replace old. Sometimes lazy >> initialization is not what you want. >> But having no way to perform lazy initialization is even worse. >> >> Ah, I just objected to the notion that startup lists inherently stinks, and >> took the diametrical view for the sake of argument :) >> Yes, lazy initialization has its uses too, but some guidelines/advice* on >> when to what those uses are, and when you'd use startUp: registration >> instead, is needed I think. >> >> Notice; in most cases where such cleanup at startup is needed (sockets, >> window handles, etc.), additional cleanup is needed when the object goes out >> of scope during regular use, and so a registry usually exist. >> > I will put some more reasons for the sake of discussion & learning. > > 1. during startup, you have to be very careful about dependencies > between services, > the errors like using uninitialized service(s) makes image > unrecoverable (because VM crashing). > For example , putting 'Transcript show: ' before freetype initialized > may kill an image, > beyond the point of recovery. WTF? Dependencies amongst services is one thing, but process interaction during startup/shutdown should *not* be a source of problems. (I assume show: triggers an invalidateRect:, which pokes the UI thread to do an update. Otherwise, show: somehow triggers a UI update directly, which is a bug) I mean, if the snapshot isn't the sole running process/ running at highest priority, all manner of strange things could potentially happen, both during/after shutdown and before/during startup. > The hardest part in it, that since > everything is late bound, it sometimes really hard to put > initialization in right order. And loading any new code in image will > also contribute to chaos > of interdependencies, unless all developers know that they should not > use facility A before facility B is properly initialized. And the only > way to do it is to add own checks and one more #startup method, > which 'enabling' your service after all dependencies initialized. > But the problem is that the longer chain of initialization gets, the > more chances that something will go wrong (as well as getting lost in > order of dependencies). When it comes to inter-dependent services; there's rarely dependencies between those dealing with cleanup of external resources. Startup services dependent on these, and eachother, sure. Again, is startUp: and the startup list the right/best abstractions? Perhaps not. Perhaps a DSL to declare dependencies would be nice, but then you're quickly moving into metacello-style complexity instead. > > 2. garbage collection. Yes, you can walk over weak registry to > invalidate all handles before they having > any chance to be used. Unless during startup, you losing sole > reference to object in registry and then VM triggers GC _before_ > entering your startup code. As result , finalization code will attempt > to free non-existing resources.. Which in most cases also leads to VM > crash. > > So, i would not agree that using lazy-initialization & check before > use is more error prone than startup :) How would this ever happen in normal uses? Does the snapshot primitive not run a GC before saving the image state? In which case, you'd have to explicitly dereference things that is supposed to be cleaned up as a later part of startup, and then trigger a GC... Maybe it's just me, but I'd characterize that as an edge case that can be classified under PEBKAC rather than the process itself being error-prone. Cheers, Henry

Oct. 9, 2012

Re: [Pharo-project] Emacs and Smalltalk code

by Lawrence Kellogg

Agreed. It's like working on a live patient versus a dead one. I write most of my methods in the debugger, with all of the context I need to get the job done, and the ability to evaluate expressions until I get the one that works. Larry On Oct 9, 2012, at 1:21 AM, Philippe Back wrote: > Live coding as experienced in pharo is really superior. It changes everything about how to think about programming. > > And I am a vi freak lets me tell you. > > Philippe Back > 0478 650 140 > > > > Igor Stasenko <siguctua(a)gmail.com> a Ã©crit : > > > On 8 October 2012 21:03, Frank Shearar <frank.shearar(a)gmail.com> wrote: > > On 8 October 2012 19:22, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 8 October 2012 20:08, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >>> On 8 October 2012 19:02, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >>>> On 8 October 2012 18:31, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >>>>> On Mon, Oct 8, 2012 at 4:51 PM, Oscar E A CallaÃº <oalvarez(a)dcc.uchile.cl> wrote: > >>>>>> I'm using Aquamacs (mac UI for emacs) as my default editor. But I have a problem, when trying to read a .st file, I don't get the syntax highlighting (so all is black-&-white). How I can solve this issue? > >>>>> > >>>>> Pharo/Smalltalk is not meant to be coded in Emacs, you have to use > >>>>> Pharo currently (that may change in the future). > >>>> > >>>> For shame, Damien. Why is Smalltalk not meant to be coded in a text > >>>> editor? It is text, after all. Next thing you'll suggest that one > >>>> shouldn't use git to store one's code. > >>> > >>> Alright, OK, I wrote that with at least 50% troll in the mix. (*) > >>> There's no reason why one shouldn't be able to use standard text > >>> manipulation techniques to hack on Smalltalk code. We simply never > >>> bothered doing so, and I dare say that the majority of people on this > >>> list are happy not supporting text-using tools. > >>> > >>> (*) OK, OK, 75%. > >>> > >> Being told so many times.. People still keep missing the point. > >> Smalltalk is not just source code it is environment of live objects. > >> Good luck manipulating live objects in emacs. > > > > Please show me a live object in a Browser. Please. No, not a textual > > representation of a computation. Oh, that's right, you are STILL > > writing source code prior to compiling. Fail. > > > > Oh come on, do you know that navigating code made by talking to live objects, > not searching through whole source text, then doing static analysis > (like some IDEs doing)? > If you using browser only for typing, then you Fail. > > >> It is , of course up to you, If you prefer to code in stone age. > >> I, personally cannot code outside image, without browser , debugger and such.. > > > > That's a strawman. I WANT a debugger, I WANT inspectors. I also WANT a > > proper top level syntax and the ability to use the thousands of tools > > that everyone else in the WHOLE WORLD takes for granted. OK, I've > > exceeded my capital letter quota for the day. (Also, clearly you've > > never used SLIME. I know this because SLIME lets you do everything you > > could want to, because it queries a real live running system to get > > its information. And guess how the Lispers store their source code? In > > text files, in git. > > > Yes. I never used SLIME. I even don't know what is it. > If you think it is far superior to what we have in pharo, please feel > free to open our eyes, > and direct us towards better system. > > > I have seen zero reason in my, er, 13 years of Smalltalk, why we > > shouldn't enter source code in a proper text editor, with source > > properly stored in files on a disk. Yes, I want to live inside a > > running system as much as possible - not all the time, not being > > forced to do so because we lack the tools - but as much as possible. > > But source code is not a live object, it is text. And text should be > > munged by text tools, and stored in text files, and kept in a > > text-friendly source control system. > > > > In 13 years, you had plenty of time to change things to meet your > demands. Instead, you chosen path of complaining.. you make me laugh :) > > I can tell you more: things which you miss would be done long ago, > if they would be needed so badly. > But reality is that they are not. > > > What else do you think bootstrapping is all about? It's taking some > > tiny system, and making a recipe to lift that bootstrap, and that > > recipe is not a living object, it is a specification, and it's written > > in text. > > > This is orthogonal. > > > Smalltalk is wonderful, and the reason I still hack in it is because I > > can find nothing else that comes close to its sense of aliveness and > > engagement, and I nearly cry when I see the community reject things > > because of some strange ideology with the result that we end up lost > > in the dark. > > > Defend your view, find allies, communicate. Contribute your code. And > one day you will awake having > much better system. > > Or, if you think we moving into wrong direction, and nothing can help, > you can always start own fork (like Juan did with Cuis) and fix things > there to meet your standards. > Sitting and crying is not a solution. > > > Anyway. When I have something to show, I'll talk more on this topic. > > > > frank > > > >>> frank > >>> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > -- > Best regards, > Igor Stasenko.

Oct. 9, 2012

[Pharo-project] [update 2.0] #20328

by Marcus Denker

20328 ----- Issue 6749: put off smart-character as default http://code.google.com/p/pharo/issues/detail?id=6749 Issue 6735: Add INRIA to the copyright (among the others) http://code.google.com/p/pharo/issues/detail?id=6735 (and yes, we do have in writing that all inria contributions are MIT license) -- Marcus Denker -- http://marcusdenker.de

Oct. 9, 2012

Re: [Pharo-project] Emacs and Smalltalk code

by dimitris chloupis

the bottom line is that lisp has been the basis where Smalltalk was founded in the first place. Foremost the idea of "code is data and data is code" is something that Smalltalk and Lisp as been founded on. Alan Kay praised Lisp and in several case afterall and said how much he was inspired by it. And many opened minded Lispers praise Smalltalk too. True there a lot of diffirence in both languages but if I could find one enviroment, one IDE close to Squeak and Pharo that would be Lisp with Emacs and slime. Even the essence of image exists in lisp and like smalltalk lisp puts loads of emphasis on live coding. Does it feel the same ? No but then it takes even the slightest change to make a diffirence in that feeling. But its very hard to deny that those two (smalltalk and lisp) are close and extremely distant from anything else out there.Â I am still torn between lisp and smalltalk myself. I am a huge fan of live coding enviroments and its so hard to choose because both are so great. Maybe I should keep using both I guess. But yes I dont think there is any point of creating a Emacs / Lisp vsÂ Pharo / Smalltalk discussion . Both are great in their own way and both are extremely successful in what they try to accomplish. I probably will end up using both for a very very long time :D ________________________________ From: Sven Van Caekenberghe <sven(a)stfx.eu> To: Pharo-project(a)lists.gforge.inria.fr Sent: Tuesday, 9 October 2012, 10:21 Subject: Re: [Pharo-project] Emacs and Smalltalk code On 09 Oct 2012, at 00:47, Igor Stasenko <siguctua(a)gmail.com> wrote: > Yes. I never used SLIME. I even don't know what is it. > If you think it is far superior to what we have in pharo, please feel > free to open our eyes, > and direct us towards better system. SWANK is a kind of interface/protocol between an advanced/extended editor and a running Lisp system/image. SLIME is a mode for Emacs to interact with a (possibly remote) Lisp using SWANK. It is quite impressive. [http://en.wikipedia.org/wiki/SLIME] Although sadly this discussion is derailing a bit, it _is_ interesting. The question of what makes Smalltalk such a nice environment to work in is hard to answer. Yes, the image and the way source code is handled is a very important part of that, but it is also true that it is all just source code that could be stored in files outside an image.Yes, the Smalltalk IDE and tools are very good, but it is also true that many environments offer similar and sometimes even better tools. Emacs is my main editor as well, I use vi occasionally, I have a long background in Lisp, for a brief period I worked a bit on real old school Symbolics Lisp machines. Although LispWorks [http://www.lispworks.com] is the closest thing to (Pharo) Smalltalk as an IDE, and although I have a production Lisp image that has been running for more than 2 years, it still does _not_ feel the same as working in Smalltalk. There is something magical there that does create a very good illusion that you really are interacting directly with live objects. Sven PS: I too sometimes curse the current editor and/or completion, but since all you do is editing short pieces of code, it does not make any difference. Navigating code and/or the live system makes all the difference. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Oct. 9, 2012

Re: [Pharo-project] Emacs and Smalltalk code

by phil＠highoctane.be

Frankly there is nothing that prevents having a superb editor in Pharo. The TextMorph and associated friends just didn't received enough love. They are already lots better than in 1.3. Also, is there any WebDav interface we can have on the image so that we can see everything as files (Like Package>Classe is modeled with folders and methods are files. Then editing something in there with whatever text editor would work and saving would result in compiling the method. Is there any such WebDav interface BTW? Phil 2012/10/9 Sven Van Caekenberghe <sven(a)stfx.eu> > > On 09 Oct 2012, at 00:47, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > Yes. I never used SLIME. I even don't know what is it. > > If you think it is far superior to what we have in pharo, please feel > > free to open our eyes, > > and direct us towards better system. > > SWANK is a kind of interface/protocol between an advanced/extended editor > and a running Lisp system/image. > SLIME is a mode for Emacs to interact with a (possibly remote) Lisp using > SWANK. > It is quite impressive. > > [http://en.wikipedia.org/wiki/SLIME] > > Although sadly this discussion is derailing a bit, it _is_ interesting. > The question of what makes Smalltalk such a nice environment to work in is > hard to answer. > > Yes, the image and the way source code is handled is a very important part > of that, but it is also true that it is all just source code that could be > stored in files outside an image.Yes, the Smalltalk IDE and tools are very > good, but it is also true that many environments offer similar and > sometimes even better tools. > > Emacs is my main editor as well, I use vi occasionally, I have a long > background in Lisp, for a brief period I worked a bit on real old school > Symbolics Lisp machines. > > Although LispWorks [http://www.lispworks.com] is the closest thing to > (Pharo) Smalltalk as an IDE, and although I have a production Lisp image > that has been running for more than 2 years, it still does _not_ feel the > same as working in Smalltalk. There is something magical there that does > create a very good illusion that you really are interacting directly with > live objects. > > Sven > > PS: I too sometimes curse the current editor and/or completion, but since > all you do is editing short pieces of code, it does not make any > difference. Navigating code and/or the live system makes all the difference. > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > >

Oct. 9, 2012

[Pharo-project] [update 2.0] One-click files

by Marcus Denker

Some fixes for the one-click build: Issue 6653: Unable to open image if path contains accentuated characters http://code.google.com/p/pharo/issues/detail?id=6653 Issue 5786: New text to put in the one-click README.txt file http://code.google.com/p/pharo/issues/detail?id=5786 -- Marcus Denker -- http://marcusdenker.de

Oct. 9, 2012

Re: [Pharo-project] Emacs and Smalltalk code

by Sven Van Caekenberghe

On 09 Oct 2012, at 00:47, Igor Stasenko <siguctua(a)gmail.com> wrote: > Yes. I never used SLIME. I even don't know what is it. > If you think it is far superior to what we have in pharo, please feel > free to open our eyes, > and direct us towards better system. SWANK is a kind of interface/protocol between an advanced/extended editor and a running Lisp system/image. SLIME is a mode for Emacs to interact with a (possibly remote) Lisp using SWANK. It is quite impressive. [http://en.wikipedia.org/wiki/SLIME] Although sadly this discussion is derailing a bit, it _is_ interesting. The question of what makes Smalltalk such a nice environment to work in is hard to answer. Yes, the image and the way source code is handled is a very important part of that, but it is also true that it is all just source code that could be stored in files outside an image.Yes, the Smalltalk IDE and tools are very good, but it is also true that many environments offer similar and sometimes even better tools. Emacs is my main editor as well, I use vi occasionally, I have a long background in Lisp, for a brief period I worked a bit on real old school Symbolics Lisp machines. Although LispWorks [http://www.lispworks.com] is the closest thing to (Pharo) Smalltalk as an IDE, and although I have a production Lisp image that has been running for more than 2 years, it still does _not_ feel the same as working in Smalltalk. There is something magical there that does create a very good illusion that you really are interacting directly with live objects. Sven PS: I too sometimes curse the current editor and/or completion, but since all you do is editing short pieces of code, it does not make any difference. Navigating code and/or the live system makes all the difference. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Oct. 9, 2012

Re: [Pharo-project] Fuel for Squeak stupid questions

by Max Leske

I guess, your idea was to not use optimized encoding, right? But that would have meant to serialize an extra DateAndTime object. So I hacked together this quick fix (see attachment) that simply encodes another int32 on the stream with the offset. The materialization method took care of creating a new DateAndTime object anyway. With the fix, the Date tests pass. Cheers, Max On 08.10.2012, at 09:36, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Mon, Oct 8, 2012 at 8:30 AM, Max Leske <maxleske(a)gmail.com> wrote: > Looking at the failing tests I see that the objects really are supposed to be different (comparison with #~~). What fails is the equality check (#=) and for Date that is the method Timespan>>=. The problem that occurs there is a really old (and annoying one), namely that the timezone offset is handled inconsistently: the materialized object has the correct offset while the original object doesn't. > > > I think it could work if you just remove Date>>fuelAccept: . Can you try? > > So: > - FLBasicSerializationTest>>testDate fails because of timezone offset > - FLBasicSerializationTest>>testGradientFillStyle fails because Object>>= isn't overridden in any subclass and therefore identity is checked, which fails > - (same as above for FLBasicInMemorySerializationTest) > > The other failures seem to be due to implementation differences between Pharo and Squeak (I didn't really look into them) but I couldn't find one test that seemed to fail because of hashing problems. > > Yes, I didn't really understand the thing with the hashes. I don't think there should be a problem there. Something obvious is that a normal object that is serialized will probabyt have a different identityHash than the materialized object. > > Thanks! > > I'll see if I can come up with a test case. > > Cheers, > Max > > > On 07.10.2012, at 16:38, Max Leske <maxleske(a)gmail.com> wrote: > >> The two objects I looked at where a string and an OrderedCollection. I wouldn't conclude that the problem is class specific... >> >> On 07.10.2012, at 16:12, "Edgar J. De Cleene" <edgardec2005(a)gmail.com> wrote: >> >>> >>> >>> >>> On 10/7/12 10:51 AM, "Max Leske" <maxleske(a)gmail.com> wrote: >>> >>> >>> Following you example, in Squeak FLBasicSerializationTest>>#testDate >>> >>> materialized largeIdentityHash = 2571 >>> >>> anObject. largeIdentityHash = 1094 >>> >>> >>> So why Date serializaded object gives this and the rest of objects no ? >>> >>> Edgar >>> > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Oct. 9, 2012