March 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Fuel] Unexpected stream version 19

by Max Leske

Weâve been discussing that and are evaluating different approaches to solving this problem. We are pretty sure (but canât guarantee) that there are no format differences between 1.9 and 1.9.3. So feel free to remove the error and continue. It will probably work (just expect that it might not). Cheers, Max On 06.03.2014, at 17:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Well, https://pharo.fogbugz.com/f/cases/13000/Integrate-Fuel-1-9-3 was just integrated. Why Fuel is so picky about minor versions, and if that matters, I don't know. > > On 06 Mar 2014, at 17:14, roberto.minelli(a)usi.ch wrote: > >> Hi, >> >> I just run into an error while materializing an object with Fuel. Unexpected stream version 19 should be 193. >> >> Do you have any idea why? I noticed that the fuel #stable version is now 1.9.3 instead of 1.9.1 which was the version I used for export. When I loaded Fuel 1.9.1 despite getting some errors, I managed to import my objects. >> >> Do you guys have an idea why? >> >> Thanks in advance, here is the stack trace. >> >> Roby >> >> FLMaterializer>>verifyVersionFrom: >> FLMaterializer>>materializeFrom: >> FLMaterializer class>>materializationFromFileNamed: in Block: [ :aFileStream | self newDefault materializeFrom: ...etc... >> StandardFileStream class(FileStream class)>>detectFile:do: in Block: [ anotherBlock value: file ] >> BlockClosure>>ensure: >> StandardFileStream class(FileStream class)>>detectFile:do: >> StandardFileStream class(FileStream class)>>oldFileNamed:do: >> FLMaterializer class>>materializationFromFileNamed: >> FLMaterializer class>>materializeFromFileNamed: >> DFPharoMenu class>>importSessionFromFuelPath: >> DFPharoMenu class>>importAllSessionsFromFolder in Block: [ :bar | ... >> BlockClosure>>cull: >> Job>>run in Block: [ result := block cull: self ] >> BlockClosure>>on:do: >> Job>>run in Block: [ ... >> BlockClosure>>ensure: >> Job>>run >> MorphicUIManager(UIManager)>>displayProgress:from:to:during: >> ByteString(String)>>displayProgressAt:from:to:during: >> DFPharoMenu class>>importAllSessionsFromFolder >> DFPharoMenu class>>menuCommandOn: in Block: [ self importAllSessionsFromFolder ] >> BlockClosure>>cull: >> ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [ ... >> BlockClosure>>ensure: >> CursorWithMask(Cursor)>>showWhile: >> ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: >> ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: >> ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: >> MouseButtonEvent>>sentTo: >> ToggleMenuItemMorph(Morph)>>handleEvent: >> >> >> >> > >

March 6, 2014

Re: [Pharo-dev] Support for git in Pharo

by Max Leske

On 06.03.2014, at 16:25, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 06/03/2014 16:14, Max Leske a Ã©crit : >> >> On 06.03.2014, at 15:53, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >>> Max wrote: >>>> I donât quite follow. What do you mean by methods? >>> >>> When mapping methods to files, there is the problem that on disk files take a minimum amount of space, >>> often 4KB. This slows writing a package to disk down a lot. >> >> I see. There are two things to consider: >> 1. the format we use to store source >> 2. the fact that Git will create one blob per file > > Git will pack blobs in a kind of archive file, in .pack files. That is only partly true: - packs will be generated when objects are transferred over the network (this may be partial packs) - packs can be force generated by using âgit gcâ - packs will be periodically created / updated to reduce size on disk But: the main storage form (and the fastest for access) are loose objects (i.e. single files) Just for completeness :) Max > >> Obviously, by choosing a source storage format that avoids this problem, we donât have to deal with the second issue. >> If you go with something like FileTree, which uses a single file per method, this changes. By combining multiple files (e.g. by zipping) we could avoid the problem of tiny blobs but we would loose the ability to look at the repository from the outside. This is something I donât want to do. It creates a dependency to Pharo (and to the particular implementation of how those files are stored) and unneeded complexity (especially with regard to maintenance). > > +1. > >> In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed. > > I agree with that :) > > Thierry > >> So yes, potentially we could do something about fragmentation but I wonât promise you anything. Does that answer your question? >> >> Cheers, >> Max >> >>> >>> Stephan >>> >>> >>> >> >> >> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

