plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Screen coordinates to data coordinates withwxWidgets driver

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

Thanks it works:-)

Le 22/12/2015 13:00, Phil Rosenberg a écrit :
> Hi Laurent, Alan
> I have just committed the changes exposing plTranslateCursor in the
> C++ binding. I have also documented it in the main API section - Alan,
> please tell me if this is not appropriate as it will not be exposed in
> other bindings. Also I am not 100% sure about the plGraphicsIn::state
> variable. This doesn't appear to be documented anywhere, there are
> just references to X11/X.h. I found a copy of that online, but haven't
> had chance to read up in detail. We really should document it
> ourselves.
>
> Laurent, if you are making use of the wxPLplotwindow templated class,
> then the easiest way to catch the mouse position now using the latest
> source is to inherit from this class and overload the virtual function
> OnLocate, which accepts a const reference to a PLGraphicsIn. This
> structure will have already been passed to plTranslateCursor and will
> have all relevant variables filled in. You can check wxPLplotDemo for
> an example of how this works. Alternatively you can check out
> wxPLplotwindow.h (in particular the OnMouse method) to see how you can
> write your own event capture code if you prefer.
>
> Phil
>
>
>
> On 22 December 2015 at 08:21, Phil Rosenberg <p.d...@gm...> wrote:
>> Okay Alan, will do. I was just a bit worried that there might be a reason
>> why pltranslatecursor had never been documented or propagated to other
>> bindings.
>> ________________________________
>> From: Alan W. Irwin
>> Sent: ‎20/‎12/‎2015 19:51
>> To: Phil Rosenberg
>> Cc: Laurent Berger; plp...@li...
>> Subject: Re: [Plplot-devel] Screen coordinates to data coordinates
>> withwxWidgets driver
>>
>> On 2015-12-20 12:07-0000 Phil Rosenberg wrote:
>>
>>> Hi Laurent
>>> (Alan, please see my email below - I accidentally replied to Laurent
>>> instead of replying to all yesterday)
>>>
>>> I've just  had a look and you can use plTranslateCursor to get the
>>> coordinates. This function is listed as part of the API on p181 of the
>>> documentation, but it doesn't seem to be documented anywhere.
>>>
>>> This function isn't exposed in the C++ interface, so therefore isn't
>>> exposed by the wxWidgets interface. Hence I am not sure how you can
>>> access it unless you are using the C interface.
>>>
>>> Alan - I have just written some code to expose plTranslateCursor in
>>> the C++ interface and have added some code to the wxWidgets binding to
>>> capture mouse events and pass them back to the user easily.
>>>
>>> Are you happy for me to commit these changes?
>> Sure.  There won't be a freeze on such merges to master for quite some
>> time so go ahead.  Please also include a test that exercises your
>> changes.  Would examples/c++/wxPLplotDemo.cpp be suitable for such a
>> test?
>>
>> 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] Screen coordinates to data coordinates withwxWidgets driver

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

Hi Laurent, Alan
I have just committed the changes exposing plTranslateCursor in the
C++ binding. I have also documented it in the main API section - Alan,
please tell me if this is not appropriate as it will not be exposed in
other bindings. Also I am not 100% sure about the plGraphicsIn::state
variable. This doesn't appear to be documented anywhere, there are
just references to X11/X.h. I found a copy of that online, but haven't
had chance to read up in detail. We really should document it
ourselves.

Laurent, if you are making use of the wxPLplotwindow templated class,
then the easiest way to catch the mouse position now using the latest
source is to inherit from this class and overload the virtual function
OnLocate, which accepts a const reference to a PLGraphicsIn. This
structure will have already been passed to plTranslateCursor and will
have all relevant variables filled in. You can check wxPLplotDemo for
an example of how this works. Alternatively you can check out
wxPLplotwindow.h (in particular the OnMouse method) to see how you can
write your own event capture code if you prefer.

Phil



On 22 December 2015 at 08:21, Phil Rosenberg <p.d...@gm...> wrote:
> Okay Alan, will do. I was just a bit worried that there might be a reason
> why pltranslatecursor had never been documented or propagated to other
> bindings.
> ________________________________
> From: Alan W. Irwin
> Sent: ‎20/‎12/‎2015 19:51
> To: Phil Rosenberg
> Cc: Laurent Berger; plp...@li...
> Subject: Re: [Plplot-devel] Screen coordinates to data coordinates
> withwxWidgets driver
>
> On 2015-12-20 12:07-0000 Phil Rosenberg wrote:
>
>> Hi Laurent
>> (Alan, please see my email below - I accidentally replied to Laurent
>> instead of replying to all yesterday)
>>
>> I've just  had a look and you can use plTranslateCursor to get the
>> coordinates. This function is listed as part of the API on p181 of the
>> documentation, but it doesn't seem to be documented anywhere.
>>
>> This function isn't exposed in the C++ interface, so therefore isn't
>> exposed by the wxWidgets interface. Hence I am not sure how you can
>> access it unless you are using the C interface.
>>
>> Alan - I have just written some code to expose plTranslateCursor in
>> the C++ interface and have added some code to the wxWidgets binding to
>> capture mouse events and pass them back to the user easily.
>>
>> Are you happy for me to commit these changes?
>
> Sure.  There won't be a freeze on such merges to master for quite some
> time so go ahead.  Please also include a test that exercises your
> changes.  Would examples/c++/wxPLplotDemo.cpp be suitable for such a
> test?
>
> 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] Problems applying patches

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

Hi Alan,



See below.

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Hi Arjen:
>
> I too am really glad the process is working for you now, but I am also just as startled
> as you were by your discovery of an LF working directory.  Therefore, I would
> appreciate you systematically investigating this question further so we can draw
> some definite conclusions with regard to other attempts at Window/Unix
> communications via "git format-patch"/"git am" results.
>
> 1. Just to double check your LF conclusion above, do you also get LF for the text
> files of a pristine working directory for master created with git clone before you make
> any local changes at all? If so, I guess that means Cygwin git is now interpreting
> your git platform as Unix with LF endings on text files, and your bad results
> yesterday were due to you creating that working directory in the past with an old
> Cygwin git version (or else some non-Cygwin git version) that interpreted your git
> platform to be CRLF.  Does that seem like a reasonable hypothesis to explain
> yesterday's bad results and today's good results?
>
No, I have checked several working directories I have for PLplot, accumulated over the years :), but I find LF line endings in various files that I did not touch myself.

