- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

by StÃ©phane Ducasse

We could rollback and introduce a new message and deprecates the other. This is just that I do not have the energy for that. Now this is also important that we do not get bound to existing API for the sake of them. Stef >> >>> ToolBuilder is one of the projects I believe deserve to stay fork-agnostic. >>> >>> Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :) >> >> That's not so difficult. Let's start by just merging the code bases, and see where this leads. I expect few, if any difficulties here. Let's add some test to document the changes (like the one Torsten was bitten by) and we should be pretty much covered. >> >> Further out, I don't expect us to stay closely in sync. The whole issue of upstream vs. downstream packages is an open one, so my opinion is that we should merge when it makes sense (i.e., new features being added) but otherwise let each project have its own choices. >> >>> With ToolBuilder, I also include the protocol of UIManagers. >>> In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels. >> >> What can I say ... I actually said in that discussion that the right choice is to introduce a different protocol, i.e., request:onCancel: or something similar. Now we'll end up with a new protocol anyways - I don't expect Pharo to change (too much pride involved) and I don't expect Squeak to change (too much legacy code involved) so a new protocol for the people who care about compatibility going forward is really the only option (which can also be back-ported if necessary). The end result will be that we'll declare the return value of #request: to be "undefined" if the dialog is canceled and recommend using the new protocol. >> >> It's a great lesson about how not to break an existing protocol. If Pharo had introduced a new protocol we could have just implemented it in Squeak and be done. Instead, the end result will be that a new protocol is introduced anyway and that nobody will be able to reliably use the the old protocol. Consider it a lesson for the next time an issue like this comes up - if you're interested in compatibility breaking an existing protocol isn't the smart choice, in particular when it comes to cross-platform / cross-dialect protocols. >> >> Cheers, >> - Andreas > No arguments from me, I strongly defended the approach you suggested at the time. > Sadly, (in my eyes) discussion just died, and everything got changed anyways. > > Cheers, > Henry > > (Link to thread in question, for those interested) > http://smalltalk.1294792.n4.nabble.com/Fwd-Issue-1129-in-pharo-UIManager-re… > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 22, 2010

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

by Henrik Johansen

On Apr 22, 2010, at 11:10 47AM, Andreas Raab wrote: > On 4/22/2010 1:21 AM, Henrik Johansen wrote: >> ToolBuilder is one of the projects I believe deserve to stay fork-agnostic. >> >> Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :) > > That's not so difficult. Let's start by just merging the code bases, and see where this leads. I expect few, if any difficulties here. Let's add some test to document the changes (like the one Torsten was bitten by) and we should be pretty much covered. > > Further out, I don't expect us to stay closely in sync. The whole issue of upstream vs. downstream packages is an open one, so my opinion is that we should merge when it makes sense (i.e., new features being added) but otherwise let each project have its own choices. > >> With ToolBuilder, I also include the protocol of UIManagers. >> In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels. > > What can I say ... I actually said in that discussion that the right choice is to introduce a different protocol, i.e., request:onCancel: or something similar. Now we'll end up with a new protocol anyways - I don't expect Pharo to change (too much pride involved) and I don't expect Squeak to change (too much legacy code involved) so a new protocol for the people who care about compatibility going forward is really the only option (which can also be back-ported if necessary). The end result will be that we'll declare the return value of #request: to be "undefined" if the dialog is canceled and recommend using the new protocol. > > It's a great lesson about how not to break an existing protocol. If Pharo had introduced a new protocol we could have just implemented it in Squeak and be done. Instead, the end result will be that a new protocol is introduced anyway and that nobody will be able to reliably use the the old protocol. Consider it a lesson for the next time an issue like this comes up - if you're interested in compatibility breaking an existing protocol isn't the smart choice, in particular when it comes to cross-platform / cross-dialect protocols. > > Cheers, > - Andreas No arguments from me, I strongly defended the approach you suggested at the time. Sadly, (in my eyes) discussion just died, and everything got changed anyways. Cheers, Henry (Link to thread in question, for those interested) http://smalltalk.1294792.n4.nabble.com/Fwd-Issue-1129-in-pharo-UIManager-re…

April 22, 2010

Re: [Pharo-project] Fix 2329 - Default MC Directory Setting

by StÃ©phane Ducasse

Sean I cannot find your slice in the inbox. Is it there? Stef On Apr 21, 2010, at 10:07 PM, Sean P. DeNigris wrote: > > In Inbox. http://code.google.com/p/pharo/issues/detail?id=2329. > > Details: > > > Michael Roberts-2 wrote: >> >> I appreciate I hijacked this thread somewhat.... >> > > That's it - I'm pissed and I'm taking my damn thread back ;-) > > > Sean P. DeNigris wrote: >> >> http://code.google.com/p/pharo/issues/detail?id=2329 >> >> Pharo image: Pharo 1.0 >> >> In Monticello Browser, when I click "+Repository" and select "directory," >> I'd love to be taken right to the directory where I keep my local >> repositories, instead of having to click to the same place over and over. >> > > Okay, now that we're back on track... > > > StÃ©phane Ducasse wrote: >> >> it would be good to be able to >> either choose to have one local cache on the side of the image >> or one shared among image - this implies a way to store and set it up >> => probably a class variable + a setting in 1.1 >> > > Steph, I followed your suggestion and implemented it as a class var + > settings. > > I had to add the capability to have directory-type settings (which was very > similar to the existing file type settings, predictably). > > Summary: > * Added ability to System-Settings to have directory-based settings > * Added defaultDirectoryName setting to Settings-Monticello > * Added feature to Monticello to remember parent directory where user likes > to keep local repository directories and start directory-choosing dialogs > there. > * Tested (by hand) in PharoCore1.1ALPHA Latest update: #11312 > > Sean > -- > View this message in context: http://n4.nabble.com/Fix-2329-Default-MC-Directory-Setting-tp2019559p201955… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 22, 2010

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

by StÃ©phane Ducasse

On Apr 22, 2010, at 11:10 AM, Andreas Raab wrote: > On 4/22/2010 1:21 AM, Henrik Johansen wrote: >> ToolBuilder is one of the projects I believe deserve to stay fork-agnostic. >> >> Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :) > > That's not so difficult. Let's start by just merging the code bases, and see where this leads. I expect few, if any difficulties here. Let's add some test to document the changes (like the one Torsten was bitten by) and we should be pretty much covered. > > Further out, I don't expect us to stay closely in sync. The whole issue of upstream vs. downstream packages is an open one, so my opinion is that we should merge when it makes sense (i.e., new features being added) but otherwise let each project have its own choices. Agreed. > >> With ToolBuilder, I also include the protocol of UIManagers. >> In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels. > > What can I say ... I actually said in that discussion that the right choice is to introduce a different protocol, i.e., request:onCancel: or something similar. Now we'll end up with a new protocol anyways - I don't expect Pharo to change (too much pride involved) and I don't expect Squeak to change (too much legacy code involved) so a new protocol for the people who care about compatibility going forward is really the only option (which can also be back-ported if necessary). The end result will be that we'll declare the return value of #request: to be "undefined" if the dialog is canceled and recommend using the new protocol. I know you remember I was in favor of your solution. > It's a great lesson about how not to break an existing protocol. If Pharo had introduced a new protocol we could have just implemented it in Squeak and be done. Instead, the end result will be that a new protocol is introduced anyway and that nobody will be able to reliably use the the old protocol. Consider it a lesson for the next time an issue like this comes up - if you're interested in compatibility breaking an existing protocol isn't the smart choice, in particular when it comes to cross-platform / cross-dialect protocols. > > Cheers, > - Andreas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 22, 2010

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

by Andreas Raab

On 4/22/2010 1:21 AM, Henrik Johansen wrote: > ToolBuilder is one of the projects I believe deserve to stay fork-agnostic. > > Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :) That's not so difficult. Let's start by just merging the code bases, and see where this leads. I expect few, if any difficulties here. Let's add some test to document the changes (like the one Torsten was bitten by) and we should be pretty much covered. Further out, I don't expect us to stay closely in sync. The whole issue of upstream vs. downstream packages is an open one, so my opinion is that we should merge when it makes sense (i.e., new features being added) but otherwise let each project have its own choices. > With ToolBuilder, I also include the protocol of UIManagers. > In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels. What can I say ... I actually said in that discussion that the right choice is to introduce a different protocol, i.e., request:onCancel: or something similar. Now we'll end up with a new protocol anyways - I don't expect Pharo to change (too much pride involved) and I don't expect Squeak to change (too much legacy code involved) so a new protocol for the people who care about compatibility going forward is really the only option (which can also be back-ported if necessary). The end result will be that we'll declare the return value of #request: to be "undefined" if the dialog is canceled and recommend using the new protocol. It's a great lesson about how not to break an existing protocol. If Pharo had introduced a new protocol we could have just implemented it in Squeak and be done. Instead, the end result will be that a new protocol is introduced anyway and that nobody will be able to reliably use the the old protocol. Consider it a lesson for the next time an issue like this comes up - if you're interested in compatibility breaking an existing protocol isn't the smart choice, in particular when it comes to cross-platform / cross-dialect protocols. Cheers, - Andreas

