- Pharo-dev - lists.pharo.org

[Pharo-project] Issues in mailinglist
by Torsten Bergmann Jan. 7, 2011

Jan. 7, 2011

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

1 0

[Pharo-project] Issues in mailinglist
by Torsten Bergmann Jan. 7, 2011

Jan. 7, 2011

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

1 0

[Pharo-project] Issue 3511 in pharo: Possibility to register own help in system help
by pharo＠googlecode.com Jan. 7, 2011

Jan. 7, 2011

Status: Accepted Owner: Torsten....@astares.de Labels: Milestone-1.2 New issue 3511 by Torsten....@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.

1 2

[Pharo-project] wiki style help
by Alain Plantec Jan. 7, 2011

Jan. 7, 2011

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

3 5

[Pharo-project] SqueakSource is down
by Alain Plantec Jan. 7, 2011

Jan. 7, 2011

1 0

[Pharo-project] tomorrow we will integrate some more fixes...
by StÃ©phane Ducasse Jan. 6, 2011

Jan. 6, 2011

Today people broke our offices (and stole my screens).... so we had to fix doors and other funny admin... So I finally got a chance to finish somehow a research proposals or two and tomorrow this is free hacking (I hope). Stef

2 1

[Pharo-project] Issue 3507 in pharo: SUnitUnloader >> unloadTestPackages is wrong and outdated
by Torsten Bergmann Jan. 6, 2011

Jan. 6, 2011

>I have the following remark: when I implemented this I took care to make all >remaining packages non-dirty. For example, you unload "Regex-Tests-Core" and >this will change the contents of the "Regex" package and hence make it >dirty. To avoid this, I moved tests into their own package â either into >... >Apparently somebody didn't take care when updating VB-Regex because the >tests are back in the main Regex package. Hi Adrian, I dont understand what you mean: Anything we forgot was to update #unloadTestPackages (which is now solved with issue 3507 by Mariano). In Pharo1.2beta #12292 there is no "VB-Regex" or "Regex" package anymore. So nothing to become dirty here. There is a "Regex-Core", "Regex-Help" and "Regex-Tests-Core". So test can easily be unloaded and existing packages are still clean. And yes ... if you would manually create a package "Regex" then it would have become "dirty" (because class categories are abused). But we know that and it can only be solved by introducing real packages. Using a "RegexTest..." package icould be a workaround and avoids this - but we use the same naming scheme as Seaside. Bye T. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

3 3

[Pharo-project] Monticello and source origin
by Torsten Bergmann Jan. 6, 2011

Jan. 6, 2011

When I create a changeset and file it out I can see the image (Pharo/Squeak and version) that was used to create the code in the header. Currently when I find an MCZ somewhere on the web I'm not able to see if Pharo 1.0 or Pharo 1.2 or Squeak 4.1 was used to create it. At least I havent found something when I check "package", "version", "snapshot.bin" or "snapshot"/source in the ZIP. Would'nt it make sense to add something like this? Thx Torsten -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

3 2

[Pharo-project] why (MCPackage named: 'NonExistenPackage') unload. doesnt fail ?
by Mariano Martinez Peck Jan. 6, 2011

Jan. 6, 2011

Do we want that? I am finding a lot of outdated code that uses code like that and it doesnt fail, but still doesnt unload the package. For example, cleanUpForRelease does a (MCPackage named: 'HelpSystem') unload. and that package doesnt exist anymore since it was split.... so...do we want that silent behaviour ? cheers mariano

4 5

Jan. 6, 2011

Hi there, While doing my experiments with SOAP and friends, I've come to the conclusion, I'll redo mainly SOAP because previous implementation is linked to an independent XML representation. I find XMLSupport very nice in design and well documented so I consider it as a basis for implementing SOAP (to me it's a really good example of package as they should be). But there come the design question. To me SOAP elements are particular XMLDocument and XMLElement. Indeed, I found the interfaces of java 6 which was quite what I have in mind [1]. I think the main problem (to me) is that XMLElement in Smalltalk has an inst var containing all children node. I think this is different in java. The consequence is to model SOAPEnvelope (subclass of XMLElement), I can't really add a body and header field respectively for the SOAPHeader and SOAPBody object. Instead I should put them in the children collection node. Is it a good practice ? Do I use a factory to ensure there's at least one and only one body and eventually a header ? Any other pattern for such situations ? Or would you avoid to subclass ? Secondary question: As I found this java API, I got really tempted to use a similar organization. It it authorized ? I couldn't really parse the license file :) Thanks in advance, CÃ©drick [1] http://download.oracle.com/javase/6/docs/api/javax/xml/soap/

3 3