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

Re: [Pharo-dev] Pharo+Git cons?

by phil＠highoctane.be

On Wed, Dec 3, 2014 at 8:21 AM, stepharo <stepharo(a)free.fr> wrote: > > Le 2/12/14 21:02, kilon alios a Ã©crit : > >> I think its great that we have this discussion we need at least people to >> report any problems they have with the git integration , real problems not >> theoretical problems so as a community we can coordinate effort. There is >> no reason to speculate about the future of Pharo with git since the >> integration is in a very early stage and we have still a long way to go . I >> am following the discussion with great interest. >> >> What fascinates me about git is that is made around the idea of modular >> community. Its architecture makes it flexible to send code around and >> create a community of commits that bounce without a need for >> centralisation. You could say that each pull request is a message and I >> feel that git architecture could fit like a glove for Pharo because they >> speak the same language. >> > > Monticello is like that too. > A decentralized version management system > As is Fossil, another cool tool deserving more success. Phil > > >> Obviously there is still a long road ahead of us but I am excited and >> believe that slowly people will contribute and in the future we will look >> back and wonder what tooks us so long to embrace git :D >> > > >

Dec. 3, 2014

Re: [Pharo-dev] Pharo+Git cons?

by phil＠highoctane.be

On Wed, Dec 3, 2014 at 7:25 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-12-03 4:16 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> Yes, but *I* care about the Monticello metadata. IMO its *better* than >> the git metadata. >> > > Eliot, you'll have to do better than just IMO on that one. > > Some of us work with *both*, and have code for going back and forth, so > the *better*; bah. > The main issue I have (and I love MCZ to transfer projects around, it is super easy, especially to patch a running box without fuss). Now, the key problem are resource files. I am working on webapps, and you get javascript, assets (images, css, svgs, mo files, and, in the current project, other languages running the backend). It is just a pain to maintain mczs on one side and assets on another one and keeping it all in sync. So, the workflow is to save with filetree:// to have it all, but still keep and eye on the package-cache/ to pick mczs as needed. One important thing to note is that Monticello saves a new mcz with a nice author+number on each save where filetree:// writes over what is there. So, if one isn't careful, it is easy to overwrite. Mczs have saved my butt once or twice here. Kind of a backup mechanism. With Mczs, there is also this feeling of being closer to the versions as they are just there in the environment. Both tools have value, and the discussion shouldn't be on what replaces what, but on how to best complement each other. For the record, I use Thierry's merge driver and it makes things smoother. It took me a while before installing that. And after a couple months of solid git usage, I am still learning. That's a pain even if the result is nice. FWIW, I have been using a cool command line tool for most of my git work on servers: tig http://jonas.nitro.dk/tig/ (runs on ubuntu without problems, has some conflict with bash-completion on CentOS 6.5 but you can install). Try it with: tig show or tig status The keybindings are like vim (so: q will get you out of most screens). You do a tig status and use 'u' to stage/unstage along with j/k to move around (or arrows). d will give you the diff view, which you can exit with q This is the kind of tool we could bring into Pharo and, while not replacing Monticello, it would complement it magnificently. Phil > I also happens to know how long it takes to parse hundreds of monticello > metadata files... and I wasn't impressed with the result. > > >> What's really lacking in Monticello is a) it's not high school so one >> can't preen in front of the world on github and b) it has no support for >> external files. Well, a) will be solved by growing up and b) can be solved >> by building the solution. I know what I'd rather do. >> >> >> [and apologies for being deliberately incendiary but I *hate* the >> movement away from tools in Squeak/Pharo. It is a movement towards stasis >> and death, and personally I'm enjoying life too much]. >> > > You then have noticed that those threads are about working on tools? > > Thierry > > > >

Dec. 3, 2014

Re: [Pharo-dev] Pharo+Git cons?

by stepharo

Le 2/12/14 21:02, kilon alios a Ã©crit : > I think its great that we have this discussion we need at least people > to report any problems they have with the git integration , real > problems not theoretical problems so as a community we can coordinate > effort. There is no reason to speculate about the future of Pharo with > git since the integration is in a very early stage and we have still a > long way to go . I am following the discussion with great interest. > > What fascinates me about git is that is made around the idea of > modular community. Its architecture makes it flexible to send code > around and create a community of commits that bounce without a need > for centralisation. You could say that each pull request is a message > and I feel that git architecture could fit like a glove for Pharo > because they speak the same language. Monticello is like that too. A decentralized version management system > > Obviously there is still a long road ahead of us but I am excited and > believe that slowly people will contribute and in the future we will > look back and wonder what tooks us so long to embrace git :D

Dec. 3, 2014

Re: [Pharo-dev] Pharo+Git cons?

by stepharo

Guille did a first attempt to add external resources to Monticello. interested people should contact him (now he cannot work on it since he should finish his PhD). While I think that moving to use git is important we should also consider that we should not put all the eggs in the same basket and that the design decision of our solution should be able to not systematically rely on git. Stef

Dec. 3, 2014

removing the last class extension of a class does not reclassify the class in nautilus

by stepharo

Hi guys While refactoring critics and RB I got the following glitch. When I remove the class extension made by critics on RBRule, the RBRules were not systematically updated in the list of extension of the critics browser. It would be good to investigate this and https://pharo.fogbugz.com/default.asp?14561 BTW we should continue to simplify nautilus. :) Stef

Dec. 3, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Thierry Goubier

2014-12-03 4:16 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Yes, but *I* care about the Monticello metadata. IMO its *better* than > the git metadata. > Eliot, you'll have to do better than just IMO on that one. Some of us work with *both*, and have code for going back and forth, so the *better*; bah. I also happens to know how long it takes to parse hundreds of monticello metadata files... and I wasn't impressed with the result. > What's really lacking in Monticello is a) it's not high school so one > can't preen in front of the world on github and b) it has no support for > external files. Well, a) will be solved by growing up and b) can be solved > by building the solution. I know what I'd rather do. > > > [and apologies for being deliberately incendiary but I *hate* the movement > away from tools in Squeak/Pharo. It is a movement towards stasis and > death, and personally I'm enjoying life too much]. > You then have noticed that those threads are about working on tools? Thierry

Dec. 3, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Eliot Miranda

On Tue, Dec 2, 2014 at 11:41 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > On 02 Dec 2014, at 19:03, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Le 02/12/2014 17:13, Yuriy Tymchuk a Ã©crit : > >> Hi Luc, > >> > >> most of these problems are solved by gitfiletree by Goubier Thierry. > >> It automatically commits the thing that you commit with Monticello, > >> it allows you to push, and it shows you the history (sometimes a bit > >> screwed, but good enough). ConfigurationOf works with GitHub > >> projects, but I think there is also something in a new Metacello that > >> I donât know about. > > > > If you find a strange history, can you share? It seems it happens, but > I'm never sure. It handles fairly complicated cases (like the FileTree > repository where, in some commits, you can't load the packages with > filetree because they are broken: merge conflicts usually). > > > >> Big con is that you essentially communicate with git through > >> Monticello. And to doing advanced stuff, like a lot of branching, > >> pull requests and so on, gives an impression that you are always > >> hacking something. > > > > I think this is the git philosophy anyway. You need to go on expensive, > entreprise versionning systems (ClearCase?) to have a very powerfull, yet > still handholding system. Git is a hacker's tool. And git users are > supposed (encouraged?) to hack it. > > My problem is not in git, itâs in Monticello. Iâm used to be able to > commit exactly what I want even if Iâve made more changes, Iâm used to make > branches for each new feature and then merge it backâ¦ But I always have two > versioning going on. I do things in git, and then I do things in > monticello. Another problem is a real lack of features. Imagine if you > could see a method blame from inside Pharo. > So *implement* it. At least in Monticello *you* can make a change and have it spread through the entire Squeak/Pharo community very quickly. You can't do that with git. Your criticisms of git+Monticello don't hold up in pure Monticello. > > > >> If you want to really work with git, you want to be able to have only > >> git versions of your code, stage and commit certain changes, > >> communicate with remote repos, and if something goes wrong talk to > >> command line and deal with file-based pharo representation. But > >> instead of this you have one more screen of Monticello + nasty > >> metadata which complicates merging. > > > > You need to use the merge driver for that, really. Ok, it requires a lot > more polish than it has, but this is a larger, Pharo wide effort we need to > plan for. The GitFileTree-MergeDriver was really a proof-of-concept which > worked surprisingly well for the time I spent on it. > > Yes, but my main point is what when I merge, I donât care about monticello > dataâ¦ I already have a git version, why do I have to care about the > ancestor of monticello version that became different because of > cherrypicking. > Yes, but *I* care about the Monticello metadata. IMO its *better* than the git metadata. What's really lacking in Monticello is a) it's not high school so one can't preen in front of the world on github and b) it has no support for external files. Well, a) will be solved by growing up and b) can be solved by building the solution. I know what I'd rather do. [and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much]. > > Again, Iâm not complaining. Iâm very glad that we have what we have now. > Itâs just that I donât agree that git support is ready to be used by > everyone. Because with git in general Iâm 10x more efficient than with git > in Pharo. And with git in pharo itâs the same as with monticello, I just > trade one problems for another ones. > > Uko > > > > > Thierry > > > >> Uko > >> > >>> On 02 Dec 2014, at 17:00, Luc Fabresse <luc.fabresse(a)gmail.com> > >>> wrote: > >>> > >>> Hi, > >>> > >>> I continue the discussion here because I really would like to know > >>> the cons of using Git + Pharo. From kilon's video (thx) and the > >>> discussion that followed, I have the following questions about > >>> possible drawbacks of Git+Pharo: > >>> > >>> - The most important point to me is: does ConfigurationOf work > >>> correctly with a repo on GitHub for example? any example > >>> somewhere? > >>> > >>> - we should go to command line to commit/update but that could be > >>> saved with what has been done by Dale in tODE (shell integration, > >>> UI to commit, push/pull) IIUC. right? > >>> > >>> - Merging could be harder because it would rely on git tools? > >>> > >>> - opening a filetree repo in MC does not show the latest content > >>> since it is the local git repo that may not be in sync with the > >>> remote one => you should first pull the repo > >>> > >>> Thx for enlightening me, > >>> > >>> #Luc > >> > >> > >> > > > > > > > -- best, Eliot

