- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About preloaded packages

by StÃ©phane Ducasse

On Jan 8, 2011, at 4:42 PM, Schwab,Wilhelm K wrote: > Stef, > > I'm not sure I follow. I think we agree that loading all configurations and running tests is good. I meant that the configurations do not have to be loaded in the image. > I understand why the web image went away when it took somebody's time time build it, but the Hudson server can do that work now. It seems reasonable to leave a range of targets that might be of value to people. yes now somebody should maintain the configuration and fix conflict. > There could be a few likely useful targets (minimal, dev, web) and then one with absolutely everything that is mostly for testing. But if somebody wants to use that, why not leave it on the server so they can get it? because who maintains if there is a bug due to a conflict. Building the seaside image took lukas time and effort. I'm learned that things do not magically work. So if somebody stands up and say ok I'm responsible for the imageXZK why not and we can set up hudson to build it. Now we (the core minimal team) should spend time on getting the infrastructure right on tracks because this is an enabler of the future. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Saturday, January 08, 2011 10:30 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] About preloaded packages > >> It would also like a PharoBloat image built by Hudson with all ConfigurationOfXXX which are supposed to work on all operating systems. > > Not loaded :) > Just published in the right squeaksource repository and validated (run, tests run and results shown....) via an hudson server. >

Jan. 8, 2011

Re: [Pharo-project] About preloaded packages

by Schwab,Wilhelm K

Stef, I'm not sure I follow. I think we agree that loading all configurations and running tests is good. I understand why the web image went away when it took somebody's time time build it, but the Hudson server can do that work now. It seems reasonable to leave a range of targets that might be of value to people. There could be a few likely useful targets (minimal, dev, web) and then one with absolutely everything that is mostly for testing. But if somebody wants to use that, why not leave it on the server so they can get it? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Saturday, January 08, 2011 10:30 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About preloaded packages > It would also like a PharoBloat image built by Hudson with all ConfigurationOfXXX which are supposed to work on all operating systems. Not loaded :) Just published in the right squeaksource repository and validated (run, tests run and results shown....) via an hudson server.

Jan. 8, 2011

Re: [Pharo-project] About preloaded packages

by Schwab,Wilhelm K

My concern about Metacello has always been that while it is terribly easy to use, it is very potentially difficult to know what to ask it to do. I *think* I have seen signs of improvement and increasing uniformity since I began playing with 1.2. The ConfigurationBrowser probably brought the confusion to light. The ConfiguationBrowser's load latest version command will either force a direct way to do that on all configurations (or at least stand as a reference on how to do it by reflecting on the configuration), but then there is another, bigger, and (I suspect) unsolvable problem: knowing which version to load of any given package. That is a good problem to have (lots of stuff being developed), but we have to acknowledge it. Laurent's Pharo-bloat idea is interesting. While it is not a build target that I would probably want to use, it makes a lot of sense for the Pharo brand to load the latest stable version of just about everything and report on test results. There will still be quirks: when did/does Seaside 3.0 replace 2.8? Of course, one can always start with the core and build anything, but the Pharo Hudson server probably should build things including: (1) recommended Pharo/Pharo-dev - whatever you want to call it, but it's a good starting point for general use; (2) Pharo web, above plus Seaside, Magritte; ... (n) Pharo-package-testing - everything, primarily to see if it builds and to get test results Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Saturday, January 08, 2011 9:00 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About preloaded packages > I would also be rather conservative with regard to adding packages that are not developer tools. > > If we add XML we should probably also add XYZ. Wouldn't it make sense to add Seaside too? The problem here is not primarily the larger image file size, but the image becomes bloated in general (e.g., search results) and there's a risk of conflicts (e.g., we are using the pharo-dev image, but with our own Seaisde 2.9 version; if the image comes with a preinstalled Seaside 3, we couldn't use it anymore). > > It appears to me that preloading packages like XML is just points out that a good package manager is missing. Yes for example moose people get problem because when they load the latest version of XMLsupport on pharodev1.2 the system barks. While pharo-dev (with tools not frameworks) is an ok image to build systems like moose. Stef

Jan. 8, 2011

Re: [Pharo-project] Issue 3224 in pharo: Migrating MethodReference to MethodReferenceWithSource

by pharo＠googlecode.com

Comment #13 on issue 3224 by Benjamin.VanRyseghem.Pharo: Migrating MethodReference to MethodReferenceWithSource http://code.google.com/p/pharo/issues/detail?id=3224 Here are two new change set which fix a little bit the SourceReference API and fix some tests. The order matters. With that, only two error tests left, but I do not know why Attachments: FixingSourceReferenceChangingTimeStampIntoAString.1.cs 4.5 KB FixTestsForSourcedMethodReference.1.cs 2.4 KB

