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

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

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