Dec. 3, 2014

Re: [Pharo-dev] contributing to Pharo testing effort

by sheridan＠sheridan-mahoney.com

Hi Hilaire, I've been looking at this class (MultiByteFileStream) and I think I might have something to contribute. Cheers, Sheridan ------------------------------ Message: 8 Date: Mon, 24 Nov 2014 11:22:15 +0100 From: Hilaire <hilaire(a)drgeo.eu> To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] contributing to Pharo testing effort Message-ID: <m4v0sn$87d$1(a)ger.gmane.org> Content-Type: text/plain; charset=windows-1252 Hi Sheridan, The MultiByteFileStream is broken when dealing with non-ascii character (see my recent post "Something strange with fileOut) and there are only 3 tests for this class. Test stressing this class will be pretty useful to properly refactor it without breaking other parts. Hilaire Le 23/11/2014 19:45, sheridan(a)sheridan-mahoney.com a ?crit : >> Hi there, I am interested in helping out with writing tests in Pharo, >> and was wondering where would be a good place to start. I am familiar >> with Smalltalk from working at GemStone Systems in their QA department >> some years ago, but am somewhat new to Pharo. Any advice would be very >> appreciated. Best regards, Sheridan Mahoney > > -- > Dr. Geo - http://drgeo.eu [1] > iStoa - http://istoa.drgeo.eu [2] > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Pharo-dev mailing list > Pharo-dev(a)lists.pharo.org > http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org [3] > > ------------------------------ > > End of Pharo-dev Digest, Vol 19, Issue 148 > ****************************************** Links: ------ [1] http://drgeo.eu [2] http://istoa.drgeo.eu [3] http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org

