March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo help (was About danny help :)

by Danny Chan

Hi Torsten! I am the first to acknowledge that this is your project. And I am also the first one to admit that my code is not great, being a beginner with Smalltalk in the first place, not being a software developer secondly (I develop optical systems in my day job), and playing with software only in my spare time (which will be certainly much less in the future, because I just got a brand new daughter). So please see my contributions more as sketches of the functionality that might be nice to have in a help system, rather than a real implementation. I am completely happy if people get a rough idea of what might be desireable, and then throw away the whole mess I've made and do it right! So please, scrap the stuff and implement it cleanly, because only by seeing what you are doing with the code I am learning. Cheers, Danny

March 6, 2010

Re: [Pharo-project] Pharo help (was About danny help :)

by laurent laffont

> > > >For the UML I would like to have a simple sccripting descriptoin so that > we can >define it. > > Do you know yuml.me? > http://yuml.me/diagram/class/class/[Collection],[Collection]-[CharacterSet] > > The interesting thing is that we can even built this into the help browser > today using HTTP and images - but one has to be online. > > However ... first I want to get the right infrastructure. More coming soon. > I wanted to try it .... but time missing for me now. I use yuml.me for http://magaloma.seasidehosting.st/ , select a package then click on "Inheritance diagram". You can load it, package SimpleWebDoc on squeaksource.You can look at SWYumlMe and SWYumlInheritanceDiagramTest classes. Laurent Laffont > > If one wants to help: create a good HTML viewer based on the reworked > Scamper (see http://www.squeaksource.com/LaurentLSandbox.html) > > Bye > T. > > > > > -- > Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - > jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 6, 2010

[Pharo-project] Pharo help (was About danny help :)

by Torsten Bergmann

Stef wrote: >I noticed it :) So I renamed the topic ;) >we are not in rush. Good. I trimmed the model down this evening to just one class and even the help browser is now much more flexible (already displaying static and dynamic help) >But I'm pragmatic. > - how to we fill up the help With the new simpler model you will be able to easily transform various sources ... for instance I think on even getting RSS feeds, IRC, list archive ... included by loading additional packages. I'm sure we will get more ideas once this all works. >For the UML I would like to have a simple sccripting descriptoin so that we can >define it. Do you know yuml.me? http://yuml.me/diagram/class/class/[Collection],[Collection]-[CharacterSet] The interesting thing is that we can even built this into the help browser today using HTTP and images - but one has to be online. However ... first I want to get the right infrastructure. More coming soon. If one wants to help: create a good HTML viewer based on the reworked Scamper (see http://www.squeaksource.com/LaurentLSandbox.html) Bye T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

March 6, 2010

[Pharo-project] Scratch Viewer comes to the iPhone

by John M McIntosh

Scratch Viewer comes to the iPhone http://mobilewikiserver.com/Scratch.html Yes I'm building an iPad version too. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 5, 2010

Re: [Pharo-project] About danny help :)

by StÃ©phane Ducasse

On Mar 5, 2010, at 9:25 PM, Torsten Bergmann wrote: > Stef wrote: >> Hi danny >> >> I would like to integrate your help system in pharo so we will have see how we can proceed. >> ... >> Yes this is good for my ego :))) > > Hey, hey ... and it is not good for my ego if you keep saying it is danny's help system! Ever looked > at the project and code? ;) ;) I noticed it :) > While I appreciate that Danny wants to contribute to the project I think his changes are not > aligned with the original goals, design and ideas. > > First and most important: I want a simple model for the help system, which I first provided as > > HelpTopic > HelpBook > HelpPage > > after Danny's changes the baseline now looks like this: > > HelpTopic > DynamicHelpPage > ClassAPIHelp > MethodListHelp > PackageAPIHelpBook > HelpBook > HelpPage > > I have several problems with these three introduced classes: > > - They do not stand the "is a" inheritance test since a book (PackageAPIHelpBook) now "is a" page (DynamicHelpPage) > - To make it even worse the class DynamicHelpPage adds three new instance variables (using blocks) totally ignoring the > ivars inherited from HelpTopic (leaving unused slots in the instances). > - the three new classes are more intended towards extracting/building the three types of dynamic help informations > (package, class, method), > So the behavior is more oriented towards "building" a book or page - but this is what the (yet unfished) builders > are used for. Therefore the classes are also misplaced. > - there is no single test provided > > Sorry Danny - but your changes look more like a quick way on getting a dynamic help "hacked in" than > a clean design towards a stable Pharo help system! You are the boss there. I was not aware of the design and I did not look at the code. I was just reading tests and class comments and I would like to get some of them promoted to help :) > However - I'm in the midst of refactoring all this and hope to provide an even simpler model than the one > I originally used. Please be a little bit patient before we all jump into this "feature adding thing". we are not in rush. >>> > Yes, it has a Metacello configuration which currently separates the test from the Core model/UI. > My further work will provide an exchangable and more enhanced UI and no dependency on the Help system itself > (at least for in image docu). I'm currently testing some ideas. > >> my point is if you imagine that we want a small system with good packages >> where do we put the helpSystem. > > I intend to use pragmas to decouple this. So you could comment your code without having the help system > installed. yes this is important > > We have to make a clean distinction for the help system for: > - in image documentation on classes/methods/packages/test cases that can also be accessed by the usual tools like browsers > - big-picture like help (books, tutorials) you lose me there. ;) > I know you are all eager to play with the first in the help system but I think the second has more value > and need for a help system. ok I guess I got it. But I'm pragmatic. - how to we fill up the help - when I here book I know the pain it is to write. > > A nice idea on squeak-dev was to add support for a simple structured markup >> language like Markdown in class comments. We could use this to write "big- >> picture" documentation directly in a class comment. > > Yes ... but a class comment is as the name implies just a comment for a class. You typically dont write a "big-picture" > documentation in a class comment. If you write a documentation on how to use Streams, Collections or Exception Handling > ... which is the class you would use for the comment? > > Dont get me wrong: I like well described classes but the Help system should mainly address the "big-picture" documentation > for tools, frameworks, the system, ... > > Adding other types like the dynamic API help are easy to integrate/generate. > > Another goal is to use the HelpSystem to document a (commercial) software you have written in Pharo or reuse the content for a > documentation appearing on a website. ok > > Danny wrote: >> In a package you put in the most important class a comment that looks somehow >> like this: > > How do you measure the importance of a class ... ? ;) > > > Stef wrote: >> we can load HelpSystem and use it but since we want to have core >> we should get it in Pharo but still make sure that everything in Core is adapted to give info >> to Pharo. > > Two simple goals: > - help is always optional and core could be without it > - infos provided should not be dependent on the help system itself (for comments) > >> In addition I would like to have a tag for promoting test to be list in the help. >> <documentation> >> >> Would be nice. > > Yes, there are many things that would be nice like generating books/pages from tests or examples > or even dynamically build UML diagrams. We can have that in future. But first we need a simple and good > model we can built on and I'm working on it. Maybe I released too early ... No this is interesting to get ideas. For the UML I would like to have a simple sccripting descriptoin so that we can define it. > > Thanks > T. > > > > -- > GMX DSL: Internet, Telefon und Entertainment fÃ¼r nur 19,99 EUR/mtl.! > http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 5, 2010

[Pharo-project] About danny help :)

by Torsten Bergmann

