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

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

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