Dec. 3, 2014

Re: [Pharo-dev] Monticello repository-browser not emphasizing packages with newer versions.

by Torsten Bergmann

Hi Ben, there are two reasons not to use bold text style again: - when switching from normal list to icon list while applying the text style made the list item text editable (ugly Morphic stuff) See the details in issue #14451 - using icons would be more in alignment with Nautilus & friends Looks like I forget to indicate this case with an icon on the left side: a package is loaded but newer mcz versions are available. This is now fixed in: https://pharo.fogbugz.com/f/cases/14558 (including a screenshot). Review and integrate. Hope this helps. Have fun T. > Gesendet: Dienstag, 02. Dezember 2014 um 17:03 Uhr > Von: "Ben Coman" <btc(a)openInWorld.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: [Pharo-dev] Monticello repository-browser not emphasizing packages with newer versions. > > Hi Torsten, > > I really like the icons you added to Monticello > https://pharo.fogbugz.com/default.asp?14451 > > however one thing I notice that seems lacking is indication of which > packages have newer versions available. When clicking on a package on > the left, on the right versions that are newer are shown in bold. It > used to be that the corresponding packages on the left would also be > bold, but now it does not. > > Do you have any ideas on how we can get bolded packages back in the left > pane? > > cheers -ben > > >

Dec. 2, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Dale Henrichs

Agreed! On Tue, Dec 2, 2014 at 12:15 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 02/12/2014 20:59, Dale Henrichs a Ã©crit : > >> >> >> On Tue, Dec 2, 2014 at 11:45 AM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> >> If you need to update (changes on the central repository), then you >> pull (git pull) and you see the new available versions (only with >> gitfiletree). FileTree will only show you the top version of each >> package. >> >> >> This is an area where I prefer to use `git diff` and enter the territory >> of "git integration"... it is possible to use git to compare two >> different SHA's for a given package/project/class/method and it is >> possible to compare the in-image package/project/class/method with a >> particular. >> > > But both approaches are allowing you that. What GitFileTree shows you is > the git commit history, filtered by packages... and you can diff, as well, > whether its by package/project/class/method, or simply explore the history > from the point of view of the entity your focusing on (well, ok, no > project...). > > In my opinion, this is the area where one should break from the >> Monticello paradigm where the package is the sole versioned entity and >> expand the versioned universe to include project/package/class/method >> versions. There is also tremendous value to simply comparing two >> different git commits which may span multiple packages and include >> updates to documentation and other text files ... >> > > Yes, the project on top. I think this is something Phil has been saying as > well, and I'm sure this is something which will be added, once Pharo will > focus on that. > > But I'll check first if some projects (I'm thinking say a compiler of > which pharo is just the front-end, i.e. over 100 000lines of which 90% is C > code) won't end up being too large. Nothing we can't solve with appropriate > tools. > > To view git through only the package model is too restrictive and limits >> some of the real power one can experience when using git ... >> > > This was the limitation of working within Monticello. > > Now that the infrastructure is there, we can (we should) do better. > > Thierry > >

Dec. 2, 2014