On Mar 28, 2010, at 7:00 PM, Michael Roberts 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.
I did not check the help code but it should be just some text tagged so it could put somewhere. And I alwyays thought as in drdoc that we should a class per pakage or group of package where we can attach metadata. > 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. > > 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. > > 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. > > 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. I suggest that we give a try to see how it flies. I'm not that having to be a subclass is good. In DrDoc I duplicated code just to make sure that we could load the package in absence of DrDoc. > > 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