> 2. Assuming LF what happens on a throwaway topic branch if you use a normal
> Windows editor to make a file change?  In particular you should check that the file
> created by that editor is CRLF, and if so, what what happens if you attempt to
> commit that file?  From my own experience with attempting to commit CRLF files, my
> prediction is the commit will tell you it is changing the repository result to LF (as it
> should) and leaving the working directory file as CRLF (which is problematic in my
> view, but that is what happened to me).  Anyhow, if your working directory starts out
> as LF, you are going to have to work pretty hard to keep it LF when using ordinary
> Windows tools to make changes.  So you might want to get clarification on the
> Cygwin list about why Cygwin's git is creating LF working directories for a repository
> like ours where the .gitattributes files says text=auto, i.e., all working directories
> should have native line endings.

If I edit a file which is then saved with CRLF and commit it, I get a warning about the CR, but the file is left as it is. Luckily my text editors don't mind.

>
> 2. Could you double-check that when you unpacked the tarball from me the patchfile
> results were LF and not CRLF?  (It might make a difference whether you unpack with
> Cygwin tar or some other tar.)
>
No, the individual patch files are simply LF, as I expected actually - the unpacking facility does not interpret files in any way.

> 3. Assuming you confirm above that both your working directory and patch files are
> LF could you try the experiments of using "git am"
> (from a fresh start each time) with (1) "--keep-cr", (2) "--no-keep-cr", and (3) neither
> option? My extremely tentative prediction is the --keep-cr option will fail (because it
> will attempt to convert the patch file to CRLF before applying), and the other two will
> succeed but it would be good for you to let us know exactly what happens in the
> three different cases as a guide to what to expect on git CRLF platforms.
>
Actually when I succeeded with applying the patch yesterday, I used the -keep-cr option. So that is working correctly in my setup.

Just now I tried the other possibilities: --no-keep-cr and no options at all. They both work in exactly the same way as -keep-cr. A few messages about trailing whitespace and that is it.

> One sure conclusion is that Windows users attempting to communicate with "git
> format-patch"/"git am" must look at their working directory (especially if they are
> using Cygwin git) to determine if it is CRLF or LF, and similarly for any patch files. I
> am pretty sure the --no-keep-cr and ---keep-cr "git am" options will help sort out
> when there is a mismatch in line-endings, but the experiments mentioned in
> 3 should help confirm/disprove that hypothesis.
>
Not sure what to conclude from the above experiments.

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.

Re: [Plplot-devel] Screen coordinates to data coordinates withwxWidgets driver

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

Okay Alan, will do. I was just a bit worried that there might be a reason why pltranslatecursor had never been documented or propagated to other bindings.

-----Original Message-----
From: "Alan W. Irwin" <ir...@be...>
Sent: ‎20/‎12/‎2015 19:51
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "Laurent Berger" <lau...@un...>; "plp...@li..." <plp...@li...>
Subject: Re: [Plplot-devel] Screen coordinates to data coordinates withwxWidgets driver

On 2015-12-20 12:07-0000 Phil Rosenberg wrote:

> Hi Laurent
> (Alan, please see my email below - I accidentally replied to Laurent
> instead of replying to all yesterday)
>
> I've just  had a look and you can use plTranslateCursor to get the
> coordinates. This function is listed as part of the API on p181 of the
> documentation, but it doesn't seem to be documented anywhere.
>
> This function isn't exposed in the C++ interface, so therefore isn't
> exposed by the wxWidgets interface. Hence I am not sure how you can
> access it unless you are using the C interface.
>
> Alan - I have just written some code to expose plTranslateCursor in
> the C++ interface and have added some code to the wxWidgets binding to
> capture mouse events and pass them back to the user easily.
>
> Are you happy for me to commit these changes?

Sure.  There won't be a freeze on such merges to master for quite some
time so go ahead.  Please also include a test that exercises your
changes.  Would examples/c++/wxPLplotDemo.cpp be suitable for such a
test?

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] Problems applying patches

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

Hi Chris, Alan,



My favourite editor and the one I use less frequently but nevertheless use from time to time both can smoothly handle LF line endings and store files either as LF or CRLF. In fact, Cygwin git behaving the way it does, makes sure that the shell scripts for testing work fine - my Cygwin installation expects such files to follow the UNIX convention.



The result of "git config -list" is surprisingly short:


git config --list
user.name=Arjen Markus
user.email=arj...@de...


So core.eol is not set. My guess is that the default "native" is now the default for the Cygwin installation, which definitely uses the UNIX convention.

More on the other experiments later.

Regards,

Arjen


> -----Original Message-----
> From: Chris Marshall [mailto:dev...@gm...]
> Sent: Monday, December 21, 2015 10:07 PM
> To: plp...@li...
> Subject: Re: [Plplot-devel] Problems applying patches
>
> I use cygwin git and it seems to behave like a standard unix git as far as line ending.
> I also use the cygwin vim which has no problem leaving the LF untouched.  Your
> mileage with windows editors will definitely vary!
>
> --Chris
>
> On 12/21/2015 15:46, Alan W. Irwin wrote:
> > On 2015-12-21 11:37-0800 Alan W. Irwin wrote:
> >
> >> I too am really glad the process is working for you now, but I am
> >> also just as startled as you were by your discovery of an LF working
> >> directory.  Therefore, I would appreciate you systematically
> >> investigating this question further so we can draw some definite
> >> conclusions with regard to other attempts at Window/Unix
> >> communications via "git format-patch"/"git am" results.
> > In addition to the other experiments I asked you to perform, you
> > should also let us know the complete results of
> >
> > git config --list
> >
> > In particular I am wondering if
> >
> > core.eol
> >
> > is set.
> >
> > That variable gives you complete control over the line endings used in
> > your working directory.  However, if using git config to set that
> > variable be sure you use the --global setting so that you do not
> > change the repository version of the config file for the rest of us
> > (see also
> > <https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration>).
> >
> > Note, if core.eol is not set the default is "native" which I think
> > might be what you want.
> >
> > However, here is the Key question: are you currently getting a LF
> > working directory because Cygwin sets core.eol to lf by default or
> > does Cygwin git assume that "native" really means a LF working
> > directory on Cygwin platforms?
> >
> > Since your editing tools are likely happier with a CRLF working
> > directory, I think that is what you ultimately want.  Of course, that
> > likely means you will have to run any patch from me through a LF to
> > CRLF converter and use the "--keep-cr" option for "git am" (which
> > further reading tells me simply avoids doing the default change from
> > CRLF to LF, but also does not enforce CRLF if the patch file is LF).
> >
> > Anyhow, I would take the time now to set up git line endings exactly
> > the way you want them based on your experiments editing files and
> > using git am.  That would be much better than enforcing LF now (say
> > with core.eol) just to keep git-am happy and regretting that
> > working-directory setting later once you start actually making further
> > changes with your favorite editor.
> >
> > 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 mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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.

