- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by StÃ©phane Ducasse

> > > Keith, please correct me if I'm wrong: > > - Sake is a domain specific language with all required tools to define > make-like rules. It allows people to describe tasks (as done in the > Ant/Java world) and execute these tasks when necessary > (http://wiki.squeak.org/squeak/5953) Yes we need that > > - Packages uses Sake to reimplement a universe-like tool with > dependencies. Then, it describes a lot of Squeak packages with their > dependencies. Ok >> What is PackagesSqueak310U....? > > > this is a class which has been generated automatically by a Sake task > from the Dev Universe. This means that each change I do in the > Universe system is reflected automatically in Sake just by running a > task. > > Moreover, the fact that each package is describe in a method using > only Smalltalk code makes creating new set of packages very easy. For > Pharo, we could just subclass PackagesSqueak310U and override the > methods we want to change. For Seaside, they could just provide yet > another class... I think it's much easier than with Universes. > Finally, the package descriptions are hosted on SqueakSource instead > of one's particular server. Good! So let us check that. Don't you want to write something for the next book Squeak by Example VOl 2 (err....Phar ....) Stef > > > -- > 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) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 27, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by StÃ©phane Ducasse

Thanks I will. since like me you would like to see some of the ideas od keith to be put forward. If you have some time, read the code andgive feedback I would like to continue to cruve out etoy for now. On Sep 27, 2008, at 11:43 AM, Damien Cassou wrote: > On Fri, Sep 26, 2008 at 6:25 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> On Sep 26, 2008, at 5:03 PM, Damien Cassou wrote: >> Did you check what LFP is doing? >> I would like to know that. >> Because the point is not that it would not be working but what are >> the stuff >> it brings in. > > http://installer.pbwiki.org/LevelPlayingField > > LPF is a script which installs Monticello 1.5 and Installer in your > image. The aim here is to get an equivalent playing field in all > images. This script allowed me to install Universes, OmniBrowser and > Shout in a Croquet image in a few minutes. > > For Pharo, we could have a look at what the script does exactly and > integrate the interesting fixes. > > -- > 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) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 27, 2008

Re: [Pharo-project] Regression testing results within package manifesto

by StÃ©phane Ducasse

I do not see how we can synchronise real texttual documentation other by care. For the tests I would like to have information such as: the last time (with a timestamp) the tests were run for this package these ones were ok and those ones not. This way we could have regression data. Same for SmallLint I would like that a package defines the list of rules that make sense to it and may be the expected results. Stef On Sep 27, 2008, at 10:23 AM, Alexandre Bergel wrote: > The idea is nice. But how will you ensure that your meta-data are > well synchronized with your code? > > Cheers, > Alexandre > > > On 27 Sep 2008, at 09:40, StÃ©phane Ducasse wrote: > >> Hi guys >> >> For Moose we started to add package manifesto using DrDoc. >> We will use the manifesto to document our package with license, >> documentation, class diagram... >> Now what I would really like to have is the results of SmallLint >> rules and the tests >> because when I run the tests if some of them were broken I do not >> know whether I made progress or not. >> >> I think that the manifesto could be a nice place to keep such >> information. >> After we could have a simple manisfesto dropping script >> Object allSubclasses do: .... >> >> what do you think about that, I would like to have a bit more self >> documentation and software engineering >> meta data within the system. >> >> Stef >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 27, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Damien Cassou

On Fri, Sep 26, 2008 at 6:50 PM, Ramon Leon <ramon.leon(a)allresnet.com> wrote: > My objection, the big ball of mud called Kernel-Extensions and the liberal > use of overrides, which I think are evil. I don't know about Kernel-Extensions but if I look at http://installer.pbwiki.com/311-KernelExtensions, I can see that Â«It should be safe to install on any 3.7 or later image, as it only adds methods.Â» If this sentence is wrong, you should contact Keith. > I like using packages that do > their best to only use extensions and don't just go around the system willy > nilly monkey patching everything. I don't trust packages with overrides not > to break my system and I absolutely don't like packages that once installed > can't be uninstalled, try removing Kernel-Extensions sometime. If you only install Kernel-Extensions, it should be safe and easy to uninstall. Now, if you install packages that depend on Kernel-Extensions, it is understandable that Kernel-Extensions becomes harder to remove :-). This is even more true, if MC1.5 depends on Kernel-Extensions (but I don't know). > Now, the code may work perfectly fine, and Keith's done a lot of work, but > it's just not community friendly code. A package should have a clear > responsibility, few dependencies, not too many extensions, no overrides if > at all possible, and must install and uninstall cleanly without hosing my > system. If it doesn't meet those criteria, I don't consider it safe to even > experiment with. -- 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)

Sept. 27, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Damien Cassou

On Fri, Sep 26, 2008 at 6:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > can you post the code to load > Sake > Packages > MC1.6 http://installer.pbwiki.com/Packages: Installer install: '311-KernelExtensions'. Installer squeaksource project: 'Sake'; install: 'Sake'. Installer squeaksource project: 'Packages'; install: 'Sake-Packages'. And you will get Sake and Packages. Look at the class PackagesDevU which contains the description of all packages from the dev-universe (it seems it is the new name for PackagesSqueak310U). For MC1.6, I don't know because it does not seem to be released yet. Look at http://installer.pbwiki.com/Monticello16-Beta and ask Keith and Matthew if you are really interested. -- 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)

