Joel de Guzman <[EMAIL PROTECTED]> writes: > 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?
Nothing. Your proposal didn't make it clear that implicit collection would go on from that point forward. It seemed to suggest you had to annotate each example you wanted to be collected. >>>>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? Do you? >> 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. I don't want it reverse-engineered, unless you think that's what you need in order to understand the capabilities and the inputs to the system. I don't see why the details of the implementation should be important to you. I only care that you have implemented the right capabilities. > 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. To what end? It's a lot of work to explain how the code is organized, and I just want to make sure it's not wasted. After all, you'll come up with your own code and organization, right? > I'd also want to know the objectives of the system The main objective was to get some automated testing for the code examples in our book. Really, that's all! ;-) > 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 Well, we have code examples that show the Boost PP lib. We need to be able to test that they do what we thought. > or check for specific strings in the output, We have examples whose correctness can only be tested well by verifying that they produce a particular output on stdio. Standard code testing stuff. Only this time, most of the code and all the instructions about what to do with it are embedded in the source text of the book. > for example. With all due respect, there might be better means to > do these tasks Sure, there might. Right now I don't see any means in your proposal, which is why I'm needling you about it. > but I won't really know for sure unless I am aware of the issues > involved. There must be some disconnect here, because to me this all looks so obvious that there seems to be no better way to explain it than what I've already said. If someone else can understand what you're confused about and translate for us, that might help. Anyone? -- 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