March 6, 2014

Re: [Pharo-dev] [Fuel] Unexpected stream version 19

by Sven Van Caekenberghe

Well, https://pharo.fogbugz.com/f/cases/13000/Integrate-Fuel-1-9-3 was just integrated. Why Fuel is so picky about minor versions, and if that matters, I don't know. On 06 Mar 2014, at 17:14, roberto.minelli(a)usi.ch wrote: > Hi, > > I just run into an error while materializing an object with Fuel. Unexpected stream version 19 should be 193. > > Do you have any idea why? I noticed that the fuel #stable version is now 1.9.3 instead of 1.9.1 which was the version I used for export. When I loaded Fuel 1.9.1 despite getting some errors, I managed to import my objects. > > Do you guys have an idea why? > > Thanks in advance, here is the stack trace. > > Roby > > FLMaterializer>>verifyVersionFrom: > FLMaterializer>>materializeFrom: > FLMaterializer class>>materializationFromFileNamed: in Block: [ :aFileStream | self newDefault materializeFrom: ...etc... > StandardFileStream class(FileStream class)>>detectFile:do: in Block: [ anotherBlock value: file ] > BlockClosure>>ensure: > StandardFileStream class(FileStream class)>>detectFile:do: > StandardFileStream class(FileStream class)>>oldFileNamed:do: > FLMaterializer class>>materializationFromFileNamed: > FLMaterializer class>>materializeFromFileNamed: > DFPharoMenu class>>importSessionFromFuelPath: > DFPharoMenu class>>importAllSessionsFromFolder in Block: [ :bar | ... > BlockClosure>>cull: > Job>>run in Block: [ result := block cull: self ] > BlockClosure>>on:do: > Job>>run in Block: [ ... > BlockClosure>>ensure: > Job>>run > MorphicUIManager(UIManager)>>displayProgress:from:to:during: > ByteString(String)>>displayProgressAt:from:to:during: > DFPharoMenu class>>importAllSessionsFromFolder > DFPharoMenu class>>menuCommandOn: in Block: [ self importAllSessionsFromFolder ] > BlockClosure>>cull: > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [ ... > BlockClosure>>ensure: > CursorWithMask(Cursor)>>showWhile: > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: > ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: > MouseButtonEvent>>sentTo: > ToggleMenuItemMorph(Morph)>>handleEvent: > > > >

March 6, 2014

[Fuel] Unexpected stream version 19

by roberto.minelli＠usi.ch

Hi, I just run into an error while materializing an object with Fuel. Unexpected stream version 19 should be 193. Do you have any idea why? I noticed that the fuel #stable version is now 1.9.3 instead of 1.9.1 which was the version I used for export. When I loaded Fuel 1.9.1 despite getting some errors, I managed to import my objects. Do you guys have an idea why? Thanks in advance, here is the stack trace. Roby FLMaterializer>>verifyVersionFrom: FLMaterializer>>materializeFrom: FLMaterializer class>>materializationFromFileNamed: in Block: [ :aFileStream | self newDefault materializeFrom: ...etc... StandardFileStream class(FileStream class)>>detectFile:do: in Block: [ anotherBlock value: file ] BlockClosure>>ensure: StandardFileStream class(FileStream class)>>detectFile:do: StandardFileStream class(FileStream class)>>oldFileNamed:do: FLMaterializer class>>materializationFromFileNamed: FLMaterializer class>>materializeFromFileNamed: DFPharoMenu class>>importSessionFromFuelPath: DFPharoMenu class>>importAllSessionsFromFolder in Block: [ :bar | ... BlockClosure>>cull: Job>>run in Block: [ result := block cull: self ] BlockClosure>>on:do: Job>>run in Block: [ ... BlockClosure>>ensure: Job>>run MorphicUIManager(UIManager)>>displayProgress:from:to:during: ByteString(String)>>displayProgressAt:from:to:during: DFPharoMenu class>>importAllSessionsFromFolder DFPharoMenu class>>menuCommandOn: in Block: [ self importAllSessionsFromFolder ] BlockClosure>>cull: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [ ... BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: MouseButtonEvent>>sentTo: ToggleMenuItemMorph(Morph)>>handleEvent:

March 6, 2014

Re: [Pharo-dev] Support for git in Pharo

