September 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Damien Cassou

Alexandre Bergel <alexandre.bergel(a)me.com> writes: > I have tried several times to use Git for my project. But I do not > want to spend time on configuring .gitattribute and other > configuration file. This does not go in the right direction I believe. > Why is it easier to use git with Java than it is with Pharo? I disagree, I think configuring .gitattribute (for the merge driver) is an important step forward. It means that Pharo can control the merge. Currently, it's only useful for metadata. But later, it might be useful to facilitate code merges: e.g., a method is renamed in a branch and improved in another. This should not generate a conflict. With Epicea, we might be able to avoid this conflict in the future and drive the merge successfully. Another example: two branches each adds an instance variable to the same class. This should not generate a conflict. The merge driver could detect that and merge successfully. Final example: the merge driver could run the unit tests while merging to tell the developer when a merge is correct and when it is not. The merge driver means we can merge ASTs, not lines of source code. For me, the merge driver is the future, not the past. Thanks Thierry. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Peter UhnÃ¡k

> > sure except that suddenly you do not know why you have to know the arcanes >> part. >> I think that git is not layered so you get exposed to a lot of details >> even when you avoid. >> > Hmm, I don't see that, but I've been using git for many years so I am not in position to judge it how complex it is. > > >> May be having a set of git macros would help. >> > > Maybe not because macros are fragile and your average set of git commands > is rather limited. Making git simpler through Pharo could be nice... > Maybe providing a way to streamline common patterns. For example in git community there's a well known workflow model http://nvie.com/posts/a-successful-git-branching-model/ There's even git extension (but you can still use git directly) on top of that pattern https://github.com/nvie/gitflow (better visualized here https://danielkummer.github.io/git-flow-cheatsheet/ ) And while most don't follow the pattern strictly, most people are at least inspired by it and adapt parts of it. Peter

Sept. 28, 2015

Re: [Pharo-dev] World.st has a new admin

by Henrik Johansen

> On 24 Sep 2015, at 4:27 , Geert Claes <geert.wl.claes(a)gmail.com> wrote: > > The admin duties have now been handed over to Sean DeNigris who kindly > volunteered to look after the www.world.st web presence as well as the > Nabble archived mailing list forums on forum.world.st. > > As mentioned in a previous post, I did establish The World of Smalltalk some > years ago I have now unfortunately too many other things on my plate. So I > feel a person who is closer to the Smalltalk action will be better suited to > take over the reins and I wish Sean all the best to continue! > > > > -- > View this message in context: http://forum.world.st/World-st-has-a-new-admin-tp4851811.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > Thanks for all the work, I've really appreciated using the forums! They have been, and continue to be, a pleasure to both browse and search compared to other mailing list web interfaces. Not to mention it's really nice to have one place to go to for all the Smalltalk lists. Cheers, Henry

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Thierry Goubier

2015-09-28 8:53 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > Le 27/9/15 15:33, Peter UhnÃ¡k a Ã©crit : > > Because to me git is **really** complex. I do not talk about add push >> commit but rebase remote.... >> > > Git allows you to do complex things if you need them. > But you can easily use git without ever needing rebase, filter-branch or > whatnot. > > Everything that Monticello can do can be done with git easily (commit, > push, pull, merge). > It just gives you much more powerful tools. > > > sure except that suddenly you do not know why you have to know the arcanes > part. > I think that git is not layered so you get exposed to a lot of details > even when you avoid. > You probably nailed it when it comes to why git seems more complex that needs to be. > May be having a set of git macros would help. > Maybe not because macros are fragile and your average set of git commands is rather limited. Making git simpler through Pharo could be nice... Thierry

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by stepharo

Le 27/9/15 15:33, Peter UhnÃ¡k a Ã©crit : > > Because to me git is **really** complex. I do not talk about add > push commit but rebase remote.... > > > Git allows you to do complex things if you need them. > But you can easily use git without ever needing rebase, filter-branch > or whatnot. > > Everything that Monticello can do can be done with git easily (commit, > push, pull, merge). > It just gives you much more powerful tools. sure except that suddenly you do not know why you have to know the arcanes part. I think that git is not layered so you get exposed to a lot of details even when you avoid. May be having a set of git macros would help. Stef

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Thierry Goubier