Re: [Plplot-devel] Problems applying patches

[Chris M. <dev...@gm...>]

I use cygwin git and it seems to behave like a
standard unix git as far as line ending.  I also use
the cygwin vim which has no problem leaving
the LF untouched.  Your mileage with windows
editors will definitely vary!

--Chris

On 12/21/2015 15:46, Alan W. Irwin wrote:
> On 2015-12-21 11:37-0800 Alan W. Irwin wrote:
>
>> I too am really glad the process is working for you now, but I am also
>> just as startled as you were by your discovery of an LF working
>> directory.  Therefore, I would appreciate you systematically
>> investigating this question further so we can draw some definite
>> conclusions with regard to other attempts at Window/Unix
>> communications via "git format-patch"/"git am" results.
> In addition to the other experiments I asked you to perform, you
> should also let us know the complete results of
>
> git config --list
>
> In particular I am wondering if
>
> core.eol
>
> is set.
>
> That variable gives you complete control over the line endings used in
> your working directory.  However, if using git config to set that
> variable be sure you use the --global setting so that you do not
> change the repository version of the config file for the rest of us
> (see also
> <https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration>).
>
> Note, if core.eol is not set the default is "native" which I think
> might be what you want.
>
> However, here is the Key question: are you currently getting a LF
> working directory because Cygwin sets core.eol to lf by default or
> does Cygwin git assume that "native" really means a LF working
> directory on Cygwin platforms?
>
> Since your editing tools are likely happier with a CRLF working
> directory, I think that is what you ultimately want.  Of course, that
> likely means you will have to run any patch from me through a LF to
> CRLF converter and use the "--keep-cr" option for "git am" (which
> further reading tells me simply avoids doing the default change from
> CRLF to LF, but also does not enforce CRLF if the patch file is LF).
>
> Anyhow, I would take the time now to set up git line endings exactly
> the way you want them based on your experiments editing files and
> using git am.  That would be much better than enforcing LF now (say
> with core.eol) just to keep git-am happy and regretting that
> working-directory setting later once you start actually making further
> changes with your favorite editor.
>
> 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 mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problems applying patches

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

On 2015-12-21 11:37-0800 Alan W. Irwin wrote:

> I too am really glad the process is working for you now, but I am also
> just as startled as you were by your discovery of an LF working
> directory.  Therefore, I would appreciate you systematically
> investigating this question further so we can draw some definite
> conclusions with regard to other attempts at Window/Unix
> communications via "git format-patch"/"git am" results.

In addition to the other experiments I asked you to perform, you
should also let us know the complete results of

git config --list

In particular I am wondering if

core.eol

is set.

That variable gives you complete control over the line endings used in
your working directory.  However, if using git config to set that
variable be sure you use the --global setting so that you do not
change the repository version of the config file for the rest of us
(see also
<https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration>).

Note, if core.eol is not set the default is "native" which I think
might be what you want.

However, here is the Key question: are you currently getting a LF
working directory because Cygwin sets core.eol to lf by default or
does Cygwin git assume that "native" really means a LF working
directory on Cygwin platforms?

Since your editing tools are likely happier with a CRLF working
directory, I think that is what you ultimately want.  Of course, that
likely means you will have to run any patch from me through a LF to
CRLF converter and use the "--keep-cr" option for "git am" (which
further reading tells me simply avoids doing the default change from
CRLF to LF, but also does not enforce CRLF if the patch file is LF).

Anyhow, I would take the time now to set up git line endings exactly
the way you want them based on your experiments editing files and
using git am.  That would be much better than enforcing LF now (say
with core.eol) just to keep git-am happy and regretting that
working-directory setting later once you start actually making further
changes with your favorite editor.

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] Problems applying patches

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

On 2015-12-21 08:29-0000 Arjen Markus wrote:

> Hi Alan,
>
>> I tried that on my current working directory and private branch: same messages as before. I will try the "fresh start" approach later. The curious thing is that it also produces error messages on files that I have not changed in any way for this branch. These files are being moved to a temporary "old" directory. Oh well, let's wait for the "fresh start" approach to either work or fail.
>
> The fresh start did the trick, but to my surprise the line endings in this completely fresh working directory are LF!

> What the reason, the most important thing is that this worked.

Hi Arjen:

I too am really glad the process is working for you now, but I am also
just as startled as you were by your discovery of an LF working
directory.  Therefore, I would appreciate you systematically
investigating this question further so we can draw some definite
conclusions with regard to other attempts at Window/Unix
communications via "git format-patch"/"git am" results.

1. Just to double check your LF conclusion above, do you also get LF
for the text files of a pristine working directory for master created
with git clone before you make any local changes at all? If so, I
guess that means Cygwin git is now interpreting your git platform as
Unix with LF endings on text files, and your bad results yesterday
were due to you creating that working directory in the past with an
old Cygwin git version (or else some non-Cygwin git version) that
interpreted your git platform to be CRLF.  Does that seem like a
reasonable hypothesis to explain yesterday's bad results and today's
good results?

2. Assuming LF what happens on a throwaway topic branch if you use a
normal Windows editor to make a file change?  In particular you should
check that the file created by that editor is CRLF, and if so, what
what happens if you attempt to commit that file?  From my own
experience with attempting to commit CRLF files, my prediction is the
commit will tell you it is changing the repository result to LF (as it
should) and leaving the working directory file as CRLF (which is
problematic in my view, but that is what happened to me).  Anyhow,
if your working directory starts out as LF, you are going to have
to work pretty hard to keep it LF when using ordinary Windows
tools to make changes.  So you might want to get clarification
on the Cygwin list about why Cygwin's git is creating LF working
directories for a repository like ours where the .gitattributes
files says text=auto, i.e., all working directories should have
native line endings.

2. Could you double-check that when you unpacked the tarball from me
the patchfile results were LF and not CRLF?  (It might make a
difference whether you unpack with Cygwin tar or some other tar.)

3. Assuming you confirm above that both your working directory and
patch files are LF could you try the experiments of using "git am"
(from a fresh start each time) with (1) "--keep-cr", (2)
"--no-keep-cr", and (3) neither option? My extremely tentative
prediction is the --keep-cr option will fail (because it will attempt
to convert the patch file to CRLF before applying), and the other two
will succeed but it would be good for you to let us know exactly what
happens in the three different cases as a guide to what to expect on
git CRLF platforms.

One sure conclusion is that Windows users attempting to communicate
with "git format-patch"/"git am" must look at their working directory
(especially if they are using Cygwin git) to determine if it is CRLF
or LF, and similarly for any patch files. I am pretty sure the
--no-keep-cr and ---keep-cr "git am" options will help sort out when
there is a mismatch in line-endings, but the experiments mentioned in
3 should help confirm/disprove that hypothesis.

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] Problems applying patches

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

Hi Alan,

> I tried that on my current working directory and private branch: same messages as before. I will try the "fresh start" approach later. The curious thing is that it also produces error messages on files that I have not changed in any way for this branch. These files are being moved to a temporary "old" directory. Oh well, let's wait for the "fresh start" approach to either work or fail.

The fresh start did the trick, but to my surprise the line endings in this completely fresh working directory are LF!

What the reason, the most important thing is that this worked.

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.

Re: [Plplot-devel] Problems applying patches

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> I was about to answer your off-list post to me concerning this issue, but taking this
> conversation to the list at this stage is a good idea so I will answer you here instead.
>
...
>
> What happens with a fresh start if you try "git am --keep-cr"?  I mentioned this
> possibility off-list before, but as far as I can tell you have not tried it yet.
>
> That seems to be the universal advice about what option should be used on
> Windows platforms with "git am" _even when communicating between Windows
> platforms_. In the current context of communicating from my Unix platform to your
> Windows platform I am hoping that what --keep-cr actually does is automatically
> transform the LF patch context lines and changed lines in my series of patches to
> CRLF before applying.
>

I tried that on my current working directory and private branch: same messages as before. I will try the "fresh start" approach later. The curious thing is that it also produces error messages on files that I have not changed in any way for this branch. These files are being moved to a temporary "old" directory. Oh well, let's wait for the "fresh start" approach to either work or fail.

> If that doesn't work, another possibility to try (starting with a fresh start) is to run my
> patch series through a utility to convert all line endings in the patch file to CRLF
> before you attempt to use "git am --keep-cr".  I cannot see how that method could
> possibly fail.... (Famous last words.  :-) )
>
> But if neither of those ideas work, I will try a question to the git list since surely there
> must be a method of working with "git format-patch"/"git am" that allows collaboration
> between developers on Windows and Unix platforms with all line endings issues
> automatically taken care of.
>
A complication might be that I am using git via Cygwin and Cygwin expects shell scripts to be in UNIX format (LF line endings). IIRC, Cygwin allows either format. You have to chose at installation time.

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.

Re: [Plplot-devel] Screen coordinates to data coordinates with wxWidgets driver

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

On 2015-12-20 12:07-0000 Phil Rosenberg wrote:

> Hi Laurent
> (Alan, please see my email below - I accidentally replied to Laurent
> instead of replying to all yesterday)
>
> I've just  had a look and you can use plTranslateCursor to get the
> coordinates. This function is listed as part of the API on p181 of the
> documentation, but it doesn't seem to be documented anywhere.
>
> This function isn't exposed in the C++ interface, so therefore isn't
> exposed by the wxWidgets interface. Hence I am not sure how you can
> access it unless you are using the C interface.
>
> Alan - I have just written some code to expose plTranslateCursor in
> the C++ interface and have added some code to the wxWidgets binding to
> capture mouse events and pass them back to the user easily.
>
> Are you happy for me to commit these changes?

Sure.  There won't be a freeze on such merges to master for quite some
time so go ahead.  Please also include a test that exercises your
changes.  Would examples/c++/wxPLplotDemo.cpp be suitable for such a
test?

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] Problems applying patches

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

On 2015-12-20 12:34-0000 Arjen Markus wrote:

> Hi everyone,

> Alan and I are developing a new Fortran binding and we would like to
cooperate using patches rather than sending complete source files to
one another. However, I am experiencing weird problems with the "git
am" command. It simply doesn't apply the patches. This may have to do
with the line endings (I work on Windows with CRLF and Alan on Linux
with CR), but I have been unable to figure out how to get git to do
its work.

Hi Arjen:

I was about to answer your off-list post to me concerning this issue,
but taking this conversation to the list at this stage is a good idea
so I will answer you here instead.

Just to clarify all Unix platforms like mine use LF (not CR) for text
file line endings.

So when I create the series of patches with git --format-patch, the
context lines and change lines are all LF.  And there doesn't appear
to be any obvious option to git format-patch to change those to CRLF.
But Arjen's checked out working directory text files are all
(correctly for his platform) CRLF so the patch won't apply without a
transformation of those LF endings in the patch context and changed
lines to CRLF.

By the way, "fresh start" below means starting with a new topic branch
that is generated from a clean up-to-date master branch.  git am
--abort probably produces that, but I wouldn't count on that until we
gain more experience.

What happens with a fresh start if you try "git am --keep-cr"?  I
mentioned this possibility off-list before, but as far as I can tell
you have not tried it yet.

That seems to be the universal advice about what option should be used
on Windows platforms with "git am" _even when communicating between
Windows platforms_. In the current context of communicating from my
Unix platform to your Windows platform I am hoping that what --keep-cr
actually does is automatically transform the LF patch context lines
and changed lines in my series of patches to CRLF before applying.

If that doesn't work, another possibility to try (starting with a
fresh start) is to run my patch series through a utility to convert
all line endings in the patch file to CRLF before you attempt to use
"git am --keep-cr".  I cannot see how that method could possibly
fail.... (Famous last words.  :-) )

But if neither of those ideas work, I will try a question to the git
list since surely there must be a method of working with "git
format-patch"/"git am" that allows collaboration between developers on
Windows and Unix platforms with all line endings issues automatically
taken care of.

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] Screen coordinates to data coordinates with wxWidgets driver

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

Hi phil,

Thanks you to waste time on my problem.

I have try something like this
void FenetreCourbe::OnLeftDown(wxMouseEvent& event)
{
     PLGraphicsIn g;
     wxPLplotstream* pls = GetStream();
     // pls->adv(0); uncomment this line does not change result
     g.dX = event.GetX();
     g.dY = event.GetY();
     g.subwindow=0;
     plTranslateCursor(&g);
}

