Joel de Guzman <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Joel de Guzman <[EMAIL PROTECTED]> writes: >> >>>David Abrahams wrote: >>> >>>>Hmm. I'm not sure I like having to label each snippet I might >>>>want to process with a collector. >>> >>>Do you have a certain suggestion in mind? >> >> Did you look at Litre? There's only one collector, and snippets >> just collect there automatically. Maybe you should collect >> everything in the last collector used until instructed otherwise. > > Yes, I looked at Litre. In fact the collector proposal was > based on it. Yes, you can collect everything in the last > collector used until instructed otherwise. That's the whole > point of it being modal. The collector proposal I gave > was just to give us better flexibility for things like > being able to present code fragments out of order and arrange > them later or have common code fragments be presented multiple > times.
I like those features a lot. I'm just asking for implicit collection, which your proposal didn't mention. >>> I think that compiling, preprocessing, building and running, etc, >>> should not be the job for QuickBook. >> >> That's fine. In Litre there is also separation of concerns. >> There's the Litre framework and a C++-specific translator subclass >> that knows about this kind of processing. >> >>> Instead, this should be a job of the build tool, in this case, >>> BJam. I could, for example have a "collector" that generates a >>> Jamfile that can be invoked automatically after the QuickBook >>> session, perhaps triggered by the same Jamfile that invoked the >>> QuickBook session. I figured that this would amount to the same >>> thing. No? >> >> Sure, but then you need programmable collectors. Programming a >> collector to do this amounts to the same thing as writing a >> C++-specific translator for Litre. Do you understand what I'm getting at here? Somebody has to build a "collector" that can generate an appropriate Jamfile. Furthermore, there has to be some mechanism to describe what goes into that Jamfile. Is this example supposed to be compiled? Run? Preprocessed? Do you need to check for specific strings in the output? Yada yada. So the "collector" has to have a pretty rich interface for handling these examples, along with some information that's not strictly in the examples, that says what to do with them. >> We don't want to rebuild quickbook each time you need a new >> collector behavior, so I think binding to an interpreted language >> (Python, please) is almost mandatory. You could do it with plug-in >> dynamic libraries, I suppose, but this is a job I just see no good >> reason to do in C++. > > I looked at Litre but haven't really had a hands on experience > with it. Perhaps I should look a bit more deeper. Could you outline > the basic process involved from documentation to execution? Edit litre/config.py as appropriate for your setup. Then python litre.py --traceback <whatever.rst> Or do you mean something else? > Most welcome. I love challenges like this! Needless to say, > documentation is a very important, but often neglected aspect > of software dev. The direction we are heading to makes the task > gratifying. I remember Eric (Niebler) say: It's fun like > programming. I think that's the key: make it fun :P -- Dave Abrahams Boost Consulting www.boost-consulting.com ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-docs mailing list [email protected] Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs
