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

Re: [Pharo-project] next irc meeting: Thursday 13 at 21h

by Alexandre Bergel

Ok for me Alexandre On 7 Jan 2011, at 05:11, StÃ©phane Ducasse wrote: > Hi guys > > Let us know if this is ok and that we broadcast it. > > the channel is #pharo-project on irc.freenode.net. If you don't have an IRC client you can browse to > http://webchat.freenode.net/?channels=pharo-project > http://www.timeanddate.com/counters/customcounter.html?day=13&month=1&year=… > > Stef -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 7, 2011

Re: [Pharo-project] About preloaded packages

by Schwab,Wilhelm K

+1 (and Hudson is a great way to build the various targets). ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Friday, January 07, 2011 5:38 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About preloaded packages A lot of work goes into building Dev and it constitutes a really useful baseline of tested code which is very important to how other perceive Pharo. Maybe there could be more than one Dev version ? Sven

Jan. 7, 2011

Re: [Pharo-project] About preloaded packages

by Schwab,Wilhelm K

I really liked the web image of the early days and would like to see Hudson build something similar for us. First, the servers required for loading various packages are not always alive. Having Hudson grabbing things would: (1) monitor the servers' health for us (if builds succeed, they are ok); (2) prevent all of our have to individually load things, reducing the load on the servers and probably helping to ensure correct selection of versions in the images that are built. With Hudson making lean, full dev and Seaside images (maybe others), each of us could choose between pre-built or home-grown images. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Johan Brichau [johan(a)inceptive.be] Sent: Friday, January 07, 2011 5:17 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About preloaded packages Hi Mariano, I'm not (really) concerned with image size. As a user of Pharo, I would expect that a Pharo dev image includes plenty of development tools and an easy way of loading external libraries (such as XML, Seaside, Glorp,....). With the advent of metacello, we now have an easy loading mechanism for external libraries such that, to me, it's strange to see those libraries being deployed in a dev image of Pharo. Even a development image should be a base to start from. But I would like to see a lot of development tools pre-loaded. Pharo is already doing a good job at that, btw, unlike Visualworks where the syntax highlighter and many other useful development packages are add-ons. Explaining that syntax highlighting is an external library to load is something new students always were amazed about when I exposed them to Smalltalk... > 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... Then again, database functionality is probably even more crucial than XML for any business app. My point is: if you need an XML library: you can load it. oh, and, not all business requires XML (lucky me ;-) > 2) We like it or not, the packages that are included in the dev images are the most known, supported, maintained and tested. So... Glorp and Seaside too? I'm overstating.... but there are so many good and useful packages out there that is seems strange to include some and others not. > 3) XMLSupport has been asked in the mailing list several times Well, it's not because people ask that it's a good thing. This also applies to my own mail, btw :-)) (it's just my opinion) > 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. I see your point, but XML is really easily installable already. But hey, I'm just expressing my opinion here and sorry that I did not react to any previous email (it's a bit too much for me). cheers, Johan

Jan. 7, 2011

Re: [Pharo-project] About preloaded packages

by Esteban Lorenzano

+1 "but" I really would include Metacello Browser (or a modified version adapted for us) in the image... Cheers, Esteban El 07/01/2011, a las 5:05a.m., StÃ©phane Ducasse escribiÃ³: > Hi guys > > I would really like that pharo-dev does not contain too many libraries pre loaded (for example XMLSupport). > I would favor push metacello so that in one click people can load what they want. > > Stef

Jan. 7, 2011

Re: [Pharo-project] About preloaded packages

by Geert Claes

To answer this question you actually need to know who pharo-dev is targeted at and what they expect from it. I reckon pharo-dev should come with the core bells-and-whistles the Pharo project would like to showcase, so yes do include the Seaside, XML etc in pharo-dev so newbies don't have to worry about finding out what to load from where to do things they expect to be included. Those who want a clean images and only load what they need can always start from the pharo (core) image. -- View this message in context: http://forum.world.st/About-preloaded-packages-tp3178755p3178953.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 7, 2011

Re: [Pharo-project] About preloaded packages

by Sven Van Caekenberghe

On 07 Jan 2011, at 11:17, Johan Brichau wrote: > I'm not (really) concerned with image size. > > As a user of Pharo, I would expect that a Pharo dev image includes plenty of development tools and an easy way of loading external libraries (such as XML, Seaside, Glorp,....). > With the advent of metacello, we now have an easy loading mechanism for external libraries such that, to me, it's strange to see those libraries being deployed in a dev image of Pharo. > > Even a development image should be a base to start from. But I would like to see a lot of development tools pre-loaded. Pharo is already doing a good job at that, btw, unlike Visualworks where the syntax highlighter and many other useful development packages are add-ons. Explaining that syntax highlighting is an external library to load is something new students always were amazed about when I exposed them to Smalltalk... Advanced users, such as most people on this list, will construct their own images based on either Core or Dev, I guess. So the main target is people starting out or other checking out pharo. Loading big packages such as Seaside or Glorp takes some time and is not always easy. So there is definitively value in having things preloaded. A lot of work goes into building Dev and it constitutes a really useful baseline of tested code which is very important to how other perceive Pharo. Maybe there could be more than one Dev version ? Sven

Jan. 7, 2011

Re: [Pharo-project] About preloaded packages

by Johan Brichau

Hi Mariano, I'm not (really) concerned with image size. As a user of Pharo, I would expect that a Pharo dev image includes plenty of development tools and an easy way of loading external libraries (such as XML, Seaside, Glorp,....). With the advent of metacello, we now have an easy loading mechanism for external libraries such that, to me, it's strange to see those libraries being deployed in a dev image of Pharo. Even a development image should be a base to start from. But I would like to see a lot of development tools pre-loaded. Pharo is already doing a good job at that, btw, unlike Visualworks where the syntax highlighter and many other useful development packages are add-ons. Explaining that syntax highlighting is an external library to load is something new students always were amazed about when I exposed them to Smalltalk... > 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... Then again, database functionality is probably even more crucial than XML for any business app. My point is: if you need an XML library: you can load it. oh, and, not all business requires XML (lucky me ;-) > 2) We like it or not, the packages that are included in the dev images are the most known, supported, maintained and tested. So... Glorp and Seaside too? I'm overstating.... but there are so many good and useful packages out there that is seems strange to include some and others not. > 3) XMLSupport has been asked in the mailing list several times Well, it's not because people ask that it's a good thing. This also applies to my own mail, btw :-)) (it's just my opinion) > 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. I see your point, but XML is really easily installable already. But hey, I'm just expressing my opinion here and sorry that I did not react to any previous email (it's a bit too much for me). cheers, Johan

