August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] splitting MC packages

by Lukas Renggli

On 12 August 2011 23:32, Damien Pollet <damien.pollet(a)gmail.com> wrote: > On 12 August 2011 22:21, Lukas Renggli <renggli(a)gmail.com> wrote: >> The only solution is to stick with consistent and well though package >> name scheme. Not the only possible naming strategy, but the one we >> developed for Seaside works pretty well: >> http://code.google.com/p/seaside/wiki/PackageNaming > > I know about these conventions, but how do I proceed towards them? :) Closing the eyes and restarting from scratch. We did that too with the Seaside packages at some point. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 13, 2011

Re: [Pharo-project] PPElementParser & a small PetitTests contribution

by Lukas Renggli

Ohh ohhh, that was a bit too fast: I don't really see the point of PPElementParser? Why don't you just use aParser answer: anObject ? For the problems of your commit: - There is not a single test case. PetitParser had 99% test coverage before your commit. - All PPParser classes should have a class comment describing the class and its instance variables. - Please stick with the formatting conventions and don't leave commented code in the codebase. Cheers, Lukas On 13 August 2011 03:28, Damien Pollet <damien.pollet(a)gmail.com> wrote: > I've committed PPElementParser + a couple factory methods on > PPPredicateObjectParser > > On 12 August 2011 16:20, Damien Pollet <damien.pollet(a)gmail.com> wrote: >> On 12 August 2011 07:21, Lukas Renggli <renggli(a)gmail.com> wrote: >>> Do you have a ready made-image somewhere? I don't understand it from >>> reading your mail only. >> >> Yup, get Pharo Coral from Jenkins: >> https://ci.lille.inria.fr/pharo/job/Pharo%20Coral/ >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 13, 2011

Re: [Pharo-project] PPElementParser & a small PetitTests contribution

by Damien Pollet

I've committed PPElementParser + a couple factory methods on PPPredicateObjectParser On 12 August 2011 16:20, Damien Pollet <damien.pollet(a)gmail.com> wrote: > On 12 August 2011 07:21, Lukas Renggli <renggli(a)gmail.com> wrote: >> Do you have a ready made-image somewhere? I don't understand it from >> reading your mail only. > > Yup, get Pharo Coral from Jenkins: > https://ci.lille.inria.fr/pharo/job/Pharo%20Coral/ > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 13, 2011

Re: [Pharo-project] splitting MC packages

by Schwab,Wilhelm K

Maybe I have no clue about your problem, or maybe I am in complete ignorance and denial about my own problems :) With that caveat, here is what I *think* has been working for me. To illustrate it, let's rewind to when Pharo was just getting started and I was just starting to move away from Windows. In my Dolphin image are packages with names like HPViridia and DatexCapnomac. The names match physiologic monitors, but that's not really important. What is important is that once I got a handle on PackageInfo, I started naming things like this as Recordkeeper-monitors-DatexCapnomac Recordkeeper-monitors-HPViridia Saving the one package called Recordkeeper then captures all of the infrastructure, device interfaces, and GUI (the latter being largely vapor right now). There are 28 sub-packages. Once you create a new sub-package, you can do things like aClass withAllSubclasses do:[ :each | each category:'ThisAndThat-NewSubpackage' ]. to move things to it. Two other packages, Studies and Hardware, have growing lists of sub-packages. AFAIK, package names are case-sensitive, with one exception: loose methods. PackageInfo abuses method categories to package these methods. Anything like *Recordkeeper-monitors-DatexCapnomac will include methods in the named package. I doubt it will work if there are two package names differing only by case, so it can be confusing. What I do is scan my image for methods that I wrote and have not claimed ownership of the containing package. Looking at the extension methods in the MC browser is one way to do that; I have code in Migrate that has saved me from myself on several occasions. HTH. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Damien Pollet [damien.pollet(a)gmail.com] Sent: Friday, August 12, 2011 5:32 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] splitting MC packages On 12 August 2011 22:21, Lukas Renggli <renggli(a)gmail.com> wrote: > The only solution is to stick with consistent and well though package > name scheme. Not the only possible naming strategy, but the one we > developed for Seaside works pretty well: > http://code.google.com/p/seaside/wiki/PackageNaming I know about these conventions, but how do I proceed towards them? :) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 13, 2011

[Pharo-project] Why is #stepTime in the 'testing' protocol?

by Sean P. DeNigris

It should be in 'stepping and presenter' with the other step methods, no? S -- View this message in context: http://forum.world.st/Why-is-stepTime-in-the-testing-protocol-tp3740584p374… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 12, 2011

[Pharo-project] Is Pharo 1.3 officially released?

by Sean P. DeNigris

I see there is now a link on the website to "Release 1.3" and that "stable" points to 1.3. Sean -- View this message in context: http://forum.world.st/Is-Pharo-1-3-officially-released-tp3740529p3740529.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 12, 2011

Re: [Pharo-project] splitting MC packages

by Damien Pollet

On 12 August 2011 22:21, Lukas Renggli <renggli(a)gmail.com> wrote: > The only solution is to stick with consistent and well though package > name scheme. Not the only possible naming strategy, but the one we > developed for Seaside works pretty well: > http://code.google.com/p/seaside/wiki/PackageNaming I know about these conventions, but how do I proceed towards them? :) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 12, 2011

[Pharo-project] uMorphic

by Pavel Krivanek

Hi, this code (see the attachment) can help in Morphic refactoring and repackaging a lot. It contains basic Morphic classes and methods (about 530) that represent the core of Morphic functionality. It is code that can be loaded into PharoKernel-Gofer image, it initializes Morphic and the only thing it can do is to open basic morph, grab and move it with mouse. It doesn't have Fonts support, SystemWindows etc. It was generated mostly automatically and it doesn't modify any code so the resultant image is very unclean and it crashes easily. -- Pavel

Aug. 12, 2011

Re: [Pharo-project] splitting MC packages

by Lukas Renggli

This has nothing to do with MC, but with how PackageInfo defines what belongs in a package. 5 years ago one could override PackageInfo in a package to define different rules, so you could have easy defined a different split. Unfortunately this is no longer possible due to hardcoded PackageInfo semantics everywhere. The only solution is to stick with consistent and well though package name scheme. Not the only possible naming strategy, but the one we developed for Seaside works pretty well: http://code.google.com/p/seaside/wiki/PackageNaming Lukas On 12 August 2011 22:14, Damien Pollet <damien.pollet(a)gmail.com> wrote: > Is there a clear doc somewhere about how to deal with MC packages that > have a common prefix ? > > e.g. I currently have Coral > > I want a separate Coral-Examples, and from how MC behaves I have the > feeling it's not possibleâ¦ > When do we switch to git already ? > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 12, 2011

[Pharo-project] splitting MC packages

by Damien Pollet

Is there a clear doc somewhere about how to deal with MC packages that have a common prefix ? e.g. I currently have Coral I want a separate Coral-Examples, and from how MC behaves I have the feeling it's not possibleâ¦ When do we switch to git already ? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 12, 2011