g.wx, g.wy are always 0 I have used this 
http://plplot.sourcearchive.com/documentation/5.9.9-1/plpage_8c_aee8b46bbe61887f2fd8dec90a7338e0d.html#aee8b46bbe61887f2fd8dec90a7338e0d. 
I do not understand why I must give g.dX, g.dy and not g.pX and g.pY

All others fields of PLGraphics structure are unitialized



Le 20/12/2015 13:07, Phil Rosenberg a écrit :
> Hi Laurent
> (Alan, please see my email below - I accidentally replied to Laurent
> instead of replying to all yesterday)
>
> I've just  had a look and you can use plTranslateCursor to get the
> coordinates. This function is listed as part of the API on p181 of the
> documentation, but it doesn't seem to be documented anywhere.
>
> This function isn't exposed in the C++ interface, so therefore isn't
> exposed by the wxWidgets interface. Hence I am not sure how you can
> access it unless you are using the C interface.
>
> Alan - I have just written some code to expose plTranslateCursor in
> the C++ interface and have added some code to the wxWidgets binding to
> capture mouse events and pass them back to the user easily.
>
> Are you happy for me to commit these changes?
>
> On 19 December 2015 at 21:46, Phil Rosenberg <p.d...@gm...> wrote:
>> Hi Laurent
>>
>> It looks to me like you are writing a wxWidgets application yourself.
>> Is this correct? Unfortunately plGetCursor only works when you do not
>> provide your own wxDC to Plplot, in this case plplot uses wxPlViewer -
>> a separate wxWidgets executable which captures the mouse clicks and
>> reports them back to the library. It is wxPlViewer that is used when
>> you run the examples from the command line.
>>
>> If you are passing a wxDC into Plplot, plGetCursor doesn't work and
>> emits a warning, but you probably don't see the warning as it is sent
>> to stdout. In this case you must handle mouse events yourself and
>> plGetCursor will not work. You need something like
>>
>> void wxPlFrame::OnMouse( wxMouseEvent &event )
>>
>> {
>>
>> if(!event.ButtonDown())
>> return;
>> //get the mouse position
>> wxPoint cursorPosition = event.GetPosition();
>>
>> //some code to convert to plot coordinate
>> }
>>
>> Bind this function using the wxWidgets Bind() function or and event
>> table. Unfortunately the last bit, converting to plot coordinates you
>> may have to do yourself. I do not think there is a built in function
>> to do it - Alan, please correct me if this is wrong. However, if in
>> your wxWindow you remember the parameters passed into plwind then you
>> should be able to calculate the plot coordinates from the pixel values
>> returned from GetPosition().

[Plplot-devel] Problems applying patches

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

Hi everyone,



Alan and I are developing a new Fortran binding and we would like to cooperate using patches rather than sending complete source files to one another. However, I am experiencing weird problems with the "git am" command. It simply doesn't apply the patches. This may have to do with the line endings (I work on Windows with CRLF and Alan on Linux with CR), but I have been unable to figure out how to get git to do its work.



1.      Applying the patch to the source files as they are (CRLF) gave errors that the patch didn't apply

2.      Changing the line endings to CR gave the message that the file didn't match the index

3.      Committing and then applying the patch got me back to the first situation



I simply have no clue as to what I am supposed to do here. My current idea is to use "patch" instead of "git am" to incorporate the changes, but that may require some tweaking on my part of the dozen patch files Alan provided.



Does anyone have a better idea?



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.

Re: [Plplot-devel] Screen coordinates to data coordinates with wxWidgets driver

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

Hi Laurent
(Alan, please see my email below - I accidentally replied to Laurent
instead of replying to all yesterday)

I've just  had a look and you can use plTranslateCursor to get the
coordinates. This function is listed as part of the API on p181 of the
documentation, but it doesn't seem to be documented anywhere.

This function isn't exposed in the C++ interface, so therefore isn't
exposed by the wxWidgets interface. Hence I am not sure how you can
access it unless you are using the C interface.

Alan - I have just written some code to expose plTranslateCursor in
the C++ interface and have added some code to the wxWidgets binding to
capture mouse events and pass them back to the user easily.

Are you happy for me to commit these changes?

On 19 December 2015 at 21:46, Phil Rosenberg <p.d...@gm...> wrote:
> Hi Laurent
>
> It looks to me like you are writing a wxWidgets application yourself.
> Is this correct? Unfortunately plGetCursor only works when you do not
> provide your own wxDC to Plplot, in this case plplot uses wxPlViewer -
> a separate wxWidgets executable which captures the mouse clicks and
> reports them back to the library. It is wxPlViewer that is used when
> you run the examples from the command line.
>
> If you are passing a wxDC into Plplot, plGetCursor doesn't work and
> emits a warning, but you probably don't see the warning as it is sent
> to stdout. In this case you must handle mouse events yourself and
> plGetCursor will not work. You need something like
>
> void wxPlFrame::OnMouse( wxMouseEvent &event )
>
> {
>
> if(!event.ButtonDown())
> return;
> //get the mouse position
> wxPoint cursorPosition = event.GetPosition();
>
> //some code to convert to plot coordinate
> }
>
> Bind this function using the wxWidgets Bind() function or and event
> table. Unfortunately the last bit, converting to plot coordinates you
> may have to do yourself. I do not think there is a built in function
> to do it - Alan, please correct me if this is wrong. However, if in
> your wxWindow you remember the parameters passed into plwind then you
> should be able to calculate the plot coordinates from the pixel values
> returned from GetPosition().

Re: [Plplot-devel] Screen coordinates to data coordinates with wxWidgets driver

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

On 2015-12-19 11:42+0100 Laurent Berger wrote:

> Thanks for your answer. I have missed option -locate and now I can see 
> coordinate in example x01c. It's really a good idea to  insert example name 
> with function description in doc:-) .
> Now I want to get coordinates in a program like wxPLplotdemo and I don't know 
> where to insert this function in my code. I have try to insert in mouse 
> event( left button down) like this:
>
> void FenetreCourbe::OnLeftDown(wxMouseEvent& event)
> {
>    PLGraphicsIn x;
>    plGetCursor(&x);
>    wxString s;
>    s.Printf("%f %f %d %d",x.dX,x.dY,x.pX,x.pY);
>    wxMessageBox(s);
> }
>
> but coordinates are always -1 -1 -1 -1 when I click in curve. I don't know 
> what to modify to get this coordinates.

Hi Laurent:

I suggest you follow exactly what is done in example 1 code since that
obviously works for you.  For example, surround the section of your
code that is outputting text with

pltext();
<text output code>
plgra();

To see more about these functions, look at
<http://plplot.sourceforge.net/docbook-manual/plplot-html-5.11.1/pltext.html>
and
<http://plplot.sourceforge.net/docbook-manual/plplot-html-5.11.1/plgra.html>.

Also my above advice is based on examples/c/x01.c, but assuming you want to
programme this in C++, you should follow the syntax for the PLplot
commands in examples/c++/x01.cc.

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] Screen coordinates to data coordinates with wxWidgets driver

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

Thanks for your answer. I have missed option -locate and now I can see 
coordinate in example x01c. It's really a good idea to  insert example 
name with function description in doc:-) .
Now I want to get coordinates in a program like wxPLplotdemo and I don't 
know where to insert this function in my code. I have try to insert in 
mouse event( left button down) like this:

void FenetreCourbe::OnLeftDown(wxMouseEvent& event)
{
     PLGraphicsIn x;
     plGetCursor(&x);
     wxString s;
     s.Printf("%f %f %d %d",x.dX,x.dY,x.pX,x.pY);
     wxMessageBox(s);
}

but coordinates are always -1 -1 -1 -1 when I click in curve. I don't 
know what to modify to get this coordinates.



Le 18/12/2015 23:54, Alan W. Irwin a écrit :
> On 2015-12-18 23:03+0100 Laurent Berger wrote:
>
>> Hi,
>>
>> In plplot using wxwidgets driver which function must I use to get data
>> coordinates using mouse event?
>>
>> I have try  plGetCursor in an event callback but i connot retrieve
>> coordinate.
>
> Hi Laurent:
>
> Look at examples/c/x01c.c for an example of how plGetCursor should
> be used.
>
> If you get a good result with an interactive device accessible to you
> for example 1 with the -locate command-line option, but not -dev
> wxwidgets, that would be a bug in -dev wxwidgets.  However, although I
> don't have access to wxwidgets at the moment, I am pretty sure I have
> already made that check in the past, and there was no such bug in -dev
> wxwidgets compared to the good interactive results that occur for the
> xwin, xcairo, and qtwidget 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] Screen coordinates to data coordinates with wxWidgets driver

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

On 2015-12-18 23:03+0100 Laurent Berger wrote:

> Hi,
>
> In plplot using wxwidgets driver which function must I use to get data
> coordinates using mouse event?
>
> I have try  plGetCursor in an event callback but i connot retrieve
> coordinate.

Hi Laurent:

Look at examples/c/x01c.c for an example of how plGetCursor should
be used.

If you get a good result with an interactive device accessible to you
for example 1 with the -locate command-line option, but not -dev
wxwidgets, that would be a bug in -dev wxwidgets.  However, although I
don't have access to wxwidgets at the moment, I am pretty sure I have
already made that check in the past, and there was no such bug in -dev
wxwidgets compared to the good interactive results that occur for the
xwin, xcairo, and qtwidget 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
__________________________

[Plplot-devel] Screen coordinates to data coordinates with wxWidgets driver

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

Hi,

In plplot using wxwidgets driver which function must I use to get data 
coordinates using mouse event?

I have try  plGetCursor in an event callback but i connot retrieve 
coordinate.

Thanks for your help

Re: [Plplot-devel] git blog

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

On 2015-12-16 08:22-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Wednesday, December 16, 2015 12:59 AM
>> To: PLplot development list
>> Subject: [Plplot-devel] git blog
>>
>> My latest "interesting" experience with git concerned line endings.
>>
>> (I ran into this issue as part of my joint work with Arjen on the new Fortran bindings
>> which we plan to merge to master a month or so before I make our next release to
>> allow plenty of time for testing.)
>>
>> Getting back to the line endings topic, by default (see
>> .gitattributes) our text files have the auto attribute which means the repository
>> version will be normalized to LF endings and the checked out versions will be native
>> line endings (i.e., LF for Unix, CRLF for Windows).
>>
>> However, I just committed (on a private topic branch) some work by Arjen that he
>> sent me in a tarball.  Those files in the tarball contained CRLF line endings.  Here is
>> what git said when I committed those (unchanged) files.
>>
>> software@raven> git commit
>> [new_f95_update 73336a7] Fortran binding: add missing files to the new binding
>> warning: CRLF will be replaced by LF in bindings/f95/plparseopts.f90.
>> The file will have its original line endings in your working directory.
>>

> Line endings cause no end of nasty little issues like this. By the
looks of the messages, git is keeping two settings per file: the way
it should go into the repository and how it should be written on disk.
I would have thought that depends only on the OS.

Hi Arjen:

It actually depends on the .gitattributes file in our repository (or
any other) which configures how line endings are treated for a
particular repository.

> Several years ago I had set my editor to save files with LF instead
of CRLF. This led to complaints from colleagues who saw these LF line
endings appear in the Windows-based repository. Every file I touched
was stored in completely new form because of this. So I turned it back
to CRLF.

CRLF is also correct for you for the PLplot repository which is configured in
the .gitattributes file to generate native line endings (i.e, LF for Unix
and CRLF for Windows) in the working directory for text files while
those files always have LF endings in the repository itself.
Furthermore (as in my early post today) git gets a bit confused if you
go out of your way to violate those working directory expectations for each
platform (i.e., if I create a text file in the working directory with CRLF or you create a text
file in the working directory with LF).  But the Unix tr command can
convert from CRLF to LF in a hurry so line endings are not much of a problem for
me especially when the git commit command warns me of exactly what it is
doing with line endings (in the case earlier today converting to LF
for the repository, but it warned the CRLF line endings were still
in my working directory.

> Perhaps I should take more care and send files in LF form when
bypassing the repository.

In all honesty it is not much of a problem for me to do the necessary
conversions.  However, I am virtually positive line endings will never
be an issue (so long as you stick with CRLF and I stick with LF that
are respectively appropriate for our two platforms), if we bypass the
SF repository (which we have to do with our rebase workflow to
collabarate on a topic branch) using "git format-patch"/"git am".

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] git blog

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, December 16, 2015 12:59 AM
> To: PLplot development list
> Subject: [Plplot-devel] git blog
>
> My latest "interesting" experience with git concerned line endings.
>
> (I ran into this issue as part of my joint work with Arjen on the new Fortran bindings
> which we plan to merge to master a month or so before I make our next release to
> allow plenty of time for testing.)
>
> Getting back to the line endings topic, by default (see
> .gitattributes) our text files have the auto attribute which means the repository
> version will be normalized to LF endings and the checked out versions will be native
> line endings (i.e., LF for Unix, CRLF for Windows).
>
> However, I just committed (on a private topic branch) some work by Arjen that he
> sent me in a tarball.  Those files in the tarball contained CRLF line endings.  Here is
> what git said when I committed those (unchanged) files.
>
> software@raven> git commit
> [new_f95_update 73336a7] Fortran binding: add missing files to the new binding
> warning: CRLF will be replaced by LF in bindings/f95/plparseopts.f90.
> The file will have its original line endings in your working directory.
>
Line endings cause no end of nasty little issues like this. By the looks of the messages, git is keeping two settings per file: the way it should go into the repository and how it should be written on disk. I would have thought that depends only on the OS.

