[Pharo-project] Thinking about Pharo distribution
Hi, I've just started writing a wiki page which details the packages we plan to install in all Pharo distributions. In the Universe, the meta-package 'Pharo packages' permit easy installation of these packages. The wiki page is at: http://code.google.com/p/pharo/wiki/Packages. Please tell me what you think -- 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)
Damien Cassou wrote:
Hi,
I've just started writing a wiki page which details the packages we plan to install in all Pharo distributions. In the Universe, the
All or developer?
meta-package 'Pharo packages' permit easy installation of these packages. The wiki page is at: http://code.google.com/p/pharo/wiki/Packages.
The list is way to long, I don't use any of these packages and I wouldn't want to see them in a "base" image. Michael
On Mon, Sep 15, 2008 at 5:36 PM, Michael Rueger <m.rueger@acm.org> wrote:
Damien Cassou wrote:
I've just started writing a wiki page which details the packages we plan to install in all Pharo distributions. In the Universe, the
All or developer?
We plan to release 2 versions of Pharo: - a pharo-core, dedicated to Pharo developers - a pharo-dev, dedicated to Pharo users Here, I'm talking about pharo-dev. Contrary to squeak-dev, pharo-dev will be official, this will be the public download by default whereas pharo-core will be hidden in the web pages.
meta-package 'Pharo packages' permit easy installation of these packages. The wiki page is at: http://code.google.com/p/pharo/wiki/Packages.
The list is way to long, I don't use any of these packages and I wouldn't want to see them in a "base" image.
You want neither syntax highlighting, nor code completion, nor refactoring tools? Then, you'd probably better stick with pharo-core :-) -- 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)
On 15.09.2008, at 17:36, Michael Rueger wrote:
Damien Cassou wrote:
Hi, I've just started writing a wiki page which details the packages we plan to install in all Pharo distributions. In the Universe, the
All or developer?
I think it is *extremely* important to only have one download. Having pharo nicely bug-free and with green tests is useless if every users of it then uses another image. In addition, I don't want a system where we need to explain "which image to use?". On Pharo-Project, there will be *one* download, and it will be a one- click image.
meta-package 'Pharo packages' permit easy installation of these packages. The wiki page is at: http://code.google.com/p/pharo/wiki/Packages.
The list is way to long, I don't use any of these packages and I wouldn't want to see them in a "base" image.
It's not that bad... shout, e-completion, refactoring-engine and OmniBrowser. The Regex will be in Pharo anyway (it's one of the big mistakes of Smalltalk to not bring a standard regexp, the result are many hard to understand methods parsing strings in the base system... and no standard for developers) If you look at younger people, e.g the students, they are used to Eclipse. Refactoring, code completion and syntax highlighting are for them not optional. For them this is what an IDE does, there is no question about that. I think not providing that would be the wrong way to go. As for size: Most code in Sqeueak are abandoned experiments that nobody uses, if we clean up, we have a lot of space to grow for stuff that actually is useful. Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
I agree. Now I would really to see how we can integrate that. For example - overrides out - and removing duplicated functionality (AST once we get the new compiler). Stef
I think it is *extremely* important to only have one download.
Having pharo nicely bug-free and with green tests is useless if every users of it then uses another image. In addition, I don't want a system where we need to explain "which image to use?".
On Pharo-Project, there will be *one* download, and it will be a one- click image.
meta-package 'Pharo packages' permit easy installation of these packages. The wiki page is at: http://code.google.com/p/pharo/wiki/Packages.
The list is way to long, I don't use any of these packages and I wouldn't want to see them in a "base" image.
It's not that bad... shout, e-completion, refactoring-engine and OmniBrowser. The Regex will be in Pharo anyway (it's one of the big mistakes of Smalltalk to not bring a standard regexp, the result are many hard to understand methods parsing strings in the base system... and no standard for developers)
If you look at younger people, e.g the students, they are used to Eclipse. Refactoring, code completion and syntax highlighting are for them not optional. For them this is what an IDE does, there is no question about that.
I think not providing that would be the wrong way to go.
As for size: Most code in Sqeueak are abandoned experiments that nobody uses, if we clean up, we have a lot of space to grow for stuff that actually is useful.
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 2008-09-15 at 17:49 +0200, Marcus Denker wrote:
On 15.09.2008, at 17:36, Michael Rueger wrote:
Damien Cassou wrote:
Hi, I've just started writing a wiki page which details the packages we plan to install in all Pharo distributions. In the Universe, the
All or developer?
I think it is *extremely* important to only have one download.
Having pharo nicely bug-free and with green tests is useless if every users of it then uses another image. In addition, I don't want a system where we need to explain "which image to use?".
On Pharo-Project, there will be *one* download, and it will be a one- click image.
meta-package 'Pharo packages' permit easy installation of these packages. The wiki page is at: http://code.google.com/p/pharo/wiki/Packages.
The list is way to long, I don't use any of these packages and I wouldn't want to see them in a "base" image.
It's not that bad... shout, e-completion, refactoring-engine and OmniBrowser. The Regex will be in Pharo anyway (it's one of the big mistakes of Smalltalk to not bring a standard regexp, the result are many hard to understand methods parsing strings in the base system... and no standard for developers)
If you look at younger people, e.g the students, they are used to Eclipse. Refactoring, code completion and syntax highlighting are for them not optional. For them this is what an IDE does, there is no question about that.
I think not providing that would be the wrong way to go.
As for size: Most code in Sqeueak are abandoned experiments that nobody uses, if we clean up, we have a lot of space to grow for stuff that actually is useful.
These are all good points. One of my biggest concerns is code compatibility. I used enhanced images and developed web applications. Often I used a method that came with the enhancements and that failed when I tried to deploy them in my base image. Then I stopped using the enhancement images and stuck to the basic ones. Is there a good way to solve this? Norbert
These are all good points. One of my biggest concerns is code compatibility. I used enhanced images and developed web applications. Often I used a method that came with the enhancements and that failed when I tried to deploy them in my base image. Then I stopped using the enhancement images and stuck to the basic ones. Is there a good way to solve this?
Integration: ie looking at the extensions made by the packages and identify the ones that should be moved in the core and not. This is unavoidable. Stef
I think it is *extremely* important to only have one download.
hmm, yes and no. Wasn't one of the longer term goals of Pharo to provide a small as possible core image on which everything else can be bootstrapped?
Yes it is! But not at the price to say that pharo is a subset. I think that modularity is one aspect and we should be able to have ***packages*** that coexist and are well designed to coexist. What marcus implies is that well factored code and tested should be modular and the infrastructure should support the modular definition of the system. So changes like better support in terms of notification, no etoy plague, no bookMorph plague should help making the system more manageable. May be at the end we will need a module system. Stef
here my 2 cents... On Sep 15, 2008, at 17:49 , Marcus Denker wrote:
I think it is *extremely* important to only have one download.
I agree that we should make it clear what to start with (obviously the dev distribution). The list of packages seems ok to me, except for Regex.
Having pharo nicely bug-free and with green tests is useless if every users of it then uses another image. In addition, I don't want a system where we need to explain "which image to use?".
But this does not exclude the possibility to have instructions on the web page that explain how to use Pharo in a production setting, right? On this page we would of course point to the download of the core image (among other stuff like GC parameter settings, preferences). Adrian
On Mon, Sep 15, 2008 at 9:45 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
I agree that we should make it clear what to start with (obviously the dev distribution). The list of packages seems ok to me, except for Regex.
What is your problem with Regex? -- 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)
Damien Cassou wrote:
On Mon, Sep 15, 2008 at 9:45 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
I agree that we should make it clear what to start with (obviously the dev distribution). The list of packages seems ok to me, except for Regex.
What is your problem with Regex?
See, that was exactly my point ;-) People prefer different sets of stuff in their image. What Pharo could deliver, would be a small core image, then a couple of approved/tested packages or package combinations that are easy to load into the core. And as a service to new developers we could offer the full blown developer image. One thing that makes Squeak difficult, even for me, is that you never have a place to go to when you want an image and a set of packages that are known to work. Usually you end up having to ask on the mailing list which combination of packages and patches work. Like in the old Linux days before Ubuntu. Btw, Eclipse does the same thing, you have the Eclipse core, add on language packages but also pre-packaged, complete environments. Michael
On Sep 16, 2008, at 07:13 , Damien Cassou wrote:
On Mon, Sep 15, 2008 at 9:45 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
I agree that we should make it clear what to start with (obviously the dev distribution). The list of packages seems ok to me, except for Regex.
What is your problem with Regex?
I think it should either be in core (as Marcus argues) or in no distro. The reason is that this is not a development tool but will be used as a library. Then if you deploy using the core distro, you have to load it anyway. And if we start to add Regex, why not also adding an XML parser? and package XYZ? So we end up accumulating libraries that blow up the image even if they are used only by few people. I'd like to control myself, which packages to make part of the application. Adrian
No this is something else. Look at all the crap in match: and other. I do not think that regex is so large that it is a problem. There are so much other totally ***useless** things in the image that something useful would be really good. What we can do: is give it a try we do not have to be perfect the first time. Having a vision and path to achieve it should not hamper us to try and learn. Look at the use of MC :) Stef
On Sep 16, 2008, at 07:13 , Damien Cassou wrote:
On Mon, Sep 15, 2008 at 9:45 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
I agree that we should make it clear what to start with (obviously the dev distribution). The list of packages seems ok to me, except for Regex.
What is your problem with Regex?
I think it should either be in core (as Marcus argues) or in no distro. The reason is that this is not a development tool but will be used as a library. Then if you deploy using the core distro, you have to load it anyway. And if we start to add Regex, why not also adding an XML parser? and package XYZ? So we end up accumulating libraries that blow up the image even if they are used only by few people. I'd like to control myself, which packages to make part of the application.
Adrian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, maybe you misunderstood me. I don't argue against putting it into core... But I think it does not make a lot of sense in dev. Only if it is in core, methods like #match: can use it. Adrian On Sep 16, 2008, at 08:54 , Stéphane Ducasse wrote:
No this is something else. Look at all the crap in match: and other. I do not think that regex is so large that it is a problem. There are so much other totally ***useless** things in the image that something useful would be really good. What we can do: is give it a try we do not have to be perfect the first time. Having a vision and path to achieve it should not hamper us to try and learn. Look at the use of MC :)
Stef
On Sep 16, 2008, at 07:13 , Damien Cassou wrote:
On Mon, Sep 15, 2008 at 9:45 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
I agree that we should make it clear what to start with (obviously the dev distribution). The list of packages seems ok to me, except for Regex.
What is your problem with Regex?
I think it should either be in core (as Marcus argues) or in no distro. The reason is that this is not a development tool but will be used as a library. Then if you deploy using the core distro, you have to load it anyway. And if we start to add Regex, why not also adding an XML parser? and package XYZ? So we end up accumulating libraries that blow up the image even if they are used only by few people. I'd like to control myself, which packages to make part of the application.
Adrian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I agree. Now we can also late bound core boundary. :) I really believe that we should learn. If tomorrow somebody come up with a really nice integration of the package then it can be really core. Stef On Sep 16, 2008, at 9:02 AM, Adrian Lienhard wrote:
Stef, maybe you misunderstood me. I don't argue against putting it into core... But I think it does not make a lot of sense in dev. Only if it is in core, methods like #match: can use it.
Adrian
On Sep 16, 2008, at 08:54 , Stéphane Ducasse wrote:
No this is something else. Look at all the crap in match: and other. I do not think that regex is so large that it is a problem. There are so much other totally ***useless** things in the image that something useful would be really good. What we can do: is give it a try we do not have to be perfect the first time. Having a vision and path to achieve it should not hamper us to try and learn. Look at the use of MC :)
Stef
On Sep 16, 2008, at 07:13 , Damien Cassou wrote:
On Mon, Sep 15, 2008 at 9:45 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
I agree that we should make it clear what to start with (obviously the dev distribution). The list of packages seems ok to me, except for Regex.
What is your problem with Regex?
I think it should either be in core (as Marcus argues) or in no distro. The reason is that this is not a development tool but will be used as a library. Then if you deploy using the core distro, you have to load it anyway. And if we start to add Regex, why not also adding an XML parser? and package XYZ? So we end up accumulating libraries that blow up the image even if they are used only by few people. I'd like to control myself, which packages to make part of the application.
Adrian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (6)
-
Adrian Lienhard -
Damien Cassou -
Marcus Denker -
Michael Rueger -
Norbert Hartl -
Stéphane Ducasse