Jan. 7, 2011

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

by Sven Van Caekenberghe

Hi, Maybe I am a bit late with this question, I also don't know who makes the decision, and it is probably external people who have to make the judgement, but would it be possible and/or a good idea to include Zinc HTTP Components into Pharo 1.2 Dev ? In any case, the code is in good shape, works on 1.2, has a reasonable number of tests, has comments, is pretty small and elegant. Whether or not to load the Zinc-Patch-HTTPSocket package is another question. This package patches (destructively overwrites) class methods in HTTPSocket, redirecting them to ZnHTTPSocketFacade, effectively steering all HTTP client access in your Smalltalk image through Zinc HTTP Components. This has been working for me for months, but my usage is certainly not universal. So maybe this should remain an option. I would especially like to expose this code to more people to get more feedback. I am also willing to keep on supporting the code. What do you think ? Sven

Jan. 7, 2011

Re: [Pharo-project] About preloaded packages

by Mariano Martinez Peck

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. 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. 7, 2011

Re: [Pharo-project] wiki style help

by Mariano Martinez Peck

Cool Alain :) I like it. Maybe in a future we are able to generate different outputs with the same source :) mariano On Fri, Jan 7, 2011 at 7:40 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Nice. > > Doru > > > On 7 Jan 2011, at 07:33, Alain Plantec wrote: > > > I've changed the section start character from $= to $! as in Pier. > > Now, such a help text can be compatible with the pier parser. > > Cheers > > Alain > > > > Le 07/01/2011 00:08, Alain Plantec a Ã©crit : > >> Le 06/01/2011 23:55, Tudor Girba a Ã©crit : > >>> That's cool, but why not use the Pier model/parser? > >> not against except that it would depend on other packages. > >> it implies that it would not be possible for the core. > >> this implementation is only made of an additional class with 3 methods. > >> at least one could use the pier syntax for declaring sections > >> Cheers > >> Alain > >>> Cheers, > >>> Doru > >>> > >>> > >>> On 6 Jan 2011, at 23:33, Alain Plantec wrote: > >>> > >>>> Hello! > >>>> I've prototyped a small addon for the help system. > >>>> It allows the using of formatted text "a la wiki" > >>>> for editing help pages. > >>>> help pages are retrieved thanks to a pragma. > >>>> In order to write an help, only 2 steps > >>>> > >>>> * Step1: You edit you help as follow: > >>>> = Introduction > >>>> Your intro here > >>>> = Section 1 > >>>> bla bla > >>>> == Section 1.1 > >>>> blo blo blo > >>>> === Subsubsection 1.1.1 > >>>> =Section 2 > >>>> == Section 2.1 > >>>> =Conclusion > >>>> > >>>> * Step 2: then you implement a method with a pragma > >>>> that return the formatted string: > >>>> Here, the help is in the comment of the class. > >>>> > >>>> SomeClass class>>help > >>>> <wikiStyleHelp: #'A wiki style help example'> > >>>> ^ self comment > >>>> > >>>> ... and you have your help (see screenshot) > >>>> > >>>> You also can use only a subpart of a comment by using a tag. > >>>> <help> > >>>> you wiki style comments here > >>>> </help> > >>>> > >>>> It is very simple and it allows the using of comments (less help > duplication ?). > >>>> Concerning the builder approach, maybe we don't > >>>> need it because we can use text markup. > >>>> > >>>> try it with HelpSystem-Core-AlainPlantec.69 in PharoTaskForces > >>>> It works. > >>>> not documented > >>>> no tests > >>>> > >>>> Cheers > >>>> Alain > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> <wikiStyleHelp.png> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Speaking louder won't make the point worthier." > >>> > >>> > >> > >> > > > > > > -- > www.tudorgirba.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > > >

Jan. 7, 2011