Help system question / monticello
Locked
Help system question / monticello
 
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Help system question / monticello
|
|
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. 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Help system question / monticello
|
|
On Fri, Mar 26, 2010 at 5:37 AM, Stéphane Ducasse <[hidden email]> wrote: Excellent idea. 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. Cheers Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Help system question / monticello
|
|
2010/3/28 Mariano Martinez Peck <[hidden email]>
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
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Help system question / monticello
|
|
yes
On Mar 28, 2010, at 5:43 PM, laurent laffont wrote: > > 2010/3/28 Mariano Martinez Peck <[hidden email]> > > > On Fri, Mar 26, 2010 at 5:37 AM, Stéphane Ducasse <[hidden email]> 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 > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Help system question / monticello
|
|
... 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. 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. thanks, Mike On Sun, Mar 28, 2010 at 5:01 PM, Stéphane Ducasse <[hidden email]> wrote: > yes > > On Mar 28, 2010, at 5:43 PM, laurent laffont wrote: > >> >> 2010/3/28 Mariano Martinez Peck <[hidden email]> >> >> >> On Fri, Mar 26, 2010 at 5:37 AM, Stéphane Ducasse <[hidden email]> 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 >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Help system question / monticello
|
|
On Sun, Mar 28, 2010 at 2:00 PM, Michael Roberts <[hidden email]> wrote: ... i have been looking at the situation. It is tricky. Ideally the That's why I said it was not as easy as it seemed to be :)
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 Yes, it would be cool to define a convention. Help or Documentation ? which seems to be more abstract for you ?
Ufffff yes...we always have the same problem with this.... So what should I do? I was thinking of uploading MonticelloHelp in the _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Help system question / monticello
|
|
In reply to this post by Michael Roberts-2
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 > <[hidden email]> wrote: >> yes >> >> On Mar 28, 2010, at 5:43 PM, laurent laffont wrote: >> >>> >>> 2010/3/28 Mariano Martinez Peck <[hidden email]> >>> >>> >>> On Fri, Mar 26, 2010 at 5:37 AM, Stéphane Ducasse <[hidden email]> 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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |