- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Which tests should be run in CI?

by Marcus Denker

On 12 Dec 2013, at 08:22, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 12 Dec 2013, at 08:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> >> On Thu, Dec 12, 2013 at 7:59 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On 12 Dec 2013, at 06:31, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> > Hi Stephan, >> > >> > Thanks for pushing the #packages problem. >> > >> > >> > But, it's strange that the Pharo3 build is not red. Could it be that the test was not integrated into Pharo? >> > >> the test tests that there is no #packages in Pharo on the class side other than the one that returns the >> rpackage istance. >> â> this is the case, the test is green. >> >> Oh, so the API classes were fixed. I should have checked before (I just did). Great. >> > But *Grease* still is the problem: in the tradition of the wonderful philosophy âLets keep all smalltalk crappy > and provide some layer on topâ, it redefines #package and therefore requires that no Smalltalk ever > implements #packages on the class side to return the system concept of package. > > What you need to find out: Why does Grease need a #package method? Is there a GreasePackage class? > What is itâs responsibility? wouldnât it be good enough to have a #gpackage method? Another idea: if there is #package in Grease, there should be a class GreasePackage (or Package?). Maybe the API of the class is actually good (grease apis tend to be good). So maybe that API makes sense to be provided by RPackage? The real question is: what is the implementation of #package in Grease, what does it return and what does that object do? Marcus

Dec. 12, 2013

Re: [Pharo-dev] Categories, packages, and tags [cont'd]

by Roberto Minelli

Thx Stef! I also found RPackage organizer packages ;) Cheers, R On Dec 12, 2013, at 8:25 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 11, 2013, at 1:40 PM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > >> Hi guys, >> >> I have a question about the new âPackageTreeModelââ¦ >> >> In a previous discussion (https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg09271.html) we discussed about the new package model. Now I understood it but I am wondering one thing. >> >> Since Stef said that categories will be removed, i.e., the ByteSymbol representation of what I used to call packages, I am wondering how one could ask the system which are the installed packages, tags, etc. >> >> In short I want to know which is the best method to ask what used to be âSystemOrganization categoriesâ. > > > PackageOrganizer default blblablabbleb packages

Dec. 12, 2013

Re: [Pharo-dev] Which tests should be run in CI?

by StÃ©phane Ducasse

+1 I do not really get it because we mentioned that several times. Grease maintainers should simply produce a new version and Seaside/users should use this new version. >> > But *Grease* still is the problem: in the tradition of the wonderful philosophy âLets keep all smalltalk crappy > and provide some layer on topâ, it redefines #package and therefore requires that no Smalltalk ever > implements #packages on the class side to return the system concept of package. > > What you need to find out: Why does Grease need a #package method? Is there a GreasePackage class? > What is itâs responsibility? wouldnât it be good enough to have a #gpackage method? > > In general, you should evaluate Grease and put all the *concepts* it adds into Pharo itself. This way even > the Core system can use them and everything gets better. > > Marcus

Dec. 12, 2013

