November 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About senders

by Damien Cassou

On Wed, Nov 12, 2008 at 10:36 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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. I don't know what you are talking about: - Open a browser on InputSensor>>anyButtonPressed - Press the 'senders' button and the 'anyButtonPressed' item. - You won't see the method in the new browser -- Damien Cassou http://damiencassou.seasidehosting.st

Nov. 12, 2008

[Pharo-project] About senders

by StÃ©phane Ducasse

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

Nov. 12, 2008

Re: [Pharo-project] OldSocket removal

by John M McIntosh

Actually this is still a work in progress, you'll find quite a few tests don't work yet because they require some modification. For example on machines 8 years back you could actually see socket state changes when you closed your side of the socket. Now you close it, and bang (usually) the socket gets unconnected, so a test fails that was looking at state changes. Also some of the tests required use of port ECHO to reflect data back to check for send/receive, that's very hard to do now because most linux systems consider poking at the echo port as a denial of service attack. On Nov 12, 2008, at 12:32 AM, Damien Cassou wrote: > Hi Dan, > > On Sat, Oct 25, 2008 at 8:36 PM, Dan Corneanu > <dan.corneanu(a)gmail.com> wrote: >> I've played with the change sets from >> http://www.smalltalkconsulting.com/html/OTNotes4.html. >> I've made some changes to the tests, to fit the current Socket and >> NetNameResolver implementations. If it is of any help, I can put up a >> mcz so others can have a look to the code. > > John released a new changeset: > http://code.google.com/p/pharo/issues/detail?id=275. However, unit > tests does not run due to missing NetNameResolver > class>>initializeNetworkIfFail:. I think you removed that method. > Could you please check the changeset, make the necessary changes, > verify that all unit tests run and commit to PharoInbox? > > Also, please update the issue on google code according to what you do. > > Bye > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 12, 2008

Re: [Pharo-project] OldSocket removal

by Damien Cassou

Hi Dan, On Sat, Oct 25, 2008 at 8:36 PM, Dan Corneanu <dan.corneanu(a)gmail.com> wrote: > I've played with the change sets from > http://www.smalltalkconsulting.com/html/OTNotes4.html. > I've made some changes to the tests, to fit the current Socket and > NetNameResolver implementations. If it is of any help, I can put up a > mcz so others can have a look to the code. John released a new changeset: http://code.google.com/p/pharo/issues/detail?id=275. However, unit tests does not run due to missing NetNameResolver class>>initializeNetworkIfFail:. I think you removed that method. Could you please check the changeset, make the necessary changes, verify that all unit tests run and commit to PharoInbox? Also, please update the issue on google code according to what you do. Bye -- Damien Cassou http://damiencassou.seasidehosting.st

Nov. 12, 2008

[Pharo-project] Re: Sake, Packages, and deployment code

by StÃ©phane Ducasse

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 >

Nov. 12, 2008

[Pharo-project] Fwd: Sake, Packages, and deployment code

by StÃ©phane Ducasse

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 >

Nov. 12, 2008

[Pharo-project] Fwd: Sake, Packages, and deployment code

by StÃ©phane Ducasse

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 > >

Nov. 12, 2008

[Pharo-project] Fwd: Sake, Packages, and deployment code

by StÃ©phane Ducasse

Begin forwarded message: > From: "Damien Pollet" <damien.pollet(a)gmail.com> > Date: November 11, 2008 10:35:49 PM CEST > To: "Keith Hodges" <keith_hodges(a)yahoo.co.uk> > Cc: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > Subject: Re: Sake, Packages, and deployment code > > 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. I guess SakeMeta separates it a bit > alreadyâ¦ maybe it would help me if I knew the implementation of rake, > but I don't :) > >> 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. > 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. > >> 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. 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 > :) > 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. > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Nov. 12, 2008

[Pharo-project] Fwd: Sake, Packages, and deployment code

by StÃ©phane Ducasse

Begin forwarded message: > From: Tudor Girba <girba(a)iam.unibe.ch> > Date: November 11, 2008 11:55:21 AM CEST > To: Damien Pollet <damien.pollet(a)gmail.com> > Cc: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr>, keith_hodges(a)yahoo.co.uk > , "Damien Cassou" <damien.cassou(a)gmail.com> > Subject: Re: Sake, Packages, and deployment code > > I completely agree. This was also the plan for the Moose project. It > just did not get realized :). I have a similar set of scripts in VW. > > Unfortunately, I do not know Sake/Packages, but the idea of a > standard name and infrastructure for the set of loading scripts > would be super nice :). > > Cheers, > Doru > > > On Nov 10, 2008, at 10:59 PM, Damien Pollet wrote: > >> Hi, >> >> I'm looking at Sake and Packages, and I'm wondering if it would make >> sense to use them in a slightly different manner. >> Currently, the Sake-Package classes duplicate the various existing >> universes (most of them are generated from the universe >> descriptions), >> so for end-developers it's basically the same, except there is no >> nice >> OB-based UI for it. There is a difference though: sake package >> descriptions are saved in Monticello. >> >> What I'm thinking is, it would be nice to have a kind of deployment >> scripts for some projects, that is written and maintained by the >> project authors and not an external guy. For instance, Doru wrote >> PRDistribution to generate the Pier kernel in the one-click image, >> which is pre-filled with a set of pages, access rights, etc. The >> problem is, PRDistribution relies on all the code already being >> present, and will fail if you forgot to install Pier-Blog, for >> instance. >> >> So it would be nice if it was able to install the required packages >> form Magritte, Pier, and Pier-Addons. Then it would act as a clear >> entry point for users of the code, and a nice place for developers to >> put stuff that currently goes into class initialization methods (like >> the Licence-popping in magritte and pier, or the login/password >> stuff). >> >> The pattern could look like this: >> >> - application developersâ¦ >> package their application code in Foo-Subfoo packages >> package their tests in Foo-Tests packages >> package deployment stuff it Foo-Setup: dependancies between >> individual Foo-specific packages + dependancies to high-level >> external >> dependancies + deployment scripts like PRDistribution >> (maybe) copy snapshots of Foo-Setup to a common repository >> - code usersâ¦ >> know that Foo-Setup will help them get a working installation of >> Foo when they browse Squeaksource >> install Foo-Setup package using Installer, then call one of the >> sake tasks it defines (there can be several of them since they are >> quite high-level) >> - distribution maintainers (e.g. the other Damien)â¦ >> pull carefully chosen versions of Foo-Setup into their repository, >> and maybe maintain a distribution-specific -Setup package. >> >> What do you think? >> >> ps. remarks on Sake-Packagesâ¦ >> IMHO the root class should be packaged separately from its >> subclasses, >> since the former provides the code and the latter define the metadata >> for particular distributions. >> Also since the rules are somewhat like unit test methods, they could >> be named taskFoo instead of just Foo. That would differenciate sake >> rules from utility smalltalk methods. >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Relationships are of two kinds: those we choose and those that > happen. They both matter." > > > >

Nov. 12, 2008

[Pharo-project] Squeak Carbon OS-X VM 3.8.19beta2U ships

by John M McIntosh

Ken Brown was lucky enough to figure out that the 3.8.19beta1U VM won't launch on a 4GB Mac Pro when you have 27 other applications running. The 3.8.19beta2U VM has a fix to work around mmap issues when the operating system would rather load you at the 42GB boundary, versus our suggested 512MB. I've posted the new VM in the usual places via ftp or my idisk at http://www.smalltalkconsulting.com/squeak.html -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 12, 2008