- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] new update
by StÃ©phane Ducasse Nov. 15, 2008

Nov. 15, 2008

Hi all I continued to curved out etoy. If you want to follow my progress or participate http://code.google.com/p/pharo/wiki/CurrentlyWorkingOn?ts=1226697010&update… Now I stop for tonight since I get "nausea" after reading too funny much code. Stef

3 4

[Pharo-project] String and Symbol comparison
by Lukas Renggli Nov. 15, 2008

Nov. 15, 2008

I want to open this for discussion: In all Smalltalk dialects the following expressions evaluate to false: 'abc' = #abc --> false #abc = 'abc' --> false This means a String and a Symbol is never the same thing, even if they contain the same characters. In Squeak/Pharo this is different though (at least this is symmetrical, pre 3.9 this wasn't even symmetrical): 'abc' = #abc --> true #abc = 'abc' --> true Unfortunately this difference makes writing portable code that deals with symbols and strings a huge pain. And it is hard to test, debug and find those kind of problems. I wonder if it would be possible to change that behavior in Squeak to match the other Smalltalk implementations? I guess this would break some code, but at least this problem would then be gone forever. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

4 8

[Pharo-project] OldSocket removal
by Damien Cassou Nov. 13, 2008

Nov. 13, 2008

I've started working on OldSocket removal: http://code.google.com/p/pharo/issues/detail?id=275. I need someone to review my first changes. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

4 27

[Pharo-project] MNU addMakeSiblingHandle:
by nicolas cellier Nov. 13, 2008

Nov. 13, 2008

The halo button brings me a debugger : Message not understood addMakeSiblingHandle: If that happens to you, just doIt: Preferences resetHaloSpecifications. Nicolas

2 1

[Pharo-project] Rio renamed to File/Directory
by Keith Hodges Nov. 13, 2008

Nov. 13, 2008

lets see how it goes Keith

1 0

[Pharo-project] About senders
by StÃ©phane Ducasse Nov. 12, 2008

Nov. 12, 2008

Hi all this is a call for features. Right now senders shows me even the method that defines the method I'm looking for just because it finds the name in the methods. It would be cool if somebody would enhance the senders to returns senders and not senders and implementors mixed together. Stef

5 7

[Pharo-project] [update] #10146
by Marcus Denker Nov. 12, 2008

Nov. 12, 2008

- Issue 219: Cryptography does not load into Pharo -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 0

Nov. 12, 2008

Please use the mailing-list > On Tue, Nov 11, 2008 at 11:04 PM, Keith Hodges <keith_hodges(a)yahoo.co.uk > > wrote: >> SSpec doesnt follow that convention, but uses method category >> 'specs'. >> So in SUnit-improved it has a more flexible approach in order to >> accomodate SSpec and not to have to follow this convention, it allows >> you to define toDo* bug* , method categories, flagged methods, >> pragmas >> or whatever else you choose. > > All good solutionsâ¦ actually I agree that relying on the method name > is somewhat of a hack. well it depends. Roel told me that annotation in Java for tests at the end of the day are a hell. Imagine that we would like to remove from our analysis unit tests when you do not need a class, you do not have method patterns, and the annotations are not that well defined. >> Neither am I. I would like "universes" to die off. The reason being >> the >> overly controlled closed nature of the master database, and the > > What bothers me most is that it's centralized. The problem is that as a user I want something that is working and not a shitty place like squeakmap where nearly nothing work >> The ethos behind Sake/Packages is that it is the package USERS that >> determine what works in what context. Developers often don't test >> their >> packages in all contexts, but users may do. Sure but I think that this is also wrong. I got so tired of squeakmap package quality that I stop to use it. And I imagine lot of people did the same >> It is a space in which the collective knowledge of what works where >> is >> collated by the community. >> Both the Users "universes" and the developers SetUp packages can be >> used >> to get the best of both worlds. > > Exactly. Developers can propose their part of the collective knowledge > (precise, minimal, low-level dependancies between individual MC > branches). Then the community can build higher-level packages or whole > integrated distributions, either by using what the developers provide, > or by doing the integration tests independantly and providing a > different set of dependencies. For instance, I expect developers would > not mention versions at all, except for planned incompatibilities. > Distributions would freeze whole sets of versions together because > they are known to work. > >>> determine success. For instance, I think SourceTalk and Bob should >>> be >>> linked or even integrated someday, so that getting automatic builds >>> for a new project is near-instant >> Just need to add MC2 support to, Installer. >> >> For the fastest loading experience, try MC1.6! >> >> I also have a plan for binary loading for both MC1 and 2. > > I meant instant in cognitive time :D > I want only one bookmark, one account, be able to link build numbers > to bug reports and unit tests versions all in one place. > > By the way, I'm trying stuff with Packages now, and I'm realizing I > need a way to depend on rules from another class. Concretely, the > Pier-Model task in PierSetup should depend on Magritte-Model in > MagritteSetup. The situation is kind of similar to makefiles and > recursive makefilesâ¦ it works but sub-makes don't have access to the > state of the parent make process. Is there a way to merge or union > several SakeTasks ? > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

