- Pharo-dev - lists.pharo.org

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

by Esteban A. Maringolo

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 kilon alios

Just for the sake of argument, I also don't like how things are broken down to one file per method and class being that json thing. Looks weird, and makes viewing code on github very tedious. On Fri, Mar 7, 2014 at 12:41 AM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Haha, sleep is overrated:) > > > On Thu, Mar 6, 2014 at 2:39 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 06.03.2014, at 23:34, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> >> wrote: >> >> My dream has finally come true ... Smalltalkers arguing the merits of git >> vs. mercurial! >> >> >> How do you sleep at night?? :p >> >> >> 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

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

by Jan Vrany

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

Haha, sleep is overrated:) On Thu, Mar 6, 2014 at 2:39 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 06.03.2014, at 23:34, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> > wrote: > > My dream has finally come true ... Smalltalkers arguing the merits of git > vs. mercurial! > > > How do you sleep at night?? :p > > > 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

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

by Max Leske

On 06.03.2014, at 23:34, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > My dream has finally come true ... Smalltalkers arguing the merits of git vs. mercurial! How do you sleep at night?? :p > > 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

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

by Dale Henrichs

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

Re: [Pharo-dev] Status of the VM?

by Jan Vrany

On 04/03/14 17:37, Eliot Miranda wrote: > > > > On Sat, Mar 1, 2014 at 4:09 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz > <mailto:jan.vrany@fit.cvut.cz>> wrote: > > Maybe I'm missing something obvious, but from my point of > view the fundamental difference here is that with JVM's JPDA > triggering of event actually **does not** affect the monitored > system. > > If these events are handled by the image, it is quite tricky to > figure out which one is caused by "application" and which one > is caused by the event handling machinery. For instance, > if (non-empty) method is called after a GC, this handler > may trigger another GC, which may... > > That brings me to another, if you do in-image profiling (event > handling), data could be quite different than what would you get > using out-of-image profiler. > > > <personal experience:> > I've used (and implemented some :-) both - Smalltalk in-image tools > and out-of-image tools, namely JPDA and DTRACE/STAP. For serious > profiling and monitoring, I always use out-of-image approach if > possible. > > > I disagree. Fair enough :-) What I use for serious VM profiling is a hybrid approach > that collects data in the VM but uses the image to display and interact > with it. The VMProfiler, which is in CogTools in the VMMaker repository > is IMNAAHO a very nice VM profiler. Looks good, indeed. > > In the VM there is a thread that interrupts the main VM thread > periodically, sampling its pc and storing this in a circular buffer. > The thread and buffer are manipulated by a couple of primitives. > Alongside is a platform-specific plugin to reveal the dlls loaded in > the VM. The JIT reports current machine code methods and PICs through a > primitive. Looks like everybody has a slightly different techniques and its own tools :-) I collect data in VM but the VM reports them to "outside" (via log file or kind of IPC). Then I analyze data post-mortem using various tools, some of them are hand-crafted, some not. I found KCachegrind quite nice. Anyway, the interesting question to me is what are the advantages of your approach? Best, Jan

March 6, 2014

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

by Jan Vrany

> > 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 Max Leske

On 06.03.2014, at 22:14, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > 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? 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). > 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 6, 2014

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

by Eliot Miranda

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 6, 2014