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

Re: [Pharo-dev] how do I install gitfiletree?

by GOUBIER Thierry

After working with github, and, in another project, with a git expert, I don't think there is a way to avoid exposing users to some nasty git things :( It's just so powerfull, and can shape-morph in many different things depending on the team involved. And well, this is git now. What will be the git of tomorrow? I wish success to your proposal. More man years on Pharo will certainly bring great things! Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Pharo4Stef [pharo4Stef(a)free.fr] Date d'envoi : samedi 25 janvier 2014 22:33 Ã : Pharo Development List Objet : Re: [Pharo-dev] how do I install gitfiletree? For the record, we will hand in monday a proposal (was rejected last year) to engineer a good git support for Pharo (but not to expose end-user to command line git idiosyncrasies. Now we should cross our fingers. I spent my vacations rewriting it and I hope that I should not have just do something else. Stef PS: if someone has 10 engineers to lend to me for a couple of years, Pharo will look really different and cooler.

Jan. 25, 2014

Re: [Pharo-dev] HandMorph ShowEvents

by Pharo4Stef

+1 events can be really really tricky to debug. I extracted the behavior in a separate methods On 23 Jan 2014, at 09:18, phil(a)highoctane.be wrote: > Don't put that into a morph. > > I used that in the past and I was glad there was no other morphs because I had refresh/drawing problems and writing directly on the display was really useful. > > > Now, why not a pref? > > > > > On Thu, Jan 23, 2014 at 7:24 AM, Sean DeNigris <sean(a)clipperadams.com> wrote: > Is there a reason that the HandMorph class>>showEvents: feature draws directly on the screen instead of opening a Morph? Am I missing a use case, or would it be okay to turn this into a proper Morph? >

Jan. 25, 2014

more code reviews :)

by Pharo4Stef

Hi marcus I agree with you. Sometimes I look at the code and I cannot help deciding if I would integrate it or not. :) For example the opal or compiler parser changes. Marcus may be we should just go slower. It takes times to have energy to have a look at a change. I would like that we take more time to do code review. May be in the future we should change the way we work: integrate only changes that have got more than two ok? I do not know, what I know is that I want to read the code of the changes I push because I want to slowly learn just by reading (without understanding much) the parts of the system I do not know. This is a gigantic task but I do not see how else we can do to learn. Stef

Jan. 25, 2014

Re: [Pharo-dev] browsing comment versions

by Pharo4Stef

What I would love is to find the bug that blocks me to edit comment :) On 22 Jan 2014, at 22:51, Nicolai Hess <nicolaihess(a)web.de> wrote: > Hi, > > someone interested in browsing older versions of class comments again? > The ClassCommentVersionBrowser is gone, but I can add it > to the NewVersionBrowser. Just some additional changes to class > ChangeSet and NewVersionBrowser are needed. > > What do you think? > > > nicolai >

Jan. 25, 2014

Re: [Pharo-dev] Bad naming: users

by Pharo4Stef

sebastian Doing is difficult. Do you think that we did not reimplemented traits from scratch already once. May be we are just not smart enough or may be the problem is more complex that people think it is. You can ask around me. Iâm not happy with traits but Iâm not happy with single inheritance too and I do not like multiple inheritance either. So :) I can tell you tales on huge macros in lisp that generate pages of macros and a company wanted to hire me to add concepts in the language to remove these hug macros. the grass is always greener elsewhere, no? If we want to really improve the system we should accept that it may not be a simple easy path. Stef On 21 Jan 2014, at 19:07, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > We have to be careful about this. > > Iâm not saying traits doesnât have its place but they are a solution to millions of non-problems > > Here is a post to reflect and learn from the problems of our neighbours, the lispers guys: > Lisp: more is less > > http://jameso.be/2014/01/19/lisp.html > > It would be super awesome if we never ever ever have those problems > > > > > > > > On Jan 21, 2014, at 3:41 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> This is where the "only 5 reserved keywords" stop being true :) >> >> I've been bitten by similar things and ended up using my own selectors, sometimes with a prefix. >> >> Regards! >> >> Esteban A. Maringolo >> >> >> 2014/1/21 Camille Teruel <camille.teruel(a)gmail.com> >> >> On 21 janv. 2014, at 17:53, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >>> I tried loading Deltawerken in Pharo 3.0 and noticed >>> it is now impossible to load code where a class side method is defined named users. >>> >>> DEUser class>>users >>> ^self subclassResponsibility >>> >>> Stephan >> >> I guess it's a consequence of the unification of Class and Trait APIs. Now SomeClass users must answer an empty collection. >> So you experience a name clash between Pharo meta-level and your domain :( >> I still think it was a mistake too push that unification that far, i.e having classes responding to trait specific methods and vice-versa. >> >> >

