David Abrahams wrote:
Joel de Guzman <[EMAIL PROTECTED]> writes:
David Abrahams wrote:
Joel de Guzman <[EMAIL PROTECTED]> writes:
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.
If the collector identifier is in quotes, the collector is
assumed to be a file. Example:
[collect "test.cpp"]
A file collector will collect all successive code snippets into
the specified file.
When we have a way of labelling examples in quickbook, it would be
nice if there were an automated way to turn the example label into a
filename, e.g. chapter5/example13.cpp
? Won't [copy "chapter5/example13.cpp" label] handle that?
Ok, you say it should be:
[copy label to "chapter5/example13.cpp"]
I am presuming the numbering will be auto-generated by BoostBook, so
we will want something to automatically generate the filename from
that number.
Oh! Hmmmm... I'll give this some more thought.
All open files are closed at the end of quickbook processing.
And then what?
In C++ Template Metaprogramming I have examples that I want to
compile, preprocess, build and run, or fail compilation. So far I
don't see any connection to backend processing here. In Litre writing
directives in Python means that I can embed semantics about the
treatment of these snippets, and can extend the way they are
handled.
Here's my line of thinking, tell me what you think:
Separation of concerns...
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. 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?
Oh, sure. Those are icings in the cake. As soon as the meat of the
facility is ironed out, it would be fun to have all these bells
and whistles :-)
Thanks for your input!
No problem. Thanks for pursuing this!
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
Cheers,
--
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
