On Sun, Mar 28, 2010 at 2:00 PM, Michael Roberts <[email protected]> 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 > <[email protected]> wrote: > > yes > > > > On Mar 28, 2010, at 5:43 PM, laurent laffont wrote: > > > >> > >> 2010/3/28 Mariano Martinez Peck <[email protected]> > >> > >> > >> On Fri, Mar 26, 2010 at 5:37 AM, Stéphane Ducasse < > [email protected]> 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 > >> > [email protected] > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [email protected] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [email protected] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [email protected] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
