- Pharo-dev - lists.pharo.org

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

by Max Leske

On 06.03.2014, at 21:18, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > Stephan, > > The reason that we have the granularity of a file per method is to leverage git's history/tracking facilities on a per method basis. > > At this level of granularity, you can move a method around in the package structure and git will maintain the method modification history because git treats these as a file rename and git is very good at tracking file renames ... > > So you can use "blame" to view a line by line history of the method modifications ... > > If one starts clumping methods into files, then you lose all method history when it moves from one clump to another â¦ Ah, I knew I had forgotten something :D Thanks Dale > > Dale > > > > On Thu, Mar 6, 2014 at 9:03 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Max wrote > >In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed. > > Iâm not totally convinced. The readability from the outside is limited by having one file per method. > Mainstream tooling assumes one file per class. The emails from github to this list are a good example > of the usability problems that leads to. I donât want to suggest switching to a larger granularity, as that > leads to another set of problems. > > My point was more if we could mostly avoid the source view, and directly work with the archive. > Why is working with single files fastest? > > Stephan >

March 6, 2014

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

by Dale Henrichs

Stephan, The reason that we have the granularity of a file per method is to leverage git's history/tracking facilities on a per method basis. At this level of granularity, you can move a method around in the package structure and git will maintain the method modification history because git treats these as a file rename and git is very good at tracking file renames ... So you can use "blame" to view a line by line history of the method modifications ... If one starts clumping methods into files, then you lose all method history when it moves from one clump to another ... Dale On Thu, Mar 6, 2014 at 9:03 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Max wrote > >In my opinion there are other factors, like readability, maintenance etc, > that are maybe more important than speed. > > I'm not totally convinced. The readability from the outside is limited by > having one file per method. > Mainstream tooling assumes one file per class. The emails from github to > this list are a good example > of the usability problems that leads to. I don't want to suggest switching > to a larger granularity, as that > leads to another set of problems. > > My point was more if we could mostly avoid the source view, and directly > work with the archive. > Why is working with single files fastest? > > Stephan >

March 6, 2014

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

by Max Leske

On 06.03.2014, at 18:03, Stephan Eggermont <stephan(a)stack.nl> wrote: > Max wrote >> In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed. > > Iâm not totally convinced. The readability from the outside is limited by having one file per method. > Mainstream tooling assumes one file per class. The emails from github to this list are a good example > of the usability problems that leads to. I donât want to suggest switching to a larger granularity, as that > leads to another set of problems. I agree that we have to keep that in mind. And you are right that one file per method may be too granular. But at the moment (and I certainly have not done exhaustive work on this) I have no better solution. Since this is part of my Masterâs thesis, the scope of what I have time for is limited and I will be very glad if I manage to finish FileSystem-Git. Iâd rather not invent something, that then will turn out to be sub par and rather go with established protocols / methods, which may be inferior to a different solution, but of which I can at least estimate the possible drawbacks. This is not to say, that I donât want to achieve the best that is possible, Iâm just trying to avoid disappointment :) > > My point was more if we could mostly avoid the source view, and directly work with the archive. > Why is working with single files fastest? Well, of course that is not generally the case, but when working with pack files, it can be. Pack files do have indexes and fanout tables, so searching for an object is easy. But usually, contrary to loose objects, objects in packs will be deltified to a certain degree (more deltas the more objects there are) and deltification incurs the cost of putting the object back together (a delta chain can be of any length in theory), which means multpile offset calculations and searches on the stream. In average (and this is just an educated guess) the access time will thus be greater than for loose objects. Max > > Stephan

March 6, 2014

Re: [Pharo-dev] [Pharo-users] Phratch one-click

by jannik laval

Hi Hilaire, Hum, probably this comes from there... Could you explain a bit more how to change it ? Cheers, Jannik 2014-03-05 11:19 GMT+01:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > For event, how is it developed? > > I remember, when I started developing DrGeo I used the change/update > event mecanism. Then I dropped it for a simple linear top/down update of > the geometric tree model, it becames much faster after that. > > Hilaire > > Le 05/03/2014 10:44, jannik laval a Ã©crit : > > > > I think now that we need some profiling. > > Any expert for that ? > > > > -- > Dr. Geo http://drgeo.eu > > > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/

March 6, 2014

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

by Stephan Eggermont

Max wrote >In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed. Iâm not totally convinced. The readability from the outside is limited by having one file per method. Mainstream tooling assumes one file per class. The emails from github to this list are a good example of the usability problems that leads to. I donât want to suggest switching to a larger granularity, as that leads to another set of problems. My point was more if we could mostly avoid the source view, and directly work with the archive. Why is working with single files fastest? Stephan

March 6, 2014

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