Jan. 25, 2014

Re: [Pharo-dev] TraitComposition equality

by Pharo4Stef

This is my impression too but it is late. Especially since traits are designed to avoid to take care about structure of the trait ânestingâ. We do not care that a method come from T1 or T1.T2 Stef > It looks like you're asking if substitution (@) is commutative. In the > general case it's not: > > T1 @ {#x -> #y} @ {#y -> #z} == T1 > > but > > T1 @ {#y -> #z} @ {#x -> #y} > > is not. > > I think Jan's suggestion of flattening the traits and then comparing > them for semantic/structural equivalence is the right way to avoid > going crazy! > > frank > > On 22 January 2014 09:05, Martin Dias <tinchodias(a)gmail.com> wrote: >> should >> >> (T1 @ {#a -> #b} @ {#x -> #y}) = (T1 @ {#x -> #y} @ {#a -> #b}) >> >> ? >> >> >> >> On Tue, Jan 21, 2014 at 6:39 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >>> >>> >>> >>> >>> On Tue, Jan 21, 2014 at 6:02 PM, Damien Cassou <damien.cassou(a)gmail.com> >>> wrote: >>>> >>>> On Tue, Jan 21, 2014 at 5:29 PM, Martin Dias <tinchodias(a)gmail.com> >>>> wrote: >>>>> Do experts on traits agree? I can open an issue and propose a slice. >>>> >>>> >>>> you have to pay attention that A + B + C = B + A + C = C + A + B. >>> >>> >>> ok, I will propose a slice >> >> >

Jan. 25, 2014

Re: [Pharo-dev] problems with RPackage and cie...

by Pharo4Stef

Hi stefan This is good that you could reproduce it because I was mad at it. I found another case in Moose but esteban could not reproduce it in plain Pharo. We just spent some times chasing the wrong bug :) Stef On 24 Jan 2014, at 14:51, Stephan Eggermont <stephan(a)stack.nl> wrote: > Esteban wrote: >> I would really like a reproducible caseâ¦ in the form of an image, if no else. >> >> btwâ¦ moose 5.0 images are severely broken in that area, so if you are using one of them you *will* have problems. > > I can deny that it is a Moose problem, I can reproduce it in Pharo 30716 on mac > > Open the image, open a Nautilus browser > Add new package AZ > Select AST-Core, Nodes > Select RBProgramNode > Copy the class with right-click menu > Rename to AZProgramNode > Enter your name (should have happened when creating the new package!) > Drag AZProgramNode to AZ > Category is not updated. > > Stephan

Jan. 25, 2014

Re: [Pharo-dev] how do I install gitfiletree?

by Pharo4Stef

For the record, we will hand in monday a proposal (was rejected last year) to engineer a good git support for Pharo (but not to expose end-user to command line git idiosyncrasies. Now we should cross our fingers. I spent my vacations rewriting it and I hope that I should not have just do something else. Stef PS: if someone has 10 engineers to lend to me for a couple of years, Pharo will look really different and cooler. >> >> oh yesâ¦ I do not think thatâs the way to go: having a repository-cache at the side of the image looks like the correct approach :) > > The current package-cache has ways to trip you that are really fun (not :(:() when using git and branches... > > With the current approach in gitfiletree, it's really easy to work with github or with any other git server setup, even in a multi-language / multi-user project (I've done C + Pharo and Ocaml + Pharo with it). > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Jan. 25, 2014

process to collaborate on cleaning morphic

by Pharo4Stef

Sean Iâm trying to understand how we could work together to share forces on cleaning morphic. Now it is not easy because some of the changes are crosscutting many packages. If somebody has an idea. Stef

Jan. 25, 2014

Re: [Pharo-dev] Font chooser broken (12704)

by Pharo4Stef

Thanks. Doing is accepting that we can make mistakes. I really like that you looked at my changes. I spent some times with Alain trying to spot my mistakes (because I had a broken version of my changes). So thank you guys. This is cool to know that they are people that have a look at what we are doing. It is not easy to work on code that we do not write and something fully understand. Stef On 25 Jan 2014, at 09:14, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014/1/25 Sean P. DeNigris <sean(a)clipperadams.com> > Nicolai Hess wrote > > Sean, can you look at my latest submission > > for 12704. > > It looks good. I made a few more small changes. Check my new sliceâ¦ in the > future I think we make a new issue with fixes to previously integrated fixes > to keep things clear... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Font-chooser-broken-12704-tp4739230p4739234.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > Ok. >

Jan. 25, 2014