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

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

by StÃ©phane Ducasse

> It sounds easy, but at least from what I can see this is very complicated. > Do you know a serializer that support this? Lets clarify with an example: > > > (of course, without putting all along the code IFs like (version > 2) ifTrue: [blabla] ) of course we are smalltalkers no? :) It means that for the slow version you have to get a format representation explicit. > I serialize graph X with Fuel 1.4 in Pharo 1.1. > Then I am in Pharo 1.3 with Fuel 1.7 and I want to materialize X. Fuel 1.4 doesn't load anymore in Pharo 1.3, so you have to use Fuel 1.7. > So you want to be able to take Fuel 1.7 and materialize X "using version 1.4" without even loading 1.4 (because it doesn't load) ? > > Thanks > > > Because then we get a win win situation. > Stef > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Oct. 16, 2011

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

by StÃ©phane Ducasse

> > > Yes, I know. The problem is if it is worth it. The effort of providing such feature could be too much in compare to just load a previous version, materialize, load new version, and serialize again. for a serializer I think that it is worth it. I once used a backup system which used a private format for my archives and I lost them since it was discontinued.... > > > Now why in fuel it is not possible to have > FuelMaterializer load: aFile > > load using the default = current format > > > FuelMaterializer load: aFile asOfVersion: 1.4 > Of course this can be much slower but when you want to load data of the past you are just happy that this is > working. > > So would not be possible to > milestone formats > get the default working fast > get old version loading slowler but loading. > > > It sounds easy, but at least from what I can see this is very complicated. > Do you know a serializer that support this? Lets clarify with an example: > > I serialize graph X with Fuel 1.4 in Pharo 1.1. > Then I am in Pharo 1.3 with Fuel 1.7 and I want to materialize X. Fuel 1.4 doesn't load anymore in Pharo 1.3, so you have to use Fuel 1.7. > So you want to be able to take Fuel 1.7 and materialize X "using version 1.4" without even loading 1.4 (because it doesn't load) ? Yes what I want to say is that if evolution is the key then you have to be explicit about milestones and version and in the end this is excellent. But of course you get a cost and effort. But this means that after that there is no more other serializer. I think that it is also a nice way to get meta about the format. Stef > > Thanks > > > Because then we get a win win situation. > Stef > > > > -- > Mariano > http://marianopeck.wordpress.com >

Oct. 16, 2011

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

by Schwab,Wilhelm K

Stef, Mariano, There are obvious advantages to a development phase during which serialized streams are at risk. At some point, I suspect Fuel will have to take the reading of old streams as a nearly sacred obligation. Otherwise, it sounds like a cheap horror movie series: "Fuel II: Your data go in, but they don't come out." I am using humor to make a point, not to ridicule you. I read the paper, and learned a LOT. Please see my post from yesterday referring to Dolphin's #environment. You might be able to simply facade old formats into a coherent backwardly-compatible whole. Without some attention to that, there are going to be projects that will not adopt Fuel. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Sunday, October 16, 2011 9:03 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] When will Fuel file format stabilize? On Sun, Oct 16, 2011 at 3:01 PM, Mariano Martinez Peck <marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>> wrote: On Sun, Oct 16, 2011 at 2:03 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: Mariano I think that the point that Philippe (our national butcher) is trying to make is the following: If by design a serializer takes the perspective that it will be able to load old formats and ensure evolution all the time then you have a really cool serializer. Yes, I know. The problem is if it is worth it. The effort of providing such feature could be too much in compare to just load a previous version, materialize, load new version, and serialize again. Now why in fuel it is not possible to have FuelMaterializer load: aFile load using the default = current format FuelMaterializer load: aFile asOfVersion: 1.4 Of course this can be much slower but when you want to load data of the past you are just happy that this is working. So would not be possible to milestone formats get the default working fast get old version loading slowler but loading. It sounds easy, but at least from what I can see this is very complicated. Do you know a serializer that support this? Lets clarify with an example: (of course, without putting all along the code IFs like (version > 2) ifTrue: [blabla] ) I serialize graph X with Fuel 1.4 in Pharo 1.1. Then I am in Pharo 1.3 with Fuel 1.7 and I want to materialize X. Fuel 1.4 doesn't load anymore in Pharo 1.3, so you have to use Fuel 1.7. So you want to be able to take Fuel 1.7 and materialize X "using version 1.4" without even loading 1.4 (because it doesn't load) ? Thanks Because then we get a win win situation. Stef -- Mariano http://marianopeck.wordpress.com -- Mariano http://marianopeck.wordpress.com

Oct. 16, 2011

Re: [Pharo-project] Native Windows

by Eliot Miranda

On Sun, Oct 16, 2011 at 3:13 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > What is the license of the code? > I do not think that newspeak code is MIT. > http://newspeaklanguage.org/the-newspeak-programming-language/downloads/new… Newspeak is Apache 2.0 with the preferred license for contributions going forward being MIT. But in this case there's no issue; you can't use the source unchanged since it's Newspeak. You're at liberty to read the code under Apache and hence can convert it to Smalltalk and then it's different code. > > Stef > On Oct 16, 2011, at 11:51 AM, Mariano Martinez Peck wrote: > > > > > > > On Sun, Oct 16, 2011 at 6:12 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > > > On Fri, Oct 14, 2011 at 9:19 AM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > What are the current options/future-possibilities? > > > > I was playing with Fffenestri's DisplayHostWindow, which kind of works in > > 1.3. What ever happened to that project? What is the status of Mars? Are > > there any other avenues? > > > > > > back-porting Vassili Bykov's native window implementation for Newspeak > (which runs above a slightly-modified Squeak VM, modified to support > Newspeak bytecodes). > > > > > > He is coming to Smalltalks.... I mention this just in case someone wants > to discuss with him. > > > > > > > > Thanks. > > Sean > > > > -- > > View this message in context: > http://forum.world.st/Native-Windows-tp3905413p3905413.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > > > > > -- > > best, > > Eliot > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- best, Eliot

Oct. 16, 2011

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

by Mariano Martinez Peck

On Sun, Oct 16, 2011 at 3:01 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sun, Oct 16, 2011 at 2:03 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Mariano I think that the point that Philippe (our national butcher) is >> trying to make is the following: >> If by design a serializer takes the perspective that it will be able to >> load old formats and ensure >> evolution all the time then you have a really cool serializer. >> > > Yes, I know. The problem is if it is worth it. The effort of providing such > feature could be too much in compare to just load a previous version, > materialize, load new version, and serialize again. > > >> >> Now why in fuel it is not possible to have >> FuelMaterializer load: aFile >> >> load using the default = current format >> >> >> FuelMaterializer load: aFile asOfVersion: 1.4 >> Of course this can be much slower but when you want to load data of >> the past you are just happy that this is >> working. >> >> So would not be possible to >> milestone formats >> get the default working fast >> get old version loading slowler but loading. >> >> > It sounds easy, but at least from what I can see this is very complicated. > Do you know a serializer that support this? Lets clarify with an example: > > (of course, without putting all along the code IFs like (version > 2) ifTrue: [blabla] ) > I serialize graph X with Fuel 1.4 in Pharo 1.1. > Then I am in Pharo 1.3 with Fuel 1.7 and I want to materialize X. Fuel 1.4 > doesn't load anymore in Pharo 1.3, so you have to use Fuel 1.7. > So you want to be able to take Fuel 1.7 and materialize X "using version > 1.4" without even loading 1.4 (because it doesn't load) ? > > Thanks > > > >> Because then we get a win win situation. >> Stef >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Oct. 16, 2011

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

by Mariano Martinez Peck

On Sun, Oct 16, 2011 at 2:03 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Mariano I think that the point that Philippe (our national butcher) is > trying to make is the following: > If by design a serializer takes the perspective that it will be able to > load old formats and ensure > evolution all the time then you have a really cool serializer. > Yes, I know. The problem is if it is worth it. The effort of providing such feature could be too much in compare to just load a previous version, materialize, load new version, and serialize again. > > Now why in fuel it is not possible to have > FuelMaterializer load: aFile > > load using the default = current format > > > FuelMaterializer load: aFile asOfVersion: 1.4 > Of course this can be much slower but when you want to load data of > the past you are just happy that this is > working. > > So would not be possible to > milestone formats > get the default working fast > get old version loading slowler but loading. > > It sounds easy, but at least from what I can see this is very complicated. Do you know a serializer that support this? Lets clarify with an example: I serialize graph X with Fuel 1.4 in Pharo 1.1. Then I am in Pharo 1.3 with Fuel 1.7 and I want to materialize X. Fuel 1.4 doesn't load anymore in Pharo 1.3, so you have to use Fuel 1.7. So you want to be able to take Fuel 1.7 and materialize X "using version 1.4" without even loading 1.4 (because it doesn't load) ? Thanks > Because then we get a win win situation. > Stef > -- Mariano http://marianopeck.wordpress.com

Oct. 16, 2011

Re: [Pharo-project] TWM doesn't work without keymappins and keymappings doesn't work

by laurent laffont

On Sun, Oct 16, 2011 at 12:32 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Thanks Guille for the whole work :) > > Laurent: let me know when I can use TWM properly with this latest version > of keymappings. > There's a new (development) version: - package TWM split into several packages - KeyMapping 2.0 - TWM shortcut prefix is now Cmd+r (see TWMKeymapping class>>#shortcuts for default shortcuts. Feel free to adapt and suggests better ones). - You can load TWM without KeyMapping using: ConfigurationOfTilingWindowManager loadDevelopmentWithoutKeyMapping. As a side note, this is the configuration I use in my Pharo images: Gofer it squeaksource: 'TilingWindowManager'; package: 'ConfigurationOfTilingWindowManager'; load. (Smalltalk at:#ConfigurationOfTilingWindowManager) loadDevelopment. (Smalltalk at:#TWMUITheme) beCurrent. TaskbarMorph showTaskbar: false. TasklistMorph keepOpen: true. (Smalltalk at:#TWMBar) perform: #showTWMBar: with: true. Cheers, Laurent Laffont > > Thanks guys > > > On Sun, Oct 16, 2011 at 10:11 AM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > >> >>>> >>> OK so cmd+w is definitely not a good prefix for TWM shortcuts. Is cmd+m >>> better ? >>> >>> >> oups Cmd+m not a good idea :) I struggle to find a good prefix..... >> >> Laurent. >> >> >> >> >> >>> >>> >>>> So i installed TWM without keybinding but now I cannot open the settings >>>>> window because keymappings is not load. >>>>> >>>>> Any solution? (install TWM without keymappings or fixing keymappings) >>>>> >>>> >>>> I've done some fixes and improvements to keymapping, and I've created a >>>> 2.0 version where: >>>> >>>> - the collisions below are fixed >>>> - keymaps can be configured per morph instance too (not only per class, >>>> as the former version) >>>> - some little improvements and code cleaning >>>> >>> >>> >>> Thanks ! >>> >>> >>> But those things I remarked of TWM should be reviewed :) >>>> >>>> Or you can Use twm without keymappings and I'll have no more feedback :( >>>> >>> >>> >>> TWM without Keymapping is not really interesting. I will produce new >>> versions of TWM. >>> >>> Laurent >>> >>> >>> >>>> >>>> >>>>> >>>>> thanks! >>>>> >>>> >>>> Thank you :) >>>> >>>> Guille >>>> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >

Oct. 16, 2011

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

by StÃ©phane Ducasse

Mariano I think that the point that Philippe (our national butcher) is trying to make is the following: If by design a serializer takes the perspective that it will be able to load old formats and ensure evolution all the time then you have a really cool serializer. Now why in fuel it is not possible to have FuelMaterializer load: aFile load using the default = current format FuelMaterializer load: aFile asOfVersion: 1.4 Of course this can be much slower but when you want to load data of the past you are just happy that this is working. So would not be possible to milestone formats get the default working fast get old version loading slowler but loading. Because then we get a win win situation. Stef

Oct. 16, 2011

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

by Mariano Martinez Peck