Jan. 8, 2011

Re: [Pharo-project] About preloaded packages

by StÃ©phane Ducasse

> Because we have to fix bug of packages that we do not know, control, want to fix... > Because been agile to load and having a good infrastructure for validating packages is way more > important than preloading XML. If we spend our time on the infrastructure (metacello publication, > configuration certification, hudson reporting) then the complete ecosystem will get better > and you should be able to automate several builds and pharo-dev whatever. > > I'm concerned that our resources are limited and they are a lot of ugly ugly things in the system > Now not everybody should work on them but then the insfrastructure is more important. > > > I agree that we should care about what packages are included in Pharo. But actually for newbies it's still complicated to discover and learn how to load a ConfigurationOfXXX. > > So one goal of Pharo 1.3 should be to have a GUI to load additional tools / libs / frameworks in one click (I've seen there's one included, that's a good step forward, but some work is needed). The tool is already there as torsten mentioned. Now what is missing are configurationOf published in the right squeaksource folders. > For Pharo 1.2 I'd rather leave XML in because today I expect that every programming environment used in enterprise supports XML out of the box. why ruby, python, .... java does it without an import statement? > It would also like a PharoBloat image built by Hudson with all ConfigurationOfXXX which are supposed to work on all operating systems. Not loaded :) Just published in the right squeaksource repository and validated (run, tests run and results shown....) via an hudson server.

Jan. 8, 2011

Re: [Pharo-project] About preloaded packages

by laurent laffont

