On Tue, Jan 06, 2009 at 09:02:06PM +0100, Werner Smekal wrote: > 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.
Werner, Actually the argument for stream-specific options is probably even stronger when you have two different drivers and you will very likely want different options. You could do this with example 14 and save the two sets of plots to two different file types for example. I agree that the multiple stream case is a special one and most users will not need it, and that is also likely to be an application specific usage best implemented in the code. I do think we should provide users with flexibility though. My suggestion was chosen so that the current usage is the default, so there is no need for users to change anything. You can use the -stream option if required and if the application supports it (i.e. call plparseopts for each stream). > 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 ;) I've not looked at the code closely so I'll take your word for it. If the user was responsible for copying the arguments before calling plparseopts, then the code changes should be relatively non-intrustive (just ignoring options not meant for this stream). I specifically did not suggest propogating specific options to all streams by default. The programmer would have to explicitly decide to call plparseopts for each stream. Anyway, this is all just my thoughts. If no-one has any strong real-world need for this then it possibly isn't worth the effort. Andrew ------------------------------------------------------------------------------ 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
