plplot-devel — Technical discussion about PLplot development

[Plplot-devel] Fortran binding: finally happy with plGetCursor

[Alan W. I. <ir...@be...>]

Hi Arjen:

The subject line pretty much says it all.  Please take a look at my
latest commit (see
<http://sourceforge.net/p/plplot/plplot/ci/282983e825f9a7814a06001844e294447e928373/>)
and let me know what you think of the new/improved plplot_graphics
module.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Disambiguation issue still exists

[Alan W. I. <ir...@be...>]

On 2016-01-21 07:43-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> I was pretty proud of that implementation, but there is a "slight" problem with it
>> which is it does not work!  :-(
>>
> Well, the idea was a good one, pity about the failure.
>
>> So the question is whether this peculiar behaviour is due to a gfortran bug or due to
>> an issue with the Fortran standard for disambiguation, and I hope you will continue
>> to pursue that question with your Fortran contacts.
>>
>> Meanwhile, I will throw away the above "good" idea and continue with the (double-
>> precision only) status quo for plstransform (and plslabelfunc).
>>

> I know of one way to solve this: the procedure arguments should be
functions that return data of a distinguishable type. For instance:
the transform callback should return the new coordinates as an array
of two reals (either single or double precision). That is much less
natural for the label function. We could require that that too returns
some single/double precision value, for instance the argument that
came in, but it feels like a kludge.

> The whole thing is evolving - in Fortran 2015 more is possible
(currently there is a thread on the Intel Forum where this is
discussed), but that is no solution for the moment.

> In view of all this, I think we should either use the "only double
precision" solution or go for the function solution, however kludgy
that feels.

If you read through the current Fortran documentation I just updated
(commit 282983e), I think I explain the current limitation on
plstransform and plslabelfunct pretty well so I am reasonably happy to
stick with the double-precision only solution that we now have, and if
the issue is actually resolved by Fortran 2015, then when that becomes
commonplace on all Fortran compilers (probably 2020 or later) we can
think again.

Thanks very much for reviewing the current status of this evolving
Fortran issue.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Disambiguation issue still exists

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> I was pretty proud of that implementation, but there is a "slight" problem with it
> which is it does not work!  :-(
>
Well, the idea was a good one, pity about the failure.

> So the question is whether this peculiar behaviour is due to a gfortran bug or due to
> an issue with the Fortran standard for disambiguation, and I hope you will continue
> to pursue that question with your Fortran contacts.
>
> Meanwhile, I will throw away the above "good" idea and continue with the (double-
> precision only) status quo for plstransform (and plslabelfunc).
>
I know of one way to solve this: the procedure arguments should be functions that return data of a distinguishable type. For instance: the transform callback should return the new coordinates as an array of two reals (either single or double precision). That is much less natural for the label function. We could require that that too returns some single/double precision value, for instance the argument that came in, but it feels like a kludge.

The whole thing is evolving - in Fortran 2015 more is possible (currently there is a thread on the Intel Forum where this is discussed), but that is no solution for the moment.

In view of all this, I think we should either use the "only double precision" solution or go for the function solution, however kludgy that feels.

Regards,

Arjen





DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-devel] Disambiguation issue still exists

[Alan W. I. <ir...@be...>]

On 2016-01-20 12:23-0000 Arjen Markus wrote:

> As for your idea for diambiguation: that ought to work, I think. I will have a close look at that aspect.

Here is the code I used to implement my idea:
     ...
     interface plstransform
         module procedure plstransform_impl
     end interface plstransform
     private :: plstransform_impl
     ...
contains
...
subroutine plstransform_impl( proc_single, proc_data_single, proc_double, proc_data_double, data )
     procedure(pltransform_proc_single), optional :: proc_single
     procedure(pltransform_proc_data_single), optional :: proc_data_single
     procedure(pltransform_proc_double), optional :: proc_double
     procedure(pltransform_proc_data_double), optional :: proc_data_double
     type(c_ptr), optional, intent(in) :: data
     interface
         subroutine interface_plstransform( proc, data ) bind(c, name = 'c_plstransform' )
             import :: c_funptr, c_ptr
             type(c_funptr), value, intent(in) :: proc
             type(c_ptr), value, intent(in) :: data
         end subroutine interface_plstransform
      end interface

      if( .not. present(proc_single) .and. .not. present(proc_data_single) &
          .and. .not. present(proc_double) .and. .not. present(proc_data_double) &
           .and. .not. present(data) ) then
         call interface_plstransform( c_null_funptr, c_null_ptr )
      elseif( present(proc_single) .and. .not. present(proc_data_single) &
           .and. .not. present(proc_double) .and. .not. present(proc_data_double) &
           .and. .not. present(data) ) then
            pltransform_single => proc_single
            call interface_plstransform( c_funloc(pltransformf2c_single), c_null_ptr )
      elseif( .not. present(proc_single) .and. present(proc_data_single) &
           .and. .not. present(proc_double) .and. .not. present(proc_data_double) &
           .and. present(data) )then
            pltransform_data_single => proc_data_single
            call interface_plstransform( c_funloc(pltransformf2c_data_single), data )
      elseif( .not. present(proc_single) .and. .not. present(proc_data_single) &
           .and. present(proc_double) .and. .not. present(proc_data_double) &
           .and. .not. present(data) ) then
            pltransform_double => proc_double
            call interface_plstransform( c_funloc(pltransformf2c_double), c_null_ptr )
      elseif( .not. present(proc_single) .and. .not. present(proc_data_single) &
           .and. .not. present(proc_double) .and. present(proc_data_double) &
           .and. present(data) ) then
            pltransform_data_double => proc_data_double
            call interface_plstransform( c_funloc(pltransformf2c_data_double), data )
      else
         write(error_unit,"(a)") "f95 plstransform ERROR: one of the following valid argument choices not used:"
         write(error_unit,"(a)") "(1) no arguments;"
         write(error_unit,"(a)") "(2) a single-precision coordinate_transform callback;"
         write(error_unit,"(a)") "(3) a single-precision coordinate_transform callback and c_loc of defined data type;"
         write(error_unit,"(a)") "(4) a double-precision coordinate_transform callback; or"
         write(error_unit,"(a)") "(5) a double-precision coordinate_transform callback and c_loc of defined data type."
         return
      endif
end subroutine plstransform_impl
...

I was pretty proud of that implementation, but there is a "slight" problem
with it which is it does not work!  :-(

After doing some experiments commenting out certain parts it turns
out that gfortran (and I assume all other Fortran compilers) treats the first
four arguments as completely interchangeable as far as disambiguation
is concerned.  So the library builds OK based on the disambiguation
between 0, 1, 2, 3, and 4 callbacks in the argument list, but when
an example specifies just one callback, the first of the possibilities
is selected which of course does not match in type (because our examples
currently use just double-precision callbacks.  Even if I comment
out all the single types, gfortran still cannot disambiguate
between proc_double and proc_data_double, and apparently just
assumes the first because under those conditions example 19 (which
does not use the data form of callback) compiles OK, but example 22
(which does use the data form) fails to compile with the message

/home/software/plplot/HEAD/plplot.git/examples/f95/x22f.f90:232.56:

          call plstransform( transform_data, c_loc(data))
                                                         1
Error: There is no specific subroutine for the generic 'plstransform' at (1)

This is really peculiar behaviour that I have alluded to before.
Clearly, the gfortran compiler enforces the rule that the callback
function arguments supplied by the calling routine must match exactly
in number and type with what is expected by the library, but that
compiler refuses to use that known information to disambiguate.  So
for this particular case we use the presence or absence of data in the
argument list to disambiguate (i.e., we use the method presently
implemented on master tip).

So the question is whether this peculiar behaviour is due to a
gfortran bug or due to an issue with the Fortran standard for
disambiguation, and I hope you will continue to pursue that question
with your Fortran contacts.

Meanwhile, I will throw away the above "good" idea and continue with
the (double-precision only) status quo for plstransform (and
plslabelfunc).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] A second rewrite of the Fortran chapter of the DocBook documentation

[Alan W. I. <ir...@be...>]

Hi Arjen:

As discussed off list I fundamentally liked your rewrite of the Fortran
chapter and just wanted to change a few things about it.  But that
effort grew and grew with the result that I have rewritten the whole
thing (as of commit e50b011) inspired by the documentation ideas
that you used in your first rewrite.
It's now 4 pages rather than 3 and
mostly stays focussed on the idea of what a PLplot developer 20 years
from now will need to know about the implementation of our Fortran
binding so he can quickly understand it.  I essentially use all
details of our binding for plstring throughout as an illustrative
example and to keep the discussion focussed.  Although there are
interfacing details in this chapter that an ordinary Fortran user will
want to skim or even skip, there is also useful information in this
chapter for that level of user as well.

I would appreciate you giving this rewritten chapter a critical read,
and if there are some further things you would like to make please go
ahead and do that and commit those changes.  Although I hope and trust
another complete rewrite will not be necessary. :-)

Normally as a Cygwin user you should be able to easily build the
DocBook documentation following the Cygwin instructions Phil inserted
into doc/docbook/README.developers.  But since you haven't tried that
procedure yet, I have attached fortran_chapter.pdf as a convenient way
for you to look at my rewrite of the Fortran chapter.  That file was produced
by the command

make -j4 print && \
pdftk doc/docbook/src/plplot-5.11.1.pdf cat 78-81 output fortran_chapter.pdf

where raw pages 78-81 correspond to the Fortran chapter part of the
doc/docbook/src/plplot-5.11.1.pdf file produced by that make command.
I have never used pdftk before, but it looks like it is an extremely
useful Linux command-line tool (unfortunately for you apparently not
yet packaged for Cygwin) for manipulating PDF files.

By the way, I think I have figured out a way to beat the
disambiguation issue with plstransform and plslabelfunc that I 
documented in the above PDF.  The idea is to have two optional
callbacks in the argument list (one being the single-precision one,
and the other being the double-precision one) with only one or the
other allowed for a given call.  But fingers crossed, and we will see
whether that wild idea actually works later today after I get
some sleep.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Redacted dimension arguments

[James T. <jt...@gm...>]

On 20 January 2016 at 08:47, Jerry <lan...@qw...> wrote:

>
> On Jan 19, 2016, at 5:32 AM, Phil Rosenberg <p.d...@gm...>
> wrote:
>
> > I'm perhaps less keen on the idea of using the minimum dimension.
> > Passing unequal sized arrays is clearly and error and so I think we
> > should flag it is such is the loudest way possible so the user can fix
> > it.
>
> I agree with Phil.
>
> Jerry
>

A suggestion -- not sure if it is practical or not -- how about a flag to
permit unequal lengths?

Re: [Plplot-devel] Redacted dimension arguments

[Jerry <lan...@qw...>]

On Jan 19, 2016, at 5:32 AM, Phil Rosenberg <p.d...@gm...> wrote:

> I'm perhaps less keen on the idea of using the minimum dimension.
> Passing unequal sized arrays is clearly and error and so I think we
> should flag it is such is the loudest way possible so the user can fix
> it.

I agree with Phil.

Jerry

Re: [Plplot-devel] Redacted dimension arguments

[Alan W. I. <ir...@be...>]

On 2016-01-19 13:07-0000 Phil Rosenberg wrote:

> Oh and a final point. We should think carefully before removing the
> forms where we pass in a raw pointer and a number of elements.

My own feeling is the advantages of full-featured arrays outweigh the
simplicity (but also dangers) of C-style arrays.  So assuming you go
ahead and implement full-featured arrays as arguments for the routines
in our C++ binding, my tentative advice would be to wean C++ users of
our code off of C-style array arguments by deprecating them. But I
leave that judgement call to support or deprecate C-style arrays up to
you and the others here who are familiar with C++.

[...]

> I'm not saying that the gains outweigh the negative or the other way
> round. Just that we need to think about it.

You have obviously already made an excellent start on the required
thinking which is really good.  However, I hope Andrew (who has been
the principal maintainer of our C++ binding for many years) also gets
involved in this discussion.

@Andrew: any thoughts?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Redacted dimension arguments

[Alan W. I. <ir...@be...>]

On 2016-01-19 12:32-0000 Phil Rosenberg wrote:

> I'm perhaps less keen on the idea of using the minimum dimension.
> Passing unequal sized arrays is clearly and error and so I think we
> should flag it is such is the loudest way possible so the user can fix
> it. I think the times when I have often got this wrong are off by one
> cases and getting x and y the wrong way round in contour plots. In an
> off by one case if we just plot the data regardless then the user is
> quite likely to never notice - in fact if we are off by many (perhaps
> the user passes a filtered array in for x and an unfiltered array in
> for y) then the results may be absolutely incorrect but the user may
> be unaware.

Hi Phil:

You make good points above, and I have to admit I have never heard
user complaints about demanding exactly consistent array sizes for our
many language bindings that enforce that constraint. So I am now
leaning toward just continuing that model with Fortran although
this may come as a shock to our Fortran users.  (I think our old
binding did not have any dimension constraints at all.) However, I
can address that in the release notes where we are already listing
all the ways the new Fortran binding differs from the old one.

Anyone else want to weigh in here before I finalize this decision for
our Fortran binding?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Redacted dimension arguments

[Phil R. <p.d...@gm...>]

Oh and a final point. We should think carefully before removing the
forms where we pass in a raw pointer and a number of elements. There
are cases where only a raw pointer will do, such as when the array
class doesn't have a size method or the array class uses () instead of
[] for element access. A user can write an interface class to deal
with that, but then we have made the interface less user friendly not
more. e.g


class myArray
{
public:
   size_t getSize(){ return m_nElements;} //get the number of elements
   const double &operator()( size_t index) {return
*(m_pointer+index);}//get an element
private:
   size_t m_nElements;
   double *m_pointer;
};

//now this won't compile as there is no size method, nor any operator[]
myArray x;
myArray y;
pl.someFunction(x,y);
//the old method used to work
pl.someFunction(x.getSize(), &x(0), &y(0));


The user now has to create an interface class to link plplot to
class plInterface
{
public:
   plInterface( myArray *array ){m_myArray = array; }
   PLINT size(){return m_myArray.getSize();}
   const double &operator[](size_t index){return (*m_myArray)(index);}
private:
   myArray *m_myArray;
};

myArray x;
myArray y;
pl.someFunction(plInterface(&x), plInterface(&y));


I'm not saying that the gains outweigh the negative or the other way
round. Just that we need to think about it.

Phil

On 19 January 2016 at 12:47, Phil Rosenberg <p.d...@gm...> wrote:
> I just realised I forgot one thing
>
> There isn't a standard 2D container in C++, so you have to create a
> vector of vectors, something like
> std::vector<std::vector<double>> myMatrix;
>
> However a lot of people don't like this as it is generally considered
> rather slow. So I think there are lots of other things people use
> including Eigen or Boost classes or just plain C matrices or their own
> home solutions.
>
> We should certainly maintain and if needed extend the C++ model that I
> think Andrew designed which wraps any kind of 2D array in an class
> where the user provides a method to access the required elements.
>
> Phil
>
> On 19 January 2016 at 12:32, Phil Rosenberg <p.d...@gm...> wrote:
>> I'm perhaps less keen on the idea of using the minimum dimension.
>> Passing unequal sized arrays is clearly and error and so I think we
>> should flag it is such is the loudest way possible so the user can fix
>> it. I think the times when I have often got this wrong are off by one
>> cases and getting x and y the wrong way round in contour plots. In an
>> off by one case if we just plot the data regardless then the user is
>> quite likely to never notice - in fact if we are off by many (perhaps
>> the user passes a filtered array in for x and an unfiltered array in
>> for y) then the results may be absolutely incorrect but the user may
>> be unaware.
>>
>> Regarding C++, this is a bit tricky. But the short answer is that the
>> best way to do this would be to turn out our C++ driver into header
>> only code. This can be done by simply inlining all the methods, or we
>> could template it something like this
>>
>> template<class ARRAY>
>> void plstream::someFunction(const ARRAY &x, const ARRAY &y)
>> {
>>     plsomefunction( x.size(), &x[0], &y[0]);
>> }
>>
>> then in the main program
>>
>> plstream pl;
>>
>> //we can call someFunction with std::vectors of doubles
>> std::vector<double> x;
>> std::vector<double> y;
>> pl.someFunction (x, y);
>>
>> //or if someone has a different array type class
>> myCustomArray x;
>> myCustomArray y;
>> pl.someFunction(x,y);
>>
>>
>> In fact plstream::someFunction can be called with any class which has
>> a size method and for which the &x[0], &y[0] syntax makes sense, so it
>> would need to understand operator [] and it would have to have all its
>> elements in contiguous memory.
>>
>>
>> So that is probably the "best" way, depending upon how you define
>> "best". It is possible to just allow plstream to accept
>> std::vector<double> arrays, which is the built in C++ array, however
>> there are complications. I won't go into the details here, but
>> basically to do this we need the following
>> 1) The library and the dll must be built with the same version of the
>> same compiler useing the same compiler and linker flags. This is
>> because C++ barely touches on defining the binary interface of the
>> language. If this isn't the case then at best you will get linker
>> errors or at worst weird run time errors because a library built in
>> MinGW has a different structure for its std::vector than the
>> executable built in VC++. By using header only code we guarantee this
>> because our code gets built into the exe.
>> 2) On windows dlls and exes have their own heap so we cannot resize
>> any std::vectors that are passed in. That would involve attempting to
>> free memory the dll doesn't have access to then allocating memory that
>> the exe wouldn't have access to. This isn't an issue for us though as
>> we don't resize them.
>>
>> There are lots of (mostly not very well written) things online about
>> C++ and dll boundaries. There is something called plain old data (POD)
>> which is I think the only place the standard really gets involved in
>> binary interfaces. POD is standard types and classes containing only
>> POD with no user defined destructor and some other limits. These can I
>> think be safely passed into and out of a dll because they are pretty
>> much like C structs with methods. stl containers including std::vector
>> are not POD.
>>
>> Don't know what your thoughts are there Alan?
>>
>> Phil
>>
>>
>> On 19 January 2016 at 07:50, Arjen Markus <Arj...@de...> wrote:
>>> Hi Alan,
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Alan W. Irwin [mailto:ir...@be...]
>>>> Sent: Tuesday, January 19, 2016 4:47 AM
>>>> To: PLplot development list
>>>> Subject: [Plplot-devel] Redacted dimension arguments
>>>> …, I came up with the following cunning plan....
>>>>
>>>> My new plan for handling redacted dimension arguments for the Fortran
>>>> binding is
>>>> simply to calculate n as the minimum dimension of the associated arrays
>>>> with the
>>>> only sanity check imposed on our users being that the resulting n > 0.  I
>>>> think this
>>>> way of handling things is a good one because it still gives the users some
>>>> type of
>>>> plot (and no memory management issues) even if they screw up and have one
>>>> associated array inadvertently shorter than the rest.
>>>>
>>> I agree on this wrt one-dimensional arrays that are passed, but for
>>> two-dimensional arrays there is a slight complication with this scheme.
>>> Thinking out loud here …
>>>
>>> Suppose the user passes arrays x(10,10) and y(20,20) to a contouring
>>> routine, then the most consistent way for the wrapping routine to pass these
>>> two arrays would be to take an array section: x(1:10,1:10) and y(1:10,1:10).
>>> Hm, that could be done easily with Fortran – since the C routine has no
>>> notion of non-contiguous array sections, the interfacing features will
>>> transform it into a temporary array that is contiguous. No copying back is
>>> required as the arguments are intent(in).
>>>
>>> Okay, this should work – provided it can be done for other bindings in the
>>> same way. I cannot comment too much on this aspect.
>>>
>>> Your remark about the Tcl binding not using redacted dimension arguments
>>> triggered me look at it again. The current bindings use the matrix data type
>>> to store the values and that type does actually keep track of the
>>> dimensions, so with a twist to that binding, we can get the same benefits.
>>>
>>> Regards,
>>>
>>> Arjen
>>>
>>>
>>>
>>> DISCLAIMER: This message is intended exclusively for the addressee(s) and
>>> may contain confidential and privileged information. If you are not the
>>> intended recipient please notify the sender immediately and destroy this
>>> message. Unauthorized use, disclosure or copying of this message is strictly
>>> prohibited. The foundation 'Stichting Deltares', which has its seat at
>>> Delft, The Netherlands, Commercial Registration Number 41146461, is not
>>> liable in any way whatsoever for consequences and/or damages resulting from
>>> the improper, incomplete and untimely dispatch, receipt and/or content of
>>> this e-mail.
>>>
>>> ------------------------------------------------------------------------------
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions now
>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>>

Re: [Plplot-devel] Redacted dimension arguments

[Phil R. <p.d...@gm...>]

I just realised I forgot one thing

There isn't a standard 2D container in C++, so you have to create a
vector of vectors, something like
std::vector<std::vector<double>> myMatrix;

However a lot of people don't like this as it is generally considered
rather slow. So I think there are lots of other things people use
including Eigen or Boost classes or just plain C matrices or their own
home solutions.

We should certainly maintain and if needed extend the C++ model that I
think Andrew designed which wraps any kind of 2D array in an class
where the user provides a method to access the required elements.

Phil

On 19 January 2016 at 12:32, Phil Rosenberg <p.d...@gm...> wrote:
> I'm perhaps less keen on the idea of using the minimum dimension.
> Passing unequal sized arrays is clearly and error and so I think we
> should flag it is such is the loudest way possible so the user can fix
> it. I think the times when I have often got this wrong are off by one
> cases and getting x and y the wrong way round in contour plots. In an
> off by one case if we just plot the data regardless then the user is
> quite likely to never notice - in fact if we are off by many (perhaps
> the user passes a filtered array in for x and an unfiltered array in
> for y) then the results may be absolutely incorrect but the user may
> be unaware.
>
> Regarding C++, this is a bit tricky. But the short answer is that the
> best way to do this would be to turn out our C++ driver into header
> only code. This can be done by simply inlining all the methods, or we
> could template it something like this
>
> template<class ARRAY>
> void plstream::someFunction(const ARRAY &x, const ARRAY &y)
> {
>     plsomefunction( x.size(), &x[0], &y[0]);
> }
>
> then in the main program
>
> plstream pl;
>
> //we can call someFunction with std::vectors of doubles
> std::vector<double> x;
> std::vector<double> y;
> pl.someFunction (x, y);
>
> //or if someone has a different array type class
> myCustomArray x;
> myCustomArray y;
> pl.someFunction(x,y);
>
>
> In fact plstream::someFunction can be called with any class which has
> a size method and for which the &x[0], &y[0] syntax makes sense, so it
> would need to understand operator [] and it would have to have all its
> elements in contiguous memory.
>
>
> So that is probably the "best" way, depending upon how you define
> "best". It is possible to just allow plstream to accept
> std::vector<double> arrays, which is the built in C++ array, however
> there are complications. I won't go into the details here, but
> basically to do this we need the following
> 1) The library and the dll must be built with the same version of the
> same compiler useing the same compiler and linker flags. This is
> because C++ barely touches on defining the binary interface of the
> language. If this isn't the case then at best you will get linker
> errors or at worst weird run time errors because a library built in
> MinGW has a different structure for its std::vector than the
> executable built in VC++. By using header only code we guarantee this
> because our code gets built into the exe.
> 2) On windows dlls and exes have their own heap so we cannot resize
> any std::vectors that are passed in. That would involve attempting to
> free memory the dll doesn't have access to then allocating memory that
> the exe wouldn't have access to. This isn't an issue for us though as
> we don't resize them.
>
> There are lots of (mostly not very well written) things online about
> C++ and dll boundaries. There is something called plain old data (POD)
> which is I think the only place the standard really gets involved in
> binary interfaces. POD is standard types and classes containing only
> POD with no user defined destructor and some other limits. These can I
> think be safely passed into and out of a dll because they are pretty
> much like C structs with methods. stl containers including std::vector
> are not POD.
>
> Don't know what your thoughts are there Alan?
>
> Phil
>
>
> On 19 January 2016 at 07:50, Arjen Markus <Arj...@de...> wrote:
>> Hi Alan,
>>
>>
>>
>>> -----Original Message-----
>>> From: Alan W. Irwin [mailto:ir...@be...]
>>> Sent: Tuesday, January 19, 2016 4:47 AM
>>> To: PLplot development list
>>> Subject: [Plplot-devel] Redacted dimension arguments
>>> …, I came up with the following cunning plan....
>>>
>>> My new plan for handling redacted dimension arguments for the Fortran
>>> binding is
>>> simply to calculate n as the minimum dimension of the associated arrays
>>> with the
>>> only sanity check imposed on our users being that the resulting n > 0.  I
>>> think this
>>> way of handling things is a good one because it still gives the users some
>>> type of
>>> plot (and no memory management issues) even if they screw up and have one
>>> associated array inadvertently shorter than the rest.
>>>
>> I agree on this wrt one-dimensional arrays that are passed, but for
>> two-dimensional arrays there is a slight complication with this scheme.
>> Thinking out loud here …
>>
>> Suppose the user passes arrays x(10,10) and y(20,20) to a contouring
>> routine, then the most consistent way for the wrapping routine to pass these
>> two arrays would be to take an array section: x(1:10,1:10) and y(1:10,1:10).
>> Hm, that could be done easily with Fortran – since the C routine has no
>> notion of non-contiguous array sections, the interfacing features will
>> transform it into a temporary array that is contiguous. No copying back is
>> required as the arguments are intent(in).
>>
>> Okay, this should work – provided it can be done for other bindings in the
>> same way. I cannot comment too much on this aspect.
>>
>> Your remark about the Tcl binding not using redacted dimension arguments
>> triggered me look at it again. The current bindings use the matrix data type
>> to store the values and that type does actually keep track of the
>> dimensions, so with a twist to that binding, we can get the same benefits.
>>
>> Regards,
>>
>> Arjen
>>
>>
>>
>> DISCLAIMER: This message is intended exclusively for the addressee(s) and
>> may contain confidential and privileged information. If you are not the
>> intended recipient please notify the sender immediately and destroy this
>> message. Unauthorized use, disclosure or copying of this message is strictly
>> prohibited. The foundation 'Stichting Deltares', which has its seat at
>> Delft, The Netherlands, Commercial Registration Number 41146461, is not
>> liable in any way whatsoever for consequences and/or damages resulting from
>> the improper, incomplete and untimely dispatch, receipt and/or content of
>> this e-mail.
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>