1 0

Nov. 12, 2008

Begin forwarded message: > From: "Damien Pollet" <damien.pollet(a)gmail.com> > Date: November 12, 2008 12:26:28 AM CEST > To: "Keith Hodges" <keith_hodges(a)yahoo.co.uk> > Cc: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr>, "Tudor Girba" <girba(a)iam.unibe.ch > >, "Damien Cassou" <damien.cassou(a)gmail.com> > Subject: Re: Sake, Packages, and deployment code > > On Tue, Nov 11, 2008 at 11:04 PM, Keith Hodges <keith_hodges(a)yahoo.co.uk > > wrote: >> SSpec doesnt follow that convention, but uses method category >> 'specs'. >> So in SUnit-improved it has a more flexible approach in order to >> accomodate SSpec and not to have to follow this convention, it allows >> you to define toDo* bug* , method categories, flagged methods, >> pragmas >> or whatever else you choose. > > All good solutionsâ¦ actually I agree that relying on the method name > is somewhat of a hack. > >> I have never looked at PRDistribution. Lukas and folks changed >> something >> which has broken all my pier deployments and so I am stuck with an >> older >> version of pier until I can find some spare time to fix it. > > Basically, it's just creating a PRKernel with a bunch of pages using > lazy initializers. > >> Right now I am betting that PRDistribution is an incompatible >> alternative to my PRFrames, which is a shame. > > Well, it's explicitly creating a PRPierFrame I think, but that's just > in a couple methods. > >> Neither am I. I would like "universes" to die off. The reason being >> the >> overly controlled closed nature of the master database, and the > > What bothers me most is that it's centralized. > >> But what I am convinced of is that if you put the control of the >> dependencies in the hands of the developers, then it will get out of >> date, when the developers get too busy, and hold on to too much >> control. > > Maybe, but they are also the ones which will most probably need to > create clean work images from scratch most often, be it for automated > test purposes, because their image broke, or simply to keep up-to-date > with the platform images. > >> The ethos behind Sake/Packages is that it is the package USERS that >> determine what works in what context. Developers often don't test >> their >> packages in all contexts, but users may do. >> >> It is a space in which the collective knowledge of what works where >> is >> collated by the community. >> Both the Users "universes" and the developers SetUp packages can be >> used >> to get the best of both worlds. > > Exactly. Developers can propose their part of the collective knowledge > (precise, minimal, low-level dependancies between individual MC > branches). Then the community can build higher-level packages or whole > integrated distributions, either by using what the developers provide, > or by doing the integration tests independantly and providing a > different set of dependencies. For instance, I expect developers would > not mention versions at all, except for planned incompatibilities. > Distributions would freeze whole sets of versions together because > they are known to work. > >>> determine success. For instance, I think SourceTalk and Bob should >>> be >>> linked or even integrated someday, so that getting automatic builds >>> for a new project is near-instant >> Just need to add MC2 support to, Installer. >> >> For the fastest loading experience, try MC1.6! >> >> I also have a plan for binary loading for both MC1 and 2. > > I meant instant in cognitive time :D > I want only one bookmark, one account, be able to link build numbers > to bug reports and unit tests versions all in one place. > > By the way, I'm trying stuff with Packages now, and I'm realizing I > need a way to depend on rules from another class. Concretely, the > Pier-Model task in PierSetup should depend on Magritte-Model in > MagritteSetup. The situation is kind of similar to makefiles and > recursive makefilesâ¦ it works but sub-makes don't have access to the > state of the parent make process. Is there a way to merge or union > several SakeTasks ? > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

1 0

Nov. 12, 2008

Begin forwarded message: > From: Keith Hodges <keith_hodges(a)yahoo.co.uk> > Date: November 11, 2008 11:11:47 PM CEST > To: Damien Pollet <damien.pollet(a)gmail.com> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, Tudor Girba <girba(a)iam.unibe.ch > >, Damien Cassou <damien.cassou(a)gmail.com> > Subject: Re: Sake, Packages, and deployment code > > Damien Pollet wrote: >> On Tue, Nov 11, 2008 at 2:13 AM, Keith Hodges > <keith_hodges(a)yahoo.co.uk> wrote: >> >>>> IMHO the root class should be packaged separately from its >>>> subclasses, >>>> >> >> Also, part of the code is there to make the task-declaration DSLâ¦ it >> would be nice if the DSL layer was documented as such and separated >> from the implementation code. > > that's a good idea. > >> I guess SakeMeta separates it a bit >> alreadyâ¦ maybe it would help me if I knew the implementation of rake, >> but I don't :) > > rakes implementation code is visible online (somewhere) > >>> tasks are generally named task* , in "bob" build methods are named > build*. >>> >> >> ok. I'm not advocating for a particular prefix (maybe a short one >> like >> pkg is best indeed). >> >> >>> However I dont see the problem with not having "task" in this > context. I would prefer pkg* or package* , but I felt it looked > untidy. >>> >> >> Well, for one, it would be symmetrical with SUnit's test* methods. >> > > Ok I am thinking about it. > > SSpec doesnt follow that convention, but uses method category 'specs'. > So in SUnit-improved it has a more flexible approach in order to > accomodate SSpec and not to have to follow this convention, it allows > you to define toDo* bug* , method categories, flagged methods, pragmas > or whatever else you choose. > >> Then, I think it's better to keep the convention that capitalized >> names are for globals; think of analysis tools. Also, this is a whole >> family of methods that are supposed to respect a few rules, so it's >> better if they are easily identifiable; we can imagine that some day, >> Slime will be extended with Sake-specific checks. >> >> As for utility methods, they are all defined in the root class >> Packages, but I don't see why there couldn't be a need for some more >> in a subclass, especially if you want to implement a kind of lazy >> graph construction like in PRDistribution. >> > > I have never looked at PRDistribution. Lukas and folks changed > something > which has broken all my pier deployments and so I am stuck with an > older > version of pier until I can find some spare time to fix it. > > I still keep trying to persuade Lukas to put the configuration for > pier > in the PRFrame, since that is the context in which it is displayed > when > I embed pier in another app. > > Right now I am betting that PRDistribution is an incompatible > alternative to my PRFrames, which is a shame. > >>> From what I understand you are simply suggesting that "sub- >>> universes" > be defined and available as SomeProject-Setup. That sounds fair > enough, > and is part of the original idea. >>> >> >> Actually I'm not convinced that the central Universe approach really >> works for the squeak community, since it's so divided. > > Neither am I. I would like "universes" to die off. The reason being > the > overly controlled closed nature of the master database, and the > dependency upon some specific server. The UI is a bit rubbish too. > > But what I am convinced of is that if you put the control of the > dependencies, purely in the hands of the developers, then it will > get out of > date, when the developers get too busy, and hold on to too much > control. > > The ethos behind Sake/Packages is that it is the package USERS have > the > power to > determine what works in what context. Developers often don't test > their > packages in all contexts, but users may do. > > It is a space in which the collective knowledge of what works where is > collated by the community. > > Both the Users "universes" and the developers SetUp packages can be > used > to get the best of both worlds. > >> Application >> developers have a precise knowledge of the dependancies of their own >> packages. They could document the fine-grained dependancies in their >> Foo-Setup (i.e. for Seaside, encode >> http://code.google.com/p/seaside/wiki/LoadOrder) Then, if someone >> wants to provide a universe-like larger-grained set of dependancies, >> they can do so in a separate place, reusing dependancies from >> multiple >> independently developed projects. >> >> >>> Will it catch on though... I expect that if I ever get to release > 3.11 it will include LPF and sake-packages as standard (with the > option > to remove them) >>> > >> Well, as far as I am concerned, if the big modular packages like >> Seaside/Magritte/Pier+addons/Moose adopt it, I consider it's caught >> on >> :) > > VW port anyone? > >> More than the features of sake over rake, I think it's whether it >> enables the community to progress in a smoother way that will >> determine success. For instance, I think SourceTalk and Bob should be >> linked or even integrated someday, so that getting automatic builds >> for a new project is near-instant > > Just need to add MC2 support to, Installer. > > For a fastest loading experience, try MC1.6! > > I also have a plan which might work for binary loading for both MC1 > and 2. > > Keith > >

1 0