gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> Here is an updated analysis of the affect of various configuration
> options on the size of the gnuplot executable. All trials were
> compiled using gcc 3.3.2 with CFLAGS "-g -O2" on a 32-bit Athlon.

termsizes.png would be a good plot for the web page.

Dan

Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Ethan M. <merritt@u.washington.edu>]

Here is an updated analysis of the affect of various configuration
options on the size of the gnuplot executable. All trials were
compiled using gcc 3.3.2 with CFLAGS "-g -O2" on a 32-bit Athlon.

  "text" contains the code section itself
  "data" contains initialized constants (e.g. string constants)
  "bss"  contains static declared storage (e.g. int foo[BIG])
  "dec"  is the total text+data+bss

# 11 Jul 2005
#----------------------------------------------------------------
    text     data      bss      dec  filename
#----------------------------------------------------------------
  912159    83428    34144  1029731  gnuplot_default
  904447    83428    34048  1021923  gnuplot_nostrings      -0.8%
  893205    83188    34144  1010537  gnuplot_noimage        -2%
  817009    78380    30912   926301  gnuplot_nopm3d        -10% 
  681291    60492    17920   759703  gnuplot_shortterm+gd  -26%
  666013    59620    14304   739937  gnuplot_shorttermlist -28%
  605467    55304    17664   678435  gnuplot_dumb+gd+x11   -34%

The first 4 were all built with the default set of terminal drivers
(including pdf and gd). The last three were built with default 
configuration options, but a reduced set of terminal drivers
  "shortterm+gd" = dumb post estimate x11 gd
  "shortterm"    = dumb post estimate x11
  "dumb+gd+x11"  = dumb x11 gd


Bottom line conclusion:

  If you want to reduce the size of the gnuplot executable, there is
  very little to be gained by disabling configuration options. Disabling
  pm3d (which automatically disables with-image and binary-polygon also)
  reduces the size by only 10%.

  On the other hand, the driver set is huge. In a default build, 40% of
  the total size of the gnuplot executable is in term.o (not shown).

  For fun, I re-compiled term.o many times with only a single driver
  enabled each time.  The resulting sizes (minus the base size of the
  core code in term.c itself) are shown in the attached plots.


Notes:

  This analysis reveals that omitting a small set of drivers, for
  example (corel tgif tkcanvas tpic), has more effect on size than
  configuring with  --disable-pm3d --disable-with-image

  The recent changes to pslatex.trm have made it impossible to omit
  the pslatex driver from a gnuplot build without hacking the code
  in several places.  I'll rant on this in a separate Email.

  This analysis does not show the effect of compilation options on
  dynamically allocated storage, but this should be a very small
  effect. 

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Gnuplot concerns

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:
> Daniel J Sebald wrote:
> 
>> I wonder why the copyright of 2004 should be attributed to Williams 
>> and Kelly if they were not contributors or didn't oversee development?
> 
> 
> Formally, they did.  Well, one of them at least.  Every release in the 
> last 10 years has been personally "blessed" by Mr. Williams himself.

I suppose, in a remote sense.