Le 28/09/2015 04:27, Ben Coman a Ã©crit : > > I have a vague recollection that the problem was a particular file > where data changed each commit and having the idea that this might be > solved by: each commit writing metadata to a different file e.g. > NNNN.metadata, and Monticello knows to pick up the highest numbered > metadata. Hum, I thought that as well, but in fact write the merge driver turned out as far better and simpler. Moreover, all type of data oriented files (ston, json, version) do not merge properly in git. So even Esteban saying he will use STON does not seems to solve the merge issue, unless he is planning something else. I do take in account we will have more metadata in the future, thanks to EPICEA, so we need a way to handle it. Merging is easy, you just need to hook into it. I believed also that we could do the merge ourselves and force git to commit the result, but discovered this was a bad idea. Imagine having to fire Pharo to merge a 250k OCaml project with 2k of st code in it :( > Git is very flexible which implies complexity for newcomers to it. > What is required on top of git is a "well defined" workflow. I see > sometimes on this mail-list that people design their tools for > flexibility since they don't want to *impose* a workflow on people, > which is a commendable philosophy, but slows adoption by newcomers. > It may be useful to define "this is *the* way its done here" , with > the standard proviso that there may be missteps that need to be tuned. Unless you have some experience of Monticello, Metacello, the Pharo workflow, some of the workflow outside Pharo, and git, then defining this workflow is shooting in the dark. So, first attempts are either: - be flexible, so that you fit into a pre-existing workflow, and explore options, - be dictatorial in your shot in the dark, and pray you got it right. Now, we've solved all the hard points (apart from the Windows support), so we can imagine a future. Thierry

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Max Leske

> On 28 Sep 2015, at 04:27, Ben Coman <btc(a)openInWorld.com> wrote: > > On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi, >> >> Iâve been using git for all my projects since more than one year now, and frankly I found it really goodâ¦ and the pull request mechanism is unbeatable. >> Now, what I do believe is that we need to improve a couple of things: >> >> 1) filtree format is not good while working on teams (which is the power of git, after all). Merging is a pain and the merge driver provided by Thierry is just a patch, not a real alternative. >> 2) double commit is annoying. >> >> We have a decent solution for (2), gitfiletree but is not working fine in windows (and thatâs mandatory). I would like a community push here to make it work fine. >> Once is working, I would like to replace the OSProcess usage with actual libgit2. As far as I understand, this is already possible but we hadnât commit time to make it possible (and I would put it as a secondary goal: first make it work with what we have, then use the library). > > Would moving to libgit2 bypass the problem with stdio? Yes. We call out to libgit2 through NativeBoost. > >> Now the filetree format has problems merging because it stores some metadata that we do not really need. The origin of this is the fact that is using git as âjust another interchangeable repository for monticelloâ. IMHO while this was desirable for start, is not a good solution now. We do not need that information at all. >> I worked in a replacement for filetree and as a file format it works fineâ¦ is just a variation who does not stores the not-needed information and relies on STON to manage the one we actually need. > > I have a vague recollection that the problem was a particular file > where data changed each commit and having the idea that this might be > solved by: each commit writing metadata to a different file e.g. > NNNN.metadata, and Monticello knows to pick up the highest numbered > metadata. > > >> After, we can build the actual tools we need. But with that working we will see a lot clearer what we actually need to do :) >> >> So I would do a âcall for pushingâ and ask community to spend some time making it work properly. >> >> cheers, >> Esteban >> >> >>> On 27 Sep 2015, at 13:43, stepharo <stepharo(a)free.fr> wrote: >>> >>> Alex do you know git? >>> Because to me git is **really** complex. I do not talk about add push commit but rebase remote.... > > Git is very flexible which implies complexity for newcomers to it. > What is required on top of git is a "well defined" workflow. I see > sometimes on this mail-list that people design their tools for > flexibility since they don't want to *impose* a workflow on people, > which is a commendable philosophy, but slows adoption by newcomers. > It may be useful to define "this is *the* way its done here" , with > the standard proviso that there may be missteps that need to be tuned. > > cheers -ben > > >>> Did you try to use sourcetree (the UI for git) to understand what I mean? >>> So we cannot use git simply we have to propose a much nicer model on top of this assembly. >>> >>> Now you can systematicall save your code with monticello and automatically publish it to git. >>> Esteban has a script for doing that. >>> >>> Stef >>> >>>> â¦ Pharo may be within the 30 most popular languages on Earth. >>>> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub. >>>> >>>> I wish we had a nice Git integration. >>>> >>>> Alexandre >>> >>> >> >> >

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by philippe.back＠highoctane.be

