January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About preloaded packages

by StÃ©phane Ducasse

> 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] About preloaded packages

by StÃ©phane Ducasse

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. > > 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] Origins [poll]

by Patrick Barroca

Jan. 8, 2011

Re: [Pharo-project] About preloaded packages

by StÃ©phane Ducasse

On Jan 7, 2011, at 10:51 AM, Mariano Martinez Peck wrote: > > > On Fri, Jan 7, 2011 at 9:16 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >I would favor push metacello so that in one click people can load what they >want. > > You already can. Push the config to the Metacello Repository for 1.2 on > squeaksource.com and use the configuration browser. You can then load > the config or the lates version with a few clicks. > > > yes, but that's not a gurantee that the package will work. You never know if the last version is the correct one in the Pharo image where you are. metacello new version + hudson should fix that. > Dale developed the symbolic versions, definfin, for example, a stable, depending on the pharo version. > I suggest that all projects commited to such repo, has defined such symbolic versions: stable, bleeding edge, blah. > And then, adapt the configuration browser (new buttons?), to load any of those symbolic versions. > > cheers > > mariano > > There are questions left/to discuss ... but at least that works already. > > Bye > T. > > BTW: Squeaksource is down today > -- > NEU: FreePhone - kostenlos mobil telefonieren und surfen! > Jetzt informieren: http://www.gmx.net/de/go/freephone > >

Jan. 8, 2011

Re: [Pharo-project] About preloaded packages

by StÃ©phane Ducasse

> > > -1 > > Sorry, But I don't agree. Who cares the size of a development image? You are not going to deploy it. But we have to do the "oh let us fix this bug" > The less effort for new comers to get what they want, the best. They can click and load. > I would let XMLSupport (and the rest) because: > > 1) If you want to do business, XML is REALLY important. You like it or not (I promise I hate XML). APIs, legacy systems, other systems, etc... > 2) We like it or not, the packages that are included in the dev images are the most known, supported, maintained and tested. > 3) XMLSupport has been asked in the mailing list several times > > I asked which packages to include in the dev image and I never received a negative answer, check: > - http://forum.world.st/Pharo-1-2-default-packages-tp3092206p3092206.html > - http://forum.world.st/Changes-in-external-packages-for-Pharo-1-2-tp2551023p… > > I would agree that XMLSupport is not installed by defaul only when we have out Metacello structure working: repository for an specific pharo version, stable versions (symbolic versions), self contained (copy all mzc), and finally the Loader to load them. Once we have that, and once that searching and installing Metacello projects is really easy, I would start removing some packages from the dev image. > > Cheers > > mariano

Jan. 8, 2011

Re: [Pharo-project] Announcements in core images?

by StÃ©phane Ducasse

>From our side announcements are really important and should replaced a lot of events. On Jan 7, 2011, at 7:44 PM, Janko MivÅ¡ek wrote: > Hi both Squeakers and Pharoers, > > What is a status of Announcements package as part of core images? Are > they already there and, are they compatible, and if not, what are the > differences? > > Announcements are namely very important and elegant way of event > notifications based on publish/subscribe pattern. And they are portable, > which is very important for us, doing cross platform frameworks like > Aida, Seaside, etc. > > Therefore I'd really like to see Announcements included in all > Smalltalks by default and at least on API level as same as possible. > > Best regards > Janko > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

Jan. 8, 2011

Re: [Pharo-project] About using pragma for help like in setting

by StÃ©phane Ducasse

