- Pharo-dev - lists.pharo.org

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

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

by Dale Henrichs

Oh I certainly don't think that FileTree is the best possible way ... as it stands FileTree functions as a bridge that allows folks to migrate towards using git/mercurial/svn ... once a beach head in the git/mercurial/svn world is established it is a good time to re-evaluate what is important... tools integration is probably much more important than the implementation detail of what the packages look like on disk ... but that's just my opinion:) Personally when I am working, the method is the unit of functionality that is important ... so for me the history of method is important information and when I identify a change that is "interesting" i then may want to see all of the other things that changed when that method was changed ... the current implementation of FileTree makes this kind of spelunking possible ... but it takes tools to bring this to reality ... Are there other ways to make this a reality? ... I'm almost certain that there are ... but perhaps this functionality is only important to me ... or perhaps there are better ways of looking at the whole problem ... or ??? I have a vision for where FileTree and tools built upon it are headed but I won't claim that my vision "the one true way"... I've said this about Metacello for years: "I can hardly wait until someone implements a replacement for Metacello" ... and I feel the same way about FileTree:) I encourage other folks to implement their own visions... This is evolution in action ... stand on the shoulders of FileTree and build something better ... stand on the shoulders of git and build something better ... Dale On Thu, Mar 6, 2014 at 5:09 PM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > Just to rephase myself: The fact we're discussing how to store things > in git is a HUGE advance in mindset, it means we'll end up versioning > on top of it. > > I said: "That means we'll end up doing it the best possible way." > > Maybe FileTree is the best possible way that considers all the > constraints and requirements you mention :) > > When you built FileTree/Cypress you were an outlier (in the Smalltalk > realm), now it's mainstream. ;-) > > Regards! > > > -- > Esteban > > > 2014-03-06 20:24 GMT-03:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com > >: > > When you invent the next format, keep in mind that cross-platform source > > code sharing is something to consider as well ... It's always harder to > make > > cross-platform code and some compromises have to be made to accommodate > > multiple dialects ... > > > > Also consider that with FileTree we are only on the first step of Make it > > work, Make it right, Make it fast ... > > > > Put your energy into implementations not arguments:) > > > > Dale > > > > > > On Thu, Mar 6, 2014 at 3:09 PM, Esteban A. Maringolo < > emaringolo(a)gmail.com> > > wrote: > >> > >> I'm coming late to this, but Dolphin's VCS format has one file per > package > >> and "extensions", and one file per class (instance and metaclass). > >> > >> We succesfuly used that approach with git for more than a year. I know > >> Object Arts did the same but backed by MS VCS (sourcesafe). > >> > >> It is good that we're discussing HOW to version everything with an > >> external file based VCS. That means we'll end up doing it the best > possible > >> way. > >> > >> Regards. > >> > >> El mar 6, 2014 7:51 PM, "Jan Vrany" <jan.vrany(a)fit.cvut.cz> escribiÃ³: > >> > >>> On 06/03/14 22:34, Dale Henrichs wrote: > >>>> > >>>> My dream has finally come true ... Smalltalkers arguing the merits of > >>>> git vs. mercurial! > >>> > >>> > >>> Lucky you, I still have to wait for this to happen :-) > >>> > >>> Let's make myself clear, +1 was not because of mercurial, > >>> but because of class-per-file on-disk layout. > >>> > >>> Jan > >>> > >>> > >>>> > >>>> Alternate implementations to FileTree are welcome! > >>>> > >>>> Dale > >>>> > >>>> > >>>> On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz > >>>> <mailto:jan.vrany@fit.cvut.cz>> wrote: > >>>> > >>>> > >>>> > >>>> 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. > >>>> > >>>> > >>>> +1. > >>>> In St/X I do exactly the same. Works just fine. > >>>> > >>>> Jan > >>>> > >>>> > >>>> > >>> > >>> > > > >

March 7, 2014

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

by Esteban A. Maringolo

Just to rephase myself: The fact we're discussing how to store things in git is a HUGE advance in mindset, it means we'll end up versioning on top of it. I said: "That means we'll end up doing it the best possible way." Maybe FileTree is the best possible way that considers all the constraints and requirements you mention :) When you built FileTree/Cypress you were an outlier (in the Smalltalk realm), now it's mainstream. ;-) Regards! -- Esteban 2014-03-06 20:24 GMT-03:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > When you invent the next format, keep in mind that cross-platform source > code sharing is something to consider as well ... It's always harder to make > cross-platform code and some compromises have to be made to accommodate > multiple dialects ... > > Also consider that with FileTree we are only on the first step of Make it > work, Make it right, Make it fast ... > > Put your energy into implementations not arguments:) > > Dale > > > On Thu, Mar 6, 2014 at 3:09 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: >> >> I'm coming late to this, but Dolphin's VCS format has one file per package >> and "extensions", and one file per class (instance and metaclass). >> >> We succesfuly used that approach with git for more than a year. I know >> Object Arts did the same but backed by MS VCS (sourcesafe). >> >> It is good that we're discussing HOW to version everything with an >> external file based VCS. That means we'll end up doing it the best possible >> way. >> >> Regards. >> >> El mar 6, 2014 7:51 PM, "Jan Vrany" <jan.vrany(a)fit.cvut.cz> escribiÃ³: >> >>> On 06/03/14 22:34, Dale Henrichs wrote: >>>> >>>> My dream has finally come true ... Smalltalkers arguing the merits of >>>> git vs. mercurial! >>> >>> >>> Lucky you, I still have to wait for this to happen :-) >>> >>> Let's make myself clear, +1 was not because of mercurial, >>> but because of class-per-file on-disk layout. >>> >>> Jan >>> >>> >>>> >>>> Alternate implementations to FileTree are welcome! >>>> >>>> Dale >>>> >>>> >>>> On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz >>>> <mailto:jan.vrany@fit.cvut.cz>> wrote: >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> +1. >>>> In St/X I do exactly the same. Works just fine. >>>> >>>> Jan >>>> >>>> >>>> >>> >>> >

March 7, 2014

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

by phil＠highoctane.be

This was mentioned a while ago but... As there is not only Smalltalk code in today's projects, Git is nice. And, file per method or not, at this point, we have code in Git and it shows, and it helps the community being more visible. So, I am happy in being able to put my code in git. And git is not only the remote thing, but the local git repository. Which helps with projects and all the kinds of files we need to deal with. All in one place, how nice. Smalltalkhub is cool but not for non Smalltalk files. Phil On Fri, Mar 7, 2014 at 12:24 AM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > When you invent the next format, keep in mind that cross-platform source > code sharing is something to consider as well ... It's always harder to > make cross-platform code and some compromises have to be made to > accommodate multiple dialects ... > > Also consider that with FileTree we are only on the first step of Make it > work, Make it right, Make it fast ... > > Put your energy into implementations not arguments:) > > Dale > > > On Thu, Mar 6, 2014 at 3:09 PM, Esteban A. Maringolo <emaringolo(a)gmail.com > > wrote: > >> I'm coming late to this, but Dolphin's VCS format has one file per >> package and "extensions", and one file per class (instance and metaclass). >> >> We succesfuly used that approach with git for more than a year. I know >> Object Arts did the same but backed by MS VCS (sourcesafe). >> >> It is good that we're discussing HOW to version everything with an >> external file based VCS. That means we'll end up doing it the best possible >> way. >> >> Regards. >> El mar 6, 2014 7:51 PM, "Jan Vrany" <jan.vrany(a)fit.cvut.cz> escribiÃ³: >> >> On 06/03/14 22:34, Dale Henrichs wrote: >>> >>>> My dream has finally come true ... Smalltalkers arguing the merits of >>>> git vs. mercurial! >>>> >>> >>> Lucky you, I still have to wait for this to happen :-) >>> >>> Let's make myself clear, +1 was not because of mercurial, >>> but because of class-per-file on-disk layout. >>> >>> Jan >>> >>> >>> >>>> Alternate implementations to FileTree are welcome! >>>> >>>> Dale >>>> >>>> >>>> On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz >>>> <mailto:jan.vrany@fit.cvut.cz>> wrote: >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> +1. >>>> In St/X I do exactly the same. Works just fine. >>>> >>>> Jan >>>> >>>> >>>> >>>> >>> >>> >

March 6, 2014

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

by Dale Henrichs

When you invent the next format, keep in mind that cross-platform source code sharing is something to consider as well ... It's always harder to make cross-platform code and some compromises have to be made to accommodate multiple dialects ... Also consider that with FileTree we are only on the first step of Make it work, Make it right, Make it fast ... Put your energy into implementations not arguments:) Dale On Thu, Mar 6, 2014 at 3:09 PM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > I'm coming late to this, but Dolphin's VCS format has one file per package > and "extensions", and one file per class (instance and metaclass). > > We succesfuly used that approach with git for more than a year. I know > Object Arts did the same but backed by MS VCS (sourcesafe). > > It is good that we're discussing HOW to version everything with an > external file based VCS. That means we'll end up doing it the best possible > way. > > Regards. > El mar 6, 2014 7:51 PM, "Jan Vrany" <jan.vrany(a)fit.cvut.cz> escribiÃ³: > > On 06/03/14 22:34, Dale Henrichs wrote: >> >>> My dream has finally come true ... Smalltalkers arguing the merits of >>> git vs. mercurial! >>> >> >> Lucky you, I still have to wait for this to happen :-) >> >> Let's make myself clear, +1 was not because of mercurial, >> but because of class-per-file on-disk layout. >> >> Jan >> >> >> >>> Alternate implementations to FileTree are welcome! >>> >>> Dale >>> >>> >>> On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz >>> <mailto:jan.vrany@fit.cvut.cz>> wrote: >>> >>> >>> >>> 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. >>> >>> >>> +1. >>> In St/X I do exactly the same. Works just fine. >>> >>> Jan >>> >>> >>> >>> >> >>

March 6, 2014

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

by Sebastian Sastre

LOLWAT! :D for what is worth, my experience.. I donât know mercurial and I was ~8 months flirting with git and in a relationship since ~4 Git is okay Exposing the code out there in a way others can use their familiar commands to test our software is something I find very healthy But for us, automation is the real winner and git kind of helped with it (not that is a total requisite, but it was a way to have both âprofitsâ in one move) On Mar 6, 2014, at 7:34 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > My dream has finally come true ... Smalltalkers arguing the merits of git vs. mercurial! > > Alternate implementations to FileTree are welcome! > > Dale > > > On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > > > 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. > > > +1. > In St/X I do exactly the same. Works just fine. > > Jan > > >

March 6, 2014