Stef wrote: >Hi danny > >I would like to integrate your help system in pharo so we will have see how we can proceed. >... >Yes this is good for my ego :))) Hey, hey ... and it is not good for my ego if you keep saying it is danny's help system! Ever looked at the project and code? ;) While I appreciate that Danny wants to contribute to the project I think his changes are not aligned with the original goals, design and ideas. First and most important: I want a simple model for the help system, which I first provided as HelpTopic HelpBook HelpPage after Danny's changes the baseline now looks like this: HelpTopic DynamicHelpPage ClassAPIHelp MethodListHelp PackageAPIHelpBook HelpBook HelpPage I have several problems with these three introduced classes: - They do not stand the "is a" inheritance test since a book (PackageAPIHelpBook) now "is a" page (DynamicHelpPage) - To make it even worse the class DynamicHelpPage adds three new instance variables (using blocks) totally ignoring the ivars inherited from HelpTopic (leaving unused slots in the instances). - the three new classes are more intended towards extracting/building the three types of dynamic help informations (package, class, method), So the behavior is more oriented towards "building" a book or page - but this is what the (yet unfished) builders are used for. Therefore the classes are also misplaced. - there is no single test provided Sorry Danny - but your changes look more like a quick way on getting a dynamic help "hacked in" than a clean design towards a stable Pharo help system! However - I'm in the midst of refactoring all this and hope to provide an even simpler model than the one I originally used. Please be a little bit patient before we all jump into this "feature adding thing". Stef/Danny wrote: >>I would like to add it in a modular way. Does anybody has a nice idea? >I am not sure what you mean by modular. It has a Metacello configuration. Yes, it has a Metacello configuration which currently separates the test from the Core model/UI. My further work will provide an exchangable and more enhanced UI and no dependency on the Help system itself (at least for in image docu). I'm currently testing some ideas. >my point is if you imagine that we want a small system with good packages >where do we put the helpSystem. I intend to use pragmas to decouple this. So you could comment your code without having the help system installed. We have to make a clean distinction for the help system for: - in image documentation on classes/methods/packages/test cases that can also be accessed by the usual tools like browsers - big-picture like help (books, tutorials) I know you are all eager to play with the first in the help system but I think the second has more value and need for a help system. >A nice idea on squeak-dev was to add support for a simple structured markup >language like Markdown in class comments. We could use this to write "big- >picture" documentation directly in a class comment. Yes ... but a class comment is as the name implies just a comment for a class. You typically dont write a "big-picture" documentation in a class comment. If you write a documentation on how to use Streams, Collections or Exception Handling ... which is the class you would use for the comment? Dont get me wrong: I like well described classes but the Help system should mainly address the "big-picture" documentation for tools, frameworks, the system, ... Adding other types like the dynamic API help are easy to integrate/generate. Another goal is to use the HelpSystem to document a (commercial) software you have written in Pharo or reuse the content for a documentation appearing on a website. Danny wrote: >In a package you put in the most important class a comment that looks somehow >like this: How do you measure the importance of a class ... ? ;) Stef wrote: >we can load HelpSystem and use it but since we want to have core >we should get it in Pharo but still make sure that everything in Core is adapted to give info >to Pharo. Two simple goals: - help is always optional and core could be without it - infos provided should not be dependent on the help system itself (for comments) >In addition I would like to have a tag for promoting test to be list in the help. ><documentation> > >Would be nice. Yes, there are many things that would be nice like generating books/pages from tests or examples or even dynamically build UML diagrams. We can have that in future. But first we need a simple and good model we can built on and I'm working on it. Maybe I released too early ... Thanks T. -- GMX DSL: Internet, Telefon und Entertainment fÃ¼r nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02

March 5, 2010

[Pharo-project] [update 1.1] #11246

by Marcus Denker

11246 ----- Issue 1336: Stack should be re-implemented Issue 1346: Clean up sort: and sortBy: (step 1: add TSortable) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 5, 2010

[Pharo-project] [update 1.1] #11245

by Marcus Denker

11245 ----- Issue 2104: remove several unimplemented calls Issue 2113: asSortedArray -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 5, 2010

Re: [Pharo-project] [1.1] Object>>initialExtent

by Igor Stasenko

On 4 March 2010 21:43, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > The user interface or the model should define the initialExtent > I do not understand why > Â Â Â Â 1 initialExtent makes sense. > :) me either. Obviously the problem is not in one who implements that message, but to whom this message should be directed. > We have to define initialExtent to some model. > > Stef > >> I ran into this as well. Â I tried to avoid triggering the deprecation, >> to see if the model understood initialExtent before sending it and >> guarding for nil models and things like that. otherwise just >> dispatching to the default extent, however this is difficult because >> all objects understand initialExtent! i needed a method >> respondsToButNotInObject:... at that point I got distracted. Â it is >> ugly to do this deep respondsTo: check so I was not sure what the >> correct way of approaching this deprecation was. I assumed someone had >> a nice solution when they deprecated it? >> >> Mike >> >> On Thu, Mar 4, 2010 at 5:49 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >>> Hi! >>> >>> I do not have a solution, but Object>>initialExtent was recently >>> deprecated and this causes great usability problem. This deprecation >>> is very valuable for a clean UI separation. However, I have a warning >>> deprecation each time a window is open. The reason stems from the >>> method: >>> >>> SystemWindow>>initialExtent >>> Â Â Â Â ^ model initialExtent >>> >>> For now, in my image, I suppressed this deprecation. >>> Again, I do not have a clean solution. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel Â http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 5, 2010