On Sun, Oct 16, 2011 at 1:20 PM, Philippe Marschall <kustos(a)gmx.net> wrote: > On 15.10.2011 15:06, Martin Dias wrote: > > I like the ideas of Stef and Ben of loading multiple fuel versions at > > the same time. Do you know something done in that sense? > > > > MartÃn > > > > On Sat, Oct 15, 2011 at 7:09 AM, Mariano Martinez Peck > > <marianopeck(a)gmail.com > > <mailto:marianopeck@gmail.com>> wrote: > > > > > > > > On Sat, Oct 15, 2011 at 11:49 AM, Philippe Marschall > > <kustos(a)gmx.net > > <mailto:kustos@gmx.net>> wrote: > > > > On 11.10.2011 21:51, Mariano Martinez Peck wrote: > > > > > > > > > On Tue, Oct 11, 2011 at 8:55 AM, Philippe Marschall > > > <philippe.marschall(a)netcetera.ch > > <mailto:philippe.marschall@netcetera.ch> > > > > > <mailto:philippe.marschall@netcetera.ch > > <mailto:philippe.marschall@netcetera.ch>>> > > wrote: > > > > > > On 10/08/2011 10:42 PM, Mariano Martinez Peck wrote: > > > > s > > > > > > > >>> > > > >>> This is IMHO more than necessary for Fuel to become a > > production > > > ready > > > >>> serializer and I'd say Fuel is now "old enough" to > > become such :) > > > >> > > > >> Yes. > > > >> Now what I would love is that even if fuel changes that > the > > > evolution of > > > >> information > > > >> is taken into account because like that it will be > > exercised for > > > real. > > > >> > > > >> > > > > 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. > > > > > > That is horribly naÃ¯ve an excludes fuel from a lot of use > > cases. You > > > can't use fuel for "archiving" objects outside of the > > image because you > > > will never know whether you will be able to read them in > > again because > > > the format changes. You will always need to have "live" > > ones in the > > > image. > > > > > > > > > No. That's incorrect. You won't be able to do that ONLY if you > > update > > > Fuel to a new image that breaks format. > > > You can still continue to use the same version and you will > > never have > > > that problem. So, again, why you need to update Fuel? > > > > Because it's old software. Bugs may not get fixed. It may not > > work in > > newer Pharo versions. I may have dependencies on other libraries > > that > > may require a new version of Fuel. You name it. > > > > > > > > I understand. What I mean is that depending on the changes and the > > amount of work, you can just adapt Fuel to new versions of Pharo but > > without changing its format. > > I mean....say you were in Fuel 1.4. You don't need to move to Fuel > > 1.8 just because. You can just try to fix 1.4 to make it work in > > latest pharo. > > Oh yeah sure, I can always fork Fuel and maintain it myself. That's > exactly what I don't don't want to do. > > Well...the thread is starting to be offtopic. I will try once again to explain MY thoguhts: A serializer can evolve in 2 ways: just changing or changing but also making previous versions incompatible. At the same time, a serializer can be in development stage or in maintenance. Fuel is still in development. Even if it is stable in the sense there are no bugs, we are still developing it and we will continue to improve it and change its format. ReferenceSteam is finish, its in maintenance. Now..as an example, Fuel 1.6 is working in Pharo 1.2, 1.3 and 1.4. THat is, 3 mayor versions of Pharo without changing even Fuel version. Isn't that enough for you? do you want to be able to materialize a graph 10 years after with the same version of Fuel? well, then you have to update Fuel to latest version of pharo without changing its format. And that is exactly what Pharo team does with ReferenceStream. Why? because it is just in the image, so if there are methods renamed or removed, ReferneceStream is immediately fixed. What's the difference with Fuel? that it is not in the core, hence not updated by them. > > That's EXACTLY what we do with ReferenceStream and friends. The only > > difference is that the Pharo team does that because it is in the > core. > > But yes, it may happen that ideed you will require a new version of > > Fuel. > > Whatâ½ What's the advantage of Fuel over ReferenceStream again? > > I don't understand your question, but if you want to know the advantages of Fuel over ReferenceStream, read the Fuel paper. > > > Why SmartRefStream does not have this problem? because it > hasn't > > > changed in the last 10 years. > > > So..do the same, take an specific Fuel version and keep it for > > 10 years. > > > Just update it to make it work in Pharo without changing the > > format and > > > you are done. > > > > > > > > > > > > That means you can't use fuel for anything Monticello > > related because > > > you may never be able to load those versions in again > > because the file > > > format has changed in the mean time. > > > > > > > > > I guess that in the end, if someone can really do something for > > > Monticello on top of Fuel it will be like 2 years from now, > > and at some > > > point Fuel format will be stable. > > > And as Stef says...you always have the code there in case of > > problems. > > > > Monticello is just an example for a case where I want to store > > objects > > outside of the image. > > > > > > Well, then you can just wait until we finish. Give us one year more. > > Instead of doing 1-year-long releases, we like to do 3 months > > releases. > > But again, that doesn't mean you have to update... > > So you're saying I shouldn't use Fuel? > > If you plan to serialize now and materialize in 10 years with a new Pharo image and you are not willing to update Fuel to make it work in that Pharo image, then yes, don't use it. Use ReferenceStream and hope that Pharo team keep it updated for 10 years without changing its format. > Cheers > Philippe > > > -- Mariano http://marianopeck.wordpress.com

