- Pharo-dev - lists.pharo.org

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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50343 Home: https://github.com/pharo-project/pharo-core

Sept. 27, 2015

Re: [Pharo-dev] [Reflectivity] Slides ESUG talk

by Marcus Denker

> On 24 Sep 2015, at 09:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 22 Sep 2015, at 17:23, roberto.minelli(a)usi.ch wrote: >> >> Hi Marcus, >> >> I am finally playing with Reflectivity. In the first place, thanks a lot for this contribution! >> >> I am wondering what is the âcorrectâ way to âremoveâ a MetaLink. Is it enough to call #uninstall on the MetaLink or should I also recompile the class/method where the link is installed? >> >> I spotted a problem with the control #after. If you try to pass #arguments to the meta, an error is returned. To reproduce: http://ws.stfx.eu/ONC4K9KQRTNQ >> >> Is this behavior somewhat desired, or is a bug? >> > Hello, I fixed it: > > https://pharo.fogbugz.com/f/cases/16629/fix-after-on-method-with-arguments > > ... > > I will integrate this fix and then write more tests (e.g. I think there are still problems with an #after on a method that defines temps, > but it will be easy to fix). > As suspectedâ¦ I added a test + fix in 50343. This update contains the #availableReifications method, too. Marcus

Sept. 27, 2015

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

by Peter UhnÃ¡k

> > 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.

Sept. 27, 2015

Re: [Pharo-dev] Lost in Git...

by Esteban Lorenzano

Hi, yes we need to clarify how it should work :) Esteban > On 27 Sep 2015, at 14:08, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 27/09/2015 13:58, stepharo a Ã©crit : >> Hi guys >> >> I'm totally lost in git/pharo support. >> The only thing I got is that we do not need metacello versions just >> baselines. > > Yes. Metacello on git delegates branches to a repository url mechanism resolution (and desactivate the cache) so just baselines are needed (with a few restrictions because of the way a baseline can include another baseline). > > Makes handling large projects a breeze compared to configurations. > >> We have fileTree, TreeMerge, gitFileTree + tons of git expressions. >> Just looking at the discussion between alex and thierry looks totally >> scary. > > ;) Far less scary than adding a self halt in RBParser these days. > >> Do we have one document explaining the situation clearly? > > I think my presentation from PharoDays is still up to date. Nothing has changed yet. > > I'm still in the dark about libcgit support / plans... > > Note that, from the outside, large projects such as Roassal and Moose use a lot of their energy in solving configurations and merge issues which are linked to the type of repository they use. They also require a significant investment in support tools such as Versionner to get things working. > > Thierry > >

Sept. 27, 2015

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

by Esteban Lorenzano

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). 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. 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.... > 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. 27, 2015

Re: [Pharo-dev] [review needed] speed up RBClassNotReferencedRule

by Nicolai Hess

2015-08-26 10:25 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > Review needed for > > > https://pharo.fogbugz.com/f/cases/16074/Is-RBClassNotReferencedRule-200x-sl… > > Speedup can be checked with: > > rule:=RBClassNotReferencedRule new. > environment:=RBBrowserEnvironment new forPackageNames: #('Fuel'). > [RBSmalllintChecker runRule: rule onEnvironment: > environment] timeToRun > > > Pharo5: "0:00:00:13.526" > Pharo5 with fix: "0:00:00:00.761" > Pharo3: 0:00:00:00.547 > > Checking all classes for usage: > > [Smalltalk allClassesAndTraits select: [ : each | each isUsed not]] > timeToRun > > still takes 1:40 to find 600 unused classes. > > This shows that adding a cache for âreferenced classesâ per environment > would speed this > up further. But it should be general, not just for RB or even RB Code > Critique. > > The nice things is that code environments only change when you add classes > or methods, > so adding a very general cache should be quite possible. > > Another thing we should add is a way for classes to define âI am usedâ. > E.g this > now finds all Configurations, all the Manifests and all cases like the RB > Rules themselves. > All these should know that they are not useless even though there are no > references. > > Marcus > But now, we have the problem that this rule does not find references to classes by symbol. The comment for this rule says: "This smell arises when a class is not referenced either directly or indirectly by a symbol." But all spec adapter classes are only referenced by their symbol and this now isn't found anymore: MorphicMenuGroupAdapter isUsed " - > false "

Sept. 27, 2015

Re: [Pharo-dev] Lost in Git...

by Thierry Goubier

Le 27/09/2015 13:58, stepharo a Ã©crit : > Hi guys > > I'm totally lost in git/pharo support. > The only thing I got is that we do not need metacello versions just > baselines. Yes. Metacello on git delegates branches to a repository url mechanism resolution (and desactivate the cache) so just baselines are needed (with a few restrictions because of the way a baseline can include another baseline). Makes handling large projects a breeze compared to configurations. > We have fileTree, TreeMerge, gitFileTree + tons of git expressions. > Just looking at the discussion between alex and thierry looks totally > scary. ;) Far less scary than adding a self halt in RBParser these days. > Do we have one document explaining the situation clearly? I think my presentation from PharoDays is still up to date. Nothing has changed yet. I'm still in the dark about libcgit support / plans... Note that, from the outside, large projects such as Roassal and Moose use a lot of their energy in solving configurations and merge issues which are linked to the type of repository they use. They also require a significant investment in support tools such as Versionner to get things working. Thierry

Sept. 27, 2015