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

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

by Max Leske

On 07.03.2014, at 09:37, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 07/03/2014 09:25, Max Leske a Ã©crit : >> >>> >>> I do have a version browser for that; but it plays with git at a bit too high level to be as powerfull as you describe. >> >> Is it on Smalltalkhub? Iâd like to take a look if you let me. > > It's on github :) I should have knownâ¦ :) > > https://github.com/ThierryGoubier/AltBrowser/tree/pharo3.0/Alt-Browser.pack… > > and the git interface lives inside gitfiletree, at: > > https://github.com/dalehenrich/filetree/blob/issue_124/repository/Monticell… > > Also available via ConfigurationOfGitFileTree. > > I'd be especially interested to know if, the way you're planning to do it, will allow to: > > - Better track methods among class renames, package renames, ownership in packages and so on: mine I think get the commits for all versions of a method right, but is limited in its ability to find them through renames (since each version path name may be different from the current one). Ummmmâ¦ Iâll have to see about thatâ¦ ^^ But Iâll definitely let you know. > > - And be able to rebuild package version history via the VCS history, as I do now in gitfiletree. Yes, that is something that should be possible. To be honest, those thoughts are a bit too far in the future at the moment. First, I want to have Git plumbing running, then Iâll see about the rest. > > Thierry > -- > 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 7, 2014

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

by Goubier Thierry

Le 07/03/2014 09:25, Max Leske a Ã©crit : > >> >> I do have a version browser for that; but it plays with git at a bit too high level to be as powerfull as you describe. > > Is it on Smalltalkhub? Iâd like to take a look if you let me. It's on github :) https://github.com/ThierryGoubier/AltBrowser/tree/pharo3.0/Alt-Browser.pack… and the git interface lives inside gitfiletree, at: https://github.com/dalehenrich/filetree/blob/issue_124/repository/Monticell… Also available via ConfigurationOfGitFileTree. I'd be especially interested to know if, the way you're planning to do it, will allow to: - Better track methods among class renames, package renames, ownership in packages and so on: mine I think get the commits for all versions of a method right, but is limited in its ability to find them through renames (since each version path name may be different from the current one). - And be able to rebuild package version history via the VCS history, as I do now in gitfiletree. Thierry -- 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 7, 2014

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

by Max Leske

On 07.03.2014, at 09:08, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 06/03/2014 23:01, Max Leske a Ã©crit : >> >> On 06.03.2014, at 22:14, Eliot Miranda <eliot.miranda(a)gmail.com >> <mailto:eliot.miranda@gmail.com>> wrote: >>> the tail wags the dog. if the diff facilities in things like git were >>> well-designed they'd be pluggable and allow one to parse files into >>> meaningful chunks. > > Can be done for git diffing and large files, so no need to push the blame on git. We just need someone to write the tools in Smalltalk. > >>> But why do you need command-line diff tools? >> >> We donât. Diffing has nothing to do with this (or only little). But if a >> method has its own file, then the hash of that method will be stable as >> long as it is unchanged, regardless of the number of commits it is >> referenced by. This makes it very easy to identify the changes that have >> been made to a particular method. How these changes are *visualized* is >> a different matter (and I would like to have a nice GUI for that too). > > I do have a version browser for that; but it plays with git at a bit too high level to be as powerfull as you describe. Is it on Smalltalkhub? Iâd like to take a look if you let me. > > Thierry > -- > 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 7, 2014

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

by Max Leske

On 07.03.2014, at 09:01, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 06/03/2014 17:30, Max Leske a Ã©crit : >> >> >> 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 > > Are you free, when fetching a git repository, to decide whether to pack or not or is the source repository in charge of that? Network transfer is always packed. > > Past a certain point, you can expect all/most of your small files (and small deltas) to be packed, no? No, unless you impelement something like post hook to force âgit gcâ. New / changed objects will be stored as loose objects. If you consider a large repository, than maybe âthe larger partâ of all objects may be packed (objects that are only read) but that very much depends on the usage of the repository (e.g. if you have to compile stuff there will be tons of new objects every time). > >> But: the main storage form (and the fastest for access) are loose objects (i.e. single files) > > But you have to support both storage form to be able to read a git repository. Yes. Thatâs a bit of a downside. But it makes things interesting :) > >> Just for completeness :) > > You known certainly more about that than I do :) Well, I should, considering the amount of time Iâve spent with Git (and itâs totally useless âthis is an excerpt from the IRC where Linus explains how Git really worksâ documentationâ¦) :p Max > > Thierry > -- > 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 7, 2014

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

by Max Leske