Several years ago I had set my editor to save files with LF instead of CRLF. This led to complaints from colleagues who saw these LF line endings appear in the Windows-based repository. Every file I touched was stored in completely new form because of this. So I turned it back to CRLF.

Perhaps I should take more care and send files in LF form when bypassing the repository.

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] git blog

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

My latest "interesting" experience with git concerned line endings.

(I ran into this issue as part of my joint work with Arjen on the new
Fortran bindings which we plan to merge to master a month or so before
I make our next release to allow plenty of time for testing.)

Getting back to the line endings topic, by default (see
.gitattributes) our text files have the auto attribute which means the
repository version will be normalized to LF endings and the checked
out versions will be native line endings (i.e., LF for Unix, CRLF for Windows).

However, I just committed (on a private topic branch) some work
by Arjen that he sent me in a tarball.  Those files in the tarball
contained CRLF line endings.  Here is what git said when
I committed those (unchanged) files.

software@raven> git commit
[new_f95_update 73336a7] Fortran binding: add missing files to the new binding
warning: CRLF will be replaced by LF in bindings/f95/plparseopts.f90.
The file will have its original line endings in your working directory.

And so forth for the remaining files he sent me in the tarball.

The repository version is LF (which is good), but I was concerned
about those CRLF files still in my working copy which are not
equivalent to the LF versions that would normally be checked out on my
platform to my working copy from my local repository.  For example, I
could conceive of a scenario where "git rebase" might run into trouble
for my local topic branch due to this issue with my local working
copy.

Accordingly, I changed to bindings/f95 in my working copy where these
files are all located and used

for FILE in *; do echo $FILE; tr -d $'\r' <$FILE >/tmp/$FILE; mv -f /tmp/$FILE $FILE; done

to transform my checked out file versions from CRLF to LF.

After that working directory change, "git status" claimed the files
were changed.  However, when I used "git add" for those files
the "git status" result turned into

On branch new_f95_update
nothing to commit, working directory clean

That result makes a lot of sense since my local changes to convert
CRLF to LF were exactly consistent with the expected native checked
out result so there was nothing to commit (once I had used "git add").

Furthermore, I looked for any other instances where my working directory
might not be consistent with the expected native treatment of line endings
using

git check-attr --all $(find . -type f |grep -v .git |xargs grep -l $'\r') |less

and in all cases, the files containing $'\r' (i.e., a carriage return
character) were all binary files with the attribute "text: unset"
which is confirmation that we have properly identified the binary
files in .gitattributes where line ending manipulations should not be
done.

So the conclusion is our git repositories are set up by our
.gitattributes file in a way that is smart about native line endings
for both text files and binary files, but potentially you could create
some line ending trouble (just for your local working directory since
this issue cannot propagate to your local repository or anywhere else)
if you copy by non-git means (e.g., via a tarball) files with
non-native line endings to your working directory and you don't fix
that situation (as I did above with the tr command for this particular
instance).

I am virtually positive that if Arjen had sent me his work as local
topic branch commits that he had formatted with "git format-patch",
then the line endings would not have been an issue when I applied his
commits to my own local topic branch using "git am".

So this is yet another reason to use "git format-patch"/"git am" to
communicate private topic branch work between our developers who are
collaborating on a topic that is not yet mature enough to qualify to
be committed to the master branch.

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] Plplot Source Error

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

On 2015-12-11 12:59-0000 Phil Rosenberg wrote:

> Hi Alan
> My latest commit has fixed the missing plot. Your option 3 will need
> some work. Currently shapelib is used if it is available regardless of
> the situation with PL_DEPECATED.

Hi Phil:

I am sorry, but what I said before was misleading and therefore
lead you into the following language propagation issue:

The current examples/c/x19.c has conditionally compiled code in it,
e.g.,

#ifdef PL_USE_SHAPEFILES

But that macro approach obviously only works for C and C+, and cannot
be propagated to the rest of our supported languages.  So instead
of using macros in the examples, we need the core library to
handle all of this.

So to rephrase what I said, what we really need is the following:

1. -DHAVE_SHAPELIB=OFF, -DPL_DEPRECATED=OFF
2. -DHAVE_SHAPELIB=ON, -DPL_DEPRECATED=OFF
3. -DHAVE_SHAPELIB=OFF, -DPL_DEPRECATED=ON
4. -DHAVE_SHAPELIB=ON, -DPL_DEPRECATED=ON

For PL_DEPRECATED=OFF _the libplplot C library_ should rely completely on the shapelib
approach, and for PL_DEPRECATED=ON that library should rely completely on the
traditional non-shapelib approach.  So following that philosophy we
should have the following results:

Case 1: The library should emit a warning for _every_ plmap-related
call that shapelib is missing and otherwise do nothing with those
calls. So for this case example 19 will plot a box (generated by
plenv) for every page plus generate warning messages, but the plotted
pages will contain nothing else for all languages.

Case 2: The library should proceed with all the shapelib logic for all
plmap calls.  Thus, the example 19 result will be complete for every
page with no warnings for all languages.  (From what you said, I think
we have this result now, but I will wait to test it until you are done
with your library changes and dropped the macro approach
in examples/c/19c.c and examples/c++/x19c.cc).

Cases 3 and 4: The library should proceed with the traditional
approach for the plmap call, but for all the rest of the plmap-related
calls that are only relevant to shapelib should emit a warning (e.g.,
"The shapelib form of plmap calls are not available when the
PL_DEPRECATED macro is #defined). The example 19 results for this case
for all languages should look fine for all but the last page, and that
page should just contain a box generated by the plenv command and also
generate a lot of warnings from the library.

Sorry for the previous misleading communication.

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] Plplot Source Error

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

Hi Alan
My latest commit has fixed the missing plot. Your option 3 will need
some work. Currently shapelib is used if it is available regardless of
the situation with PL_DEPECATED.

Phil

