On Tuesday, January 6, 2009 at 21:02:06 (+0100) Werner Smekal writes: > Hi Andrew and Alan, > >> Would it be straightforward to implement a -stream command-line option > >> that > >> means all subsequent options refer to the specified stream number? That > >> would provide an elegant solution to the example 14 issue with, e.g., > >> > >> c/x14c -dev psc -o x14ac.psc -stream 1 -dev psc -o x14bc.psc > >> > > > > Or how about anything before the option could be applied to all streams, > > options after a -stream command only apply to that stream, unless > > another -stream option is encountered. Each stream can then call > > plparseopts and only extract the commands meant for it. Default would be > > the current behaviour. A stream can then decide whether or not it wants > > to use command line options. The only down side of this is that the > > (currently internal) stream numbers are exposed to the user. > > > I think you provide a solution for only one specific example. Before we > do that we should think about if this is a common case which is often > used (which I don't think). Also it is very easy to do that inside the > program, e.g. before we parse the command line options, make a copy of > them and then parse the copy for the new stream. Personally I think 95% > of the time PLplot is used only a single stream is used. I you use a > second stream you most likely use it to use a different driver (e.g. to > save a png), where different options apply. > > I actually want to say, that when I had a look at the command line > options parsing code I obtained the opinion that it is a lot of work to > make changes to this code (bugfree), so it is not worth it, since there > are a lot of other things to do and since it works at the moment and it > is transparent how it works (although maybe not well documented ;) we > should just keep it as it is. I also had big troubles, since due to a > bug driver specific options propagated to different streams (with > different drivers) which lead to crashes which were not easy to > understand. Maybe that is the reason why I'm against changes ;) > > Regards, > Werner
I've been watching this thread and mulling the issue over. Fortunately Werner jumped in with an argument very similar to one I might have made. The arg parsing part of PLplot was indeed a substantial project. It seemed a bit of overkill at the time, but at the same time I didn't see what part of it I could comfortably leave out. I've come up with a few wish-list items for it over the years but nothing major. So in my opinion, serious modification should be undertaken only with a measure of certainty that it's really needed. I did consider the issue of initialization of separate streams, but the issue is still as murky now as it was then. What does the application intend to do with those extra streams? And if this behavior is so application-dependent, shouldn't it be controlled from the application writer directly? The way options are supported now is clear & unambiguous. If there were a clear demand for command line args with multiple stream support, or if it were easy to do, or preferably both :), I'd say sure. But I don't think "supporting x14 in the test suite" qualifies. As it is, x14 was created to be a demonstration of something cool you could do with multiple streams in an interactive environment, that's all. One can go much farther down that path as an application writer. But the farther down that path you go, the more likely you are to be handling configuration changes via GUI input, config files, or X resources, rather than supporting a massive command line syntax. -- Maurice LeBrun ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