by Goubier Thierry

Le 06/03/2014 16:14, Max Leske a Ã©crit : > > On 06.03.2014, at 15:53, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> Max wrote: >>> I donât quite follow. What do you mean by methods? >> >> When mapping methods to files, there is the problem that on disk files take a minimum amount of space, >> often 4KB. This slows writing a package to disk down a lot. > > I see. There are two things to consider: > 1. the format we use to store source > 2. the fact that Git will create one blob per file Git will pack blobs in a kind of archive file, in .pack files. > Obviously, by choosing a source storage format that avoids this problem, we donât have to deal with the second issue. > If you go with something like FileTree, which uses a single file per method, this changes. By combining multiple files (e.g. by zipping) we could avoid the problem of tiny blobs but we would loose the ability to look at the repository from the outside. This is something I donât want to do. It creates a dependency to Pharo (and to the particular implementation of how those files are stored) and unneeded complexity (especially with regard to maintenance). +1. > In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed. I agree with that :) Thierry > So yes, potentially we could do something about fragmentation but I wonât promise you anything. Does that answer your question? > > Cheers, > Max > >> >> Stephan >> >> >> > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

March 6, 2014

Re: [Pharo-dev] Support for git in Pharo

by Max Leske

On 06.03.2014, at 15:53, Stephan Eggermont <stephan(a)stack.nl> wrote: > Max wrote: >> I donât quite follow. What do you mean by methods? > > When mapping methods to files, there is the problem that on disk files take a minimum amount of space, > often 4KB. This slows writing a package to disk down a lot. I see. There are two things to consider: 1. the format we use to store source 2. the fact that Git will create one blob per file Obviously, by choosing a source storage format that avoids this problem, we donât have to deal with the second issue. If you go with something like FileTree, which uses a single file per method, this changes. By combining multiple files (e.g. by zipping) we could avoid the problem of tiny blobs but we would loose the ability to look at the repository from the outside. This is something I donât want to do. It creates a dependency to Pharo (and to the particular implementation of how those files are stored) and unneeded complexity (especially with regard to maintenance). In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed. So yes, potentially we could do something about fragmentation but I wonât promise you anything. Does that answer your question? Cheers, Max > > Stephan > > >

March 6, 2014

Re: [Pharo-dev] Support for git in Pharo

by Stephan Eggermont

Max wrote: >I donât quite follow. What do you mean by methods? When mapping methods to files, there is the problem that on disk files take a minimum amount of space, often 4KB. This slows writing a package to disk down a lot. Stephan

March 6, 2014

Re: [Pharo-dev] AST-Interpreter on CI is green

by ClÃ©ment Bera

Thanks for fixing it. Tthe tests are green but last time I tried the regression tests (package AST-Interpreter-PharoTest) were failing. 2014-03-06 13:18 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > The build was red, referring to dh83/ast-Interpreter (empty). > Changed the config to use Pharo/AST-Interpreter > > Stephan > > > >

March 6, 2014

Re: [Pharo-dev] Support for git in Pharo

by Max Leske

On 06.03.2014, at 15:04, Stephan Eggermont <stephan(a)stack.nl> wrote: > Max wrote: >> Iâm working on libgit2 bindings for Pharo. If we can include libgit2 in the VM environment there will be no dependencies to a >Git installation. Iâll be visiting Lille for two weeks starting on monday and one goal is to advance that work to a stage where >we can start doing something with it. > > That sounds good. I happen to have older git versions which no longer work after upgrading to Mavericksâ¦ > > Will that allow us to avoid the filesystem bottleneck for large packages where minimum disk block size for methods is much larger than the actual method size? I donât quite follow. What do you mean by methods? > > Stephan

March 6, 2014

Re: [Pharo-dev] Support for git in Pharo

by Stephan Eggermont

Max wrote: >Iâm working on libgit2 bindings for Pharo. If we can include libgit2 in the VM environment there will be no dependencies to a >Git installation. Iâll be visiting Lille for two weeks starting on monday and one goal is to advance that work to a stage where >we can start doing something with it. That sounds good. I happen to have older git versions which no longer work after upgrading to Mavericksâ¦ Will that allow us to avoid the filesystem bottleneck for large packages where minimum disk block size for methods is much larger than the actual method size? Stephan

March 6, 2014