On 10 December 2015 at 20:16, Alan W. Irwin <ir...@be...> wrote:
> On 2015-12-10 12:36-0000 Phil Rosenberg wrote:
>
>> Hi Alan
>> Sorry this has taken me a while to look at.
>>
>> I just want to check what you think the behaviour should be id
>> shapelib is off, deprecated is on and the user passes in a map name
>> other than one of the ones we supply? The behaviour before we began
>> using shapefiles was the same as it is now: If a file with that name
>> existed then plplot attempted to read it, if not then plplot reported
>> the warning you saw. I think that is still correct behaviour.
>> What should probably happen is that the final page of the example
>> should not be drawn unless shapelib support is on. To do this we need
>> either a compile time or runtime check for whether plplot was built
>> with shapelib support. Not wanting to touch the public API I guess a
>> #define PL_USE_SHAPEFILES in plConfig.h is required. However I'm not
>> sure how to do that. I tried adding
>>
>> set(PL_USE_SHAPEFILES, TRUE)
>
>                        ^
>
>> In shapelib.cmake and
>>
>> #cmakedefine PL_USE_SHAPEFILES
>>
>> in plConfig.h.in, but this doesn't work.
>
>
> The issue is the comma in the above set command.  Commas are extremely
> rare (if they exist at all) in CMake syntax.  I don't know, but I
> suspect the variable name you set was "PL_USE_SHAPEFILES," with
> the above command.
>
> I followed up by pushing that comma removal (as of commit 4970505) which
> lead to
>
> // Define if built with shapefile support
> #define PL_USE_SHAPEFILES
>
> being set in the configured include/plConfig.h in the build tree.
>
> So all is well there, and here are the relevant results in the cache
> for my (default) configuration:
>
> software@raven> grep -E "SHAPE|DEPRECATED" CMakeCache.txt
> HAVE_SHAPELIB:BOOL=ON
> PL_DEPRECATED:BOOL=OFF
> SHAPELIB_INCLUDE_DIR:PATH=/usr/include
> SHAPELIB_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libshp.so
>
> So that all seems fine, but for this combination I now get the result that
> the last page of example 19 does not display any more.
>
> Instead of looking at that issue alone, I suggest you systematically
> look at example 19 results for all combinations of HAVE_SHAPELIB and
> PL_DEPRECATED
>
> 1. -DHAVE_SHAPELIB=OFF, -DPL_DEPRECATED=OFF
>
> 2. -DHAVE_SHAPELIB=ON, -DPL_DEPRECATED=OFF
>
> 3. -DHAVE_SHAPELIB=OFF, -DPL_DEPRECATED=ON
>
> 4. -DHAVE_SHAPELIB=ON, -DPL_DEPRECATED=ON
>
> For PL_DEPRECATED=OFF we should rely completely on the shapelib
> approach, and for PL_DEPRECATED=ON we should rely completely on the
> traditional non-shapelib approach.  So following that philosophy we
> should have the following behaviour for example 19:
>
> Case 1 should not plot anything for any page and instead should
> emit a warning for each page that shapelib is missing.
>
> Case 2 (the above case I tested) should display all pages with no
> warnings (the last page is missing in error for me).
>
> Cases 3 and 4 should display all but the last page using the
> deprecated approach, and for the last page should not plot anything
> but give a warning message that shapelib and PL_DEPRECATED=OFF are
> required for that page.
>
> I hope this clarifies what is needed by example 19 in each of the 4 cases.
>
>
> 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] Plplot Source Error

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

On 2015-12-10 12:36-0000 Phil Rosenberg wrote:

> Hi Alan
> Sorry this has taken me a while to look at.
>
> I just want to check what you think the behaviour should be id
> shapelib is off, deprecated is on and the user passes in a map name
> other than one of the ones we supply? The behaviour before we began
> using shapefiles was the same as it is now: If a file with that name
> existed then plplot attempted to read it, if not then plplot reported
> the warning you saw. I think that is still correct behaviour.
> What should probably happen is that the final page of the example
> should not be drawn unless shapelib support is on. To do this we need
> either a compile time or runtime check for whether plplot was built
> with shapelib support. Not wanting to touch the public API I guess a
> #define PL_USE_SHAPEFILES in plConfig.h is required. However I'm not
> sure how to do that. I tried adding
>
> set(PL_USE_SHAPEFILES, TRUE)
                        ^

> In shapelib.cmake and
>
> #cmakedefine PL_USE_SHAPEFILES
>
> in plConfig.h.in, but this doesn't work.

The issue is the comma in the above set command.  Commas are extremely
rare (if they exist at all) in CMake syntax.  I don't know, but I
suspect the variable name you set was "PL_USE_SHAPEFILES," with
the above command.

I followed up by pushing that comma removal (as of commit 4970505) which
lead to

// Define if built with shapefile support
#define PL_USE_SHAPEFILES

being set in the configured include/plConfig.h in the build tree.

So all is well there, and here are the relevant results in the cache
for my (default) configuration:

software@raven> grep -E "SHAPE|DEPRECATED" CMakeCache.txt 
HAVE_SHAPELIB:BOOL=ON
PL_DEPRECATED:BOOL=OFF
SHAPELIB_INCLUDE_DIR:PATH=/usr/include
SHAPELIB_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libshp.so

So that all seems fine, but for this combination I now get the result that
the last page of example 19 does not display any more.

Instead of looking at that issue alone, I suggest you systematically
look at example 19 results for all combinations of HAVE_SHAPELIB and
PL_DEPRECATED

1. -DHAVE_SHAPELIB=OFF, -DPL_DEPRECATED=OFF

2. -DHAVE_SHAPELIB=ON, -DPL_DEPRECATED=OFF

3. -DHAVE_SHAPELIB=OFF, -DPL_DEPRECATED=ON

4. -DHAVE_SHAPELIB=ON, -DPL_DEPRECATED=ON

For PL_DEPRECATED=OFF we should rely completely on the shapelib
approach, and for PL_DEPRECATED=ON we should rely completely on the
traditional non-shapelib approach.  So following that philosophy we
should have the following behaviour for example 19:

Case 1 should not plot anything for any page and instead should
emit a warning for each page that shapelib is missing.

Case 2 (the above case I tested) should display all pages with no
warnings (the last page is missing in error for me).

Cases 3 and 4 should display all but the last page using the
deprecated approach, and for the last page should not plot anything
but give a warning message that shapelib and PL_DEPRECATED=OFF are
required for that page.

I hope this clarifies what is needed by example 19 in each of the 4 cases.

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
__________________________