Re: [Plplot-devel] Redacted dimension arguments

[Phil R. <p.d...@gm...>]

I'm perhaps less keen on the idea of using the minimum dimension.
Passing unequal sized arrays is clearly and error and so I think we
should flag it is such is the loudest way possible so the user can fix
it. I think the times when I have often got this wrong are off by one
cases and getting x and y the wrong way round in contour plots. In an
off by one case if we just plot the data regardless then the user is
quite likely to never notice - in fact if we are off by many (perhaps
the user passes a filtered array in for x and an unfiltered array in
for y) then the results may be absolutely incorrect but the user may
be unaware.

Regarding C++, this is a bit tricky. But the short answer is that the
best way to do this would be to turn out our C++ driver into header
only code. This can be done by simply inlining all the methods, or we
could template it something like this

template<class ARRAY>
void plstream::someFunction(const ARRAY &x, const ARRAY &y)
{
    plsomefunction( x.size(), &x[0], &y[0]);
}

then in the main program

plstream pl;

//we can call someFunction with std::vectors of doubles
std::vector<double> x;
std::vector<double> y;
pl.someFunction (x, y);

//or if someone has a different array type class
myCustomArray x;
myCustomArray y;
pl.someFunction(x,y);


In fact plstream::someFunction can be called with any class which has
a size method and for which the &x[0], &y[0] syntax makes sense, so it
would need to understand operator [] and it would have to have all its
elements in contiguous memory.


So that is probably the "best" way, depending upon how you define
"best". It is possible to just allow plstream to accept
std::vector<double> arrays, which is the built in C++ array, however
there are complications. I won't go into the details here, but
basically to do this we need the following
1) The library and the dll must be built with the same version of the
same compiler useing the same compiler and linker flags. This is
because C++ barely touches on defining the binary interface of the
language. If this isn't the case then at best you will get linker
errors or at worst weird run time errors because a library built in
MinGW has a different structure for its std::vector than the
executable built in VC++. By using header only code we guarantee this
because our code gets built into the exe.
2) On windows dlls and exes have their own heap so we cannot resize
any std::vectors that are passed in. That would involve attempting to
free memory the dll doesn't have access to then allocating memory that
the exe wouldn't have access to. This isn't an issue for us though as
we don't resize them.

There are lots of (mostly not very well written) things online about
C++ and dll boundaries. There is something called plain old data (POD)
which is I think the only place the standard really gets involved in
binary interfaces. POD is standard types and classes containing only
POD with no user defined destructor and some other limits. These can I
think be safely passed into and out of a dll because they are pretty
much like C structs with methods. stl containers including std::vector
are not POD.

Don't know what your thoughts are there Alan?

Phil