On Sat, Jan 8, 2011 at 2:59 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Jan 7, 2011, at 5:10 PM, Miguel CobÃ¡ wrote: > > > I concur with Mariano and wonder why StÃ©phane wants a smaller dev image? > > Because we have to fix bug of packages that we do not know, control, want > to fix... > Because been agile to load and having a good infrastructure for validating > packages is way more > important than preloading XML. If we spend our time on the infrastructure > (metacello publication, > configuration certification, hudson reporting) then the complete ecosystem > will get better > and you should be able to automate several builds and pharo-dev whatever. > I'm concerned that our resources are limited and they are a lot of ugly > ugly things in the system > Now not everybody should work on them but then the insfrastructure is more > important. > I agree that we should care about what packages are included in Pharo. But actually for newbies it's still complicated to discover and learn how to load a ConfigurationOfXXX. So one goal of Pharo 1.3 should be to have a GUI to load additional tools / libs / frameworks in one click (I've seen there's one included, that's a good step forward, but some work is needed). For Pharo 1.2 I'd rather leave XML in because today I expect that every programming environment used in enterprise supports XML out of the box. It would also like a PharoBloat image built by Hudson with all ConfigurationOfXXX which are supposed to work on all operating systems. Laurent. > > > > > Right now there are two images, the core and the dev. As the core is > > promoted for deploying, the size of the dev isn't an issue. At least in > > terms of deploying. > > > > Now the dev image is currently targeted to new users, so I think that it > > should have everything that is know to work in Pharo loaded, so that > > the users doesn't have to cope with the installation issue of new > > packages. > > This also means that tutorials and documentation can be straightforward. > > Just showing what they want to teach, and not explaining what to do to > > install some random package. So this will help document and promote > > Pharo. > > > > Now maybe the name dev is misleading. It says development although the > > image is for everyone that is not deploying some application. On the > > other side, there isn't officially a dev image, only PharoCore and > > Pharo. So maybe we need to create a official PharoDev image targeted to > > the developers but this is also very subjective as what packages made a > > development environment, it is upon the developer. So maybe this make no > > sense at all. > > > > So the options are: > > > > 1. Refer to Pharo dev as Pharo, the official name and officially make it > > targeted to new users and so include everything under the sun (like the > > fun images of Edgar, that can show off the capabilities of Pharo) > > 2. Create a PharoDev, with a list of common dev packages, also > > officially supported > > > > TL;DR; Pharo is for new users and should include everything preloaded. > > PharoCore is for deploying and the developer install just what he wants. > > Maybe a PharoDev is needed targeted directly to developers. > > > > Cheers > > -- > > Miguel CobÃ¡ > > http://twitter.com/MiguelCobaMtz > > http://miguel.leugim.com.mx > > > > > > > > > > >

Jan. 8, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

by Peter Hugosson-Miller

+100 :-D -- Cheers, Peter On Sat, Jan 8, 2011 at 3:22 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > What we will do is > > deprecate copyFrom: from Object -> copyStateFrom: > add copyFrom: in Sequenceable > as > self copyFrom: a to: self size > > Stef > >

Jan. 8, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

by StÃ©phane Ducasse

What we will do is deprecate copyFrom: from Object -> copyStateFrom: add copyFrom: in Sequenceable as self copyFrom: a to: self size Stef

Jan. 8, 2011

Re: [Pharo-project] wiki style help

by StÃ©phane Ducasse

Ok I suggest to integrate that in 1.2 because this is important. Now let me open a big can of worms but we truly need it. When you write documentation (I did several experiments with Soup) the documentation in class comment is cool because you to not have to have " and " and '' ' ' '' '" everytimes you manipulate a string or a comment. Now you do not want to have huge class comments I would prefer to have a couple of methods and it does not work: you put back the crappy unnestable " ugly boring.... better not putting comments. So I would really like to have */ this is a nice nestable comment "hkjkhhkjh " 'hkjjkh' 1 + 2 */yet another comment: increbile this is a nested ones: yes you know Smalltalkers are discovering the world/* /* As you see stealing the C comment syntax is a plus because everybody knows it. I remember a discussion on VW about possible syntax to support that. Before replying to this point thing hard because we need that support. Stef On Jan 8, 2011, at 10:15 AM, Alain Plantec wrote: > Hi all, > very cool, thanks Torsten. > Now, I think it's better to wait 1.3 because 1.2 > is almost ready ... > and I would use $! instead of $= as section > marker to keep Pier compatibility. > Cheers > Alain > Le 07/01/2011 14:16, Torsten Bergmann a Ã©crit : >> Hi, >> >> Nice idea, I like the "wiki help description" for three reasons: >> >> - its pragma based AND allows for definition of structured books >> (so Lukas should be satisfied since he can define content >> without dependency on help system) >> >> - it allows us to reuse existing swiki contents >> (if the full syntax is supported we can query existing >> swikis!) >> >> So it is a nice idea and would be a good addition. >> >> >> I reworked Alains code to better fit the pluggable architecture >> of the HelpSystem framework (now using a builder): >> >> Use an updated 1.2 core image, code is attached >> >> 1. File in "Foo.st" (which defines a simple help description) >> => no dependency on any help system >> >> 2. First I added a registration mechanism (pragma<systemHelp> >> so one can add own help types to the system help >> (the one that appears when you open the default help browser) >> >> => load "AddToSystemHelpFix.1.cs" >> => at least this fix should go into Core 1.2, so >> no ugly hacks are necessary to appear in the >> default help browser >> >> I added a now fixed issue for core 1.2 on: >> http://code.google.com/p/pharo/issues/detail?id=3511 >> >> 3. I reworked Alains code so it uses a WikiStyleHelpBuilder >> (similar to the other builders) and a WikiStyleHelp as >> a new help type >> >> => see WikiStyleHelp.5.cs >> => if we agree on this we can integrated it into core too, >> currently it is in an own class category/package >> => "HelpBrowser openOn: WikiStyleHelp" >> will show all contents defined using the wiki style syntax, >> so only the one defined in class Foo appears >> => "HelpBrowser open" >> will show all help in the system (including the ones >> defined in Foo) >> => since it uses the new registration mechanism (see 2. above) >> all these topics will also appear in the help browser >> that is accessible from the menu >> >> I would vote for adding this to core 1.2 too. It's additional, >> nothing should break. What do you all think... >> >> And thanks Alain for the idea and initial code!!! >> >> Have fun >> T. >> >> >> >> >> >> >> > >

Jan. 8, 2011

Re: [Pharo-project] Including Zinc HTTP Components in Pharo 1.2 Dev ?

by StÃ©phane Ducasse

On Jan 7, 2011, at 8:10 PM, Sven Van Caekenberghe wrote: > > On 07 Jan 2011, at 13:58, StÃ©phane Ducasse wrote: > >> I was just reading the code with olivier auverlot. >> I would love to have a small if possible replacement to the HTTPSocket. > > There really is a lot of cleanup to do. Yes. Again infrastructure backbone work. Now since I want to work on/with pharo for a couple of years in the future, we will continue to improve. > The key/core replacement of HTTP client functionality is done, but HTTPSocket does so much stuff in such bizar ways that it will require a concerted effort of many people to clean it up. > > Then again, if Pharo won't do it, who will ? :) Stef

Jan. 8, 2011