Le 28 sept. 2015 04:29, "Ben Coman" <btc(a)openinworld.com> a Ã©crit : > > On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > > > Iâve been using git for all my projects since more than one year now, and frankly I found it really goodâ¦ and the pull request mechanism is unbeatable. > > Now, what I do believe is that we need to improve a couple of things: > > > > 1) filtree format is not good while working on teams (which is the power of git, after all). Merging is a pain and the merge driver provided by Thierry is just a patch, not a real alternative. > > 2) double commit is annoying. > > > > We have a decent solution for (2), gitfiletree but is not working fine in windows (and thatâs mandatory). I would like a community push here to make it work fine. > > Once is working, I would like to replace the OSProcess usage with actual libgit2. As far as I understand, this is already possible but we hadnât commit time to make it possible (and I would put it as a secondary goal: first make it work with what we have, then use the library). > > Would moving to libgit2 bypass the problem with stdio? > > > Now the filetree format has problems merging because it stores some metadata that we do not really need. The origin of this is the fact that is using git as âjust another interchangeable repository for monticelloâ. IMHO while this was desirable for start, is not a good solution now. We do not need that information at all. > > I worked in a replacement for filetree and as a file format it works fineâ¦ is just a variation who does not stores the not-needed information and relies on STON to manage the one we actually need. > > I have a vague recollection that the problem was a particular file > where data changed each commit and having the idea that this might be > solved by: each commit writing metadata to a different file e.g. > NNNN.metadata, and Monticello knows to pick up the highest numbered > metadata. > > > > After, we can build the actual tools we need. But with that working we will see a lot clearer what we actually need to do :) > > > > So I would do a âcall for pushingâ and ask community to spend some time making it work properly. > > > > cheers, > > Esteban > > > > > >> On 27 Sep 2015, at 13:43, stepharo <stepharo(a)free.fr> wrote: > >> > >> Alex do you know git? > >> Because to me git is **really** complex. I do not talk about add push commit but rebase remote.... > > Git is very flexible which implies complexity for newcomers to it. > What is required on top of git is a "well defined" workflow. I see > sometimes on this mail-list that people design their tools for > flexibility since they don't want to *impose* a workflow on people, > which is a commendable philosophy, but slows adoption by newcomers. > It may be useful to define "this is *the* way its done here" , with > the standard proviso that there may be missteps that need to be tuned. Currently working in a distributed team with multiple companies. We use git and also Phabricator for reviews which is really great. I cant think of *not* using a DVCS and features like git rebase in such an environment. Phil > > cheers -ben > > > >> Did you try to use sourcetree (the UI for git) to understand what I mean? > >> So we cannot use git simply we have to propose a much nicer model on top of this assembly. > >> > >> Now you can systematicall save your code with monticello and automatically publish it to git. > >> Esteban has a script for doing that. > >> > >> Stef > >> > >>> â¦ Pharo may be within the 30 most popular languages on Earth. > >>> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub. > >>> > >>> I wish we had a nice Git integration. > >>> > >>> Alexandre > >> > >> > > > > >

Sept. 28, 2015

Re: [Pharo-dev] If all Pharo projects were on GitHub...

by Ben Coman