Oct. 16, 2011

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

by Philippe Marschall

On 15.10.2011 15:06, Martin Dias wrote: > I like the ideas of Stef and Ben of loading multiple fuel versions at > the same time. Do you know something done in that sense? > > MartÃn > > On Sat, Oct 15, 2011 at 7:09 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com > <mailto:marianopeck@gmail.com>> wrote: > > > > On Sat, Oct 15, 2011 at 11:49 AM, Philippe Marschall > <kustos(a)gmx.net > <mailto:kustos@gmx.net>> wrote: > > On 11.10.2011 21:51, Mariano Martinez Peck wrote: > > > > > > On Tue, Oct 11, 2011 at 8:55 AM, Philippe Marschall > > <philippe.marschall(a)netcetera.ch > <mailto:philippe.marschall@netcetera.ch> > > > <mailto:philippe.marschall@netcetera.ch > <mailto:philippe.marschall@netcetera.ch>>> > wrote: > > > > On 10/08/2011 10:42 PM, Mariano Martinez Peck wrote: > > > s > > > > > >>> > > >>> This is IMHO more than necessary for Fuel to become a > production > > ready > > >>> serializer and I'd say Fuel is now "old enough" to > become such :) > > >> > > >> Yes. > > >> Now what I would love is that even if fuel changes that the > > evolution of > > >> information > > >> is taken into account because like that it will be > exercised for > > real. > > >> > > >> > > > 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. > > > > That is horribly naÃ¯ve an excludes fuel from a lot of use > cases. You > > can't use fuel for "archiving" objects outside of the > image because you > > will never know whether you will be able to read them in > again because > > the format changes. You will always need to have "live" > ones in the > > image. > > > > > > No. That's incorrect. You won't be able to do that ONLY if you > update > > Fuel to a new image that breaks format. > > You can still continue to use the same version and you will > never have > > that problem. So, again, why you need to update Fuel? > > Because it's old software. Bugs may not get fixed. It may not > work in > newer Pharo versions. I may have dependencies on other libraries > that > may require a new version of Fuel. You name it. > > > > I understand. What I mean is that depending on the changes and the > amount of work, you can just adapt Fuel to new versions of Pharo but > without changing its format. > I mean....say you were in Fuel 1.4. You don't need to move to Fuel > 1.8 just because. You can just try to fix 1.4 to make it work in > latest pharo. Oh yeah sure, I can always fork Fuel and maintain it myself. That's exactly what I don't don't want to do. > That's EXACTLY what we do with ReferenceStream and friends. The only > difference is that the Pharo team does that because it is in the core. > But yes, it may happen that ideed you will require a new version of > Fuel. Whatâ½ What's the advantage of Fuel over ReferenceStream again? > > Why SmartRefStream does not have this problem? because it hasn't > > changed in the last 10 years. > > So..do the same, take an specific Fuel version and keep it for > 10 years. > > Just update it to make it work in Pharo without changing the > format and > > you are done. > > > > > > > > That means you can't use fuel for anything Monticello > related because > > you may never be able to load those versions in again > because the file > > format has changed in the mean time. > > > > > > I guess that in the end, if someone can really do something for > > Monticello on top of Fuel it will be like 2 years from now, > and at some > > point Fuel format will be stable. > > And as Stef says...you always have the code there in case of > problems. > > Monticello is just an example for a case where I want to store > objects > outside of the image. > > > Well, then you can just wait until we finish. Give us one year more. > Instead of doing 1-year-long releases, we like to do 3 months > releases. > But again, that doesn't mean you have to update... So you're saying I shouldn't use Fuel? Cheers Philippe

Oct. 16, 2011