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

Re: [Pharo-project] MCDirectoryRepository defaultDirectoryName ignored?

by Mariano Martinez Peck

On Sat, Oct 15, 2011 at 4:39 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > The value is updated after you save or open an image, because you > could have moved the image. This is a desired behavior. > > Thanks Lukas. I have just tried saving the image and re-open it but still, it keeps using the default. Even if MCDirectoryRepository defaultDirectoryName prints the one I want. > I suggest that you symlink the package cache directory, this works > very well for the builder to avoid that builds re-download the same > versions over and over again. > But I don't want to use a symlink nor nothing related to bash or OS setup. I have a ConfiguratioOf and I want that before starting to download everything, to change the package-cache to another place... Thanks! > > Lukas > > On 15 October 2011 16:25, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Hi guys. I have changed the value of MCDirectoryRepository > > defaultDirectoryName by doing > > > > MCDirectoryRepository defaultDirectoryName: > > '/Users/mariano/Pharo/localRepo/'. > > > > or by the settings browser...but anyway, it seems "ignored". For example, > if > > I now create a new repository in the monticello browser, and I download a > > package, the package cache used is the previous/original one (there the > > .image is). > > I want to set an specific package-cache and that all projects/packages > > loaded in the future take that package cache. > > > > any ideas? > > > > thanks > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Mariano http://marianopeck.wordpress.com

Oct. 15, 2011

Re: [Pharo-project] MCDirectoryRepository defaultDirectoryName ignored?

by Lukas Renggli

The value is updated after you save or open an image, because you could have moved the image. This is a desired behavior. I suggest that you symlink the package cache directory, this works very well for the builder to avoid that builds re-download the same versions over and over again. Lukas On 15 October 2011 16:25, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. I have changed the value of MCDirectoryRepository > defaultDirectoryName by doing > > MCDirectoryRepository defaultDirectoryName: > '/Users/mariano/Pharo/localRepo/'. > > or by the settings browser...but anyway, it seems "ignored". For example, if > I now create a new repository in the monticello browser, and I download a > package, the package cache used is the previous/original one (there the > .image is). > I want to set an specific package-cache and that all projects/packages > loaded in the future take that package cache. > > any ideas? > > thanks > > -- > Mariano > http://marianopeck.wordpress.com > > -- Lukas Renggli www.lukas-renggli.ch

Oct. 15, 2011

[Pharo-project] MCDirectoryRepository defaultDirectoryName ignored?

by Mariano Martinez Peck

Hi guys. I have changed the value of MCDirectoryRepository defaultDirectoryName by doing MCDirectoryRepository defaultDirectoryName: '/Users/mariano/Pharo/localRepo/'. or by the settings browser...but anyway, it seems "ignored". For example, if I now create a new repository in the monticello browser, and I download a package, the package cache used is the previous/original one (there the .image is). I want to set an specific package-cache and that all projects/packages loaded in the future take that package cache. any ideas? thanks -- Mariano http://marianopeck.wordpress.com

Oct. 15, 2011

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

by Mariano Martinez Peck

On Sat, Oct 15, 2011 at 4:04 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > On Sat, Oct 15, 2011 at 2:47 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi guys. I was trying to use TWM in Pharo 1.3 release. TWM brings with >> keymappings, which breaks the shortcuts of my image. For example, after >> installing keymappings I cannot close windows anymore with cmd + w or I >> cannot run tests from the browser using cmd + t. 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 can make Keymapping dependency optional, should not be a lot of work - > split TilingWMSettings class and put the Keymapping part in another package. > > That said, Keymapping is a great feature for TWM (I always use it), so > would be cool to add "Close Window" and "Run Test" - (I can add Close Window > to TWM). > > Yes, the problem is that I found those just by chance (because are those I use all the time), but I am worried if there are even more shortcuts that are broken... > Waiting for feedback, you can load this one in Pharo 1.3 that will work: > > Gofer it > squeaksource: 'TilingWindowManager'; > version: 'TWM-CheckKeymapping-LaurentLaffont.76'; > load > Thanks, I will test it. > > Laurent. > > > >> >> thanks! >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > -- Mariano http://marianopeck.wordpress.com

Oct. 15, 2011

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

by laurent laffont

On Sat, Oct 15, 2011 at 2:47 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys. I was trying to use TWM in Pharo 1.3 release. TWM brings with > keymappings, which breaks the shortcuts of my image. For example, after > installing keymappings I cannot close windows anymore with cmd + w or I > cannot run tests from the browser using cmd + t. 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 can make Keymapping dependency optional, should not be a lot of work - split TilingWMSettings class and put the Keymapping part in another package. That said, Keymapping is a great feature for TWM (I always use it), so would be cool to add "Close Window" and "Run Test" - (I can add Close Window to TWM). Waiting for feedback, you can load this one in Pharo 1.3 that will work: Gofer it squeaksource: 'TilingWindowManager'; version: 'TWM-CheckKeymapping-LaurentLaffont.76'; load Laurent. > > thanks! > > -- > Mariano > http://marianopeck.wordpress.com > >

Oct. 15, 2011

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

by Schwab,Wilhelm K

