March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Code review tools?

by Igor Stasenko

pff... really people... i am thinking how to streamline our existing development process.. and instead i hear once again about git. okay, lets throw away MC & stuff, migrate everything on file-based file-per-method git repository and then navigate diffs on github, and trying to find senders or implementors of selector using web browser . -- Best regards, Igor Stasenko.

March 11, 2013

Re: [Pharo-project] Code review tools?

by stephane ducasse

On Mar 11, 2013, at 6:09 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2013/3/11 stephane ducasse <stephane.ducasse(a)free.fr>: > >> because pay attention when you talk about smalltalker reinventing the wheel. >> So far with this argument we could say that we should all use eclipse because Java invented the ide, isn't. > > Well... Eclipse was a mutation from VisualAge... it took the best > parts of it. So in that case they did exactly that. > I don't want an Eclipse IDE Plugin for Pharo. I expect the Pharo team > to do that? Of course not! But I wont deny I think it could be a good > selling point. > >> So if you want Pharo to make progress, contribute. >> Simple easy and with measurable impact. > > I totally agree with that. > > On the other hand there's no need to be harsh, I'm not harsh :) Believe the day where I will be harsh you will feel it. > we're all on the same > side, but please consider that contributing with a project is not only > a matter of producing code. Sure You have blogs, tests, chapter, documentation, doing presentation in various audienceâ¦â¦ > Getting people aboard by advocating its use also helps. IMHO, The user base is as important as the features. Totally true. > > Regards, > > Esteban. >

March 11, 2013

Re: [Pharo-project] Code review tools?

by stephane ducasse

On Mar 11, 2013, at 6:04 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 11 March 2013 16:39, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>> >>>> Do you know when monticello was invented? >>>> and working for real? >>> >>> Around 2004-2005 as far as I remember. And working for real at that >>> very moment, I guess. >>> >>> Why? >> >> because pay attention when you talk about smalltalker reinventing the wheel. >> So far with this argument we could say that we should all use eclipse because Java invented the ide, isn't. > > In 2003, Monticello was the only game in town. It's now 10 years > later. You need to reevaluate your decisions sometimes. Concentrating > on application level stuff at the expense of infrastructure comes at a > cost. Apparently you did not read the documentation I wrote about the Pharo vision :) too bad because I wrote it so that people understand that we are focusing on infrastructure. This is already 3 years that we are focusing infrastructure. I suggest that you have a serious look at what we are doing. > In particular, spending time on better code review tools will in > the long run accelerate your development velocity. Yes may be > This is supposed to be a key Pharo trait. Now note: I said "spending time". That MIGHT > mean reinventing github's features. That MIGHT mean giving Camillo and > friends free reign to integrate git into a Pharoer's workflow. > > But this kind of passive aggressive attitude is seriously > counterproductive. Because you're _not_ just telling people to shut up > and contribute. You're just telling people to shut up. Ahhhh you were talking to esteban :) > At any rate, Esteban, people _are_ working on Smalltalk/github > integration. Some of them are actually Pharo devs! > > frank >

March 11, 2013

Re: [Pharo-project] Code review tools?

by Camillo Bruni

>>> i am very happy that github exists.. and its features available only if you >>> put code there.. >>> but if code is not on github, then what you will do? >> >> To rephrase the question: what do we still need to do before we can >> integrate (something like) github into a standard Smalltalk workflow? > > how many man month engineer time do you have free for that? > Personally I prefer that > FFI > VM > vector graphics > â¦ > get pushed. > > So git integration will come but on people free time. So I see, your git allergies haven't stopped yet

March 11, 2013

Re: [Pharo-project] Code review tools?

by Camillo Bruni

> Presumably because it predates git :) But I think 2003 is the actual birth year. yet it shares almost the same model as git does. Sadly the tools don't make proper use of it :). But that means that Monticello as a model isn't that bad. > But the counter argument is trivial: how many people use Monticello? > (At most, hundreds. In comparison to at least 10s of thousands using > git.) Does Monticello actually use any of the special syntax-awareness > it's supposed to bring to the table? (No.) indeed, that is one of the arguments that make git support for smalltalk absolutely feasible. And even if there is going to be special object support, I think we can store that in separate binary blobs if necessary. > But the counter-counter argument is "it's good enough". (I disagree, > but I accept the argument that it does work well enough to actually > get stuff done, even if code review in Smalltalk is currently way > harder than in Ruby or Clojure, the other languages in which I most > commonly program. And they're so easy to code review because being > git-friendly allows me to see diffs and discuss diffs and use all > manner of cool tools that hook into git.) I would love to run different branches on that topic: - in image tools (such as torch) - versioning model (such as git) those two are basically orthogonal, but if you have a look at torch you see that there is already quite a complex and rich tool available for Pharo. It needs polishing I guess and depends on too many external packages, but it is there and can server as a very good basis to go further. For the versioning model we're running multiple branches as well: - git (slow progress) - libgit bindings - filetree as a dialect agnostic fileout format (mostly completed)

