David Abrahams wrote:
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.
Perhaps we can set the default to [collect all]. This will give
us the implicit collection you want. I think it won't have any
effect on pre-existing qbk docs other than dumping all code
to the "all" collector. The initial proposal suggests defaulting
to [collect none]. Is it really a big deal? What's so wrong with
writing a single:
[collect all]
at the very top?
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>
No. I've read your original email outlining Litre a couple of times
in the past and some more a few minutes ago. The "rambling rush of
info" is not quite adequate for me to sufficiently visualize what's
going on. If you wish this to be properly reverse engineered, you'd
have to provide a better discription of the process involved. What
I'd like to know is what's going on behind the scenes. Otherwise,
I'd have to invest more time reading the code and figuring out myself.
I'd also want to know the objectives of the system and how it
addresses that. Oh sure, it's a literate programming system, but
I do not see the connection with that and having the ability to
preprocess or check for specific strings in the output, for example.
With all due respect, there might be better means to do these
tasks, but I won't really know for sure unless I am aware of
the issues involved.
Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
-------------------------------------------------------
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
