- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

On Jan 7, 2011, at 8:07 PM, Sven Van Caekenberghe wrote: > I was in meeting all day, hence the late reply. > > On 07 Jan 2011, at 14:08, StÃ©phane Ducasse wrote: > >> Sven >> >> two questions: >> - if we want to use zn for pharo to replace HTTPSocket, don't you think that Zinc-HTTP-Client-Server should be split into pieces. > > I don't think that would make a lot of sense: HTTP is a client-server protocol, the client and server sides have a lot in common; a split in three pieces would be possible but each piece would be rather small. Having the necessary pieces for a simple HTTP server present will lower the bar for others, so that makes sense too. (For example, the Seaside adaptor is really very little code, no more need for Kom unless you really want it). Ok I was just thinking in them of what shoud we add to pharo-core to get mcz with http working > >> - do you think that some parts of zinc could be reused to implement other protocols such as POP, SMTP, IMAP? > > Maybe, finding shared code can only be done by doing both implementations I'm afraid ;-) I will let olivier looking at your code and playing with his ideas and see what comes out. > > Another, related point is the following: maybe you noticed browsing the code that I have a number of classes in Zn that redo some standard functionality (ZnMimeType, ZnUrl, ZnCharacterEncoder, and some of the code in the utils classes), a bit like Seaside does. The reason is that the existing classes were broken beyond repair (IMHO), or that I was not confortable extending them. I agree. > Now, if the existing classes could be improved/replaced, it would make sense to replace the Zn variant with a good system wide one. This is a search for the best solution. Yes this is great.

Jan. 8, 2011

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

by StÃ©phane Ducasse

On Jan 7, 2011, at 2:02 PM, Adrian Lienhard wrote: > Hi Sven, > > +1 for Pharo 1.2 (the dev image) > -1 for patching HTTPSocket (dev packages should not modify core code) > > For 1.3 we should think about integrating Zinc in PharoCore to replace HTTPSocket. Yes! > > Cheers, > Adrian > > > On Jan 7, 2011, at 11:05 , Sven Van Caekenberghe wrote: > >> 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. 8, 2011

Re: [Pharo-project] announcements and weak references

by StÃ©phane Ducasse

let us know. > Thanks. > > I will take a look. > > Cheers, > Doru > > > On 7 Jan 2011, at 18:08, Lukas Renggli wrote: > >> As far as I remember my announcement implementation uses ActionSequence to represent the actions of an event. You just have to replace these with WeakActionSequence to get the desired behavior. >> >> Lukas

Jan. 8, 2011

Re: [Pharo-project] announcements and weak references

by StÃ©phane Ducasse

Yes This is on our plate....I would like igor to have a look at all the weak stuff and after Annoucements > Hi, > > Are there any plans to get Announcements use weak references? > > I saw that in the repository of Lukas, there is a WeakAnnouncer. However, here the subscriptions are still held in a regular Dictionary. > > Actually, I am not sure what is the status of weak references. I tried the following, but it does not seem to work: > > | x array | > x := GLMPane new. > array := WeakArray with: x. > x := nil. > Smalltalk garbageCollect. > array size > > ==> 1 > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > >

Jan. 8, 2011

Re: [Pharo-project] Origins [poll]

by S Krish

Jan. 8, 2011

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