On Sun, Mar 28, 2010 at 2:00 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
... i have been looking at the situation. It is tricky. Ideally the help would be near the code it is the help for. That way any API described in help could be updated as the code is updated. I want to, for example, commit some network help.
However, as pointed out, the core help classes are not in the core image so the help can't be loaded and therefore can't go in the core monticello package.
That's why I said it was not as easy as it seemed to be :)
This could be solved by having the few classes required to define help in the core image. Or, we could look at extending the help system to use pragmas to annotate the necessary methods without needing to subclass CustomHelp.
I like very much this apporoach. It would like to have: Metacello-Core Metacello-Documentation and put in Documentation methods with pragmas. Or even those methods can be directly in Monticello-Core Then, when someone install HelpSystem (probably, not in the core but in the Dev), it search the pragmas and makes the HelpSystem with that. Similar to the new menu registration scheme with the difference that the one who looks the pragmas and do something, is not in the core but in a separate package.
The other thing, is that in the HelpSystem project, there is a naming convention already in use e.g Metacello-Help. So in principle I would upload a new package Monticello-Help.
Yes, it would be cool to define a convention. Help or Documentation ? which seems to be more abstract for you ?
However, Monticello is already defined in the core image as a package, so if I create a package Monticello-Help I dirty the core package.
Ufffff yes...we always have the same problem with this....
So what should I do? I was thinking of uploading MonticelloHelp in the short term to the help system project. Or I can just add the help to the PharoProject-Help.
Perhaps we should think about the help system a bit more deeply, in case we want a convention we can follow for the long-term and scales.
thanks, Mike
On Sun, Mar 28, 2010 at 5:01 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
yes
On Mar 28, 2010, at 5:43 PM, laurent laffont wrote:
2010/3/28 Mariano Martinez Peck <marianopeck@gmail.com>
On Fri, Mar 26, 2010 at 5:37 AM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:
Excellent idea. I do not know where is the story about the help system. I would like something extremely simple.
Published in the pharo inbox and I will merge it.
This is not as easy as that. If I understood correctly, he said HelpSystem classes. That is, extensions, to Torsten's HelpSystem. Which is in http://www.squeaksource.com/HelpSystem
That package is not in PharoCore, neither in PharoDev images for the moment (It can be added for PharoDev 1.1 if people want). So...you will commit those classes....but if there is no HelpSystem, it has no sense.
Is there a sense in having a sort of Staging repository for things waiting for inclusion in Pharo ? Like the Linux kernel development process. If a package in Staging has a minimum of activity, developers around it, tests passes, then it goes into next Pharo major release.
So you can put ConfigurationOfHelpSystem in Staging. Michael can add its package too.
I also like the 2 weeks merge window of Linux where new modules are added. Then the merge window closes and begin the test / fix / debug process with several rc released. So new major versions are produced quite often and it's easy to upgrade from one major version to another one.
Laurent Laffont
Cheers
Mariano
On Mar 25, 2010, at 7:40 PM, Michael Roberts wrote:
Hi, based on Lukas' recent blog post about Monticello merging, I created some help system classes for this content. What is the best way to integrate this? We have our own version of Monticello in the Pharo repository. Which package, would we add it to? Or do we want to add it upstream somewhere?
Also, has anyone thought or spiked some simple formatting? that would be really nice.
thanks, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project