Hi,
I'm sorry that I needed such a long time to think about that problem,
but it needed some time to understand the source code behind all that
(apart from doing much other stuff). Anyway, I think now that I have
understood most of the code and how it was intended to be used. There is
actually a difference between the common options and the driver options
in coding and in usage. While common options are processed during the
SetOpt() call, are the driver options saved, so that they can be
processed during the driver initialization (exactly once). Also the
common options are not remembered, e.g. if you call SetOpt("-geometry
800x600") before one driver initialisation, it will have no effect on a
later driver initialisation.
Your patch applied will have the effect, that the driver options are
remembered (as it is now btw.). This is in my opinion not consistent and
will lead to errors. Apart from that, drivers don't have too much
options in common, especially the interactive drivers and the file
drivers, which is the usual case where you encounter problems with the
"remembered" driver options. E.g. the wingcc driver has the following
options: freetype, smooth and save_reg, while the ps driver has text,
color and hrshsym. Your solution would lead to an program abort, if I
would set the freetype and smooth option, which is not known by the ps
driver. I would have to explicitly delete the options. So the
unexperienced programmer will encounter a problem, which may not be
exactly clear at the first sight. If the options are deleted after
initialization, the worst what will happen is, that e.g. the png driver
will not have nice font rendering, but no program abort. And the
programmer would then know, that he has to set the options again.
So the solution I think is the most appropriate is, that the driver
options are deleted right after driver initialization. Therefore, before
you initialize a new driver you always start with no driver options set.
I committed this changes. To test them, try the following.
Before you update the code base, run
./x01c -dev xwin -drvopt nobuffered=1 -save t.ps
After you press enter, the program will abort, no file saved.
After the update, run
./x01c -dev xwin -drvopt nobuffered=1 -save t.ps
everything works as expected.
Reading through this thread Alan mentions the multi stream example 14 -
this still works (i.e. the driver options are valid for both streams)
e.g. for wxwidgets driver. Reason is, that I set static variables, which
are still have the same values during the second call of plinit(). But
this leads to a different question I'll raise in my next email.
Best Regards,
Werner
Jonathan Woithe wrote:
> Hi Werner
>
>> thanks again for your comments and for the patches. As usual I already
>> worked on a fix and in fact made nearly the identical changes to the
>> code as you suggested (commited to svn just now). About the merging
>> the options - this we should discuss here on the list. I conclude now
>> everything and ask the list for comments:
>>
>> Before the commit:
>> - every time plsetopt was called the saved (command line options
>> and options set with plsetopt) *driver* options were forgotten
>> (leading to a memory leak) even if you didn't set driver options but
>> other options like "geometry"
>
> That is what I concluded, yes.
>
>> After the commit:
>> - every time driver option are set (at command line or with
>> plsetopt()) driver options set before are "forgotten" (without memory
>> leak). If other options (e.g. plsetopt("geometry","800x600")) are set
>> which are not driver specific the driver options are still "remembered".
>
> That's certainly better, but as you said:
>
>> The only problem now is, that you can't delete already set drv_opt
>> without setting new ones - but some drivers don't take any specific
>> driver options.
>
> The ability to delete existing options I think would be helpful if we can
> work out a way to make it happen without contradicting other assumptions
> within the PLplot option parsing mechanism.
>
>> Jonathan, your merge code contradicts the driver
>> options policy, since as far as I understand it, the following code >>
>> plsetopt( "drvopt", "text" ); << would cause the option text to be
>> deleted if it was already set. But such code should actually set the
>> driver option text to the value 1.
>
> Um no, that was certainly not the intention. Since no "=" sign is given in
> your example the value should be set to 1 before opt_drvopt_merge() is
> called. Thus the original behaviour regarding default values is retained.
>
> What *will* happen is if you instead call
>
> plsetopt( "drvopt", "text=" );
>
> then that will trigger a delete operation on any existing driver option
> called "text".
>
> This behaviour comes about due to the structure of opt_drvopt(). Before
> calling opt_drvopt_merge() "fl" is checked and if it's zero then a default
> value is set. fl will be 0 only if no "=" has occurred within the option
> specification, and it is this behaviour that the delete functionality
> exploits.
>
>> Also, I'm not sure if merging is needed (it was also my first thought in
>> the beginning), since the options for the different drivers are not
>> identical anyway, so for a new driver you need to clean the options table
>> anyway.
>
> The reason why merging appealed to me is that it could simplify program flow
> in some circumstances. If one is setting device options based on a number
> of conditionals, a merging plsetopt() means this can happen cumulatively. If
> it's "all or nothing" then one has to keep adding options to a string buffer
> and then do a single plsetopt() at the end. Furthermore, if merging is not
> done then I *think* any device options given on the command line will be
> immediately lost when plsetopt() is called.
>
> Merging is also closely related to the idea of changing the value of an
> existing options (something else my patch allows). If we don't do merging
> one has to keep track of all options currently in use and reconstruct an
> entire option string whenever one needs to change only one option. Given
> the alternative of just re-setting the option concerned, the resulting code
> would be rather messy.
>
> To help put some of this into context, I came across this whole issue while
> working on changes which give the ability to use the xcairo driver to draw
> into an X Drawable rather than a managed window. I hope to post a
> proof-of-concept patch in a few days once I've ironed out one or two rough
> edges.
>
>> So, I'm not sure if it makes sense to merge options. Still now it's
>> not possible to clean the drv_opt table which I think is necessary.
>
> To clean the option table we could just special-case a call of
>
> plsetopt( "drvopt", "" );
>
> to mean "clean the driver options table". Or we could reserve the "delete"
> pseudo-option to trigger this behaviour.
>
> Regards
> jonathan
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
email: [EMAIL PROTECTED]
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
+43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