Sept. 27, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Damien Cassou

On Fri, Sep 26, 2008 at 6:28 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > What is Packages? compared to Sake Keith, please correct me if I'm wrong: - Sake is a domain specific language with all required tools to define make-like rules. It allows people to describe tasks (as done in the Ant/Java world) and execute these tasks when necessary (http://wiki.squeak.org/squeak/5953) - Packages uses Sake to reimplement a universe-like tool with dependencies. Then, it describes a lot of Squeak packages with their dependencies. > What is PackagesSqueak310U....? this is a class which has been generated automatically by a Sake task from the Dev Universe. This means that each change I do in the Universe system is reflected automatically in Sake just by running a task. Moreover, the fact that each package is describe in a method using only Smalltalk code makes creating new set of packages very easy. For Pharo, we could just subclass PackagesSqueak310U and override the methods we want to change. For Seaside, they could just provide yet another class... I think it's much easier than with Universes. Finally, the package descriptions are hosted on SqueakSource instead of one's particular server. -- 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)

Sept. 27, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Damien Cassou

On Fri, Sep 26, 2008 at 6:25 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > On Sep 26, 2008, at 5:03 PM, Damien Cassou wrote: > Did you check what LFP is doing? > I would like to know that. > Because the point is not that it would not be working but what are the stuff > it brings in. http://installer.pbwiki.org/LevelPlayingField LPF is a script which installs Monticello 1.5 and Installer in your image. The aim here is to get an equivalent playing field in all images. This script allowed me to install Universes, OmniBrowser and Shout in a Croquet image in a few minutes. For Pharo, we could have a look at what the script does exactly and integrate the interesting fixes. -- 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)

Sept. 27, 2008

Re: [Pharo-project] Regression testing results within package manifesto

by Alexandre Bergel

The idea is nice. But how will you ensure that your meta-data are well synchronized with your code? Cheers, Alexandre On 27 Sep 2008, at 09:40, StÃ©phane Ducasse wrote: > Hi guys > > For Moose we started to add package manifesto using DrDoc. > We will use the manifesto to document our package with license, > documentation, class diagram... > Now what I would really like to have is the results of SmallLint > rules and the tests > because when I run the tests if some of them were broken I do not > know whether I made progress or not. > > I think that the manifesto could be a nice place to keep such > information. > After we could have a simple manisfesto dropping script > Object allSubclasses do: .... > > what do you think about that, I would like to have a bit more self > documentation and software engineering > meta data within the system. > > Stef > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 27, 2008

[Pharo-project] Regression testing results within package manifesto

by StÃ©phane Ducasse

Hi guys For Moose we started to add package manifesto using DrDoc. We will use the manifesto to document our package with license, documentation, class diagram... Now what I would really like to have is the results of SmallLint rules and the tests because when I run the tests if some of them were broken I do not know whether I made progress or not. I think that the manifesto could be a nice place to keep such information. After we could have a simple manisfesto dropping script Object allSubclasses do: .... what do you think about that, I would like to have a bit more self documentation and software engineering meta data within the system. Stef

Sept. 27, 2008

Re: [Pharo-project] About Flap

by StÃ©phane Ducasse

OK we will go slowly there. One of the problem is that flaps are taking also a cpu On Sep 27, 2008, at 12:27 AM, Gary Chambers wrote: > I quite like the tools flap, when configured for auto-popout and > with "solid" style... > Just my 2c > > Gary. > > > ----- Original Message ----- From: "Igor Stasenko" > <siguctua(a)gmail.com> > To: "An open mailing list to discuss any topics related to an open- > sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, September 24, 2008 8:46 PM > Subject: Re: [Pharo-project] About Flap > > >> 2008/9/24 Marcus Denker <denker(a)iam.unibe.ch>: >>> >>> On 24.09.2008, at 20:14, Bill Schwab wrote: >>> >>>> Lukas, >>>> >>>> That's fine if my hands are on the keyboard, but if I have one on >>>> the >>>> mouse (common when browsing), then (in Dolphin at least), I end up >>>> either right clicking on a class in an open browser, or hitting a >>>> toolbar button. For the more obscure tools, the shell menus >>>> (Tools) do >>>> the trick. Shortcuts are great, but we should also provide mouse- >>>> based >>>> options. >>>> >>> >>> remember: there will be a menu, with a "tools" entry. And there will >>> always be the world-menu (click on the backround). >>> >>> the flap is not faster in the number of clicks than a pulldown >>> menu... >>> >> >> well, with flaps is more convenient because you can drag a tool >> window >> and place it where you want to. >> While from menu - first, it placing a window automatically, and then >> often you need to arrange it again. >> How about putting a window in hand, when you opening it from menu? >> I find it very convenient and useful feature - it gives you chance to >> arrange window with no extra clicks. >> >> >>> Marcus >>> >>> -- >>> Marcus Denker -- denker(a)iam.unibe.ch >>> http://www.iam.unibe.ch/~denker >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 27, 2008