On 07.03.2014, at 08:38, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > I hope that somebody will have a look at the newspeak library that abstract from the back-end storage because this is an interesting idea. Noted. > >> >> >> On Thu, Mar 6, 2014 at 12:18 PM, 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. >> >> the tail wags the dog. if the diff facilities in things like git were well-designed they'd be pluggable and allow one to parse files into meaningful chunks. >> >> But why do you need command-line diff tools? If one spends most of one's time in Pharo why not have diff tools there-in and avoid all these contortions to appease a primitive VCS? You're already hitting thins like filename length limits in the mapping, and you're hitting performance problems. >> >> The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO. >> >> >> 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 >> >> >> >> >> -- >> best, >> Eliot >

March 7, 2014

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

by Goubier Thierry

Le 06/03/2014 23:01, Max Leske a Ã©crit : > > On 06.03.2014, at 22:14, Eliot Miranda <eliot.miranda(a)gmail.com > <mailto:eliot.miranda@gmail.com>> wrote: >> the tail wags the dog. if the diff facilities in things like git were >> well-designed they'd be pluggable and allow one to parse files into >> meaningful chunks. Can be done for git diffing and large files, so no need to push the blame on git. We just need someone to write the tools in Smalltalk. >> But why do you need command-line diff tools? > > We donât. Diffing has nothing to do with this (or only little). But if a > method has its own file, then the hash of that method will be stable as > long as it is unchanged, regardless of the number of commits it is > referenced by. This makes it very easy to identify the changes that have > been made to a particular method. How these changes are *visualized* is > a different matter (and I would like to have a nice GUI for that too). I do have a version browser for that; but it plays with git at a bit too high level to be as powerfull as you describe. Thierry -- 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 7, 2014

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

by Goubier Thierry

Le 06/03/2014 17:30, Max Leske a Ã©crit : > > > 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 Are you free, when fetching a git repository, to decide whether to pack or not or is the source repository in charge of that? Past a certain point, you can expect all/most of your small files (and small deltas) to be packed, no? > But: the main storage form (and the fastest for access) are loose objects (i.e. single files) But you have to support both storage form to be able to read a git repository. > Just for completeness :) You known certainly more about that than I do :) Thierry -- 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 7, 2014

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

by Pharo4Stef

I hope that somebody will have a look at the newspeak library that abstract from the back-end storage because this is an interesting idea. > > > On Thu, Mar 6, 2014 at 12:18 PM, 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. > > the tail wags the dog. if the diff facilities in things like git were well-designed they'd be pluggable and allow one to parse files into meaningful chunks. > > But why do you need command-line diff tools? If one spends most of one's time in Pharo why not have diff tools there-in and avoid all these contortions to appease a primitive VCS? You're already hitting thins like filename length limits in the mapping, and you're hitting performance problems. > > The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO. > > > 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 > > > > > -- > best, > Eliot

March 7, 2014

Re: [Pharo-dev] TWM and 3.0: icons/themes, UpdatingMenuMorph

by Pharo4Stef

On 06 Mar 2014, at 12:05, phil(a)highoctane.be wrote: > And of course, the TWMUI Theme doesn't work at all anymore... > > Is there some info about how the new theming works in 3.0? What have been removed are UIManager creation methods (I would have prefer to have them deprecated we could still do it). newColumns and others, if I remember correctly Now for the theming I do not think it changed. > > TIA > Phil > > > > > On Thu, Mar 6, 2014 at 12:00 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I am trying to get TWM to work in 3.0 > > I use the Metacello config flag "trick" to make it load 2.x things. > > Now, things do load but there is the deprecation warnings about the way icons are handled. > > e.g. > > deleteSnapshotIcon > ^ dock theme smallDeleteIcon. > > gives a warning. > > I looked into the code and now, we are supposed to do: > > Smalltalk ui smallDeleteIcon. > > Well, I changed the things that needed to be changed and then hit: > > newMenu: aSelector icon: aForm help: aString > ^ MenuItemMorph new > contents: ''; > subMenu: (UpdatingMenuMorph new updater: self updateSelector: aSelector); > icon: aForm; > setBalloonText: aString. > > Where Updating MenuMorph appears to be gone in 3.0 > > What am I supposed to use as a replacement? > > TIA > > Phil > > >

March 7, 2014

Re: [Pharo-dev] What happened with petitmarkdown?

by Damien Cassou

Try on github On Mar 6, 2014 1:27 PM, "Stephan Eggermont" <stephan(a)stack.nl> wrote: > Camillo, > > While fixing some ci builds, I noticed that at least some of your > smalltalkhub > repositories are empty (petitmarkdown, ast-interpreter). What happened > with the code? ast-interpreter I could find back, but petitmarkdown not. > > Stephan > > >

March 7, 2014