April 22, 2010

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

by Henrik Johansen

On Apr 22, 2010, at 10:21 20AM, Henrik Johansen wrote: > > On Apr 22, 2010, at 5:25 29AM, Andreas Raab wrote: > >> On 4/21/2010 4:32 AM, Hannes Hirzel wrote: >>> A question: Art the ToolBuilder in Squeak 4.1 and Pharo 1.0 the same? >>> Or if there is a difference what is the impact of it? >>> >>> Or put the question in another way. If I code an UI using the >>> ToolBuilder in Squeak 4.1 will it run in Pharo? >> >> They are mostly the same but not identical. If there is interest in the Pharo community we should merge the versions upstream in http://www.squeaksource.com/ToolBuilder.html (contact me if you're interested). >> >> Cheers, >> - Andreas > > ToolBuilder is one of the projects I believe deserve to stay fork-agnostic. > > Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :) > > With ToolBuilder, I also include the protocol of UIManagers. > In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels. > > Cheers, > Henry > Should of course be noted, if you take a look in a Pharo image, this change has not been reflected in the ToolBuilder UIManager comment, nor the MorphicUIManager, just in the PSUIManager which is the default manager in Pharo. (Don't see that changing anytime soon though :) ) Cheers, Henry

April 22, 2010

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

by Henrik Johansen

On Apr 22, 2010, at 5:25 29AM, Andreas Raab wrote: > On 4/21/2010 4:32 AM, Hannes Hirzel wrote: >> A question: Art the ToolBuilder in Squeak 4.1 and Pharo 1.0 the same? >> Or if there is a difference what is the impact of it? >> >> Or put the question in another way. If I code an UI using the >> ToolBuilder in Squeak 4.1 will it run in Pharo? > > They are mostly the same but not identical. If there is interest in the Pharo community we should merge the versions upstream in http://www.squeaksource.com/ToolBuilder.html (contact me if you're interested). > > Cheers, > - Andreas ToolBuilder is one of the projects I believe deserve to stay fork-agnostic. Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :) With ToolBuilder, I also include the protocol of UIManagers. In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels. Cheers, Henry

April 22, 2010

Re: [Pharo-project] About help

by StÃ©phane Ducasse

yes On Apr 22, 2010, at 9:18 AM, Adrian Lienhard wrote: > I like it too! > > One nice to have feature would be a search... For class names, method names, and help content. Like this you would not need to do #openOn:. If you need help you may not even know how the class you are looking for is named. > > Cheers, > Adrian > > > On Apr 21, 2010, at 22:54 , StÃ©phane Ducasse wrote: > >> Hi pharo >> >> >> Gofer new >> squeaksource: 'HelpSystem'; >> version: 'HelpSystem-Core-tbn.35'; >> load >> >> and enjoy >> >> HelpBrowser openOn: SystemReference >> HelpBrowser openOn: (SystemReference forClass: Integer) >> HelpBrowser openOn: (SystemReference hierarchyFor: Integer) >> HelpBrowser openOn: (SystemReference hierarchyWithMethodsFor: Integer) >> >> with some tweaks it can be realllllly cool. >> >> 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

April 22, 2010

Re: [Pharo-project] HelpSystem (was Documentation Team)

by StÃ©phane Ducasse

What would be good is to have a class comments for each of the class we see in HelpSystem openOn: SystemReference. This would be a countable progress. stef On Apr 21, 2010, at 11:32 PM, laurent laffont wrote: > Yes, Python documentation is really impressive, the best I know. > > May be we can go the other way, from HelpSystem to web. I've tried something like some months ago.ex: http://magaloma.seasidehosting.st/Collections-Streams. > > So we can have a documentation page like http://docs.python.org/py3k/ with: > - collaborator book > - web edition of Pharo By Example > - HelpSystem books > - API reference generated from comments in classes / methods (with the possibility to add comments like jQuery or PHP online docs.) > All on one page, starting point to look for documentation, at http://docs.pharo-project.org > > Cheers, > > Laurent Laffont > > > On Wed, Apr 21, 2010 at 10:46 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > Laurent, i think this is a tension that a number of us feel. should we > put documentation in the colab book, or in the system? For me the two > are distinct. The book, ultimately, should read as a book. That is > there is a logical flow from start to finish and the content is > consistent, from start to finish, for a given version of the system. > Writing a book appears hard - i have never done it - but i have > attempted to copy-edit material that turned out to be as big as a > reasonably sized book; i found that near impossible. So whilst the > colab book effort is currently in its infancy, i would expect over > time it to tend towards being published as a consistent whole. I'm > sure anyone involved in SBE/PBE could comment on the real work > required to write such a book. > > As for help in the system, as torsten nicely articulated either "Help" > or "Reference", this should really be dynamic. It should change at the > unit of which it is changing. so if a new version of a package is > loaded, perhaps the Reference docs change. using hyperlink references > you should be able to jump around it in an arbitrary order. I don't > see a book performing this function. really it must flow consistently > from start to finish and the layout of the book is carefully picked by > the editors. the only realy hyperlink function is from the TOC, and to > any particular index or reference. it is quite distinct from arbitrary > jumping at a system doc level. > > at the moment these two forces I consider are at tension, because > there is not enough reference material in the system as we shipped > 1.0, and i think the barrier to viewing & editing such reference > documentation, as a coherent whole, to my satisfaction is harder than > using Pier. therefore i find it easier to edit pier even if i have > only contributed a few paragraphs. however longer term this will not > be the case. We must strive for something akin to Python > documentation. as an engineering artifact, it is simply stunning; you > can find documentation on anything to do with a given released > version. i'm sure this applies to other languages too, i just use > python as an example because I particularly like its style towards doc > annotation and its completeness. > > so personally i don't think we should export the pier content into the > help system. i see them as quite different, and for both to succeed I > think they require a different point of view to writing the content. > > Torsten - i did not reply to the other thread which stef and I both > commented on, have not had the time. For me i am a total pragmatist > when it comes toward reference documentation and i am only really > interested in reference docs. i fully understand your design and i'm > fine with that. I just hope that as a community we can author the > reference side, since that is what i feel is most missing. > > cheers, > Mike > > 2010/4/21 laurent laffont <laurent.laffont(a)gmail.com>: > > Hi, > > It's cool to have so many interests in documentation. I deeply think it's a > > key point to success. > > As an hobbyist contributor to Pharo documentation :) I wonder whether I > > should write doc in HelpSystem (which indeed is very cool !) or in the > > collaborator active book (which is very attractive for me). > > So a way to get the best of both world may be to generate an HelpSystem book > > from the collaborator book. Every day, if there has been changes in the > > collaborative book, it can be "packaged" automatically as an HelpSystem book > > / SystemHelp , put on squeaksource, having ConfigurationOfHelpSystem project > > lastVersion pointing to the last package. > > Sounds good ? > > Cheers, > > Laurent Laffont > > > > > > On Wed, Apr 21, 2010 at 7:56 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> > >> To clearify a few things from my side on the discussion > >> on squeak-dev: > >> > >> 1. HelpSystem is working, if ASCII is OK for now we can use > >> it Pharo/Squeak - otherwise I would see it as an early preview. > >> I have clear goals how it should look like in the > >> next iterations. For this more patience is necessary. > >> > >> 2. HelpSystem is independent from where and how the actual > >> information is stored (I think I demonstrated this with > >> the IRC example, the books and the API help). > >> > >> 3. I hope to keep HelpSystem in sync for major Squeak distributions > >> (Squeak, Pharo, Cuis, ...) > >> > >> The last additions from Hannes already broke the code > >> in Pharo. Seems to be a Pharo issue this time > >> http://code.google.com/p/pharo/issues/detail?id=2342 > >> > >> But please dont commit when it is only working in > >> Squeak since my development environment is Pharo. > >> > >> 4. Yes, the content is currently ASCII but the design is prepared > >> to add other types in future releases. > >> > >> A HelpTopic defines an ivar "contents" - currently referring > >> to a string. I may add another ivar "contentType" > >> in the future to handle/distinguish additionaly types > >> (HTML, SqueaksRichText, Morphs/BookMorph, ...) > >> > >> 5. HelpSystem should not be limited to Squeak. It should also > >> serve the case that when you write and deploy a commercial > >> app in Squeak you may use it to provide help to your > >> end user/customer > >> > >> 6. There are two types of help I see: > >> > >> A. SystemHelp: Help books/Tutorials/Manuals > >> B. SystemReference: API Help, class comments > >> > >> HelpSystem is supporting both. > >> I already wrote about the differences and details in > >> > >> http://lists.gforge.inria.fr/pipermail/pharo-project/2010-April/024857.html > >> > >> 7. I would really like to see support for HTML viewing > >> in the image (HTMLViewMorph or so) - maybe based on Scamper > >> to get a better viewer (headings, tables, ...) than the > >> current plain text. > >> If people want to contribute they should start right with this > >> task. > >> > >> I know that Laurent already made Scamper loadable in Pharo, > >> dont know about the state in Squeak. > >> > >> There is also another HTML browser with markup and CSS now available > >> open source as MIT (WithStyle), I already mentioned this. > >> > >> > >> http://www.cincomsmalltalk.com/userblogs/rowanb/blogView?showComments=true&… > >> > >> 8. I know that we now have discussions on which syntax (Wiki,...) > >> to use for describing the contents. > >> My answer is: it is important but I dont care (yet) since > >> this discussion is useless until we have an HTML viewer (see 7.) > >> and even when there are different syntax styles you can provides > >> builders to transform them into HTML or other contentTypes > >> afterwards. > >> > >> See the class HelpBuilder and subclasses. > >> > >> 9. If you want to write a book for SystemHelp (see 6.A) then > >> the help system provides a class "CustomHelp" similar > >> to TestCase in SUnit. This class is used to directly > >> map book structures to the class hierarchy. > >> > >> The intention was to be able to create, store and manage > >> these books directly with the usual Smalltalk tools. > >> You can even restructure your book with the RefactoringBrowser. > >> > >> 10. If you want to write API help you (see 6.B) can contribute > >> right now by commenting all the undocumented classes in the > >> standard image. > >> > >> HelpSystem just queries these informations from the usual > >> sources (class comments, ...). I would not change this > >> or make it too complicated since this is what people are > >> used too. > >> > >> I dont see more documented classes by introducing a > >> special syntax (wiki or whatever) people have to learn/know about > >> - so lets clean up documenting the classes first. > >> > >> 11. HelpSystem is able to get contents from external sources > >> (see the IRC example) - but I would prefer that authoring/viewing > >> could be done right from within the image. > >> Even when the result is stored external afterwards. > >> > >> Look at my example books: I can view and change them > >> right from the image and make them available to other images > >> using Metacello/Squeaksource. > >> Accessibility of docu (viewing and authoring) is the key to keep > >> the system and docu in sync and up to date. > >> > >> External authoring mostly results in unmaintained docu (see > >> the Squeak Swiki). > >> > >> 12. I thought again if it is ready to integrate into Pharo and > >> Squeak. From all the discussions I would say it is too early. > >> > >> 13. If one wants the docu on the web the answer is easy: we > >> can generate static files or serve them with Seaside. > >> But I have no need for that right now, especially since > >> this is already available in various forms. > >> > >> We can do many things (similar to Python, JavaDoc, you name it) > >> > >> But - let's do it step by step. As I said: > >> > >> - Someone working on a good HTML Viewer that I can integrate > >> would really help moving this forward > >> (based on Scamper or by porting WithStyle) > >> - Updating class comments would also help a lot > >> > >> Bye > >> Torsten > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > >> > >> _______________________________________________ > >> 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

April 22, 2010

Re: [Pharo-project] About help

by Adrian Lienhard

I like it too! One nice to have feature would be a search... For class names, method names, and help content. Like this you would not need to do #openOn:. If you need help you may not even know how the class you are looking for is named. Cheers, Adrian On Apr 21, 2010, at 22:54 , StÃ©phane Ducasse wrote: > Hi pharo > > > Gofer new > squeaksource: 'HelpSystem'; > version: 'HelpSystem-Core-tbn.35'; > load > > and enjoy > > HelpBrowser openOn: SystemReference > HelpBrowser openOn: (SystemReference forClass: Integer) > HelpBrowser openOn: (SystemReference hierarchyFor: Integer) > HelpBrowser openOn: (SystemReference hierarchyWithMethodsFor: Integer) > > with some tweaks it can be realllllly cool. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 22, 2010