On 19 January 2016 at 07:50, Arjen Markus <Arj...@de...> wrote:
> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Tuesday, January 19, 2016 4:47 AM
>> To: PLplot development list
>> Subject: [Plplot-devel] Redacted dimension arguments
>> …, I came up with the following cunning plan....
>>
>> My new plan for handling redacted dimension arguments for the Fortran
>> binding is
>> simply to calculate n as the minimum dimension of the associated arrays
>> with the
>> only sanity check imposed on our users being that the resulting n > 0.  I
>> think this
>> way of handling things is a good one because it still gives the users some
>> type of
>> plot (and no memory management issues) even if they screw up and have one
>> associated array inadvertently shorter than the rest.
>>
> I agree on this wrt one-dimensional arrays that are passed, but for
> two-dimensional arrays there is a slight complication with this scheme.
> Thinking out loud here …
>
> Suppose the user passes arrays x(10,10) and y(20,20) to a contouring
> routine, then the most consistent way for the wrapping routine to pass these
> two arrays would be to take an array section: x(1:10,1:10) and y(1:10,1:10).
> Hm, that could be done easily with Fortran – since the C routine has no
> notion of non-contiguous array sections, the interfacing features will
> transform it into a temporary array that is contiguous. No copying back is
> required as the arguments are intent(in).
>
> Okay, this should work – provided it can be done for other bindings in the
> same way. I cannot comment too much on this aspect.
>
> Your remark about the Tcl binding not using redacted dimension arguments
> triggered me look at it again. The current bindings use the matrix data type
> to store the values and that type does actually keep track of the
> dimensions, so with a twist to that binding, we can get the same benefits.
>
> Regards,
>
> Arjen
>
>
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is strictly
> prohibited. The foundation 'Stichting Deltares', which has its seat at
> Delft, The Netherlands, Commercial Registration Number 41146461, is not
> liable in any way whatsoever for consequences and/or damages resulting from
> the improper, incomplete and untimely dispatch, receipt and/or content of
> this e-mail.
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Redacted dimension arguments

[Alan W. I. <ir...@be...>]

On 2016-01-19 07:50-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Tuesday, January 19, 2016 4:47 AM
>> To: PLplot development list
>> Subject: [Plplot-devel] Redacted dimension arguments
>> ..., I came up with the following cunning plan....
>>
>> My new plan for handling redacted dimension arguments for the Fortran binding is
>> simply to calculate n as the minimum dimension of the associated arrays with the
>> only sanity check imposed on our users being that the resulting n > 0.  I think this
>> way of handling things is a good one because it still gives the users some type of
>> plot (and no memory management issues) even if they screw up and have one
>> associated array inadvertently shorter than the rest.
>>

> I agree on this wrt one-dimensional arrays that are passed, but for
two-dimensional arrays there is a slight complication with this
scheme. Thinking out loud here ...

> Suppose the user passes arrays x(10,10) and y(20,20) to a contouring
routine, then the most consistent way for the wrapping routine to pass
these two arrays would be to take an array section: x(1:10,1:10) and
y(1:10,1:10). Hm, that could be done easily with Fortran - since the C
routine has no notion of non-contiguous array sections, the
interfacing features will transform it into a temporary array that is
contiguous. No copying back is required as the arguments are
intent(in).

> Okay, this should work

Hi Arjen:

Thanks for this additional discussion of the 2D case.  I agree with your conclusion.

> - provided it can be done for other bindings in the same way.

I believe each language should be moved to less constrained rules for
dimensions of arrays independently of the rest of the languages.  I
also think such a project would be pretty straightforward for any
language binding written in C or C++ (e.g., all our swig-generated
bindings).  I don't know a lot about some of our other language
binding methods, but hopefully some method can be found to move to the
less constrained rules when someone takes a look.

> Your remark about the Tcl binding not using redacted dimension
arguments triggered me look at it again. The current bindings use the
matrix data type to store the values and that type does actually keep
track of the dimensions, so with a twist to that binding, we can get
the same benefits.

That would be great.  And if we could get the C++ enthusiasts on side
as well, that would mean all our bindings would be redacted.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Redacted dimension arguments

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, January 19, 2016 4:47 AM
> To: PLplot development list
> Subject: [Plplot-devel] Redacted dimension arguments
> ..., I came up with the following cunning plan....
>
> My new plan for handling redacted dimension arguments for the Fortran binding is
> simply to calculate n as the minimum dimension of the associated arrays with the
> only sanity check imposed on our users being that the resulting n > 0.  I think this
> way of handling things is a good one because it still gives the users some type of
> plot (and no memory management issues) even if they screw up and have one
> associated array inadvertently shorter than the rest.
>
I agree on this wrt one-dimensional arrays that are passed, but for two-dimensional arrays there is a slight complication with this scheme. Thinking out loud here ...

Suppose the user passes arrays x(10,10) and y(20,20) to a contouring routine, then the most consistent way for the wrapping routine to pass these two arrays would be to take an array section: x(1:10,1:10) and y(1:10,1:10). Hm, that could be done easily with Fortran - since the C routine has no notion of non-contiguous array sections, the interfacing features will transform it into a temporary array that is contiguous. No copying back is required as the arguments are intent(in).

Okay, this should work - provided it can be done for other bindings in the same way. I cannot comment too much on this aspect.

Your remark about the Tcl binding not using redacted dimension arguments triggered me look at it again. The current bindings use the matrix data type to store the values and that type does actually keep track of the dimensions, so with a twist to that binding, we can get the same benefits.

Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-devel] Redacted dimension arguments

[Alan W. I. <ir...@be...>]

@Phil (and other C++ enthusiasts here):

There is a question for you at the end about redacted
dimension arguments for the C++ case.

@Everybody:

Normally for higher-level languages that treat arrays as first-class
objects (i.e., _all_ the computer languages we support other than C,
Tcl, and [strangely] C++, see below) that carry their dimension
information along with them, we use a redacted PLplot API, where
arguments containing a redundant dimension are removed from argument
lists.  So, for example, plline(n, x, y) gets called as plline(x,y),
from Python, Fortran, etc.

But for this and like cases what should be the rule for calculating 
the dimension argument (e.g., n in the plline arguments)
for the corresponding C call and what sanity checks should be made
concerning n?

For our swig-generated bindings (e.g., Python, Jave, Octave, and Lua)
n is calculated from the actual length of the first related array
argument (e.g., the x argument for plline) and the sanity check is the
length of the other related arrays (e.g., the y argument of plline)
are checked whether they have the same length, and if not, an error
occurs.  And this model has propagated further to other high-level
languages (e.g., at least to D) and perhaps all of them since the
swig-generated bindings were implemented first.

For our new Fortran binding the current status is the dimension
information is usually taken from the first array and no further
checking done of the dimensions of the other associated arrays, and I
was starting the process of converting that bad model (lots of chance
for user error there) to the above model. However, then I started to
consider the extra burden this "sanity check" would impose on our
Fortran users, I came up with the following cunning plan....

My new plan for handling redacted dimension arguments for the Fortran
binding is simply to calculate n as the minimum dimension of the
associated arrays with the only sanity check imposed on our users
being that the resulting n > 0.  I think this way of handling things
is a good one because it still gives the users some type of plot (and
no memory management issues) even if they screw up and have one
associated array inadvertently shorter than the rest.

I also think this change should be done for all our languages that
redact dimension arguments from argument lists.  If there is general
agreement that would be a good goal to have, I am willing to take a
further look at this in the long term or happily encourage from the
sidelines if someone else wants to make these language bindings
changes in the shorter term.

I also realized when researching this post, that our C++ binding has
no redaction of the n argument for plline (or presumably any other
part of our C++ API). I assume this is because our C++ binding
currently just uses C-style arrays, but although I have only
minimal knowledge of C++ my quick google search found an article that
stated "C++ provides an alternative array type as a standard
container" which have more powerful capabilities (like carrying
array information with the object than C-style arrays.

@ Phil (and other C++ enthusiasts here):

Could you comment on why we are not using this possibility which
should allow redacted argument lists for our C++ binding and much
less chance of user error due to array issues?

If you are enthusiastic about choosing to use the more powerful array
type in our C++ binding arguments, I would encourage you to go ahead
and make that change.  To ease the transition to the new kind of
arrays in argument lists you would probably want to keep the
non-redacted form available in overloaded form around for a while but
only if a user specifically chooses it with a CMake option such as
-DPL_DEPRECATED_cxx=ON (as a gentle reminder to users to move to the
more powerful array API before it is too late and we remove the
deprecated version that uses C-style arrays).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

[Alan W. I. <ir...@be...>]

On 2016-01-18 16:57-0000 Phil Rosenberg wrote:

> Hi
> Can we reopen this again please. I have just hit another case where
> when plotting a contour plot something goes wrong and the whole plot
> gets filled.
>
> Alan, you said you were going to see if you could work out why the
> fuzzy logic was needed and I said I would try to generate a test case.
> I know I haven't held up my side of the bargain, but I will try to
> sort one asap.

Hi Phil:

The status here is I guessed at the cause of the issue you originally
reported and got pretty far with a fix for that on a private topic
branch but did not finish that off because some higher priorities
intervened such as the new Fortran binding.  But if you have found a
complicated case demonstrating an issue with the fill logic on master
branch, that would be like gold because such cases are quite rare.

So your absolutely first priority should be to preserve the exact
complicated conditions where you found the bug.  Then please send me
_that exact case_ to make sure I can replicate it here.  After that,
we can attempt to simplify the issue down to a much more managable
simple test case, fix that simple case, then go back to the
complicated case to make sure that fix works for it as well. Or other
possibilities exist such as fixing some fuzzy issues with the present
logic (for example, how nearly parallel intersections are treated by
the logic) to see if those fixes make any difference to your complex
case.  But essential to all of this bug-fixing process is a case (no
matter how complicated) that can be replicated elsewhere.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

[Phil R. <p.d...@gm...>]

Hi
Can we reopen this again please. I have just hit another case where
when plotting a contour plot something goes wrong and the whole plot
gets filled.

Alan, you said you were going to see if you could work out why the
fuzzy logic was needed and I said I would try to generate a test case.
I know I haven't held up my side of the bargain, but I will try to
sort one asap.

Phil

On 24 June 2015 at 19:02, Alan W. Irwin <ir...@be...> wrote:
> On 2015-06-24 11:10+0100 Phil Rosenberg wrote:
>
>> Hi Alan
>
>
>> I will try to do this. Unfortunately the fail case of mine was very
>
> well wrapped in my own wrapper code so it might be a challenge to
> generate a simple test.
>
> I was afraid of that, but I hope you can overcome that challenge
> because a strong test case would be most helpful to make sure I have
> fixed all the issues that I have spotted during my review of
> the fill code that directly or indirectly uses notcrossed results.
>
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

Re: [Plplot-devel] Need help to debug a library build

[Alan W. I. <ir...@be...>]

On 2016-01-17 20:59-0800 Greg Jung wrote:

> I tried setting re-building the qhullstatic.a library with CFLAGS,
> CXXFLAGS=-fPIC to no avail.
>
> Can anyone clue me in to where the problem is?

Hi Greg:

The rule is that all static libraries linked to by shared objects must
have -fPIC set since that static library code is put directly into the
shared object and must therefore have the correct -fPIC flag set.  So
I think you are completely on the right track with qhullstatic.a, but
have you done this (used the -fPIC compiler option) also for the
static build of PLplot libraries as well as every other static library
that the shared build of libgdl is linked to?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] New Fortran binding has now landed on master

[Arjen M. <Arj...@de...>]

Hi Alan, everyone,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, January 18, 2016 5:12 AM
> To: PLplot development list
> Subject: [Plplot-devel] New Fortran binding has now landed on master
>
> I am happy to report I just landed a big topic (complete update of our Fortran
> binding and Fortran examples that Arjen and I have been working on for some time)
> on master.
>
> If you update your local master branches to the latest version (commit id 498019cf)
> you will see that commit is the last of 70 (!) commits that Arjen and I collaborated
> on (using "git format-patch"/"git am") using a private topic branch.
>
> This commit finalized the Fortran PLplot API and also passed all my comprehensive
> tests so it was time to land this topic. I did that following the method documented in
> README.developers.  However, that method is a little more scary when you are
> dealing with 70 commits rather than just one or two maintenance commits.  But
> everything worked very well as you can see.
>
> To see our motivation for working so hard on this topic, please consult the notes
> about this Fortran binding rewrite in README.release.  The net result I think is
> Fortran is for the very first time one of our most powerful language bindings, and
> that fits in quite well with our advertising PLplot as a scientific plotting library
> because modern Fortran (2003 or later) is in something of a renaissance with
> scientists now that it has gained so many high-power capabilities compared to
> Fortran 77.
>
> I am in a celebratory mood tonight because of this joint achievement with Arjen, and
> I am sure he is feeling the same way!
>
:) I can confirm that. Overall it has been my most extensive exercise with the ISO_C_BINDING feature and we have been able to eliminate all intermediate C code, which should make the maintenance of this binding easier as well.

There still remains a lot to do: cleaning up the code, properly document it and - a mental note on the promise I made myself and Alan - write it all down in a handy little article. But I am happy that the bulk of the work is done and that it can be shared with everyone.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-devel] Need help to debug a library build

[Greg J. <gv...@gm...>]

Hi all,
  I've been using a static build of the plplot library to build GDL,
in order to have a stable and somewhat unique set of parameters:

> cmake -DCMAKE_INSTALL_PREFIX=/d/bld/plplot/linux/cmake-static \
>
> -DENABLE_DYNDRIVERS=OFF -DDEFAULT_NO_CAIRO_DEVICES=ON
>> -DDEFAULT_NO_QT_DEVICES=ON \
>
> -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON -DENABLE_wxwidgets=ON
>> -DOLD_WXWIDGETS=ON \
>
> -DWITH_FREETYPE=OFF -DBUILD_SHARED_LIBS=OFF \
>
> -DPLD_pdf=OFF -DPLD_psttf=OFF \
>
> /f/tarball/plplot-5.11.1
>
>
OLD_WIDGETS is a requirement for the gdl widgets subroutines to operate.
After I install this result in /usr/local/lib, I apply the following:
(libplplotXXX.a files have been renamed to libplplotXXX-static.a)

in /usr/local/lib:

> rm -rf .o .p libplplot-custom.a libplplotcxx-custom.a
> mkdir .p && cd .p && ar x ../libplplot-static.a && ar x
> ../libplplotwxwidgets-static.a && cd ..
> mkdir .o && cd .o
> ar x ../libcsironn.a
> ar x ../libcsirocsa.a
> ar x ../libqsastime.a
> ar x ../libshp.a
> ar x ../libqhullstatic.a
> cd ..
> ar rc libplplot-custom.a .p/* .o/*
> cp -p libplplotcxx-static.a libplplotcxx-custom.a


And this works fine, on the usual build of GDL.

( Which I encourage any and all of you to do - its only 2 MB of code with a
minimal patch
https://sourceforge.net/p/gnudatalanguage/patches/102/ that will adapt the
current (recent)
distribution to a mingw, or mingw-w64, build.)

I am running into an issue now trying to build gdl as a llibrary+main
program, the error output
suggest I don;t have enough -fPIC-compiled routines:

Linking CXX shared library libgnudatalanguage.so

/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
> /usr/local/lib/libplplot-custom.a(global.c.o): relocation R_X86_64_32S
> against `qh_qh' can not be used when making a shared object; recompile with
> -fPIC

/usr/local/lib/libplplot-custom.a: error adding symbols: Bad value

collect2: error: ld returned 1 exit status

src/CMakeFiles/gnudatalanguage.dir/build.make:3397: recipe for target
> 'src/libgnudatalanguage.so.0' failed


I tried setting re-building the qhullstatic.a library with CFLAGS,
CXXFLAGS=-fPIC to no avail.

Can anyone clue me in to where the problem is?

Thanks,
Greg

[Plplot-devel] New Fortran binding has now landed on master

[Alan W. I. <ir...@be...>]

I am happy to report I just landed a big topic (complete update of our
Fortran binding and Fortran examples that Arjen and I have been
working on for some time) on master.

If you update your local master branches to the latest version
(commit id 498019cf) you will see that commit is the last of 70 (!)
commits that Arjen and I collaborated on (using "git
format-patch"/"git am") using a private topic branch.

This commit finalized the Fortran PLplot API and also passed all my
comprehensive tests so it was time to land this topic. I did that
following the method documented in README.developers.  However, that
method is a little more scary when you are dealing with 70 commits
rather than just one or two maintenance commits.  But everything
worked very well as you can see.

To see our motivation for working so hard on this topic, please
consult the notes about this Fortran binding rewrite in
README.release.  The net result I think is Fortran is for the very
first time one of our most powerful language bindings, and that fits
in quite well with our advertising PLplot as a scientific plotting
library because modern Fortran (2003 or later) is in something of a
renaissance with scientists now that it has gained so many high-power
capabilities compared to Fortran 77.

I am in a celebratory mood tonight because of this joint achievement
with Arjen, and I am sure he is feeling the same way!

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Correct implementation of key and button events in the interactive drivers

[Alan W. I. <ir...@be...>]

To summarize my contribution to this thread so far, I think it is
important that interactivity should work consistently between all our
interactive devices following what is done for the xwin device, and I
have also proved we are very far from that goal now to the point that
all interactive devices other than xwin that I have tried do not work
correctly for the -xor mode of example 1, example 20, or many of the
special interactive "p" examples that are available for octave.

But my further thought today is it is going to take a lot of work for
each interactive device developer to figure out the xwin interactive
paradigm and mimic it for their own device so why not instead move the
mouse button, keystroke, and crosshairs part of the xwin logic to a
central function residing in libplplot instead that can be used by
every interactive device?  That central function would use code
directly from xwin.c for the X case or the equivalent Windows-based 
code for the Windows case starting with what Arjen has currently
implemented in wingcc.c.

This centralized approach automatically satisfies the above
consistency goal and should be a lot less effort than every developer
of an interactive device driver having to deal with this issue.

Anyhow, I hope this idea inspires a volunteer here to delve deeply
into the xwin code and equivalent wingcc.c code to see what would be
required to centralize interactive handling of mouse button events,
keystroke events, and crosshairs, and then implement that to give us
consistent rich interactivity capabilities for all our X-based and
Windows-based interactive devices.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Uisng plplot with wxwidgets and vs 2015

[Phil R. <p.d...@gm...>]

Hi Laurent
I just looked into seeing if I could swap to using wxWidgets 3.1 from
their Git repo. I had already downloaded it for some other reason.

However, when I checked I am already using this version checked out at
the following commit
commit 24580198b8c6ad6cc8d52689f89efc96407e30bb
Author: JulianSmart <ju...@an...>
Date:   Mon Dec 14 23:16:21 2015 +0000

I don't know how different that commit is to yours, but our systems
are now even closer than we thought.

Phil

On 13 January 2016 at 10:36, Phil Rosenberg <p.d...@gm...> wrote:
> Hi Laurent
> I have never used VS2013, I upgraded directly form 2012.
>
> My best guess is that something is being deleted twice, by removing
> that line of code it may be that some things are not deleted at all,
> so you may end up with memory leaks.
>
> As I mentioned before, the destructor was modified after the commit
> you last checked out, which may have fixed the problem. The next check
> should be to check out the latest version of PLPlot to see if that
> helps.
>
> You are correct that VS2015 seems to be quite different and is binary
> incompatible with previous versions. I had a number of problems when I
> upgraded too.
>
> Phil
>
> On 13 January 2016 at 09:33, Laurent Berger
> <lau...@un...> wrote:
>> Hi,
>>
>> I need to resume before further insvestigations
>> on my computer
>> VS2013 wx3.1.0(commit 25-nov 2015)  plplot (commit 22 dec 2015) ==> no
>> problem
>> VS2015 wx3.1.0(commit 25-nov 2015)  plplot (commit 22 dec 2015) ==> bug in
>> closing window
>>
>> on your computer
>> VS2013 wx3.0.2  plplot (commit 22 dec 2015)  ==> no problem
>> VS2015 wx3.0.2   plplot (commit 22 dec 2015)  ==> no problem
>>
>> I think VS 2015 compiler is not like vs2013 compiler
>>
>> I have comment line 2527 of plcore.c : plPTidy() and there is no exception.
>> Of course it is not an answer to this problem but i think it helps to
>> localize this problem.
>>
>> As you are not able to reproduce my error  may be something is wrong in my
>> configuration. I can stay with VS 2013
>>
>> Laurent
>>
>>
>>
>>
>> Le 11/01/2016 18:54, Phil Rosenberg a écrit :
>>>
>>> Hi Laurent
>>> I am unfortunately so far unable to reproduce your error. I have tried
>>> checking out the same commit that you have and still I do not see the
>>> same error
>>>
>>> I can only think that this must be something to do with the new
>>> version of wxWidgets. I will try to look into it further, but I am not
>>> sure exactly when I will be able to upgrade to that version. Hopefully
>>> later this week.
>>>
>>> However, later on the 22nd Dec - the same day you checked out your
>>> version of PLPlot, I changed the destructor of wxPLplotwindow to
>>> virtual, which it should have been all the time, because wxWidgets is
>>> probably deleting it via a wxWindow * pointer. There is a chance this
>>> may have fixed your issue. Can you please check out the latest version
>>> of from the git repo and let me know if you still have the same
>>> problem.
>>>
>>> If the problem persists can I just confirm that you are getting the
>>> second stack trace twice identically? If you are then that is very
>>> strange as it means that  plend() is getting called twice somehow.
>>>
>>> Also it is worth noting that I have just made some commits that fix
>>> some not quite correct aspect ratio problems that the wxWidgets driver
>>> was having (although I'm not sure if they existed when you pass a wxDC
>>> in, maybe just when run from non-wxWidgets apps).
>>>
>>> Phil
>>>
>>> On 9 January 2016 at 09:11, Phil Rosenberg <p.d...@gm...>
>>> wrote:
>>>>
>>>> Hi Laurent
>>>> I am working with wxWidgets 3.0.2. Perhaps there have been some changes.
>>>>
>>>> However, looking at your two stack traces I think there is a plplot
>>>> problem.
>>>> It looks like the wxPlplotwindow destructor is being called twice, once
>>>> by
>>>> plplot and once by wxWidgets.
>>>>
>>>> I will look at this today and get back to you asap.
>>>>
>>>> Phil
>>>> ________________________________
>>>> From: Laurent Berger
>>>> Sent: ‎08/‎01/‎2016 21:35
>>>> To: Phil Rosenberg
>>>> Subject: Re: [Plplot-devel] Uisng plplot with wxwidgets and vs 2015
>>>>
>>>> Hi phil
>>>>
>>>> i use git from git://git.code.sf.net/p/plplot/plplot
>>>> Using git log I have got this :
>>>> commit b90635d9fcba816f5bdd75c547c18bfe25d67ec0
>>>> Author: Phil Rosenberg <p.d...@gm...>
>>>> Date:   Tue Dec 22 11:52:17 2015 +0000
>>>> I'm working too with windows 10
>>>>
>>>> my wxWidgets is 3.1.0 with last commit from 8 jan 2016
>>>>
>>>> Le 08/01/2016 22:24, Phil Rosenberg a écrit :
>>>>
>>>> Hi Laurent
>>>> Are you using the latest development version or the latest release
>>>> version?
>>>>
>>>> I have also just swapped to VS2015 and the current development version I
>>>> working for me on Windows 10.
>>>> ________________________________
>>>> From: Laurent Berger
>>>> Sent: ‎08/‎01/‎2016 20:23
>>>> To: plp...@li...
>>>> Subject: [Plplot-devel]  Uisng plplot with wxwidgets and vs 2015
>>>>
>>>> Hi,
>>>>
>>>> I want to use VS2015 now with wxwidgets and plplot. When I wxPlplotDemo
>>>> It works fine until I press close box. An exception occurs at line 273
>>>> wxWidgets-3.1.0/src/common/dcgraph.cpp stack. When I set a breakpoint at
>>>> line 273 in dcgraph.cpp stack trace for first call
>>>>>
>>>>>     wxPLplotDemo.exe!wxGCDCImpl::~wxGCDCImpl() Ligne 273    C++
>>>>
>>>>        [Code externe]
>>>>        wxPLplotDemo.exe!wxDC::~wxDC() Ligne 742    C++
>>>>        wxPLplotDemo.exe!wxGCDC::~wxGCDC() Ligne 122    C++
>>>>        [Code externe]
>>>> wxPLplotDemo.exe!wxPLplotwindow<wxFrame>::~wxPLplotwindow<wxFrame>()
>>>> Ligne 110    C++
>>>>        [Code externe]
>>>>        wxPLplotDemo.exe!wxAppConsoleBase::DeletePendingObjects() Ligne
>>>> 637    C++
>>>>        wxPLplotDemo.exe!wxAppConsoleBase::ProcessIdle() Ligne 445 C++
>>>>        wxPLplotDemo.exe!wxAppBase::ProcessIdle() Ligne 373    C++
>>>>        wxPLplotDemo.exe!wxEventLoopBase::ProcessIdle() Ligne 98    C++
>>>>        wxPLplotDemo.exe!wxEventLoopManual::DoRun() Ligne 263    C++
>>>>        wxPLplotDemo.exe!wxEventLoopBase::Run() Ligne 76    C++
>>>>        wxPLplotDemo.exe!wxAppConsoleBase::MainLoop() Ligne 380    C++
>>>>        wxPLplotDemo.exe!wxAppConsoleBase::OnRun() Ligne 302    C++
>>>>        wxPLplotDemo.exe!wxAppBase::OnRun() Ligne 312    C++
>>>>        wxPLplotDemo.exe!wxEntryReal(int & argc, wchar_t * * argv) Ligne
>>>> 503    C++
>>>>        wxPLplotDemo.exe!wxEntry(int & argc, wchar_t * * argv) Ligne
>>>> 181    C++
>>>>        wxPLplotDemo.exe!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ *
>>>> __formal, char * __formal, int nCmdShow) Ligne 290    C++
>>>>        wxPLplotDemo.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ *
>>>> hPrevInstance, char * __formal, int nCmdShow) Ligne 129    C++
>>>>        [Code externe]
>>>>
>>>> If i go on debugging I reach break point twice with this statck trace
>>>>
>>>>>     wxPLplotDemo.exe!wxGCDCImpl::~wxGCDCImpl() Ligne 273    C++
>>>>
>>>>        [Code externe]
>>>>        wxPLplotDemo.exe!wxDC::~wxDC() Ligne 742    C++
>>>>        wxPLplotDemo.exe!wxGCDC::~wxGCDC() Ligne 122    C++
>>>>        [Code externe]
>>>>        wxPLplotDemo.exe!wxPLDevice::~wxPLDevice() Ligne 543    C++
>>>>        [Code externe]
>>>>        wxPLplotDemo.exe!plD_tidy_wxwidgets(PLStream * pls) Ligne 383
>>>> C++
>>>>        wxPLplotDemo.exe!plP_tidy() Ligne 235    C
>>>>        wxPLplotDemo.exe!c_plend1() Ligne 2528    C
>>>>        wxPLplotDemo.exe!plstream::~plstream() Ligne 347    C++
>>>>        wxPLplotDemo.exe!wxPLplotstream::~wxPLplotstream() Ligne 91 C++
>>>> wxPLplotDemo.exe!wxPLplotwindow<wxFrame>::~wxPLplotwindow<wxFrame>()
>>>> Ligne 111    C++
>>>>        [Code externe]
>>>>        wxPLplotDemo.exe!wxAppConsoleBase::DeletePendingObjects() Ligne
>>>> 637    C++
>>>>        wxPLplotDemo.exe!wxAppConsoleBase::ProcessIdle() Ligne 445 C++
>>>>        wxPLplotDemo.exe!wxAppBase::ProcessIdle() Ligne 373    C++
>>>>        wxPLplotDemo.exe!wxEventLoopBase::ProcessIdle() Ligne 98    C++
>>>>        wxPLplotDemo.exe!wxEventLoopManual::DoRun() Ligne 263    C++
>>>>        wxPLplotDemo.exe!wxEventLoopBase::Run() Ligne 76    C++
>>>>        wxPLplotDemo.exe!wxAppConsoleBase::MainLoop() Ligne 380    C++
>>>>        wxPLplotDemo.exe!wxAppConsoleBase::OnRun() Ligne 302    C++
>>>>        wxPLplotDemo.exe!wxAppBase::OnRun() Ligne 312    C++
>>>>        wxPLplotDemo.exe!wxEntryReal(int & argc, wchar_t * * argv) Ligne
>>>> 503    C++
>>>>        wxPLplotDemo.exe!wxEntry(int & argc, wchar_t * * argv) Ligne
>>>> 181    C++
>>>>        wxPLplotDemo.exe!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ *
>>>> __formal, char * __formal, int nCmdShow) Ligne 290    C++
>>>>        wxPLplotDemo.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ *
>>>> hPrevInstance, char * __formal, int nCmdShow) Ligne 129    C++
>>>>        [Code externe]
>>>>
>>>> An if press step exception occurs this->m_graphicContexthas been
>>>> 0xFFFFFFFFFFF7...
>>>>
>>>> With VS 2013 there is no problem and setting breakpoint at same point
>>>> this breakpoint is reach only once.
>>>> I have build plplot with static lib and shared  lib  using release or
>>>> debug mode and that's change nothing.
>>>>
>>>> Have you got an idea to help me solving  this problem?
>>>>
>>>> Thanks in advance
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>>> Monitor end-to-end web transactions and take corrective actions now
>>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>>>> _______________________________________________
>>>> Plplot-devel mailing list
>>>> Plp...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>>>
>>>>
>>

Re: [Plplot-devel] Uisng plplot with wxwidgets and vs 2015

[Phil R. <p.d...@gm...>]

Hi Laurent
I have never used VS2013, I upgraded directly form 2012.

My best guess is that something is being deleted twice, by removing
that line of code it may be that some things are not deleted at all,
so you may end up with memory leaks.

As I mentioned before, the destructor was modified after the commit
you last checked out, which may have fixed the problem. The next check
should be to check out the latest version of PLPlot to see if that
helps.

You are correct that VS2015 seems to be quite different and is binary
incompatible with previous versions. I had a number of problems when I
upgraded too.

Phil

On 13 January 2016 at 09:33, Laurent Berger
<lau...@un...> wrote:
> Hi,
>
> I need to resume before further insvestigations
> on my computer
> VS2013 wx3.1.0(commit 25-nov 2015)  plplot (commit 22 dec 2015) ==> no
> problem
> VS2015 wx3.1.0(commit 25-nov 2015)  plplot (commit 22 dec 2015) ==> bug in
> closing window
>
> on your computer
> VS2013 wx3.0.2  plplot (commit 22 dec 2015)  ==> no problem
> VS2015 wx3.0.2   plplot (commit 22 dec 2015)  ==> no problem
>
> I think VS 2015 compiler is not like vs2013 compiler
>
> I have comment line 2527 of plcore.c : plPTidy() and there is no exception.
> Of course it is not an answer to this problem but i think it helps to
> localize this problem.
>
> As you are not able to reproduce my error  may be something is wrong in my
> configuration. I can stay with VS 2013
>
> Laurent
>
>
>
>
> Le 11/01/2016 18:54, Phil Rosenberg a écrit :
>>
>> Hi Laurent
>> I am unfortunately so far unable to reproduce your error. I have tried
>> checking out the same commit that you have and still I do not see the
>> same error
>>
>> I can only think that this must be something to do with the new
>> version of wxWidgets. I will try to look into it further, but I am not
>> sure exactly when I will be able to upgrade to that version. Hopefully
>> later this week.
>>
>> However, later on the 22nd Dec - the same day you checked out your
>> version of PLPlot, I changed the destructor of wxPLplotwindow to
>> virtual, which it should have been all the time, because wxWidgets is
>> probably deleting it via a wxWindow * pointer. There is a chance this
>> may have fixed your issue. Can you please check out the latest version
>> of from the git repo and let me know if you still have the same
>> problem.
>>
>> If the problem persists can I just confirm that you are getting the
>> second stack trace twice identically? If you are then that is very
>> strange as it means that  plend() is getting called twice somehow.
>>
>> Also it is worth noting that I have just made some commits that fix
>> some not quite correct aspect ratio problems that the wxWidgets driver
>> was having (although I'm not sure if they existed when you pass a wxDC
>> in, maybe just when run from non-wxWidgets apps).
>>
>> Phil
>>
>> On 9 January 2016 at 09:11, Phil Rosenberg <p.d...@gm...>
>> wrote:
>>>
>>> Hi Laurent
>>> I am working with wxWidgets 3.0.2. Perhaps there have been some changes.
>>>
>>> However, looking at your two stack traces I think there is a plplot
>>> problem.
>>> It looks like the wxPlplotwindow destructor is being called twice, once
>>> by
>>> plplot and once by wxWidgets.
>>>
>>> I will look at this today and get back to you asap.
>>>
>>> Phil
>>> ________________________________
>>> From: Laurent Berger
>>> Sent: ‎08/‎01/‎2016 21:35
>>> To: Phil Rosenberg
>>> Subject: Re: [Plplot-devel] Uisng plplot with wxwidgets and vs 2015
>>>
>>> Hi phil
>>>
>>> i use git from git://git.code.sf.net/p/plplot/plplot
>>> Using git log I have got this :
>>> commit b90635d9fcba816f5bdd75c547c18bfe25d67ec0
>>> Author: Phil Rosenberg <p.d...@gm...>
>>> Date:   Tue Dec 22 11:52:17 2015 +0000
>>> I'm working too with windows 10
>>>
>>> my wxWidgets is 3.1.0 with last commit from 8 jan 2016
>>>
>>> Le 08/01/2016 22:24, Phil Rosenberg a écrit :
>>>
>>> Hi Laurent
>>> Are you using the latest development version or the latest release
>>> version?
>>>
>>> I have also just swapped to VS2015 and the current development version I
>>> working for me on Windows 10.
>>> ________________________________
>>> From: Laurent Berger
>>> Sent: ‎08/‎01/‎2016 20:23
>>> To: plp...@li...
>>> Subject: [Plplot-devel]  Uisng plplot with wxwidgets and vs 2015
>>>
>>> Hi,
>>>
>>> I want to use VS2015 now with wxwidgets and plplot. When I wxPlplotDemo
>>> It works fine until I press close box. An exception occurs at line 273
>>> wxWidgets-3.1.0/src/common/dcgraph.cpp stack. When I set a breakpoint at
>>> line 273 in dcgraph.cpp stack trace for first call
>>>>
>>>>     wxPLplotDemo.exe!wxGCDCImpl::~wxGCDCImpl() Ligne 273    C++
>>>
>>>        [Code externe]
>>>        wxPLplotDemo.exe!wxDC::~wxDC() Ligne 742    C++
>>>        wxPLplotDemo.exe!wxGCDC::~wxGCDC() Ligne 122    C++
>>>        [Code externe]
>>> wxPLplotDemo.exe!wxPLplotwindow<wxFrame>::~wxPLplotwindow<wxFrame>()
>>> Ligne 110    C++
>>>        [Code externe]
>>>        wxPLplotDemo.exe!wxAppConsoleBase::DeletePendingObjects() Ligne
>>> 637    C++
>>>        wxPLplotDemo.exe!wxAppConsoleBase::ProcessIdle() Ligne 445 C++
>>>        wxPLplotDemo.exe!wxAppBase::ProcessIdle() Ligne 373    C++
>>>        wxPLplotDemo.exe!wxEventLoopBase::ProcessIdle() Ligne 98    C++
>>>        wxPLplotDemo.exe!wxEventLoopManual::DoRun() Ligne 263    C++
>>>        wxPLplotDemo.exe!wxEventLoopBase::Run() Ligne 76    C++
>>>        wxPLplotDemo.exe!wxAppConsoleBase::MainLoop() Ligne 380    C++
>>>        wxPLplotDemo.exe!wxAppConsoleBase::OnRun() Ligne 302    C++
>>>        wxPLplotDemo.exe!wxAppBase::OnRun() Ligne 312    C++
>>>        wxPLplotDemo.exe!wxEntryReal(int & argc, wchar_t * * argv) Ligne
>>> 503    C++
>>>        wxPLplotDemo.exe!wxEntry(int & argc, wchar_t * * argv) Ligne
>>> 181    C++
>>>        wxPLplotDemo.exe!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ *
>>> __formal, char * __formal, int nCmdShow) Ligne 290    C++
>>>        wxPLplotDemo.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ *
>>> hPrevInstance, char * __formal, int nCmdShow) Ligne 129    C++
>>>        [Code externe]
>>>
>>> If i go on debugging I reach break point twice with this statck trace
>>>
>>>>     wxPLplotDemo.exe!wxGCDCImpl::~wxGCDCImpl() Ligne 273    C++
>>>
>>>        [Code externe]
>>>        wxPLplotDemo.exe!wxDC::~wxDC() Ligne 742    C++
>>>        wxPLplotDemo.exe!wxGCDC::~wxGCDC() Ligne 122    C++
>>>        [Code externe]
>>>        wxPLplotDemo.exe!wxPLDevice::~wxPLDevice() Ligne 543    C++
>>>        [Code externe]
>>>        wxPLplotDemo.exe!plD_tidy_wxwidgets(PLStream * pls) Ligne 383
>>> C++
>>>        wxPLplotDemo.exe!plP_tidy() Ligne 235    C
>>>        wxPLplotDemo.exe!c_plend1() Ligne 2528    C
>>>        wxPLplotDemo.exe!plstream::~plstream() Ligne 347    C++
>>>        wxPLplotDemo.exe!wxPLplotstream::~wxPLplotstream() Ligne 91 C++
>>> wxPLplotDemo.exe!wxPLplotwindow<wxFrame>::~wxPLplotwindow<wxFrame>()
>>> Ligne 111    C++
>>>        [Code externe]
>>>        wxPLplotDemo.exe!wxAppConsoleBase::DeletePendingObjects() Ligne
>>> 637    C++
>>>        wxPLplotDemo.exe!wxAppConsoleBase::ProcessIdle() Ligne 445 C++
>>>        wxPLplotDemo.exe!wxAppBase::ProcessIdle() Ligne 373    C++
>>>        wxPLplotDemo.exe!wxEventLoopBase::ProcessIdle() Ligne 98    C++
>>>        wxPLplotDemo.exe!wxEventLoopManual::DoRun() Ligne 263    C++
>>>        wxPLplotDemo.exe!wxEventLoopBase::Run() Ligne 76    C++
>>>        wxPLplotDemo.exe!wxAppConsoleBase::MainLoop() Ligne 380    C++
>>>        wxPLplotDemo.exe!wxAppConsoleBase::OnRun() Ligne 302    C++
>>>        wxPLplotDemo.exe!wxAppBase::OnRun() Ligne 312    C++
>>>        wxPLplotDemo.exe!wxEntryReal(int & argc, wchar_t * * argv) Ligne
>>> 503    C++
>>>        wxPLplotDemo.exe!wxEntry(int & argc, wchar_t * * argv) Ligne
>>> 181    C++
>>>        wxPLplotDemo.exe!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ *
>>> __formal, char * __formal, int nCmdShow) Ligne 290    C++
>>>        wxPLplotDemo.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ *
>>> hPrevInstance, char * __formal, int nCmdShow) Ligne 129    C++
>>>        [Code externe]
>>>
>>> An if press step exception occurs this->m_graphicContexthas been
>>> 0xFFFFFFFFFFF7...
>>>
>>> With VS 2013 there is no problem and setting breakpoint at same point
>>> this breakpoint is reach only once.
>>> I have build plplot with static lib and shared  lib  using release or
>>> debug mode and that's change nothing.
>>>
>>> Have you got an idea to help me solving  this problem?
>>>
>>> Thanks in advance
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions now
>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>>
>>>
>

Re: [Plplot-devel] Uisng plplot with wxwidgets and vs 2015

[Laurent B. <lau...@un...>]

Hi,

I need to resume before further insvestigations
on my computer
VS2013 wx3.1.0(commit 25-nov 2015)  plplot (commit 22 dec 2015) ==> no 
problem
VS2015 wx3.1.0(commit 25-nov 2015)  plplot (commit 22 dec 2015) ==> bug 
in closing window

on your computer
VS2013 wx3.0.2  plplot (commit 22 dec 2015)  ==> no problem
VS2015 wx3.0.2   plplot (commit 22 dec 2015)  ==> no problem

I think VS 2015 compiler is not like vs2013 compiler

I have comment line 2527 of plcore.c : plPTidy() and there is no 
exception. Of course it is not an answer to this problem but i think it 
helps to localize this problem.

As you are not able to reproduce my error  may be something is wrong in 
my configuration. I can stay with VS 2013

Laurent



Le 11/01/2016 18:54, Phil Rosenberg a écrit :
> Hi Laurent
> I am unfortunately so far unable to reproduce your error. I have tried
> checking out the same commit that you have and still I do not see the
> same error
>
> I can only think that this must be something to do with the new
> version of wxWidgets. I will try to look into it further, but I am not
> sure exactly when I will be able to upgrade to that version. Hopefully
> later this week.
>
> However, later on the 22nd Dec - the same day you checked out your
> version of PLPlot, I changed the destructor of wxPLplotwindow to
> virtual, which it should have been all the time, because wxWidgets is
> probably deleting it via a wxWindow * pointer. There is a chance this
> may have fixed your issue. Can you please check out the latest version
> of from the git repo and let me know if you still have the same
> problem.
>
> If the problem persists can I just confirm that you are getting the
> second stack trace twice identically? If you are then that is very
> strange as it means that  plend() is getting called twice somehow.
>
> Also it is worth noting that I have just made some commits that fix
> some not quite correct aspect ratio problems that the wxWidgets driver
> was having (although I'm not sure if they existed when you pass a wxDC
> in, maybe just when run from non-wxWidgets apps).
>
> Phil
>
> On 9 January 2016 at 09:11, Phil Rosenberg <p.d...@gm...> wrote:
>> Hi Laurent
>> I am working with wxWidgets 3.0.2. Perhaps there have been some changes.
>>
>> However, looking at your two stack traces I think there is a plplot problem.
>> It looks like the wxPlplotwindow destructor is being called twice, once by
>> plplot and once by wxWidgets.
>>
>> I will look at this today and get back to you asap.
>>
>> Phil
>> ________________________________
>> From: Laurent Berger
>> Sent: ‎08/‎01/‎2016 21:35
>> To: Phil Rosenberg
>> Subject: Re: [Plplot-devel] Uisng plplot with wxwidgets and vs 2015
>>
>> Hi phil
>>
>> i use git from git://git.code.sf.net/p/plplot/plplot
>> Using git log I have got this :
>> commit b90635d9fcba816f5bdd75c547c18bfe25d67ec0
>> Author: Phil Rosenberg <p.d...@gm...>
>> Date:   Tue Dec 22 11:52:17 2015 +0000
>> I'm working too with windows 10
>>
>> my wxWidgets is 3.1.0 with last commit from 8 jan 2016
>>
>> Le 08/01/2016 22:24, Phil Rosenberg a écrit :
>>
>> Hi Laurent
>> Are you using the latest development version or the latest release version?
>>
>> I have also just swapped to VS2015 and the current development version I
>> working for me on Windows 10.
>> ________________________________
>> From: Laurent Berger
>> Sent: ‎08/‎01/‎2016 20:23
>> To: plp...@li...
>> Subject: [Plplot-devel]  Uisng plplot with wxwidgets and vs 2015
>>
>> Hi,
>>
>> I want to use VS2015 now with wxwidgets and plplot. When I wxPlplotDemo
>> It works fine until I press close box. An exception occurs at line 273
>> wxWidgets-3.1.0/src/common/dcgraph.cpp stack. When I set a breakpoint at
>> line 273 in dcgraph.cpp stack trace for first call
>>>     wxPLplotDemo.exe!wxGCDCImpl::~wxGCDCImpl() Ligne 273    C++
>>        [Code externe]
>>        wxPLplotDemo.exe!wxDC::~wxDC() Ligne 742    C++
>>        wxPLplotDemo.exe!wxGCDC::~wxGCDC() Ligne 122    C++
>>        [Code externe]
>> wxPLplotDemo.exe!wxPLplotwindow<wxFrame>::~wxPLplotwindow<wxFrame>()
>> Ligne 110    C++
>>        [Code externe]
>>        wxPLplotDemo.exe!wxAppConsoleBase::DeletePendingObjects() Ligne
>> 637    C++
>>        wxPLplotDemo.exe!wxAppConsoleBase::ProcessIdle() Ligne 445 C++
>>        wxPLplotDemo.exe!wxAppBase::ProcessIdle() Ligne 373    C++
>>        wxPLplotDemo.exe!wxEventLoopBase::ProcessIdle() Ligne 98    C++
>>        wxPLplotDemo.exe!wxEventLoopManual::DoRun() Ligne 263    C++
>>        wxPLplotDemo.exe!wxEventLoopBase::Run() Ligne 76    C++
>>        wxPLplotDemo.exe!wxAppConsoleBase::MainLoop() Ligne 380    C++
>>        wxPLplotDemo.exe!wxAppConsoleBase::OnRun() Ligne 302    C++
>>        wxPLplotDemo.exe!wxAppBase::OnRun() Ligne 312    C++
>>        wxPLplotDemo.exe!wxEntryReal(int & argc, wchar_t * * argv) Ligne
>> 503    C++
>>        wxPLplotDemo.exe!wxEntry(int & argc, wchar_t * * argv) Ligne
>> 181    C++
>>        wxPLplotDemo.exe!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ *
>> __formal, char * __formal, int nCmdShow) Ligne 290    C++
>>        wxPLplotDemo.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ *
>> hPrevInstance, char * __formal, int nCmdShow) Ligne 129    C++
>>        [Code externe]
>>
>> If i go on debugging I reach break point twice with this statck trace
>>
>>>     wxPLplotDemo.exe!wxGCDCImpl::~wxGCDCImpl() Ligne 273    C++
>>        [Code externe]
>>        wxPLplotDemo.exe!wxDC::~wxDC() Ligne 742    C++
>>        wxPLplotDemo.exe!wxGCDC::~wxGCDC() Ligne 122    C++
>>        [Code externe]
>>        wxPLplotDemo.exe!wxPLDevice::~wxPLDevice() Ligne 543    C++
>>        [Code externe]
>>        wxPLplotDemo.exe!plD_tidy_wxwidgets(PLStream * pls) Ligne 383    C++
>>        wxPLplotDemo.exe!plP_tidy() Ligne 235    C
>>        wxPLplotDemo.exe!c_plend1() Ligne 2528    C
>>        wxPLplotDemo.exe!plstream::~plstream() Ligne 347    C++
>>        wxPLplotDemo.exe!wxPLplotstream::~wxPLplotstream() Ligne 91 C++
>> wxPLplotDemo.exe!wxPLplotwindow<wxFrame>::~wxPLplotwindow<wxFrame>()
>> Ligne 111    C++
>>        [Code externe]
>>        wxPLplotDemo.exe!wxAppConsoleBase::DeletePendingObjects() Ligne
>> 637    C++
>>        wxPLplotDemo.exe!wxAppConsoleBase::ProcessIdle() Ligne 445 C++
>>        wxPLplotDemo.exe!wxAppBase::ProcessIdle() Ligne 373    C++
>>        wxPLplotDemo.exe!wxEventLoopBase::ProcessIdle() Ligne 98    C++
>>        wxPLplotDemo.exe!wxEventLoopManual::DoRun() Ligne 263    C++
>>        wxPLplotDemo.exe!wxEventLoopBase::Run() Ligne 76    C++
>>        wxPLplotDemo.exe!wxAppConsoleBase::MainLoop() Ligne 380    C++
>>        wxPLplotDemo.exe!wxAppConsoleBase::OnRun() Ligne 302    C++
>>        wxPLplotDemo.exe!wxAppBase::OnRun() Ligne 312    C++
>>        wxPLplotDemo.exe!wxEntryReal(int & argc, wchar_t * * argv) Ligne
>> 503    C++
>>        wxPLplotDemo.exe!wxEntry(int & argc, wchar_t * * argv) Ligne
>> 181    C++
>>        wxPLplotDemo.exe!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ *
>> __formal, char * __formal, int nCmdShow) Ligne 290    C++
>>        wxPLplotDemo.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ *
>> hPrevInstance, char * __formal, int nCmdShow) Ligne 129    C++
>>        [Code externe]
>>
>> An if press step exception occurs this->m_graphicContexthas been
>> 0xFFFFFFFFFFF7...
>>
>> With VS 2013 there is no problem and setting breakpoint at same point
>> this breakpoint is reach only once.
>> I have build plplot with static lib and shared  lib  using release or
>> debug mode and that's change nothing.
>>
>> Have you got an idea to help me solving  this problem?
>>
>> Thanks in advance
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>>