I should have thought of this earlier: Dolphin's #environment concept will do the job. Instead of hard references to classes or adding a new name space syntax, one can simply use messages to delay binding. I should *look* at Fuel to find an example, but suppose there is a class FuelDWORD. Instead of referencing it, one would do something like Fuel formatDWORD or Fuel environment formatDWORD or ( Fuel version:3 ) formatDWORD etc. There are many ways one could handle the details, but #environment or #version: can return a "system dictionary" (an ordinary class would suffice) that is version specific, allowing FuelDWORD_3 to be used by code that otherwise knows only that it should use given selector to get the class it needs. To develop the different version/environments, one could use the RB to rename classes and then save the new version classes in a Fuel sub-package. Add FuelVersion3 to give out the correct selectors, and a basic facade should be able to make everything go with the various versions in the system at one time. Finally, one could facade the entire serializer, something like (Fuel version:3) save:anObject on:aStream. (Fuel version:3) readFrom:aStream. etc. Does that make sense? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Martin Dias [tinchodias(a)gmail.com] Sent: Saturday, October 15, 2011 9:06 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] When will Fuel file format stabilize? 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. 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. > 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... Cheers Philippe -- Mariano http://marianopeck.wordpress.com

Oct. 15, 2011

Re: [Pharo-project] [squeak-dev] Any serializer can customize serialization strategy?

by Masashi UMEZAWA

Hi, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >Is there any serializer (Fuel/StOMP/Ma object >serialization/BOSS/SRP/SIXX??) which let me attach an external >compressor/decompressor for specific Strings to the >serialization/deserialization process? Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > I think StOMP should support this as well: > http://stomp.smalltalk-users.jp/home/how-to-use-stomp/hook-methods Yes. StOMP does support such kind of custom serialization. Pattern 1: Using Memento. StOMP has two basic hook methods (stompWriteValue/stompReadValue). With a memento pattern, you can customize serialization/deserialization behavior easily. SpecificString>> stompWriteValue ^ StringCompressedMemento on: self StringCompressedMemento>> stompReadValue ^ SpecificString on: self uncompressToString SpecificString is a mere wrapper class (holding original string). And StringCompressedMemento should implement compress/uncompress logic. Pattern 2: Subclassing Writer/Reader Pattern 1 is usable, but it is basically suitable for pointer objects. For String-like objects, defining a new String wrapper and Memento is overwhelming. You can also subclass StompWriter/Reader for adding custom serialization/deserialization behaviors. MyStompWriter>>writeString: aString (self isSpecificString: aString) ifTrue: [^super writeString: (self compressString: aString)]. ^ super writeString: string MyStompReader>>readByteString | rawString | rawString := self basicReadObject asString. ^ (self isCompressedString: rawString) ifTrue: [self uncompressString: rawString] ifFalse: [rawString] You have to add some marking headers to the original string for determining it should be compressed/uncompressed. (Yes. this is a little awkward, but works well). I've attached working sample codes. So please see for details. Best regards, -- [:masashi | ^umezawa]

Oct. 15, 2011

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

by Martin Dias

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> wrote: > > > On Sat, Oct 15, 2011 at 11:49 AM, Philippe Marschall <kustos(a)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>> 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. > 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. > > > >> > 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... > > > > >> Cheers >> Philippe >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >

Oct. 15, 2011

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

by Mariano Martinez Peck

Hi guys. I was trying to use TWM in Pharo 1.3 release. TWM brings with keymappings, which breaks the shortcuts of my image. For example, after installing keymappings I cannot close windows anymore with cmd + w or I cannot run tests from the browser using cmd + t. 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) thanks! -- Mariano http://marianopeck.wordpress.com

Oct. 15, 2011

Re: [Pharo-project] [ANN] Fuel release version 1.7

by Henrik Sperre Johansen

On 14.10.2011 08:15, Martin Dias wrote: > Hi folks! > > We have released the new version 1.7 of Fuel, a binary serialization > framework for Pharo that provides extremely fast deserialization. More > information on our home page > <http://rmod.lille.inria.fr/web/pier/software/Fuel>. Again, I thank > ESUG for sponsoring me through the SummerTalk > <http://www.esug.org/wiki/pier/Promotion/SummerTalk/SummerTalk2011> program. > > You can download this version in Pharo 1.2.1 or 1.3 with: > > Gofer new > squeaksource: 'Fuel'; > package: 'ConfigurationOfFuel'; > load. > ((Smalltalk at: #ConfigurationOfFuel) project version: '1.7') load. > > > The list of changes includes performance optimizations, design > clean-ups, and new features. > > - The FLSerializer and FLMaterializer API has changed. They are no > longer implementing the algorithms but are a kind of FaÃ§ade. > - Developer guides with examples: Getting Started > <http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.7/StreamsGuide> > and Customizing the graph > <http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.7/Hooks>. > - Serialization substitutions: "Store this object instead of me." > - Global sends: "Restore me by sending this selector to this global" > - Versioning the stream: We prefix the stream with a version number > that should match when loading. > - Performance optimizations on instances of: > -- Word-like classes. (We thank a lot to Henrik Sperre Johansen for > your help!) > -- ByteString and Symbol. > -- Date, Time, Duration and DateAndTime. > -- Point and Rectangle. > -- MethodDictionary. Now materialization is 2000x faster, thanks to > its new rehash without become. > - Huge clean-up in Tests package. > > Cheers! > MartÃn Dias Grats! Any blog posts with benchmarks comparing different Fuel versions? Cheers, Henry

Oct. 15, 2011