Re: [Pharo-project] [update 1.1] #11243

by Lukas Renggli

The problem is that some ancestor versions disappeared, what makes it impossible to merge. We've manually integrated the delta into: Name: Tests-lr.79 Author: lr Time: 5 March 2010, 12:16:05 pm UUID: 99f8b58a-0923-4264-9ea6-58fec6cf4d18 Ancestors: Tests-MichaelRueger.78 - merged Jorges Code Lukas On 5 March 2010 11:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Jorge > > could you publish the tests for 1.1 because I could not find my way 11 conflicts for 1.1? > > Stef > > >> Hi Adrian, >> >> Sorry for the delay, too many things today. >> >> Ok, I added 17 test to Tests-Compiler which model the cases of >> shadowing, at least the ones I could come up with. I also modified the >> Encoder>>bindTemp: in order to make it a little bit more intention >> revealing. >> >> My changes are in: >> >> Â Â Â Â Â Â Â Â Â Â Â Compiler-JorgeRessia.144 >> Â Â Â Â Â Â Â Â Â Â Â Tests-JorgeRessia.46 >> >> Some comments: >> >> - In order to test the not interactive mode I had to mock the >> Transcript. I could not find a better solution, if anybody has a >> better one just let me know I'll change it. >> - There is a special case which is that when you are NOT in >> interactive mode if the shadowed variable is a temp then the syntax >> error is triggered as in interactive mode. This is the behavior >> implemented before I did the changes. Is that what we want? >> - I added this test to Tests-Compiler package, I would have preferred >> to add them to Compiler-Tests but there was nothing there. >> >> Cheers, >> >> Jorge >> >> On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>> Hi Jorge, >>> >>> Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! >>> >>> Cheers, >>> Adrian >>> >>> On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: >>> >>>> Hi Adrian, >>>> >>>> Yep, I have the same problem as you. My idea was to make it work as >>>> before without completely changing it. Basically because I did not >>>> have the test support to validate my changes. >>>> Anyhow, what I propose is to write a bunch of tests for every case >>>> that we know and then if new cases show up add them to the test suite. >>>> And then play with the code. >>>> >>>> I will work on that today, is that ok? >>>> >>>> For the explanation of what is going on is that now node can be an >>>> instance variable node, then the behavior that was there was not >>>> appropriate in the sense that instance variable nodes do not >>>> understand #scope. >>>> However, why this validation "(node isTemp or: [requestor >>>> interactive])" was there in the first place is not that clear to me, >>>> but it's been there since 1999. >>>> >>>> I'll try to build the tests and come up with a better solution. >>>> >>>> Cheers, >>>> >>>> Jorge >>>> >>>> On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>> Jorge, >>>>> >>>>> I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? >>>>> >>>>> This is the code: >>>>> >>>>> "When non-interactive raise the error only if its a duplicate" >>>>> (node isTemp or: [requestor interactive]) >>>>> Â Â Â Â ifTrue:[ ((node isTemp) and: [node scope <= 0] ) >>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [^self notify:'Name is already defined' ]] >>>>> >>>>> Cheers, >>>>> Adrian >>>>> >>>>> On Mar 3, 2010, at 20:47 , StÃ©phane Ducasse wrote: >>>>> >>>>>> 11243 >>>>>> ----- >>>>>> >>>>>> - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed >>>>>> Â Â Â Problem fixed: >>>>>> We cannot have twice the same block arg in a method >>>>>> >>>>>> Â Â Â [:each | each ...] >>>>>> Â Â Â [:each | each ...] >>>>>> >>>>>> THANKS jorge :) >>>>>> Do you like good bio beer? >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

March 5, 2010