March 11, 2013

Re: [Pharo-project] Fwd: Code review tools?

by Esteban A. Maringolo

2013/3/11 stephane ducasse <stephane.ducasse(a)free.fr>: > because pay attention when you talk about smalltalker reinventing the wheel. > So far with this argument we could say that we should all use eclipse because Java invented the ide, isn't. Well... Eclipse was a mutation from VisualAge... it took the best parts of it. So in that case they did exactly that. I don't want an Eclipse IDE Plugin for Pharo. I expect the Pharo team to do that? Of course not! But I wont deny I think it could be a good selling point. > So if you want Pharo to make progress, contribute. > Simple easy and with measurable impact. I totally agree with that. On the other hand there's no need to be harsh, we're all on the same side, but please consider that contributing with a project is not only a matter of producing code. Getting people aboard by advocating its use also helps. IMHO, The user base is as important as the features. Regards, Esteban.

March 11, 2013

Re: [Pharo-project] Fwd: Code review tools?

by Frank Shearar

On 11 March 2013 16:39, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> >>> Do you know when monticello was invented? >>> and working for real? >> >> Around 2004-2005 as far as I remember. And working for real at that >> very moment, I guess. >> >> Why? > > because pay attention when you talk about smalltalker reinventing the wheel. > So far with this argument we could say that we should all use eclipse because Java invented the ide, isn't. In 2003, Monticello was the only game in town. It's now 10 years later. You need to reevaluate your decisions sometimes. Concentrating on application level stuff at the expense of infrastructure comes at a cost. In particular, spending time on better code review tools will in the long run accelerate your development velocity. This is supposed to be a key Pharo trait. Now note: I said "spending time". That MIGHT mean reinventing github's features. That MIGHT mean giving Camillo and friends free reign to integrate git into a Pharoer's workflow. But this kind of passive aggressive attitude is seriously counterproductive. Because you're _not_ just telling people to shut up and contribute. You're just telling people to shut up. At any rate, Esteban, people _are_ working on Smalltalk/github integration. Some of them are actually Pharo devs! frank

March 11, 2013

[Pharo-project] Fwd: [INRIAGForge] Scheduled downtime - March 18 and March 19

by Camillo Bruni

our file servers won't be available most probably during that period: http://files.pharo.org/ http://pharo.gforge.inria.fr/ Begin forwarded message: > From: <noreply(a)gforge.inria.fr> > Subject: [INRIAGForge] Scheduled downtime - March 18 and March 19 > Date: 11. MÃ¤rz 2013 17:18:01 MEZ > To: camillobruni(a)gmail.com > > Due to sheduled maintenance on network equipment, the INRIA Forge will be unavailable : > - from 6 pm to 8 pm on Monday, March 18th 2013, > - from 1 pm to 2 pm on Tuesday, March 19th 2013. > > The InriaForge team apologizes for any inconvenience.

March 11, 2013

Re: [Pharo-project] Fwd: Code review tools?

by Sven Van Caekenberghe

On 11 Mar 2013, at 17:39, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > So if you want Pharo to make progress, contribute. > Simple easy and with measurable impact. > > Stef +100

March 11, 2013

Re: [Pharo-project] Porting SmaCC from 1.4 to 2.0; doSilently: equivalent ?

by stephane ducasse

>> >> then you add symbolic version >> >> stable: spec >> <symbolicVersion: #'stable'> >> >> spec for: #'common' version: '1.1'. >> spec for: #'pharo1.4.x' version: '1.4' >> spec for: #'pharo2.0.x' version: '1.8' >> >> Have a look at the metacello chapter > > Done, but then I had a segfault (#becomeForward:)... well in fact two, trying to load SmaCCDev and OSProcess. Will try to recover my changes soon. > > Kind of hard at the moment to use Pharo 2.0, with the segfaults. Yes if you have a reproducible case we would love to get it. This is probably related to the bug of the become implementation in Cog. Esteban was working on getting also the Stack VM working so that we get a stable fallback. Stef > > 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 >

March 11, 2013