On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Iâve been using git for all my projects since more than one year now, and frankly I found it really goodâ¦ and the pull request mechanism is unbeatable. > Now, what I do believe is that we need to improve a couple of things: > > 1) filtree format is not good while working on teams (which is the power of git, after all). Merging is a pain and the merge driver provided by Thierry is just a patch, not a real alternative. > 2) double commit is annoying. > > We have a decent solution for (2), gitfiletree but is not working fine in windows (and thatâs mandatory). I would like a community push here to make it work fine. > Once is working, I would like to replace the OSProcess usage with actual libgit2. As far as I understand, this is already possible but we hadnât commit time to make it possible (and I would put it as a secondary goal: first make it work with what we have, then use the library). Would moving to libgit2 bypass the problem with stdio? > Now the filetree format has problems merging because it stores some metadata that we do not really need. The origin of this is the fact that is using git as âjust another interchangeable repository for monticelloâ. IMHO while this was desirable for start, is not a good solution now. We do not need that information at all. > I worked in a replacement for filetree and as a file format it works fineâ¦ is just a variation who does not stores the not-needed information and relies on STON to manage the one we actually need. I have a vague recollection that the problem was a particular file where data changed each commit and having the idea that this might be solved by: each commit writing metadata to a different file e.g. NNNN.metadata, and Monticello knows to pick up the highest numbered metadata. > After, we can build the actual tools we need. But with that working we will see a lot clearer what we actually need to do :) > > So I would do a âcall for pushingâ and ask community to spend some time making it work properly. > > cheers, > Esteban > > >> On 27 Sep 2015, at 13:43, stepharo <stepharo(a)free.fr> wrote: >> >> Alex do you know git? >> Because to me git is **really** complex. I do not talk about add push commit but rebase remote.... Git is very flexible which implies complexity for newcomers to it. What is required on top of git is a "well defined" workflow. I see sometimes on this mail-list that people design their tools for flexibility since they don't want to *impose* a workflow on people, which is a commendable philosophy, but slows adoption by newcomers. It may be useful to define "this is *the* way its done here" , with the standard proviso that there may be missteps that need to be tuned. cheers -ben >> Did you try to use sourcetree (the UI for git) to understand what I mean? >> So we cannot use git simply we have to propose a much nicer model on top of this assembly. >> >> Now you can systematicall save your code with monticello and automatically publish it to git. >> Esteban has a script for doing that. >> >> Stef >> >>> â¦ Pharo may be within the 30 most popular languages on Earth. >>> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub. >>> >>> I wish we had a nice Git integration. >>> >>> Alexandre >> >> > >

Sept. 28, 2015

[pharo-project/pharo-core] 6a2134: 50343

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 6a21341a640e1e49f2b391d17f92f3731c08744f https://github.com/pharo-project/pharo-core/commit/6a21341a640e1e49f2b391d1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-27 (Sun, 27 Sep 2015) Changed paths: R AST-Core.package/RBParser.class/instance/private-parsing/parseNegatedNumber.st M AST-Core.package/RBParser.class/instance/private-parsing/parsePrimitiveObject.st A AST-Tests-Core.package/RBParserTest.class/instance/tests parsing/testNegativeNumberError.st A Reflectivity-Tests.package/MetaLinkTest.class/instance/tests - misc/testAvailableReifications.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterMethodWithTemps.st M Reflectivity.package/RFASTTranslator.class/instance/reflectivity/emitPrepareLinkAfter_.st A Reflectivity.package/extension/LiteralVariable/instance/availableReifications.st A Reflectivity.package/extension/RBProgramNode/instance/availableReifications.st A Reflectivity.package/extension/Slot/instance/availableReifications.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50342.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50343.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50342.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50343.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50343 16646 test + fix: #after mit access to temp in method https://pharo.fogbugz.com/f/cases/16646 16642 availableReifications: return the list of supported reifications for an entity https://pharo.fogbugz.com/f/cases/16642 16632 RBParser should reject - space literal https://pharo.fogbugz.com/f/cases/16632 http://files.pharo.org/image/50/50343.zip

Sept. 27, 2015