Re: [Pharo-dev] Categories, packages, and tags [cont'd]

by StÃ©phane Ducasse

On Dec 11, 2013, at 1:40 PM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Hi guys, > > I have a question about the new âPackageTreeModelââ¦ > > In a previous discussion (https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg09271.html) we discussed about the new package model. Now I understood it but I am wondering one thing. > > Since Stef said that categories will be removed, i.e., the ByteSymbol representation of what I used to call packages, I am wondering how one could ask the system which are the installed packages, tags, etc. > > In short I want to know which is the best method to ask what used to be âSystemOrganization categoriesâ. PackageOrganizer default blblablabbleb packages

Dec. 12, 2013

[Pharo Trick: #0003] - halt in button

by StÃ©phane Ducasse

[Pharo Trick: #0003] - halt in button when you are building a user interface and you want to define the behavior of a button but you do not really know. you can use self halt or self inspect and you get an inspector/debugger on your application model Stef

Dec. 12, 2013

Re: [Pharo-dev] could we stop to create spaghetti code?

by StÃ©phane Ducasse

I will check but probably next firday during the sprint. On Dec 11, 2013, at 1:25 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > And if we are at it, the SpecDebugger still requires the EyeInspector to be the default inspector: > https://pharo.fogbugz.com/f/cases/12055/The-Spec-Debugger-should-not-requir… > > Cheers, > Doru > > > On Wed, Dec 11, 2013 at 1:15 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 11 Dec 2013, at 11:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > EyeInspector should not depend on Nautilus. > > > > icon > > ^ (self value iconOrThumbnailOfSize: 16) > > ifNil: [ self value class nautilusIcon ] > > > > ^^^^^^^^^^^^^^^^^^^^^^ > > > > https://pharo.fogbugz.com/f/cases/12392/EyeInspector-should-not-depend-on-N… > > > > Now we are trying to fix it. The question is how to dispatch. > > May be we should extract from Nautilus the nautilusIcon if the eyeInspector use it. > > > > I think the idea here is that maybe a class should have an icon. Independend of Nautilus.\ > (either just icon or toolIcon). > > Marcus > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Dec. 12, 2013

Re: [Pharo-dev] Which tests should be run in CI?

by Marcus Denker

On 12 Dec 2013, at 08:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > > On Thu, Dec 12, 2013 at 7:59 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 12 Dec 2013, at 06:31, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi Stephan, > > > > Thanks for pushing the #packages problem. > > > > > > But, it's strange that the Pharo3 build is not red. Could it be that the test was not integrated into Pharo? > > > the test tests that there is no #packages in Pharo on the class side other than the one that returns the > rpackage istance. > â> this is the case, the test is green. > > Oh, so the API classes were fixed. I should have checked before (I just did). Great. > But *Grease* still is the problem: in the tradition of the wonderful philosophy âLets keep all smalltalk crappy and provide some layer on topâ, it redefines #package and therefore requires that no Smalltalk ever implements #packages on the class side to return the system concept of package. What you need to find out: Why does Grease need a #package method? Is there a GreasePackage class? What is itâs responsibility? wouldnât it be good enough to have a #gpackage method? In general, you should evaluate Grease and put all the *concepts* it adds into Pharo itself. This way even the Core system can use them and everything gets better. Marcus

Dec. 12, 2013

Re: [Pharo-dev] could we stop to create spaghetti code?

by StÃ©phane Ducasse

>> > > I think the idea here is that maybe a class should have an icon. Independend of Nautilus.\ > (either just icon or toolIcon). Yes we got the idea :) Now we faced extensions management problems with pavel so we could not fix it. We did not want to produce more mess. But this is the next thing I want to fix because we cannot explore dependencies with a broken explorer. I think that if we are real about modularity. We should really focus on it for a while in 4.0 Else if it will never happen. People just do not think about dependencies. We should have a tool that check that. Stef

Dec. 12, 2013

Re: [Pharo-dev] Which tests should be run in CI?

by StÃ©phane Ducasse

> We need to reconsider how we approach continuous integration for pharo-based images. can you expand ?

Dec. 12, 2013

Re: [Pharo-dev] Which tests should be run in CI?

by Tudor Girba

Hi, On Thu, Dec 12, 2013 at 7:59 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 12 Dec 2013, at 06:31, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi Stephan, > > > > Thanks for pushing the #packages problem. > > > > > > But, it's strange that the Pharo3 build is not red. Could it be that the > test was not integrated into Pharo? > > > the test tests that there is no #packages in Pharo on the class side other > than the one that returns the > rpackage istance. > â> this is the case, the test is green. Oh, so the API classes were fixed. I should have checked before (I just did). Great. > > The Moose jobs run the Moose-specific tests (those defined in the Tests > group in the configuration). > > You are not running that test as you are only running the moose tests. I know. I just explained why the test does not fail in the moose job :). We need to reconsider how we approach continuous integration for pharo-based images. Doru > > Marcus > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 12, 2013