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

[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

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

by stepharo

Coming back from africa I can say that windows is first then linux..... and may be 1% mac >>> we have more than a nice Git integration. I have been using Github for >>> my pharo project for over a year now without any issue, the last few >>> months I have been using gitfiltree which is making it even easier. >>> Definitely beats the alternatives . >>> >> >> Hi! >> >> Did you try to use git on a big project with a team? Did you try to >> merge .st files ? >> I heard it's really annoying to merge files with meta informations on >> git. > >> An other point is that git file tree will not work on Windows if we do >> not fix the problem of the stdio. And a lot of people out of the >> community use Windows, so this is not a issue we should forget. Most of >> the people I know in company use Windows, so if we want to attract >> people this problem need to be corrected. > > I'd really like people who put Windows as an important platform invest > on making sure what we have for Windows support in Pharo really works. > > Thierry > >

Sept. 27, 2015

Re: [Pharo-dev] Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

by stepharo

We should update Garage :) Stef Le 2/9/15 13:35, Sven Van Caekenberghe a Ã©crit : > But Timestamp was already removed completely from 4.0, why re-add it, even deprecated ? > > I am sure many external packages are already modified, I know I did it for mine. > >> On 02 Sep 2015, at 13:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On 02 Sep 2015, at 12:32, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi guille >>> >>> there is not stress. I just wanted to let you know. >>> I was wondering if just subclassing DateAndTime would not be enough for now. >> Yes, as far as I remember Timestamp was just an empy subclass. >> >> We could: >> >> -> add it back to Deprecated50 or maybe even to a âCompatibilityâ package >> -> Write a Quality Check rule. >> >>> I will go back to code with Pharo 40 >>> >>> stef >>> >>> Le 2/9/15 10:30, Guillermo Polito a Ã©crit : >>>> If somebody can check it and fix it it would be good :). I've just started my new job and my evenings are busy looking for an apartment or staying in a hostel without a proper internet connection... >>>> >>>> If not, I think we can wait a bit. The first step should be enabling CI jobs for pharo5. Also, I do not think the intersection between 'people using garage opendbx' and 'people using pharo5' is that big to justify a rush. >>>> >>>> Guille >>>> >>>> El miÃ©., 2 de sept. de 2015 a la(s) 10:12 a. m., stepharo <stepharo(a)free.fr> escribiÃ³: >>>> for your info... >>>> >>>> Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp >>>> >>>> Stef >>>> > >

Sept. 27, 2015

Re: [Pharo-dev] how do I get the git commit diff

by stepharo

I would like to see the code changed in email. In github first I have to go there (does not work when I'm off) or when internet is slow. Then I have to click/expand and I just want to see the three lines that changes there and there. It works well for the VM mailing-list. In a glance I can see the changes. Without any extra tools. Le 5/9/15 18:43, Dimitris Chloupis a Ã©crit : > the mail is not made for version control, github is. Why you would > prefer a static way of doing things, from a very dynamic website ? > > When you commit to a github repo everyone that watches that repo , > that is everyone that is either a contributor to that repo or a github > user that has clicked the watch button will be alerted about > everything related to that repo. The alerts appear in the front page > of github.com <http://github.com> when you log in. That includes > commits, pull requests, new branches, issues, bugs, feature requests > you name it. You could link that feed to your email so you get email > alerts but personally I prefer keeping my email seperate from version > controlling stuff. > > The advantages of github are too numerous to go in detail here, just > read the github documentation. But to be put short, its easy to link > towards other commits, you can comment commits , you can even comment > specific lines of code (even using markdown ), and edit and commit on > the fly using the website without opening pharo or git pulling to your > local repo. Personally I would prefer to see a lot more pull requests > because they are a very nice way to chain commits together and view > them as one entity since they will concern the same matter. Pull > requests also can be chained to issues and bug reports to mark the > closed or open. > > What you list you refer to ? The link > https://github.com/pharo-project/pharo-core/commit/8a1f79b44b14f8eafaf6d91a…, > refers to a single commit with a ton of renamed files. You mean how > you can get the list with the diff of each file changed ? thats easy, > click on the commit. If you go to the repo for example here > https://github.com/pharo-project/pharo-core/commits/4.0 clicking .... > will expand the commit message but you if click on the commit itself > will send you to the list of the diff log for that commit. Do you mean > something else ? > > > > On Sat, Sep 5, 2015 at 10:02 AM stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi > > I still think that I would like in the squeak mailing-list to see the > diff of every commit by mail. > How can we enable that? Marcus you complain that not enough people are > active but we do not engage people by showing > changes. oh yes they can - by reading git commit.... oh boy if we > believe that people systematically have a look at that then > we are pretty naive. > > Now do not tell me that I can browse git commit I know it and this is > not what I need. > I need SYSTEMATIC awareness of a change. I NEED everybody to be > able to > have look before deleting a mail. > It is working in Squeak. I can in my mail look at the changes. > > Or of course nobody cares in Pharo about changes and we can get > regression. > > Another question: how can I get the list of links to git with the > commit > logs like > https://github.com/pharo-project/pharo-core/commit/8a1f79b44b14f8eafaf6d91a… > below? > How can I get the list? so that I can browse (I'm probably one of the > two few interested in fixing bugs after they got introduced). > > > Branch: refs/heads/5.0 Home: > https://github.com/pharo-project/pharo-core > Commit: 8a1f79b44b14f8eafaf6d91a8bab3c28e673114c > https://github.com/pharo-project/pharo-core/commit/8a1f79b44b14f8eafaf6d91a… > > Author: Jenkins Build Server <board(a)pharo-project.org > <mailto:board@pharo-project.org>> Date: 2015-09-04 > (Fri, 04 Sep 2015) >

Sept. 27, 2015