- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3510 in pharo: HistoryNode problem with two consecutives closeGroup

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3510 by marcus.denker: HistoryNode problem with two consecutives closeGroup http://code.google.com/p/pharo/issues/detail?id=3510 12293

Jan. 7, 2011

[Pharo-project] Issues in mailinglist

by Torsten Bergmann

works again, sorry for this post -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Jan. 7, 2011

[Pharo-project] Issues in mailinglist

by Torsten Bergmann

New issues dont seem to appear in the mailinglist/archive anymore: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-January/date.html Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Jan. 7, 2011

Re: [Pharo-project] Issue 3511 in pharo: Possibility to register own help in system help

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3511 by marcus.denker: Possibility to register own help in system help http://code.google.com/p/pharo/issues/detail?id=3511 12293

Jan. 7, 2011

[Pharo-project] wiki style help

by Torsten Bergmann

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. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

Jan. 7, 2011

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

by StÃ©phane Ducasse

BTW it was thinking that the expected a JPEG should be more inadequate mimetype or something else. Stef getImageOfType: mimeType usingParser: parserClass fromUrl: urlObject | url stream request response | url := urlObject asZnUrl. stream := ZnUtils socketStreamToUrl: url. (request := ZnRequest get: url) setAccept: mimeType. response := self executeOneShot: request on: stream. response status = 200 ifFalse: [ ^ self error: 'Expected OK response' ]. response contentType = mimeType ifFalse: [ ^ self error: 'Expected a JPEG' ]. On Jan 7, 2011, at 11:05 AM, 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. 7, 2011

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

by StÃ©phane Ducasse

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. - do you think that some parts of zinc could be reused to implement other protocols such as POP, SMTP, IMAP? Stef On Jan 7, 2011, at 11:05 AM, 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. 7, 2011

Re: [Pharo-project] Issue 3511 in pharo: Possibility to register own help in system help

by pharo＠googlecode.com

Updates: Status: Fixed Cc: stephane.ducasse Comment #1 on issue 3511 by Torsten....(a)astares.de: Possibility to register own help in system help http://code.google.com/p/pharo/issues/detail?id=3511 Here is the fix - we can safely add it to 1.2 since it doesnt break anything. It just queries in a different way. Now a prama <systemHelp> can be used to mark help types that should appear in the standard system help Attachments: AddToSystemHelpFix.1.cs 1.3 KB

Jan. 7, 2011

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

by Adrian Lienhard

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

[Pharo-project] Issue 3511 in pharo: Possibility to register own help in system help

by pharo＠googlecode.com

Status: Accepted Owner: Torsten....(a)astares.de Labels: Milestone-1.2 New issue 3511 by Torsten....(a)astares.de: Possibility to register own help in system help http://code.google.com/p/pharo/issues/detail?id=3511 One can open the help browser on own topics like this HelpBrowser openOn: myTopic But when you open the help browse via menu or "HelpBrowser open" only CustomHelp and subbooks are displayed. Help System should provide a way to register own help types for the default system wide help. I tag this for Pharo 1.2 since it is important to get extensible help.

Jan. 7, 2011