On Jan 7, 2011, at 5:22 PM, Torsten Bergmann wrote: > Dont confuse this, marking with <systemHelp> does not > mean you mark a method that returns a string and it > magically appears in the system help. > > This pragma is used to mark "help types" that should be > included in the SystemHelp. Classes marked with this > pragma are converted to to a help topic (#asHelpTopic) > and using subtopics for SystemHelp. > > This allows to easily "register" own help types like the > WikiStyleHelp. So this pragma is for people WHO WISH TO > EXTEND the help system itself (for new syntaxes, new help > contents sources, ... without patching it). > > This pragma is NOT FOR END USERS who want to write help contents. > > There is no difference since issue #3511 is integrated since > CustomHelp is the only provider of <systemHelp> so for. > Anything thats changed is the way SystemHelp (which is used > as default in HelpBrowser) queries for its roots. > > If you load the WikiStyleHelp you have another provider > of system help. > > Your scenario is different: > =========================== > - you want to write help contents that should load > in 1.1. and 1.2 and display at least in 1.2 > > > If it is OK for you to have a special help package > with the dependency on the help framework: > => use a CustomHelp subclass since this is supported in > 1.1. and 1.2 (loads and displays in both) > > If this (dependency) is a "no-go" then describe it using > the <wikiStyle> pragma do you have an example? HelpSystem looks too complex for me > > => it is loadable in both, but not displayed in both > => it will only appear in 1.2 if we either integrate > "WikiStyleHelp" into core or dev image or you load > the wiki style help extension it with your soup config > > Thats why I would like to see Alains idea pushed into 1.2. > (either as part of Help system in 1.2-core or as an help > extension package in 1.2-dev). which idea?

Jan. 8, 2011

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

by Nicolas Cellier

2011/1/7 <csrabak(a)bol.com.br>: > > I will take this as meaning "I agree that Object>>copyFrom: is ambiguous..." > > If I misunderstood you, please feel free to correct. > > OTHO, as it is not explicitly written, I would like to understand your > stance on having this method name as a shorcut to > copyFrom: start to: (self size). > I don't think it's a good idea for backward compatibility reasons. Changing the semantics of #copyFrom: is worse than just deprecating the message. Do we really need this message ? For porting a package from another dialect ? > > I do agree 100% on this. Â However, there is a rub: > > aComplicatedName copyFrom: pocnu to: kraja. > > What can they be? Â As Smalltalk is dynamic even if you could see the > > |pocnu kraja| > . > . > . > you'll probably would need to see the implementers of the code that attribute > values to these (say) local variables. > Of course, one can always obfuscate its code, and the naming of these variable is well chosen with this respect. > > Again I think this is a reasoning that only can be explained due being > too comfy in our crib: > > Put this stub of code in a book (especially if the dead tree variety) and > claim that it is only a 'browsing of sender' away and you will understand > WHY the whole thread is not that much "ubuesque" as it seemed at first... > We can perfectly write a book explaining these selectors. Just group the selectors (copy copyFrom:to: etc..), explain copy vs partial copy, and explain theses selectors are in the ANSI standard API. Then group the selectors (first, first: etc..), explain that they are extensions, and don't need a copy prefix, because anyway most messages will do a copy. > > The semantics of copyFrom:to: are not the issue. The issue as is written > in the issue tracker _and_ the subject line is the semantics of copyFrom: > Agree, but i was seeing this thread derivate a bit. >> Â So no, Â I don't Â need to Â add a Â copy prefix Â to this >> message, and no i don't really care for a higher homogeneity. >> Â If we change Â a few missnamed selectors here Â and there, that's OK, >> but Â if Â we change Â a Â large amount Â of Â Kernel Â messages with Â many >> senders, it's a Â recipee for Pharo rejection, because Â we would make >> developer's life a hell for no valid reason. > > Or not! There is no reason why a newer "kernel" be created and if the usage > of it be so compelling or productive or practical or ....<put your favorite > marketing word> that it takes over the present state of affairs in the > usage of Smalltalk, why not!? > Well, we have to balance pros and cons of changing, especially in the kernel. > -- > Cesar Rabak > >

Jan. 8, 2011

Re: [Pharo-project] Adding hudson links from pharo webpage?

by Mariano Martinez Peck

On Fri, Jan 7, 2011 at 10:41 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > I would not have thought to put it there, but it's a good idea. I think > there should also be a link on the download section?? > > Exactly. THis is why I didn't even check in Community. It would have a section under download or something like this. Cheers Mariano > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Tudor Girba [ > tudor.girba(a)gmail.com] > Sent: Friday, January 07, 2011 1:53 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Adding hudson links from pharo webpage? > > Currently, the link is here: > http://pharo-project.org/community > > Cheers, > Doru > > > On 7 Jan 2011, at 19:22, Mariano Martinez Peck wrote: > > > Now that hudson seems to be working fine, I think it is a good moment to > link hudson links from the pharo website. > > > > cheers > > > > mariano > > -- > www.tudorgirba.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > > >

Jan. 8, 2011

Re: [Pharo-project] wiki style help

by Alain Plantec

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