>> I don't know a whole lot of copyright law in the case of derived 
>> works, but wouldn't it make more sense 
> 
> 
> In my experience, (American) law and "making sense" are mutually 
> exclusive concepts ;-(

You're making a mockery of our legal system?!...  That's for us to do.

> 
>  > to be something like
> 
>>
>> Copyright 1986 - 1993, 1998  Thomas Williams, Colin Kelly
>> Copyright 2004  Gnuplot Developer Group
> 
> 
> That would be quite impossible, because there is no legal entity called 
> the "Gnuplot Developer Group" to which that 2004 copyright could 
> possibly long. Moreover, the original authors could never have signed 
> over copyright to this non-existing entity.

I suppose that is a big hole in the argument.  It would have to be a person or an actual corporation, which probably gets better protection than personal copyrights; you know how that goes.

Dan

Re: Gnuplot concerns

[Hans-Bernhard B. <br...@ph...>]

Daniel J Sebald wrote:

> I wonder why the copyright of 2004 should be attributed to Williams and 
> Kelly if they were not contributors or didn't oversee development?

Formally, they did.  Well, one of them at least.  Every release in the 
last 10 years has been personally "blessed" by Mr. Williams himself.

> I don't know a whole lot of copyright law in the case of derived works, 
> but wouldn't it make more sense 

In my experience, (American) law and "making sense" are mutually 
exclusive concepts ;-(

 > to be something like
> 
> Copyright 1986 - 1993, 1998  Thomas Williams, Colin Kelly
> Copyright 2004  Gnuplot Developer Group

That would be quite impossible, because there is no legal entity called 
the "Gnuplot Developer Group" to which that 2004 copyright could 
possibly long. Moreover, the original authors could never have signed 
over copyright to this non-existing entity.

RE: Gnuplot concerns

[Ray, W. N <wil...@lm...>]

I thank you for your time and effort in responding.  As I've said in a
previous response, we really enjoy your software and think highly of it,
however we must convince our legal council of the lack of liability,
especially after the whole SCO ordeal.  Your input is appreciated.

Robert Hard wrote:

"are you using pre-compiled gnuplot binaries?"

No, and it seems this will solve the majority of the problems that they
are having with the legal council.

"I am curious how you created this list. Many of the files you refer to
seem to contain the exact same text as the "Copyright" file. e.g. you
list all the terminal drivers as lacking a license, yet virtually all of
them do. In fact, I'm actually struggling to find any files in the
gnuplot source that you haven't listed as lacking a license."

One possible reason for this, as has recently been brought to my
attention is the "European" (as I was told) spelling of the word
license.  The tool that was used to check files did not check for the
word licence (note the c), only license.  So any files that had the
alternative spelling were marked as not having the information, my
apologies for overlooking that if that happens to be the case.

I thank you very much for your suggestions, and the time spent to
respond.  It is very well appreciated.

Regards,
Bill Ray


-----Original Message-----
From: Robert Hart [mailto:en...@no...] 
Sent: Tuesday, July 12, 2005 12:05 PM
To: Ray, William N
Cc: gnu...@li...
Subject: Re: Gnuplot concerns

On Mon, 2005-07-11 at 14:42 -0500, Ray, William N wrote:

> We currently use the Gnuplot package and we are quite pleased with it,
> but our legal council has recommended that we discontinue its use.  We
> have been advised the following problems need to be addressed before
> we can continue to use the tools Gnuplot provides.

are you using pre-compiled gnuplot binaries? if so, I'd have thought the
copyright method that appears at start up, and the "help license"
command is all you need worry about. Also if you are only using gnuplot
on a specific platform (e.g. windows) then many of the files you list
aren't relevant.

>      1. We need to have no more than 1 license covering files in any
>         one directory.  We have been advised against using software
>         with mismatched licensing.

Can you give specific examples of this problem? I vaguely remember
seeing some files licenses in *more permissive* ways than the standard
license - usually stating public domain - or explicitly dual licensing.
Isn't this quite common in open source software?
 
> There are currently 177 files without copyright information as well as
> 418 files without any licensing information.  Is there any
> possibility 

I am curious how you created this list. Many of the files you refer to
seem to contain the exact same text as the "Copyright" file. e.g. you
list all the terminal drivers as lacking a license, yet virtually all of
them do. In fact, I'm actually struggling to find any files in the
gnuplot source that you haven't listed as lacking a license.

> that this information may be added to the files in the next release?  

Any genuine problems that can be cleaned up should be cleaned up.
However, this could require a great deal of work, and it is most likely
to get done if you do as much of it as possible yourself. Note that this
may well require contacting original authors of individual files, and
seeking their permission.

Rob

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an
attachment
may still contain software viruses, which could damage your computer
system:
you are advised to perform your own checks. Email communications with
the
University of Nottingham may be monitored as permitted by UK
legislation.

RE: Gnuplot concerns

[Ray, W. N <wil...@lm...>]

I thank you for your time and effort in your response.  Please
understand these are not my personal problems.  This has all come from
our legal council and we are looking to either justify ourselves to them
or comply with their decisions, so any input is appreciated.

Hans-Bernhard Broeker wrote:

"And what made you think there's more than license, let alone a mismatch

of licenses involved here?

What a directory should have to do with such a legalese issue is 
completely beyond me."

I should have provided a listing of mismatched licenses.  This was
merely told to us by our legal council, I will (and should have)
verified this first before adding this part into the message. 

"Those are, ultimately, impossible requirements.  Among the files you 
listed, there are quite a lot that are generated by other tools we don't

control, and some that simply cannot hold a license or copyright 
statement (graphics, e.g.)."

I believe that the directory the tool was run on was extracted directly
from the source package found on the web.  I can double check that if
there appears to be a discrepancy.  Also, files that are un-editable,
such as image files, etc. have been intentionally excluded.  If in our
ignorance we have failed to exclude some types of un-editable files, any
information as to which file extensions are un-editable that we missed
would be appreciated.

Thank you again for the response, and I sincerely hope we can continue
to use this great software.

Regards,
Bill Ray

-----Original Message-----
From: Hans-Bernhard Broeker [mailto:br...@ph...] 
Sent: Tuesday, July 12, 2005 11:04 AM
To: Ray, William N
Cc: gnu...@li...
Subject: Re: Gnuplot concerns

Ray, William N wrote:
> We currently use the Gnuplot package and we are quite pleased with it,
> but our legal council has recommended that we discontinue its use.  

Congratulations --- you may be the first company ever to try and 
investigate this deeply into the matter.

> 1.	We need to have no more than 1 license covering files in any one
> directory.  We have been advised against using software with
mismatched
> licensing.

And what made you think there's more than license, let alone a mismatch 
of licenses involved here?

What a directory should have to do with such a legalese issue is 
completely beyond me.

> 2.	There are several files without any licensing information.
[...]
> 3.	There are several files without any copyright.

Those are, ultimately, impossible requirements.  Among the files you 
listed, there are quite a lot that are generated by other tools we don't

control, and some that simply cannot hold a license or copyright 
statement (graphics, e.g.).

(I hope this one makes it through --- I already had one bounce off the 
e-mail address you used).

Re: Gnuplot concerns

[Daniel J S. <dan...@ie...>]

Lars Hecking wrote:

>  All files without explicit licensing or copyright information are subject
>  to the gnuplot Copyright terms
> 
>   http://cvs.sourceforge.net/viewcvs.py/gnuplot/gnuplot/Copyright?view=auto

One thing that is slightly strange is

 * Copyright 1986 - 1993, 1998, 2004   Thomas Williams, Colin Kelley

I wonder why the copyright of 2004 should be attributed to Williams and Kelly if they were not contributors or didn't oversee development?

I don't know a whole lot of copyright law in the case of derived works, but wouldn't it make more sense to be something like

Copyright 1986 - 1993, 1998  Thomas Williams, Colin Kelly
Copyright 2004  Gnuplot Developer Group

and then have some kind of notice in the license that any third party patches considered an extension and used by the developer group will automatically become copyright by the developer group?

Dan

Re: Gnuplot concerns

[Daniel J S. <dan...@ie...>]

Lars Hecking wrote:
>  The files you emailed us are meaningless. Word documents are not welcome on
>  this list.

Also, emailing your lists as ASCII would have been one fourth the size.


> > 3.    There are several files without any copyright.
> 
> 
> Those are, ultimately, impossible requirements.  Among the files you
> listed, there are quite a lot that are generated by other tools we
> don't control, and some that simply cannot hold a license or copyright
> statement (graphics, e.g.).

Narrowing down the list might help developers identify (if any) files that definitely should have a copyright and license notice.  Did you run your list generating program before doing a compilation?

Dan

Re: Gnuplot concerns

[Robert H. <en...@no...>]

On Mon, 2005-07-11 at 14:42 -0500, Ray, William N wrote:

> We currently use the Gnuplot package and we are quite pleased with it,
> but our legal council has recommended that we discontinue its use.  We
> have been advised the following problems need to be addressed before
> we can continue to use the tools Gnuplot provides.

are you using pre-compiled gnuplot binaries? if so, I'd have thought the
copyright method that appears at start up, and the "help license"
command is all you need worry about. Also if you are only using gnuplot
on a specific platform (e.g. windows) then many of the files you list
aren't relevant.

>      1. We need to have no more than 1 license covering files in any
>         one directory.  We have been advised against using software
>         with mismatched licensing.

Can you give specific examples of this problem? I vaguely remember
seeing some files licenses in *more permissive* ways than the standard
license - usually stating public domain - or explicitly dual licensing.
Isn't this quite common in open source software?
 
> There are currently 177 files without copyright information as well as
> 418 files without any licensing information.  Is there any
> possibility 

I am curious how you created this list. Many of the files you refer to
seem to contain the exact same text as the "Copyright" file. e.g. you
list all the terminal drivers as lacking a license, yet virtually all of
them do. In fact, I'm actually struggling to find any files in the
gnuplot source that you haven't listed as lacking a license.

> that this information may be added to the files in the next release?  

Any genuine problems that can be cleaned up should be cleaned up.
However, this could require a great deal of work, and it is most likely
to get done if you do as much of it as possible yourself. Note that this
may well require contacting original authors of individual files, and
seeking their permission.

Rob

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: Gnuplot concerns

[Hans-Bernhard B. <br...@ph...>]

Ray, William N wrote:
> We currently use the Gnuplot package and we are quite pleased with it,
> but our legal council has recommended that we discontinue its use.  

Congratulations --- you may be the first company ever to try and 
investigate this deeply into the matter.

> 1.	We need to have no more than 1 license covering files in any one
> directory.  We have been advised against using software with mismatched
> licensing.

And what made you think there's more than license, let alone a mismatch 
of licenses involved here?

What a directory should have to do with such a legalese issue is 
completely beyond me.

> 2.	There are several files without any licensing information.
[...]
> 3.	There are several files without any copyright.

Those are, ultimately, impossible requirements.  Among the files you 
listed, there are quite a lot that are generated by other tools we don't 
control, and some that simply cannot hold a license or copyright 
statement (graphics, e.g.).

(I hope this one makes it through --- I already had one bounce off the 
e-mail address you used).

Re: Gnuplot concerns

[Lars H. <lhe...@us...>]

 The files you emailed us are meaningless. Word documents are not welcome on
 this list.

> 1.	We need to have no more than 1 license covering files in any one
> directory.  We have been advised against using software with mismatched
> licensing.
 
 All files without explicit licensing or copyright information are subject
 to the gnuplot Copyright terms

  http://cvs.sourceforge.net/viewcvs.py/gnuplot/gnuplot/Copyright?view=auto

> 2.	There are several files without any licensing information.  We
> have been advised that we would be putting ourselves at risk if we do
> not have specific licensing information for every file. 
 
 See above.

> 3.	There are several files without any copyright.  We have also
> been counseled that we would be putting ourselves at risk if we used
> files without any copyright on them. 
 
 See above.

Re: user-defined function & string file name

[Juergen W. <wie...@fr...>]

On Tuesday 28 June 2005, Ethan Merritt wrote:
> I will consolidate the (isstring() || isstringvar()) test into a single
> call isstringvalue().  This simplifies the code, which is good.
> If/when Juergen comes up with a fully working isstringfunc(), that can be
> added at a single point in isstringvalue().

I have uploaded a patch addressing the plot/splot problem [#1231847,
str_or_express-2005-07-09.patch].  As far as I can see, it works
sensible in almost all cases.  The only known failure case is

gnuplot> x = "file"
gnuplot> f(x) = x . ".dat"
gnuplot> plot f(x)

where it assumes f(x) to be a function plot.  But anyone careless
enough to use a dummy name in such a way ...


The second patch [#1231847, get_string-2005-07-09.patch] introduces
the function isexpr().  The idea is to provide a set of functions,
which do as many work as possible.

For example:
* get_string():
   Read in string.  If there is none, int_error().
   Probably a more concise error message could be given from the
   calling function.

* try_to_get_string()
   Read in string if there is one.  If there is none, no operation.
   Implementation draft:

   save_token = c_token;
   result = NULL;
   if (isexpr()) {
      struct value a;
      const_expr(&a);
      if (a.type == STRING)
         result = a.v.string_val;
      else
         c_token = save_token;
      gpfree_string(&a);
   }

* get_number()

* try_to_get_number()

* get_number_or_string():
   Well, basically the same as const_expr() now.

* try_to_get_number_or_string()

The latter two functions would be easier to implement without the
GP_STRING_VARS conditionals.  They can also be written similar to
str_or_express(), though.

In my opinion such functions should allow for some simplification to
the current code.  What do you think?  Is this worth going on?


Juergen

PS: I won't read my mails a week or so because I'm on holiday.

Re: garbage collection

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

> On Friday 08 July 2005 01:57 am, Dave Denholm wrote:
>> That reminds me...  there's a couple of memory/cleanup issues been
>> mentioned recently, and IIRC, there used to be a problem with
>> memory leaks if SIGINT is sent during a plot, since the exact state is
>> unknown, and so data structures cannot safely be traversed and freed.
>
> SIGINT while actually in the eval_plots code must be a rare occurance,
> so I'm not sure how much effort we should put into worrying about it.
> SIGINT to terminate a "pause for mouse" is much more common, but I can't
> see why that would lead to any leaks.
>  
>> allocated blocks are kept in linked lists : say a list of "permanent"
>> blocks (eg udf's)
>
> This is already done. The listhead for udvs is first_udv, the listhead
> for labels is first_label, and so on. 
>

I'm talking about the blocks themselves. The memory system maintains a
list of all blocks it has given out.

Whether the blocks are also linked into other lists (such as lists of
plots, or lists of udf, or whatever) is at a higher level.

>> and a list of transient blocks (allocated during a 
>> plot, for example). 
>

Acutally, it's simpler than that. Can have one list of blocks. The
reference count is for "permanent" references. Transient blocks have a
zero ref. count. Then a gc happens at the end of every transaction,
and just reaps everything with 0 reference count.

using a block for a udf means that it picks up a ref count, and so the
memory manager doesn't reclaim the memory until the udf code drops the
reference.

Could also store a pointer to an "owner" block. Eg all blocks
allocated by a udf would reference that block. When the owner is
reaped, all the blocks marked as belonging to it get reaped.

The point is just that you do a little more work when you allocate a
block (to tell the memory manager what its properties are), but then
you don't have to bother finding blocks to free afterwards, because
the memory manager is doing the work of tracking stuff.



> Hmmm.  I think this is also already done, although maybe I am overlooking
> a category of allocated space.  The major dynamic allocations for a plot
> are referenced by elements of the corresponding   struct curve_points,
> and these structures are themselves linked into a list.
>
>> At end of a plot, everything in the transient list is reclaimed.
>
> The previous allocations are freed at the time a new plot is built up.
> This should work even if the previous plot was interrupted by SIGINT.
>  

The difference is just that in a gc scheme, at the end of the plot you
just tell the memory manager to find and free all transient
blocks. You don't have to traverse data structures finding things.

Ditto for freeing a udf : you don't have to explicitly look along the
actions freeing string literals. You just drop the ref. count on the
primary udf block, and the memory manager does all the rest of the
work,


>> Need to be a little careful with registration of non-trivial objects,
>> to make sure things are atomic wrt SIGINT. 
>
> That is indeed an issue in principle (but hard to debug I think!).
>
> New allocations (udv, whole plots, ...) are added at the end of a
> linked list. But this allocate+link operation is not guaranteed 
> atomic by the current code.   I'm not particularly worried by the
> possibily of leaking a single newly-allocated block. But if the
> SIGINT were to occur at just the  wrong time, the final list link
> pointer itself could become corrupt. That would show up as a
> segfault rather than a memory leak.
>
>    new_element = &(current_end_of_list->next);
>    new_element = gp_alloc(...);
>                     <<<<  SIGINT here is bad news
>    new_element->next = NULL;
>

Don't know about you, but I would never write it in that order anyway.

> This is fixable, either by careful audit of all the routines that
> do list insertion or by modifying gp_alloc to zero out new space
> before returning it.  
>


In the proposed scheme, there is exactly one place where the blocks
are registered - in the memory manager. So there's only one place to
worry about getting it right. All the clients of the memory system
just ask for permanent or transient blocks.

But anyway, need to be careful when manipulating "permanent" blocks,
but for transient blocks, you never need to worry. The memory mananger
doesn't follow the clients unsafe links, but only follows its own
"safe" links.


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: garbage collection (was Re: gpfree_string within temp_at())

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Friday 08 July 2005 01:57 am, Dave Denholm wrote:
>>Need to be a little careful with registration of non-trivial objects,
>>to make sure things are atomic wrt SIGINT. 
> 
> 
> That is indeed an issue in principle (but hard to debug I think!).
> 
> New allocations (udv, whole plots, ...) are added at the end of a
> linked list. But this allocate+link operation is not guaranteed 
> atomic by the current code.  I'm not particularly worried by the
> possibily of leaking a single newly-allocated block. But if the
> SIGINT were to occur at just the  wrong time, the final list link
> pointer itself could become corrupt. That would show up as a
> segfault rather than a memory leak.
> 
>    new_element = &(current_end_of_list->next);
>    new_element = gp_alloc(...);
>                     <<<<  SIGINT here is bad news
>    new_element->next = NULL;
> 
> This is fixable, either by careful audit of all the routines that
> do list insertion or by modifying gp_alloc to zero out new space
> before returning it.  

I think the only true way to fix that sort of thing is if SIGINT is disabled before starting the memory allocation and re-enabled after recording the pointer in the linked list.  Otherwise, the same problem can still occur inside gp_alloc() I would think.

Dan

Re: garbage collection (was Re: gpfree_string within temp_at())

[Ethan M. <merritt@u.washington.edu>]

On Friday 08 July 2005 01:57 am, Dave Denholm wrote:
> That reminds me...  there's a couple of memory/cleanup issues been
> mentioned recently, and IIRC, there used to be a problem with
> memory leaks if SIGINT is sent during a plot, since the exact state is
> unknown, and so data structures cannot safely be traversed and freed.

SIGINT while actually in the eval_plots code must be a rare occurance,
so I'm not sure how much effort we should put into worrying about it.
SIGINT to terminate a "pause for mouse" is much more common, but I can't
see why that would lead to any leaks.
 
> allocated blocks are kept in linked lists : say a list of "permanent"
> blocks (eg udf's)

This is already done. The listhead for udvs is first_udv, the listhead
for labels is first_label, and so on. 

> and a list of transient blocks (allocated during a 
> plot, for example). 

Hmmm.  I think this is also already done, although maybe I am overlooking
a category of allocated space.  The major dynamic allocations for a plot
are referenced by elements of the corresponding   struct curve_points,
and these structures are themselves linked into a list.

> At end of a plot, everything in the transient list is reclaimed.

The previous allocations are freed at the time a new plot is built up.
This should work even if the previous plot was interrupted by SIGINT.
 
> Need to be a little careful with registration of non-trivial objects,
> to make sure things are atomic wrt SIGINT. 

That is indeed an issue in principle (but hard to debug I think!).

New allocations (udv, whole plots, ...) are added at the end of a
linked list. But this allocate+link operation is not guaranteed 
atomic by the current code.  I'm not particularly worried by the
possibily of leaking a single newly-allocated block. But if the
SIGINT were to occur at just the  wrong time, the final list link
pointer itself could become corrupt. That would show up as a
segfault rather than a memory leak.

   new_element = &(current_end_of_list->next);
   new_element = gp_alloc(...);
                    <<<<  SIGINT here is bad news
   new_element->next = NULL;

This is fixable, either by careful audit of all the routines that
do list insertion or by modifying gp_alloc to zero out new space
before returning it.  

Am I missing other issues?


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

garbage collection (was Re: gpfree_string within temp_at())

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

> On Wednesday 06 July 2005 02:36 pm, Juergen Wieferink wrote:
>> But I have placed the "#ifdef" quite funny, did you notice?  
>
> I noticed. But then, we *had* been discussing whether to remove
> the conditional coding around string variables. I figured you
> were just off to a quick start :-) 
>

That reminds me...  there's a couple of memory/cleanup issues been
mentioned recently, and IIRC, there used to be a problem with
memory leaks if SIGINT is sent during a plot, since the exact state is
unknown, and so data structures cannot safely be traversed and freed.

I was wondering if there's a case for some sort of garbage
collection. Nothing sophisticated like moving memory around, updating
pointers, etc. Just simple reference counting (probably).
Perhaps something along the lines of:

allocated blocks are kept in linked lists : say a list of "permanent"
blocks (eg udf's), and a list of transient blocks (allocated during a
plot, for example). At end of a plot, everything in the transient list
is reclaimed.

items can have a reference count (eg for strings, rather than making a
copy, just increase the ref count on copy, and decrease it when the
string goes out of scope)

items can have cleanup routines.
 - eg for the recent issue with c++ destructors, the cleanup routine
 could be a c++ fn to cleanup objects
 - cleanup routine for an 'at' can in turn free string literals, etc.


Need to be a little careful with registration of non-trivial objects,
to make sure things are atomic wrt SIGINT. But I think it should be
do-able. All the allocation used to go through a common routine, so
it shouldn't be hard to intercept all allocs and frees.


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

gnuplot manual misprint (no.17)

[Shigeharu T. <sh...@ie...>]

shige 07/08 2005
----------------

In gnuplot.doc of current CVS version

 C RCS $Id: gnuplot.doc,v 1.311 2005/07/06 22:01:00 sfeam Exp $

I found some points that seem to be misprints. I send the unified
diff file for them.

----- From here -----
--- gnuplot.doc~	2005-07-08 11:04:22.000000000 +0900
+++ gnuplot.doc	2005-07-08 11:18:02.000000000 +0900
@@ -8394,7 +8394,7 @@
        plot 'file.dat' using 2, '' using 4, '' using 6:xtic(1) 
 
  This will produce a plot in which each vertical bar contains a stack of three
- segments, corresponding in height to the values found in columns 2, 4 and 3
+ segments, corresponding in height to the values found in columns 2, 4 and 6
  of the datafile.
 
  Finally, the commands
@@ -8405,7 +8405,7 @@
  will produce three vertical stacks. The stack at x=1 will contain a box for
  each entry in column 2 of the datafile.  The stack at x=2 will contain a box
  for each parallel entry in column 4 of the datafile, and the stack at x=3 a
- box for each entry of column 3.  Because this interchanges gnuplot's usual
+ box for each entry of column 6.  Because this interchanges gnuplot's usual
  interpretation of input rows and columns, the specification of key titles and
  x-axis tic labels must also be modified.
----- To here ----- 
+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: word(s) patch

[Petr M. <mi...@ph...>]

> I don't know either.  Perhaps I should just remove the substr()
> function altogether.  That would make a clear distinction between
> the operation  STRING[beg:end]  (uses C-language indexing from 0)
> and the function calls like word(STRING,N)  (uses rexx or fortran
> indexing starting from 1).
>
> But I agree that the substr(beg,end) indexing is confusing, and
> contradicts the awk equivalent  substr(beg,length) regardless
> of whether beg starts at 0 or 1.
>
> Petr: What are your thoughts?  It was your suggestion to include
> a subroutine form of the substring operator (and it was utterly
> trivial to implement).  But it may add more confusion than it is
> worth.

I propose the substr() be compatible to awk (i.e. indexing from 1 and with 
parameter giving length of the substring).

---
PM

Re: Key layout

[Daniel J S. <dan...@ie...>]

OK, I'm done with the key layout, unless there is something people want added.  I suggest adding this patch soon.  Syntax is good, I think.  The code is cleaner than the current.  We can touch up and loose ends rather easily after the fact.

The 3D key box may not be as robust as 2D (still works the same for the demos), but I say let's cross that bridge when we come to it.  (I'd propose unifying 2D/3D as a better alternative than attempting a complete revamping of 3D key.)

The 'all.dem' will show three or four plots as slightly different.  For example, in the current CVS version, simple.dem has:

set key outside below
plot [-5*pi:5*pi] [-5:5] real(tan(x)/atan(x)), 1/x
pause -1 "Hit return to continue"

set key left box
set autoscale
set samples 800
plot [-30:20] sin(x*20)*atan(x)
pause -1 "Hit return to continue"

Currently, that "set key left" seems to do nothing at all, as it may not make sense in the current cvs.  (The key stays "below" from the previous plot.)  The new setup will position the key below and to the left.

Something that is strange in current CVS is prob.dem:

set key bottom outside
plot [0:2] [0:1.1] a = 2.0, n = 1, sine(x) title "a = 2.0, n = 1", \
                   a = 2.0, n = 3, sine(x) title "a = 2.0, n = 3"
pause -1 "Hit return to continue"
set title "sine CDF"
set key top left
plot [0:2] [0:1.1] a = 2.0, n = 1, csine(x) title "a = 2.0, n = 1", \
                   a = 2.0, n = 3, csine(x) title "a = 2.0, n = 3"

puts the key of the second plot at the *inside* of the plot.  Now that seems like a silly behavior to be backward compatible to.  (For the synonyms "above", "below", "under", "over" assuming a position is fine, but not the more abstract "top left".)  I'd suggest changing prob.dem to "set key top left inside" if the plots in that demo are to remain as is.

I looked at the set_label() code Hans pointed out.  That is a creative way of implementing conflicting keywords (and I notice that nothing is changed until the whole line syntax is verified).  However, I'm going to leave the warnings I implemented as is; for two reasons.  One, what I've done is slightly more flexible if detailed warnings are desired.  Two, the warnings (as opposed to error) will not cause the "outside below" of the above example to fail during the demos.  We then have examples of doing this a variety of ways and can discuss pros/cons on the list.

So, the July 7 patch should do nicely.

Dan

Re: gpfree_string within temp_at()

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 06 July 2005 02:36 pm, Juergen Wieferink wrote:
> But I have placed the "#ifdef" quite funny, did you notice?  

I noticed. But then, we *had* been discussing whether to remove
the conditional coding around string variables. I figured you
were just off to a quick start :-) 

> I don't think there is much reason to hurry, 
> so I'd suggest to wait.

OK.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Key layout

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:
> Daniel J Sebald wrote:
> 
>> gnuplot> set key right outside top right
>>                                   ^
>>         warning: Multiple horizontal position settings
>>
>> where the second occurrence of the horizontal position overrides the 
>> first occurrence?  This would be setting a precedent perhaps for 
>> multiple specs for all commands?  
> 
> 
> Actually I think we already have some precedence for repeated options. 
> See set.c:set_label(), and all the TBOOLEAN flags like set_position are 
> handled: repetition of "strong" options is treated as an error:
> 
> gnuplot> set label 'text' at 1,2 at 3,4
>                                  ^
>          extraneous or contradicting arguments in label options
> 
> The difference in your current "set key" is that some options' effects 
> are "weak", i.e. they only set a default for some other choice, which is 
> expressly allowed to be overwritten by an explicit specification.

Yes, but there are a large number where an obvious conflict is present.  How about creating a special error for this?  Something that might be called as:

int_conflict_error(c_token, "label");
int_conflict_error(c_token, "key");

Dan

PS:  I forgot the revamped key documentation:

[...]
 Syntax:
       set key {on|off} {default}
               {{inside | outside} | {lmargin | rmargin | tmargin | bmargin}
                 | {at <position>}}
               {left | right | center} {top | bottom | center}
               {vertical | horizontal} {Left | Right}
               {{no}reverse} {{no}invert}
               {samplen <sample_length>} {spacing <vertical_spacing>}
               {width <width_increment>}
               {height <height_increment>}
               {{no}autotitle {columnheader}}
               {title "<text>"} {{no}enhanced}
               {{no}box { {linestyle | ls <line_style>}
                          | {linetype | lt <line_type>}
                            {linewidth | lw <line_width>}}}
       unset key
       show key

 Plots may be drawn with no visible key by requesting `set key off` or
 `unset key`.

 Elements within the key are stacked according to `vertical` or `horizontal`.
 In the case of `vertical`, the key occupies as few columns as possible.  That
 is, elements are aligned in a column until running out of vertical space at
 which point a new column is started.  In the case of `horizontal`, the key
 occupies as few rows as possible.

 By default the key is placed in the upper right inside corner of the graph.
 The keywords `left`, `right`, `top`, `bottom`, `center`, `inside`, `outside`,
 `lmargin`, `rmargin`, `tmargin`, `bmargin` (, `above`, `over`, `below` and
 `under`) may be used to automatically place the key in other positions of the
 graph.  Also an `at <position>` may be given to indicate precisely where the
 plot should be placed.  In this case, the keywords `left`, `right`, `center`,
 `bottom` and `center` serve an analogous purpose for alignment.

 To understand positioning, the best concept is to think of a region, i.e.,
 inside/outside, or one of the margins.  Along with the region, keywords
 `left/center/right` (l/c/r) and `top/center/bottom` (t/c/b) control where
 within the particular region the key should be placed.

 When in `inside` mode, the keywords `left` (l), `right` (r), `top` (t),
 `bottom` (b), and `center` (c) push the key out toward the plot boundary as
 illustrated:

      t/l   t/c   t/r

      c/l   c     c/r

      b/l   b/c   b/r


 When in `outside` mode, automatic placement is similar to the above
 illustration, but with respect to the view, rather than the graph boundary.
 That is, a border is moved inward to make room for the key outside of
 the plotting area, although this may interfere with other labels and may
 cause an error on some devices.  The particular plot border that is moved
 depends upon the position described above and the stacking direction.  For
 options centered in one of the dimensions, there is no ambiguity about which
 border to move.  For the corners, when the stack direction is `vertical`, the
 left or right border is moved inward appropriately.  When the stack direction
 is `horizontal`, the top or bottom border is moved inward appropriately.

 The margin syntax allows automatic placement of key regardless of stack
 direction.  When one of the margins `lmargin` (lm), `rmargin` (rm),
 `tmargin` (tm), and `bmargin` (bm) is combined with a single, non-conflicting
 direction keyword, the following illustrated positions may contain the key:

           l/tm  c/tm  r/tm

      t/lm                  t/rm

      c/lm                  c/rm

      b/lm                  b/rm

           l/bm  c/bm  r/bm


 Keywords `above` and `over` are synonymous with `tmargin`.  For version
 compatibility, `above` or `over` without an additional l/c/r or stack direction
 keyword uses `center` and `horizontal`.  Keywords `below` and `under` are
 synonymous with `bmargin`.  For compatibility, `below` or `under` without an
 additional l/c/r or stack  direction keyword uses `center` and `horizontal`.  A
 further compatibility issue is that `outside` appearing without an additional
 t/b/c or stack direction keyword uses `top`, `right` and `vertical` (i.e., the
 same as t/rm above).

 The <position> can be a simple x,y,z as in previous versions, but these can
 be preceded by one of five keywords (`first`, `second`, `graph`, `screen`,
 `character`) which selects the coordinate system in which the position of
 the first sample line is specified.  See `coordinates` for more details.
 The effect of `left`, `right`, `top`, `bottom`, and `center` when <position>
 is given is to align the key as though it were text positioned using the
 label command, i.e., `left` means left align with key to the right of
 <position>, etc.
[...]

Re: UTF8 encoding

[Robert H. <en...@no...>]

On Tue, 2005-07-05 at 12:37 -0700, Ethan Merritt wrote:

> As I understand it, a single character glyph may have more than one legal
> representation in UTF-8.  So =E4 =F6 =FC each have a one-byte representat=
ion
> (\344 \366 \374 if the encoding is iso8559-1 or iso8559-15) and also have
> a multibyte unicode representation (C3A4 C3B6 C3BC).

I think you are confused. In UTF-8 only characters 0-127 are encoded in
one byte. There is no equivalence between UTF-8 and iso8559-* except for
the basic ASCII part.

i.e. any characters with accents, or in foreign scripts are always
multibyte in UTF-8.

see, http://en.wikipedia.org/en/utf-8/

Interestingly gnuplot fails to detect my locale. I have
LANG=3Den_GB.UTF-8, but gnuplot falls back to C. I will investigate
further when I have the time.

Rob

--=20
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: Key layout

[Hans-Bernhard B. <br...@ph...>]

Daniel J Sebald wrote:
> gnuplot> set key right outside top right
>                                   ^
>         warning: Multiple horizontal position settings
> 
> where the second occurrence of the horizontal position overrides the 
> first occurrence?  This would be setting a precedent perhaps for 
> multiple specs for all commands?  

Actually I think we already have some precedence for repeated options. 
See set.c:set_label(), and all the TBOOLEAN flags like set_position are 
handled: repetition of "strong" options is treated as an error:

gnuplot> set label 'text' at 1,2 at 3,4
                                  ^
          extraneous or contradicting arguments in label options

The difference in your current "set key" is that some options' effects 
are "weak", i.e. they only set a default for some other choice, which is 
expressly allowed to be overwritten by an explicit specification.

Re: Question about gnuplot v 4.0

[Hans-Bernhard B. <br...@ph...>]

Luca Montabone wrote:
> I would like to know how is possible to write a text  in colour in a
> legend, by using the combination of <set key> and the command
> <title> in <plot>

Not in any way independent of the choice of terminal driver, I think.

I.e. some will do it by themselves, or governed by some option, others 
won't do it at all.  There's no direct control over this; neither 'plot 
... title' nor 'set key' have a textcolour option.

> The previous version of Gnuplot was doing it automatically, the version
> 4.0 does not..

Using which terminal driver?  Did you check the help for that driver to 
see if the old behaviour can perhaps be turned back on by some new option?

Re: Key layout

[Daniel J S. <dan...@ie...>]

Does the following warning make sense to people?

gnuplot> set key lmargin top right
         warning: Ignoring left/center/right; incompatible with lmargin/tmargin.

That is, the region (lmargin/rm/tm/bm) trumps position (l/r/t/b/c) and "right" is ignored in this case.

The above type of warning should definitely be issued.  How about warnings such as

gnuplot> set key right outside top right
                                   ^
         warning: Multiple horizontal position settings

where the second occurrence of the horizontal position overrides the first occurrence?  This would be setting a precedent perhaps for multiple specs for all commands?  All/nothing?  Take out?

Dan