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

Re: [Pharo-project] OT: Dart

by Mariano Martinez Peck

On Mon, Oct 10, 2011 at 6:16 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Mon, Oct 10, 2011 at 7:34 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Mon, Oct 10, 2011 at 3:58 PM, Frank Shearar <frank.shearar(a)gmail.com>wrote: >> >>> On 10 October 2011 14:22, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> > My first impression: >>> > - a cross-breeding of C and .... C and a bit of C.. and then C on top. >>> > >>> > And i bet it is implemented in C >>> > :D >>> >>> You mean C#, of course. C#, with a side order of share-nothing message >>> passing concurrency. C# on the whole isn't a bad language: it's way >>> better than Java (which isn't, admittedly, exactly a high bar). >>> >>> But still, Dart seems like nothing to write home about. >>> >>> Note one sneaky thing: using an image as means of deployment: >>> http://www.infoq.com/news/2011/10/google-dart-language mentions "Dart >>> comes with tools to create an image of the heap of an application and >>> package it into an optimized format which can be loaded nearly >>> instantly, reminiscient of Smalltalk's image system." >>> >>> >> A couple of hours ago, I have asked this: >> https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/fd… >> > > You was Gilad's reply? > > yes :) > Hi Mariano, > > On Mon, Oct 10, 2011 at 5:55 AM, Mariano Martinez Peck < > > marianop...<https://groups.google.com/a/dartlang.org/groups/unlock?_done=/a/dartlang.or…> > @gmail.com> wrote: > > > So I wonder...is this a kind of Smalltalk image? what is similar and what > different? > > Better analog is a Strongtalk BST file. It contains the classes > and compile-time constants, but no state. > > -- > Cheers, Gilad > And as I understand it a BST file is pretty much the same intent as a > parcel or a fuel package containing code. > > Interesting. I would like to see the code and see if there is something I can learn from. > >> >> >>> Funny, given the number of arguments Smalltalkers have with people >>> over the use of images. >>> >>> frank >>> >>> > On 10 October 2011 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>> wrote: >>> >> Hi, >>> >> >>> >> Google published the first information about Dart: >>> >> http://www.dartlang.org/ >>> >> >>> >> Cheers, >>> >> -- Pavel >>> >> >>> >> >>> > >>> > >>> > >>> > -- >>> > Best regards, >>> > Igor Stasenko. >>> > >>> > >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > best, > Eliot > > -- Mariano http://marianopeck.wordpress.com

Oct. 10, 2011

Re: [Pharo-project] Migrating Complex in a separate package

by StÃ©phane Ducasse

Hi nicolas I would like to have a nice complex package. Do you remember the lengthly discussion that we got in pharo two years ago because the old implementation was not good. I still have the code somewhere. Now if you take the lead on that issue we will follow you. Stef > Hi, > > Facts: > - Complex is present in Squeak trunk image but not used in Kernel > - Complex is absent from Pharo image. > This breaks portability of some packages. > > I suggest putting Complex in its own package in squeaksource. This can > work for Pharo alone. > I also suggest to optionally remove Squeak.Complex from trunk. > > There are then other choices: > - the name of the package : can be Complex or Math-Complex (I already > put a few Math-* in squeak source...) > - the name of the class can be Complex or ComplexNumber > Specifically I don't like isComplex, many objects could respond true > because complicated; > isComplexNumber is much more explicit. > We could also think of having complex expressions in a symbolic > algebra, and isComplexNumber would be true only for a literal value.. > > What I could eventually do is publish an old Complex in package > Complex for backard compatibility and an updated ComplexNumber in a > Math-Complex package... > > How many of you use Complex ? > What do you think of these proposals ? > > Nicolas >

Oct. 10, 2011

Re: [Pharo-project] OT: Dart

by Schwab,Wilhelm K

Stef, Best of both worlds then. I am actually working on a "slower" version of what you might want. My interest in building images is (mostly) confined to saving code from an old version and loading into a new image. The hard part is external packages advance and the installation procedures change too. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Monday, October 10, 2011 2:42 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] OT: Dart > Stef, I wish you luck in reaching your kernel and scripting language. It would be really nice if the system can still save images. It will :)

Oct. 10, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Mariano Martinez Peck

On Mon, Oct 10, 2011 at 6:50 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 08/10/11 6:03 PM, StÃ©phane Ducasse wrote: > >> Mariano >> >> >> No, that's impossible, and if posible, it is not worth it. >>> Migrating from an old format to a new one is extremelly complicated >>> and innecessary. The easiest way to solve this is to take the >>> correct version of Fuel, materialize the graph from the stream, >>> load new version of Fuel, and seriaize it again. That the easiest, >>> more secure, and more practical approach I can see. >>> >> >> It would be interesting to see if you can get two different versions >> in memory :) (a need for a module system) so that you can load with >> one and save with the other. >> > > For the case where a lot of serialized files need to be converted, having > two versions in memory is almost a necessity; heheheheh how people could live with ReferenceStream for 10 years? > otherwise, the Fuel code update would have to be applied for each file > being converted. > > but answer my question: why would you need to update Fuel so frequently ? > A separate issue is that at some point I wanted to serialize something > differently, in two different contexts. In one case, serializing a Pier > kernel, I want Fuel to just do its thing. In the other case, when exporting > a portion a Pier kernel, I want to fine tune (i.e. map to different objects) > the objects being exported/imported. There is a hook to allow the object > swap, but the swap would then take place for the other case of serializing > to whole kernel (where the desired behaviour was for no such mapping). > That's an interesting point....Let me see if I understood. Let's say that you want to exclude certain instance variables of a class. What you mean is that you want to apply this hook (or another one) in an specific serialization and not always? because right now with Fuel (and SIXX, and I guess StOMP also) since you put the hooks in methods of the class, they are always taken into account. How would the API for the user should be? you can you specify for an specific serialization run that certain hook of certain object/class must be applied and some should not ? Apart from that, do you have a real example where you need such behavior ? Beause it looks quite complex/rare scenario ;) Thanks guys for the nice thread. > > -- > Yanni > > > -- Mariano http://marianopeck.wordpress.com

Oct. 10, 2011

Re: [Pharo-project] OT: Dart

by StÃ©phane Ducasse

On Oct 10, 2011, at 8:24 PM, Schwab,Wilhelm K wrote: > Andy Bower once compared an image to a "messy bedroom" - (paraphrasing the rest), e.g. one that maybe does not look all that great, but the occupant knows where to find everything. The biggest problem I have with images is that they start to work for me and I don't want to change them. > > It seems to be a universal argument among Smalltalkers: save things in the image vs. know exactly how to build the image and do so every day. The latter has the advantage of not requiring lots of archeology to discover what makes something work. One argument against saving images is that they can get damaged over time. I have had reasonable luck in avoiding ugliness. In part, I know that some things (e.g. running new FFI code) are dangerous and can corrupt an image or just plain crash the vm. So, I get things ready to run the suspect code, save, and then run/exit/edit/save until I have something that work. > > Stef, I wish you luck in reaching your kernel and scripting language. It would be really nice if the system can still save images. It will :) > > Dolphin's licensing more or less requires that applications be deployed differently than development images. I have had success making a Pharo image work as an end-user application, but it is a somewhat clunky process. It would be nice to have something that takes care of the details (saving the image elsewhere, locking it, etc.) using a wizard interface. Too many ideas, too little time... yes same here :) > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Monday, October 10, 2011 1:54 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] OT: Dart > > Indeed I always felt stupid :) > But now I also want a mall kernel and scripting syntax (and a image one demand only). > So :) > > Stef > >> >> Note one sneaky thing: using an image as means of deployment: >> http://www.infoq.com/news/2011/10/google-dart-language mentions "Dart >> comes with tools to create an image of the heap of an application and >> package it into an optimized format which can be loaded nearly >> instantly, reminiscient of Smalltalk's image system." >> >> Funny, given the number of arguments Smalltalkers have with people >> over the use of images. >> >> frank >> >>> On 10 October 2011 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>>> Hi, >>>> >>>> Google published the first information about Dart: >>>> http://www.dartlang.org/ >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >> > > >

Oct. 10, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Mariano Martinez Peck

Thanks guys for all the answers and ideas. I really appreaciate all of them. And in fact, this thread would probably be a source of information for Fuel's future work. But so far, nobody (janko?) yet answer my initial question of this thread. So I will copy paste it here and I will be willing to hear the answers: "We cannot. Let me just give you my thoughts: - It is a pity that we cannot make progress just because we break the format. If improving means breaking the format, we will do it. - The main question is WHY you need to update Fuel all the time? which are the reasons behind that? I have only 3 things in mind: a) because Fuel is too slow for you and hence you need a newer/faster version b) because you have changed Pharo version and Fuel doesn't work anymore there with the same version? c) because you found a bug. a) looks unlikely. I think Fuel was fast enough for most scenarios from the beginning even if new versions are faster. b) is unlikely also. For example, the last version (1.6) works out of the box in Pharo 1.2, 1.3 and 1.4. So it means that even between 3 versions of Pharo you don't need to update Fuel. c) we haven't found so far a critical bug which would requires to update Fuel. So...my question is, WHY you need to always use a new version of Fuel and why you cannot stay with a stable/fixed Metacello version? That's why we have metecello configurations. You can stick with version 1.6 (or whatever version) and just migrate when it is really necessary. For example, Francois Stephany is using Fuel for his website, and he is still using Fuel 1.4. He didn't need to update yet, because there aren't bugs and it is fast enough for what he needs. " On Mon, Oct 10, 2011 at 7:24 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: > Maybe the way to go is to provide a metadescription of the changes done to > the format since last version. That way, you can use it to convert your > serialized objects from one version to another (even back and forward). > That's what I think databases do, if you update your version, you have to > update the database. It seems like a less effort approach. > > Cheers! > Pocho. > > > On Mon, Oct 10, 2011 at 1:50 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > >> On 08/10/11 6:03 PM, StÃ©phane Ducasse wrote: >> >>> Mariano >>> >>> >>> No, that's impossible, and if posible, it is not worth it. >>>> Migrating from an old format to a new one is extremelly complicated >>>> and innecessary. The easiest way to solve this is to take the >>>> correct version of Fuel, materialize the graph from the stream, >>>> load new version of Fuel, and seriaize it again. That the easiest, >>>> more secure, and more practical approach I can see. >>>> >>> >>> It would be interesting to see if you can get two different versions >>> in memory :) (a need for a module system) so that you can load with >>> one and save with the other. >>> >> >> For the case where a lot of serialized files need to be converted, having >> two versions in memory is almost a necessity; otherwise, the Fuel code >> update would have to be applied for each file being converted. >> >> A separate issue is that at some point I wanted to serialize something >> differently, in two different contexts. In one case, serializing a Pier >> kernel, I want Fuel to just do its thing. In the other case, when exporting >> a portion a Pier kernel, I want to fine tune (i.e. map to different objects) >> the objects being exported/imported. There is a hook to allow the object >> swap, but the swap would then take place for the other case of serializing >> to whole kernel (where the desired behaviour was for no such mapping). >> >> -- >> Yanni >> >> >> > > > -- > Lic. Javier PimÃ¡s > Ciudad de Buenos Aires > -- Mariano http://marianopeck.wordpress.com

Oct. 10, 2011

Re: [Pharo-project] Remove/deprecate String adaptation?

by StÃ©phane Ducasse

I thought that we already did it. Henrik can you open a bug entry and provide some code. Stef On Oct 10, 2011, at 2:59 PM, Henrik Sperre Johansen wrote: > Could we please remove, or at least deprecate the > String>> #adaptTo*: andSend: protocol? > > Made me question my sanity a bit when I forgot some parenthesis, and > 0.1 + 0.2 storeString > didn't raise any errors, nor returned the string like I'd intended it to... > > Cheers, > Henry >

Oct. 10, 2011

[Pharo-project] Migrating Complex in a separate package

by Nicolas Cellier

Hi, Facts: - Complex is present in Squeak trunk image but not used in Kernel - Complex is absent from Pharo image. This breaks portability of some packages. I suggest putting Complex in its own package in squeaksource. This can work for Pharo alone. I also suggest to optionally remove Squeak.Complex from trunk. There are then other choices: - the name of the package : can be Complex or Math-Complex (I already put a few Math-* in squeak source...) - the name of the class can be Complex or ComplexNumber Specifically I don't like isComplex, many objects could respond true because complicated; isComplexNumber is much more explicit. We could also think of having complex expressions in a symbolic algebra, and isComplexNumber would be true only for a literal value.. What I could eventually do is publish an old Complex in package Complex for backard compatibility and an updated ComplexNumber in a Math-Complex package... How many of you use Complex ? What do you think of these proposals ? Nicolas

Oct. 10, 2011

Re: [Pharo-project] OT: Dart

by Schwab,Wilhelm K

Andy Bower once compared an image to a "messy bedroom" - (paraphrasing the rest), e.g. one that maybe does not look all that great, but the occupant knows where to find everything. The biggest problem I have with images is that they start to work for me and I don't want to change them. It seems to be a universal argument among Smalltalkers: save things in the image vs. know exactly how to build the image and do so every day. The latter has the advantage of not requiring lots of archeology to discover what makes something work. One argument against saving images is that they can get damaged over time. I have had reasonable luck in avoiding ugliness. In part, I know that some things (e.g. running new FFI code) are dangerous and can corrupt an image or just plain crash the vm. So, I get things ready to run the suspect code, save, and then run/exit/edit/save until I have something that work. Stef, I wish you luck in reaching your kernel and scripting language. It would be really nice if the system can still save images. Dolphin's licensing more or less requires that applications be deployed differently than development images. I have had success making a Pharo image work as an end-user application, but it is a somewhat clunky process. It would be nice to have something that takes care of the details (saving the image elsewhere, locking it, etc.) using a wizard interface. Too many ideas, too little time... Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Monday, October 10, 2011 1:54 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] OT: Dart Indeed I always felt stupid :) But now I also want a mall kernel and scripting syntax (and a image one demand only). So :) Stef > > Note one sneaky thing: using an image as means of deployment: > http://www.infoq.com/news/2011/10/google-dart-language mentions "Dart > comes with tools to create an image of the heap of an application and > package it into an optimized format which can be loaded nearly > instantly, reminiscient of Smalltalk's image system." > > Funny, given the number of arguments Smalltalkers have with people > over the use of images. > > frank > >> On 10 October 2011 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> Hi, >>> >>> Google published the first information about Dart: >>> http://www.dartlang.org/ >>> >>> Cheers, >>> -- Pavel >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >

Oct. 10, 2011

Re: [Pharo-project] Mailinglit Archive not working

by StÃ©phane Ducasse

They got power failure in a center in the west of france. On Oct 10, 2011, at 2:54 PM, Davide Varvello wrote: > It's down again: 2.53 pm CET > Davide > > > > Marcus Denker-4 wrote: >> >> >> gforge.inria.fr was down as a whole, its working again now. >> >> Marcus >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> > > > -- > View this message in context: http://forum.world.st/Mailinglit-Archive-not-working-tp3889580p3890124.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Oct. 10, 2011