Re: [Plplot-devel] setlocale

[Hazen Babcock via Plplot-devel]

Hi Phil,

Thank you for the clarification.

If setting the locale is only important for text rendering, using a 
period instead of a comma for example, then maybe it would make more 
sense to guard just the plplot functions that create text? No idea how 
hard it would be to track down all the functions in the library that 
might create text such as tick labels, etc.


Do you know of a unit test that checks that plplot is actually handling 
the locale properly? I wasn't able to find one in my searches.


-Hazen

On 6/14/23 13:33, Phil Rosenberg wrote:

Hi Hazen
Yes, a multiple of around 2.5.

But for my current scenario, that's the difference between a plot taking 
5-10 minutes to render Vs 15-30 minutes. So it's a big difference.


Basically the code spends nearly three quarters of its time changing the 
locale, and only a quarter of its time rendering.


But setting/getting the locale is a a file write/read, so it's wy 
slower than setting a few pixels.


Phil



Sent from Outlook for Android <https://aka.ms/AAb9ysg>
--------
*From:* Hazen Babcock 
*Sent:* Wednesday, June 14, 2023 6:03:03 PM
*To:* Phil Rosenberg ; 
plplot-devel@lists.sourceforge.net 

*Subject:* Re: [Plplot-devel] setlocale

Hi Phil,

Can you clarify a bit about the performance difference? Re-reading what
you wrote below I get the impression that just removing the locale calls
alone would only improve things by about 2.5x? Is that correct?

It sounds like you might have done some profiling, so you might already
have the numbers for memory churn versus the calls to the C locale
function(s)?

best,
-Hazen

On 6/13/23 14:15, Phil Rosenberg wrote:

Hi Hazen
I hadn't considered what you say about libraries. Let's rule out option 1.

Yes you are correct that drawing large numbers of lines would probably 
have a similar poor performance.


I think the act of checking the locale would be similarly slow. I don't 
think it's memory churn that is causing slowness. I think it's because 
checking and setting the locale involves checking environment variables 
or registry entries. I'm not entirely sure though.


I think if options 1 and 2 are disliked, then option 3 is probably the 
best option.


I can set things up so that the local only gets set for the first 
fill/line and is reset for the last fill/line.


Does that sound okay?

Phil



Sent from Outlook for Android <https://aka.ms/AAb9ysg <https://aka.ms/AAb9ysg>>
--------
*From:* Hazen Babcock 
*Sent:* Tuesday, June 13, 2023 1:31:38 PM
*To:* Phil Rosenberg ; 
plplot-devel@lists.sourceforge.net 

*Subject:* Re: [Plplot-devel] setlocale

Hi Phil,

I don't think (1) is a good idea. It seems like this only effects
somewhat extreme plotting situations? Some of the examples also use
plshade() and they don't seem to be particularly slow.

Alan I think was concerned that the libraries that come with a driver
might change the locale. The cairo driver for example has a rather large
library behind it. This library might not change the locale, but it
would be hard to be sure, and this might change as the library changes.

Also it seems that the overhead of setting and restoring the locale
would affect any situation with a complicated plot, perhaps most easily
created using plshades, but if you tried to dray 1M lines you might see
something similar? So perhaps there are some optimizations that could be
made instead? For example we could check if the locale was already "C"
before setting it to "C" and then restoring? We could change
saved_lc_numerical_locale to a static variable (and not free it in
plrestore_locale) to reduce the amount of memory churn? We could add a
compiler flag that makes plsave_set_locale() and plrestore_locale() into
nops for those who are okay with this?

best,
-Hazen

On 6/2/23 05:55, Phil Rosenberg wrote:

Hi Hazen, Arjen
Thanks for the detective work - Alan has used that feature to help me in 
the past and I had totally forgotten about it.


I can see Alan's intention here. In the wxWidgets driver I did similar 
things with other properties. For example I ensure the device context 
pen and brush are always set and reset during calls to the driver. This 
is so that if the user draws to the device context between calls, then 
plPlot does not cause problems for the user and visa-versa.


Setting and resetting the brush was also an expensive operation, so to 
avoid those calls I have added an escape for starting and stopping 
plshade. I know that between these escapes there is no need to worry 
about setting and restoring the state.


I think there are a few options, from most intrusive to least intrusive.
1. Undo Alan's work and make it the responsibility of the driver to 
restore the locale. This is what wxWidgets does with device context bru

Re: [Plplot-devel] setlocale

[Hazen Babcock via Plplot-devel]

Hi Phil,

Can you clarify a bit about the performance difference? Re-reading what 
you wrote below I get the impression that just removing the locale calls 
alone would only improve things by about 2.5x? Is that correct?


It sounds like you might have done some profiling, so you might already 
have the numbers for memory churn versus the calls to the C locale 
function(s)?


best,
-Hazen

On 6/13/23 14:15, Phil Rosenberg wrote:

Hi Hazen
I hadn't considered what you say about libraries. Let's rule out option 1.

Yes you are correct that drawing large numbers of lines would probably 
have a similar poor performance.


I think the act of checking the locale would be similarly slow. I don't 
think it's memory churn that is causing slowness. I think it's because 
checking and setting the locale involves checking environment variables 
or registry entries. I'm not entirely sure though.


I think if options 1 and 2 are disliked, then option 3 is probably the 
best option.


I can set things up so that the local only gets set for the first 
fill/line and is reset for the last fill/line.


Does that sound okay?

Phil



Sent from Outlook for Android <https://aka.ms/AAb9ysg>
--------
*From:* Hazen Babcock 
*Sent:* Tuesday, June 13, 2023 1:31:38 PM
*To:* Phil Rosenberg ; 
plplot-devel@lists.sourceforge.net 

*Subject:* Re: [Plplot-devel] setlocale

Hi Phil,

I don't think (1) is a good idea. It seems like this only effects
somewhat extreme plotting situations? Some of the examples also use
plshade() and they don't seem to be particularly slow.

Alan I think was concerned that the libraries that come with a driver
might change the locale. The cairo driver for example has a rather large
library behind it. This library might not change the locale, but it
would be hard to be sure, and this might change as the library changes.

Also it seems that the overhead of setting and restoring the locale
would affect any situation with a complicated plot, perhaps most easily
created using plshades, but if you tried to dray 1M lines you might see
something similar? So perhaps there are some optimizations that could be
made instead? For example we could check if the locale was already "C"
before setting it to "C" and then restoring? We could change
saved_lc_numerical_locale to a static variable (and not free it in
plrestore_locale) to reduce the amount of memory churn? We could add a
compiler flag that makes plsave_set_locale() and plrestore_locale() into
nops for those who are okay with this?

best,
-Hazen

On 6/2/23 05:55, Phil Rosenberg wrote:

Hi Hazen, Arjen
Thanks for the detective work - Alan has used that feature to help me in 
the past and I had totally forgotten about it.


I can see Alan's intention here. In the wxWidgets driver I did similar 
things with other properties. For example I ensure the device context 
pen and brush are always set and reset during calls to the driver. This 
is so that if the user draws to the device context between calls, then 
plPlot does not cause problems for the user and visa-versa.


Setting and resetting the brush was also an expensive operation, so to 
avoid those calls I have added an escape for starting and stopping 
plshade. I know that between these escapes there is no need to worry 
about setting and restoring the state.


I think there are a few options, from most intrusive to least intrusive.
1. Undo Alan's work and make it the responsibility of the driver to 
restore the locale. This is what wxWidgets does with device context brushes.
2. Find where we think the locale might need saving and restoring and 
only do it for these calls. I'm not sure I like this, as it makes 
responsibility a grey area. Also I just tried 'ack locale' and 'ack 
LC_NUMERIC in the src directory and found references only in plargs.c, 
plcore.c and plctrl.c. So I don't think any drivers do actually change 
the locale.
3. I can add a variable to the PLStream which records when we enter and 
leave a plshade call. This can be checked during plfill calls so that 
only direct plfill calls save and restore the locale.


My preference is for 1 or 3, does anyone else have a preference or other 
thought? 3 is certainly an easier change, but I'm happy to go down 
another route if people think it will be an improvement.


Just to give an idea of the overall benefits here. I'm plotting data on 
a grid with millions of points. The wxWidgets driver changes I mentioned 
above and the removal of the locale save/restore and the changes I 
mentioned a few weeks ago with buffer memory, mean that instead of 
giving up after plPlot had been rendering for a few hours, the plot is 
rendered in under 2 minutes. So that's around two orders of magnitude 
speed increase at least.


Phil
------

Re: [Plplot-devel] setlocale

[Hazen Babcock via Plplot-devel]

Hi Phil,

I don't think (1) is a good idea. It seems like this only effects 
somewhat extreme plotting situations? Some of the examples also use 
plshade() and they don't seem to be particularly slow.


Alan I think was concerned that the libraries that come with a driver 
might change the locale. The cairo driver for example has a rather large 
library behind it. This library might not change the locale, but it 
would be hard to be sure, and this might change as the library changes.


Also it seems that the overhead of setting and restoring the locale 
would affect any situation with a complicated plot, perhaps most easily 
created using plshades, but if you tried to dray 1M lines you might see 
something similar? So perhaps there are some optimizations that could be 
made instead? For example we could check if the locale was already "C" 
before setting it to "C" and then restoring? We could change 
saved_lc_numerical_locale to a static variable (and not free it in 
plrestore_locale) to reduce the amount of memory churn? We could add a 
compiler flag that makes plsave_set_locale() and plrestore_locale() into 
nops for those who are okay with this?


best,
-Hazen

On 6/2/23 05:55, Phil Rosenberg wrote:

Hi Hazen, Arjen
Thanks for the detective work - Alan has used that feature to help me in 
the past and I had totally forgotten about it.


I can see Alan's intention here. In the wxWidgets driver I did similar 
things with other properties. For example I ensure the device context 
pen and brush are always set and reset during calls to the driver. This 
is so that if the user draws to the device context between calls, then 
plPlot does not cause problems for the user and visa-versa.


Setting and resetting the brush was also an expensive operation, so to 
avoid those calls I have added an escape for starting and stopping 
plshade. I know that between these escapes there is no need to worry 
about setting and restoring the state.


I think there are a few options, from most intrusive to least intrusive.
1. Undo Alan's work and make it the responsibility of the driver to 
restore the locale. This is what wxWidgets does with device context brushes.
2. Find where we think the locale might need saving and restoring and 
only do it for these calls. I'm not sure I like this, as it makes 
responsibility a grey area. Also I just tried 'ack locale' and 'ack 
LC_NUMERIC in the src directory and found references only in plargs.c, 
plcore.c and plctrl.c. So I don't think any drivers do actually change 
the locale.
3. I can add a variable to the PLStream which records when we enter and 
leave a plshade call. This can be checked during plfill calls so that 
only direct plfill calls save and restore the locale.


My preference is for 1 or 3, does anyone else have a preference or other 
thought? 3 is certainly an easier change, but I'm happy to go down 
another route if people think it will be an improvement.


Just to give an idea of the overall benefits here. I'm plotting data on 
a grid with millions of points. The wxWidgets driver changes I mentioned 
above and the removal of the locale save/restore and the changes I 
mentioned a few weeks ago with buffer memory, mean that instead of 
giving up after plPlot had been rendering for a few hours, the plot is 
rendered in under 2 minutes. So that's around two orders of magnitude 
speed increase at least.


Phil
----
*From:* Arjen Markus 
*Sent:* Friday, June 2, 2023 7:47:08 AM
*To:* Hazen Babcock ; 
plplot-devel@lists.sourceforge.net 

*Subject:* Re: [Plplot-devel] setlocale
Hi Hazen, Phil,

If the setting and restoring of the locale takes so much time, then 
would it be an option to use this only on the plot functions that might 
actually be affected by the locale? I have only glanced at the code and 
I have no idea how much work it would be. That would preserve the 
intended functionality though and get rid of the performance issue.


Regards,

Arjen

-Original Message-
From: Hazen Babcock via Plplot-devel 
Sent: Thursday, June 1, 2023 12:57 AM
To: plplot-devel@lists.sourceforge.net
Subject: Re: [Plplot-devel] setlocale

Caution: This message was sent from outside of Deltares. Please do not 
click links or open attachments unless you recognize the source of this 
email and know the content is safe. Please report all suspicious emails 
to "servicedesk-...@deltares.nl" as an attachment.



Github has an interesting feature which lets you browse the code and see 
the last commit that touched a particular part of the code. Using that 
it looks like saving and restoring the locale was added to the functions 
in src/plcore.c by Alan on Sep 7, 2009.


The commit message:
"""
Protect all device driver calls using the (now) reentrant plsave_set_... 
...locale


and plrestore_locale. The former saves th

Re: [Plplot-devel] setlocale

[Hazen Babcock via Plplot-devel]

Github has an interesting feature which lets you browse the code and see 
the last commit that touched a particular part of the code. Using that 
it looks like saving and restoring the locale was added to the functions 
in src/plcore.c by Alan on Sep 7, 2009.


The commit message:
"""
Protect all device driver calls using the (now) reentrant plsave_set_…
…locale

and plrestore_locale. The former saves the fundamental PLplot LC_NUMERIC
locale and then sets the LC_NUMERIC locale to "C" for everything done by all
device drivers.  Of course, any library called by a device driver can also
change the locale, but we guard against such changes affecting the rest of
PLplot by using plrestore_locale to restore the fundamental PLplot
LC_NUMERIC locale saved by plsave_set_locale.

N.B. this logic allows the fundamental PLplot LC_NUMERIC locale (except for
the parts like the device drivers and palette file reading that are
protected by the combination of plsave_set_locale and plrestore_locale) to
be any valid locale set by any application or library that calls the PLplot
library.  If that locale specifies comma decimal separators rather than
period decimal separators, for example, then the PLplot core will
automatically use those for for specifying axis labels.  Those commas for
axis labels are drawn by the PLplot core for the Hershey font device drivers
or just propagate to the unicode device drivers as UCS4 arrays.  Thus, in
both cases, we get a comma decimal separator for axis labels (if that is
what the fundamental PLplot LC_NUMERIC locale calls for) independently of
the logic of the present commit that sets the LC_NUMERIC locale to "C" for
all device driver code that is executed.


svn path=/trunk/; revision=10383
"""

-Hazen

On 5/31/23 10:56, Phil Rosenberg wrote:
> Sorry, I was wrong in my last email - removing the locale calls from 
plP_state as well (used to reset the width after a contour draw within 
plshade) I ended up with a 2.5 times speed increase

>
> Phil
>
> On Mon, 29 May 2023 at 00:38, Phil Rosenberg > wrote:

>
> Hi all
> I have been making further optimisations to the wxwidgets backen, as
> I have still been finding it painfully slow for plshade calls.
> It turned out that almost all the time within the backend (>99%) was
> spent selecting pens and brushes and allocating memory for every
> fill within the plshade call. Less that 1% was actually spent within
> the rendering call to wxWidgets. I have made some good improvements
> here.
>
> However, in addition to this, about 50% of the total execution time
> is spent in the setlocale function. This is called before and after
> each polygon fill in the core plplot code.
>
> I wondered if anyone really knows the purpose of these calls?
> Perhaps they are to ensure we have consistent numeric
> representations across regions? If so, then I don't really
> understand why they are needed for polygon fills.
>
> Any thoughts would be welcome
> Phil
>
>
>
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel



On 5/31/23 10:56, Phil Rosenberg wrote:
Sorry, I was wrong in my last email - removing the locale calls from 
plP_state as well (used to reset the width after a contour draw within 
plshade) I ended up with a 2.5 times speed increase


Phil

On Mon, 29 May 2023 at 00:38, Phil Rosenberg > wrote:


Hi all
I have been making further optimisations to the wxwidgets backen, as
I have still been finding it painfully slow for plshade calls.
It turned out that almost all the time within the backend (>99%) was
spent selecting pens and brushes and allocating memory for every
fill within the plshade call. Less that 1% was actually spent within
the rendering call to wxWidgets. I have made some good improvements
here.

However, in addition to this, about 50% of the total execution time
is spent in the setlocale function. This is called before and after
each polygon fill in the core plplot code.

I wondered if anyone really knows the purpose of these calls?
Perhaps they are to ensure we have consistent numeric
representations across regions? If so, then I don't really
understand why they are needed for polygon fills.

Any thoughts would be welcome
Phil



___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel




___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] ndiff software commit

[Hazen Babcock via Plplot-devel]

Hello,

The ndiff software commit (a974e9802cc0b54ed33d9078b7767b29286c5684 I
believe) added a lot of files and directories in the utils/ndiff
directory that appear to be output files (checkXYZ.xyz). Perhaps this
was a mistake?

best,
-Hazen


___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Tentative plan for removing our support of Qt4

[Hazen Babcock via Plplot-devel]

@Hazen: In light of the smoke binding issue we should discuss this
still tentative roadmap further.

That smoke binding issue is bindings/qt_gui/smoke/ needs to be removed
when we drop support for Qt4 because [smoke is not available for
Qt5](https://news.ycombinator.com/item?id=20636312).  You apparently
implemented the PLplot smoke binding because that binding was needed
by another independent project of yours.


No problem, go ahead and remove the smoke bindings.

-Hazen



___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Status of examples/c/extXdrawable_demo.c

[Hazen Babcock]

On 06/20/2018 07:51 PM, Alan W. Irwin wrote:


If you try the -DGTK_DISABLE_SINGLE_INCLUDES flag that is recommended
in the above URL that works, but as soon as you try the additional
recommended -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED flags a
whole host of issues show up, i.e., porting this example is not going
to be trivial.  Therefore I abandoned that idea for myself, but I
encourage you to take a look at porting this example because I believe
your GTK+ skills/experience are a lot more extensive than mine.


I'm sorry, I can't help with this. I also know very little about GTK.

-Hazen

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PyQt4 on MinGw-w64/MSYS2 - pyqtconfig

[Hazen Babcock]

On 06/02/2017 08:40 AM, Arjen Markus wrote:

Hi everyone,

I have a simple question regarding PyQt4 on MinGW-w64/MSYS2. I have 
installed the package but when I run Cmake to build PLplot, I get the 
message that pyqtconfig is missing – is this something I need to install 
separately? If so, how? (I have a version for Cygwin, but I do not know 
if that is exactly the same)


Maybe pyqtconfig is part of the sip package?

-Hazen


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Python3

[Hazen Babcock]

On 04/21/2017 03:42 AM, Alan W. Irwin wrote:


Hi Hazen:

Could you please test commit 578b028?  For that commit I made some
modest progress with Python 3 for both pyqt4 and pyqt5, but I have hit
a roadblock with a run-time error saying the plplot_pyqt[45] extension
modules are not initialized properly when the script tries to import
one of those modules.  The sip, pyqt[45], and python3 software
packages are all supposed to work well together for their latest
versions according to my google search results, but it is possible the
Debian Jessie versions of these software packages are too old and
buggy which is why I am asking you to test this commit by attempting
to build the test_pyqt[45]_example target (depending on whether your
build system finds Qt4 or Qt5) for both the python2 and python3 cases
(where the former builds and runs plplot_pyqt[45] without issues here,
but the latter case only builds these extension modules without
obvious issues but runs into initialization errors at run time).

The test_pyqt4_example target build all
prerequisites with success but fails the final run-time test.

Here is the relevant error message if I attempt to do the
run-time test by hand:

software@raven> python3 examples/python/pyqt4_example.py Traceback (most
recent call last):
  File "examples/python/pyqt4_example.py", line 33, in 
import plplot_pyqt4
ImportError: dynamic module does not define init function
(PyInit_plplot_pyqt4)

Do you get a similar error there or success?


It works for me with Python3 and pyqt5. My understanding is that error 
messages like you are seeing mean that the C library was built for the 
wrong version of Python.


I've attached my CMakeCache.txt file.

-Hazen
# This is the CMakeCache file.
# For build in directory: /home/hbabcock/Code/plplot-build
# It was generated by CMake: /usr/bin/cmake
# You can edit this file to change values found and used by cmake.
# If you do not want to change any of the values, simply exit the editor.
# If you do want to change a value, simply edit, save, and exit the editor.
# The syntax for the file is as follows:
# KEY:TYPE=VALUE
# KEY is the name of a variable in the cache.
# TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!.
# VALUE is the current value for the KEY.


# EXTERNAL cache entries


//Add extra source-tree consistency checking targets that require
// special tools
ADD_SPECIAL_CONSISTENCY_CHECKING:BOOL=OFF

//Enable build of DocBook documentation
BUILD_DOC:BOOL=OFF

//Build doxygen documentation
BUILD_DOX_DOC:BOOL=OFF

//Build Hershey fonts?
BUILD_HERSHEY_FONTS:BOOL=OFF

//Build shared libraries
BUILD_SHARED_LIBS:BOOL=ON

//Compile examples in the build tree and enable ctest
BUILD_TEST:BOOL=ON

//Build the testing tree.
BUILD_TESTING:BOOL=ON

//Path to a program.
BZRCOMMAND:FILEPATH=BZRCOMMAND-NOTFOUND

//Path to a program.
CAMLIDL:FILEPATH=CAMLIDL-NOTFOUND

//Path to a program.
CMAKE_AR:FILEPATH=/usr/bin/ar

//Ada compiler
CMAKE_Ada_COMPILER:FILEPATH=/usr/bin/gnatgcc

//Flags used by the compiler during all build types.
CMAKE_Ada_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_Ada_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release builds for minimum
// size.
CMAKE_Ada_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the compiler during release builds.
CMAKE_Ada_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the compiler during release builds with debug info.
CMAKE_Ada_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//Choose the type of build, options are: None(CMAKE_CXX_FLAGS or
// CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
CMAKE_BUILD_TYPE:STRING=

//Enable/Disable color output during build.
CMAKE_COLOR_MAKEFILE:BOOL=ON

//CXX compiler
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++

//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release builds for minimum
// size.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the compiler during release builds.
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the compiler during release builds with debug info.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//C compiler
CMAKE_C_COMPILER:FILEPATH=/usr/bin/cc

//Flags used by the compiler during all build types.
CMAKE_C_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_C_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release builds for minimum
// size.
CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the compiler during release builds.
CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the compiler during release builds with debug info.
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//Flags used by the linker.
CMAKE_EXE_LINKER_FLAGS:STRING=

//Flags used by the linker during debug builds.
CMAKE

Re: [Plplot-devel] A mysterious pyc file corruption issue

[Hazen Babcock]

On 02/21/2017 09:26 PM, Alan W. Irwin wrote:
>
> I have now been in contact with the OP, Barry Warsaw of python.org, of
> that thread who was quite helpful.  For example, Barry told me that
> Python is designed so it is frankly impossible for
>
> import Plframe
> from Plframe import *
>
> to race (i.e., the first import completely finishes before the second
> one starts).  And I cannot find any other cases where Plframe is
> imported.  So I think the best bet for explaining this *.pyc
> Python-generated file corruption is some unknown Python 2 bug that
> does not have anything to do with races.  I got the sense from
> what Barry said that he feels Python 3 is now much more reliable than
> Python 2.  So this may be another instance of that general idea.
>
> Anyhow, I think the next step is to test whether this corruption
> occurs for Python 3.  (And if it does I get the sense that Barry would
> be anxious to figure out what that Python 3 bug was.)
>
> @Hazen:
>
> This issue lends lots of additional motivation for making PLplot work
> correctly with Python 3.  So please go ahead and push your Python 3
> topic as soon as it is in reasonable state, and we can mature it
> further (if necessary) from there.

Pushed.

One possibly important thing to note is that Python3 does not allow a 
mix of tabs and spaces in a file. So these changes are less extensive 
then they might appear as a lot of it was converting the examples to be 
all spaces. And hopefully our file formatting utility will not introduce 
regressions.

-Hazen


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Python3

[Hazen Babcock]

On 12/01/2016 04:13 AM, Alan W. Irwin wrote:
>> Spoke too soon I guess. It appears that swig detects which version of
>> Python you are using and creates a binding that only works with that
>> version. So if you create the bindings in a Python3 environment they
>> will not work with Python2 and vice versa.
>
> I suggest the proper thing for me to do here (post-release since you
> are not quite ready yet to merge your Python 3 work, and I am pretty
> busy myself) is to have the build system look preferentially for
> support for Python 3 + consistent numpy for that Python version, and
> if that is not found fall back to looking for Python 2 + consistent
> numpy for that version.  But the user has the option to skip the look
> for that first preference if they so desire. So the approach would be
> similar to the way the build system looks first for Qt4, then Qt5
> with the user option to skip the look for Qt4
> except in the Python case the first preference order should likely be the
> newer Python (which I assume is completely stable), then the older (as
> opposed to the Qt case where the preference order is old, then new for
> the reasons I have discussed).

I'm not clear on how cmake detects which version(s) of Python are 
available, but I would suggest the use of which ever version is 
currently active, i.e. the one that runs when the user types "python" at 
the command prompt. If this is Python2 and Python3 is used instead then 
I think this violates the principle of least surprise. I think we should 
assume that the user had their reasons for choosing one or the other 
versions of Python to be active and not over-riding that. Otherwise I 
predict a lot of questions about why Python fails with:

"ImportError: dynamic module does not define init function (init_plplotc)"

Which is what will happen when you built with 3 and tried to run with 2.

It may also be more difficult to implement because I don't think swig 
has a flag that allows you to specify which version of Python to use. So 
to force swig to use the desired Python you'd need to change the users 
environment so that the desired Python was the active Python.

Somewhere in the build process though we should at least report which 
version of Python (if any) the bindings will be compatible with.

>> (3) Based on the make output I think plplot_widgetmodule.c will not
>> work with Python3. Is this important? Is there a test for this?
>
> Yes and yes.  The pytkdemo Python script discussed above and for which
> I have just implemented the test_pytkdemo target contains the following
> import statement:
>
> from plplot_widget import *
>
> and is a test of that module (as well as the xNN.py set now, but
> hopefully that will be changed to the xwNN.py set soon, see above).

Great, thanks! Once you have finished all of your Python changes (and 
the release) I will rebase my changes and get them working with the 
changes to the examples and the additional tests you have been working on.

-Hazen

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Python3

[Hazen Babcock]

On 11/27/2016 01:40 PM, Alan W. Irwin wrote:
> It is good to hear it is likely going to be even easier than I thought.  I
> guess that -py3 flag is needed for more complex Python bindings than ours.

Spoke too soon I guess. It appears that swig detects which version of 
Python you are using and creates a binding that only works with that 
version. So if you create the bindings in a Python3 environment they 
will not work with Python2 and vice versa.

> I have looked at the naming conventions used in practice for
> python-2.6 and python-2.7 on Debian, and even there the old-fashioned idea
> of inserting a "module" suffix on the basename of the shared object
> has mostly (but not completely) fallen out of favour.  So it is fine
> with me if you drop the module part of the shared object name as well.

I just changed the output target from _plplotcmodule to _plplotc. Maybe 
this will have some downstream consequences?

> Try,
>
> make test_python_psc

..

> Then, you can run that example individually
> (_in the build tree_) as follows:
>
> examples/python/x00 -dev psc -o test.psc

Thank you, this was very helpful.

The Python bindings are now compatible with Python3 as well as Python2, 
as judged by running the (basic?) tests, i.e.

$ make
$ ctest

New questions:
(1) How does one run the tests that compare the example output files to 
each other so that I can verify that the output is still the same?

(2) There appear to be at least two versions of each Python example. 
Maybe we could get rid of one set? i.e. the xNN.py set and not the 
xwNN.py set that are actually tested?

(3) Based on the make output I think plplot_widgetmodule.c will not work 
with Python3. Is this important? Is there a test for this?

If anyone is interested, my python3 branch is available here:
https://github.com/HazenBabcock/PLplot/tree/python3

Just for testing though, don't do any work off of it :).

I'm going to wait until after the release to push this into master as 
the changes were somewhat intrusive and are likely to have broken something.

-Hazen

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Python3

[Hazen Babcock]

On 11/27/2016 02:51 AM, Alan W. Irwin wrote:
>
> P.S.  This further comment assumes that generating a python3 binding
> is fairly trivial, i.e., nothing much more than using the -py3 option
> to swig. If your experiments confirm that assumption holds, then I
> suggest you should define a CMake option called PLPLOT_USE_PYTHON3. If
> the user sets that to ON, the build system generates and uses a
> python3 binding (using, e.g., that -py3 option to swig), and if OFF it
> generates and uses a python2 binding (which we will likely want to
> support indefinitely in any case).  With that either/or organization
> between the two cases, the names of the modules we build will be
> identical in the two cases, and the examples should just work
> regardless of whether the binding is python2 or python3 (assuming you
> can convert the syntax of the examples so that they work both with
> python-2.7 and python-3.0).

The bindings that swig generates are compatible with Python3 as well as 
Python2 without the -py3 flag, so unless it turns out that we absolutely 
need it I'm not going to use it. I also have no plans to add a special 
PLPLOT_USE_PYTHON3 option. I'm reasonable confident we can be agnostic 
here and it will not matter if the Python bindings are built in a 
Python2 environment and run in a Python3 environment or vice-versa.

I would appreciate thoughts on:

(1) In Python2 imp.find_module('_plplotc', ..) will find the shared 
library _plplotcmodule.so, but this fails in Python3. I'm not sure why 
we chose to have a file name that was different from the module name, 
but swig is not generating the right calls for imp.find_module() and 
imp.load_module() to work with this convention in Python3. For the time 
being I have just been editing the generated plplotc.py file by hand to 
fix this. However, unless there is some reason why the C library needs 
to be named _plplotcmodule.so I would like to change its name to 
_plplotc.so, or alternatively change the module name to _plplotcmodule. 
It looks like we are already doing this on windows, the C library is 
called _plplotc.pyd and not _plplotcmodule.pyd.

(2) What is the command line to run a python example in the build tree 
outside of ctest? Some of the examples are failing and debugging would 
be a lot easier if I could run them by hand. Among other annoyances, 
ctest eats any print() output breaking my preferred approach to debugging.

-Hazen

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Testing with Docker

[Hazen Babcock]

On 11/25/2016 09:46 AM, Hazen Babcock wrote:
>
> I think have this more or less working now. I created a git repository
> for this here:
> https://github.com/PLplot/plplot-docker
>
> And our docker images are here:
> https://hub.docker.com/u/plplot/
>
> Assuming that you have docker installed and running, then:
> docker run plplot/debian-stable 2>&1 | tee debian-stable.txt
>
> For example will pull the most recent version of PLplot, build and test
> it on debian stable.

I updated the docker images so that you can also test a local repository:

docker run -v /absolute/path/to/local/plplot:/plplot_repo 
plplot/debian-latest 2>&1 | tee debian-latest.txt

Or to test against all the images:

cd /path/to/plplot-docker
python test_all.py --plplot_repo /absolute/path/to/local/plplot

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Python3

[Hazen Babcock]

Hello,

I would like to fix PLplot so that it works with Python3. At a minimum 
it looks like this means fixing all the print statements, i.e.:

print "asdf" -> print("asdf")

I'll test against Python2.7. Do I also need to test against Python2.6? 
Or is that far enough in the past that we don't support it anymore?

-Hazen

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Testing with Docker

[Hazen Babcock]

Going in a completely different direction from travis-ci.. I've been 
experimenting with Docker:


https://docs.docker.com/

Quoting the web-site "Docker provides a way to run applications securely 
isolated in a container, packaged with all its dependencies and libraries".


What this means for us is that we can test just about any linux distro 
with just about any set of libraries. For example, the attached will 
test the current SF PLplot with a very limited number of dependencies on 
the debian-latest distro. More interestingly, we can create images that 
have all the dependencies and PLplot loaded. Then for updated test 
results all that we'd have to do is pull the most recent version of 
PLplot, cmake, make and ctest.


So, thoughts about what 5 or so linux distros we want to be sure that 
PLplot works on?


-Hazen
# Distro
FROM debian:latest
MAINTAINER Hazen Babcock 

# Update sources
RUN apt update

# Get dependencies, these are in alphabetical order
RUN apt --yes install camlidl
RUN apt --yes install cmake
RUN apt --yes install gcc
#RUN apt --yes install gdc
RUN apt --yes install gfortran
RUN apt --yes install git
#RUN apt --yes install gnat
RUN apt --yes install g++
#RUN apt --yes install default-jdk
#RUN apt --yes install default-jre
#RUN apt --yes install itcl3
#RUN apt --yes install itcl3-dev
#RUN apt --yes install libcairo-dev
#RUN apt --yes install libgtk2.0-dev
#RUN apt --yes install libhpdf-dev
#RUN apt --yes install liblasi-dev
#RUN apt --yes install liblua5.2-dev
#RUN apt --yes install libpango1.0-dev
#RUN apt --yes install libqhull-dev
#RUN apt --yes install libshp-dev
#RUN apt --yes install libxml-dom-perl
#RUN apt --yes install libxml-parser-perl
#RUN apt --yes install libwxgtk3.0-dev
#RUN apt --yes install lua5.2
RUN apt --yes install ocaml
#RUN apt --yes install octave
#RUN apt --yes install pdl
#RUN apt --yes install python-dev
#RUN apt --yes install python-numpy
#RUN apt --yes install python-qt4
#RUN apt --yes install python-qt4-dev
#RUN apt --yes install sip-dev
#RUN apt --yes install swig

# Get PLplot, configure, build and test.
RUN cd tmp && git clone git://git.code.sf.net/p/plplot/plplot plplot
RUN cd tmp && mkdir plplot-build
RUN cd tmp/plplot-build && cmake ../plplot -DBUILD_TEST=ON -DENABLE_tk=OFF
RUN cd tmp/plplot-build && make
RUN cd tmp/plplot-build && ctest --verbose
--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Fwd: Failed: HazenBabcock/PLplot#26 (master - ae56402)

[Hazen Babcock]

Everything is passing now except for lasi, hdpf (harupdf?) and wxwidgets.

To make it easier to figure out which test was doing what I added a 
dummy variable to the environment, PLTEST, which shows up in the build 
jobs table.


Once everything is working I will likely combine most of the tests to 
reduce the load on the travis build servers.


I've attached my current .travis.yml file for those who are interested.

best,
-Hazen

 Forwarded Message 
Subject:Failed: HazenBabcock/PLplot#26 (master - ae56402)
Date:   Wed, 23 Nov 2016 18:27:44 +
From:   Travis CI 
To: hbabc...@mac.com



*HazenBabcock / PLplot <https://travis-ci.org/HazenBabcock/PLplot>* 
(master <https://github.com/HazenBabcock/PLplot/tree/master>)


	Build #26 failed. 
<https://travis-ci.org/HazenBabcock/PLplot/builds/178368681> 	

37 minutes and 50 seconds
	*Hazen Babcock* 	ae56402 
<https://github.com/HazenBabcock/PLplot/commit/ae56402e823575520597230fa9784c1ce0e75cd4> 
Changeset → 
<https://github.com/HazenBabcock/PLplot/compare/e7b1446e83aa...ae56402e8235> 


Separate out the libhpdf test

*Want to know about upcoming build environment updates?*

Would you like to stay up-to-date with the upcoming Travis CI build 
environment updates? We set up a mailing list for you! Sign up here 
<http://eepurl.com/9OCsP>.


Documentation <https://docs.travis-ci.com> about Travis CI
Need help? Mail support <mailto:supp...@travis-ci.com>!
Choose who receives these build notification emails in your 
configuration file <https://docs.travis-ci.com/user/notifications>.


*Would you like to test your private code?*

Travis CI for Private Projects 
<https://travis-ci.com?utm_source=build_email_footer&utm_campaign=travis-ci.org&utm_medium=email> 
could be your new best friend!





.travis.yml
Description: application/yaml
--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Continuous Integration

[Hazen Babcock]

On 11/23/2016 06:08 AM, Alan W. Irwin wrote:
>
> Sorry for the length of this, but I have a lot to say that should be a
> big help to you for testing purposes.

No problem, I appreciate your thoughts and help.

> * -- WARNING: CMAKE_VERSION = 3.2.2 is in the range from 3.2 through
>   3.3.1 which has a compromised find ability that was fixed in 3.3.2.
>   Please upgrade to 3.3.2 or greater.

I changed the builds to download and install cmake-3.7.0, which seems to 
be working.

> * Currently, your PLplot version is at least 3 commits behind.

That is true. Once I have gotten the .travis.yml file to a point where 
it is providing useful results for us I plan to commit it to the SF 
repo. Since (I believe) travis-ci only works off the master branch on 
Github I thought this was the easiest way to do the testing.

> From this cmake output message, it appears you don't have any X
> display available to you during testing. If you cannot fix that issue,
> I suggest you specifically disable Tk (-DENABLE_tk=OFF) to get rid of
> the above warning.

Done.

> * -- Looking for itcl.h - not found
>   -- WARNING: Disabling Itcl interface code

This is still failing with cmake-3.7.0 and the itcl3 and itcl3-dev packages.

> Your detailed install messages for itcl3-dev seemed to successful
> as noted above, but they did include the following warning message
> about 110 packages that needed updating.
>
> 0 upgraded, 2 newly installed, 0 to remove and 110 not upgraded.
>
> To reduce that "not upgraded" number to 0, do the following:
>
> sudo apt-get update
> sudo apt-get dist-upgrade

I suspect that you can't do that, but I have not actually tried. There 
are a number of issues on the travis github page basically complaining 
that the distros they provide are a bit old and why can't they provide 
something more modern.

> You need to install a package that contains the
> gnatmake command.  On Debian Jessie the name of that package is gnat-4.9.

Done.

> On Debian Jessie, the packages you need to install are called
> liblua5.2-dev (for the development version of the lua library) and lua5.2
> (for the lua executable).

Done.

> On Debian Jessie, the package you need to install is called gdc.

Done.

> On Debian Jessie, the package you need to install is called libshp-dev.

Done.

> On Debian Jessie, the package you need to install is called sip-dev.

Done, but it appears we are also missing the package that contains 
pyqt4. I should be able to fix this on my own :).

> On Debian Jessie, the package you need to install is called liblasi-dev.

This causes the build to fail with:

Scanning dependencies of target psttf
[ 20%] Building CXX object drivers/CMakeFiles/psttf.dir/psttf.cc.o
In file included from 
/home/travis/build/HazenBabcock/PLplot/drivers/psttf.cc:44:0:
/usr/include/LASi.h:14:30: fatal error: freetype/ftglyph.h: No such file 
or directory
compilation terminated.
make[2]: *** [drivers/CMakeFiles/psttf.dir/psttf.cc.o] Error 1
make[1]: *** [drivers/CMakeFiles/psttf.dir/all] Error 2
make: *** [all] Error 2

So I think we are still missing something, a freetype package perhaps?

> On Debian Jessie, the package you need to install is called
> libwxgtk3.0-dev.

This causes the build to fail with:
[ 14%] Building CXX object 
bindings/wxwidgets/CMakeFiles/plplotwxwidgets.dir/wxPLplotstream.cpp.o
In file included from /usr/include/c++/5/type_traits:35:0,
  from /usr/include/wx-3.0/wx/strvararg.h:25,
  from /usr/include/wx-3.0/wx/string.h:46,
  from /usr/include/wx-3.0/wx/memory.h:15,
  from /usr/include/wx-3.0/wx/object.h:19,
  from /usr/include/wx-3.0/wx/wx.h:15,
  from 
/home/travis/build/HazenBabcock/PLplot/bindings/wxwidgets/wxPLplotstream.cpp:22:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file 
requires compiler and library support for the ISO C++ 2011 standard. 
This support must be enabled with the -std=c++11 or -std=gnu++11 
compiler options.
  #error This file requires compiler and library support \
   ^
In file included from /usr/include/wx-3.0/wx/string.h:46:0,
  from /usr/include/wx-3.0/wx/memory.h:15,
  from /usr/include/wx-3.0/wx/object.h:19,
  from /usr/include/wx-3.0/wx/wx.h:15,
  from 
/home/travis/build/HazenBabcock/PLplot/bindings/wxwidgets/wxPLplotstream.cpp:22:
/usr/include/wx-3.0/wx/strvararg.h:345:18: error: ‘is_enum’ in namespace 
‘std’ does not name a template type
  typedef std::is_enum is_enum;
   ^
/usr/include/wx-3.0/wx/strvararg.h:349:54: error: ‘is_enum’ was not 
declared in this scope
  enum { value = 
wxFormatStringSpecifierNonPodType::value };
   ^
/usr/include/wx-3.0/wx/strvararg.h:349:68: error: template argument 1 is 
invalid
  enum { value = 
wxFormatStringSpecifierNonPodType::value };
   

Re: [Plplot-devel] Continuous Integration

[Hazen Babcock]

On 11/23/2016 02:52 AM, Arjen Markus wrote:
>
> Nevertheless, do you have an error report for gfortran 4.8? We have seen
> a few issues when we started on this, but I do not remember whether they
> were serious and with the newer version they have disappeared. (The NAG
> compiler is rather picky about not following the standard ;)).

It looks like 4.8.5? If you go to the Travis page you can see the logs 
for all of the builds that I tried (click on "Build History"). Here is 
one example of a build that failed because of fortran95:

https://travis-ci.org/HazenBabcock/PLplot/jobs/178182917

All the error messages are some form of:

included_plplot_real_interfaces.f90:2502.25:

 Included at 
/home/travis/build/HazenBabcock/PLplot/bindings/f95/plplot_double.f90:117:

c_loc(plotentries), size(plotentries, 
kind=private_plint) )

  1

Error: Assumed-shape array 'plotentries' at (1) cannot be an argument to 
the procedure 'c_loc' because it is not C interoperable

-Hazen

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Continuous Integration

[Hazen Babcock]

On 11/20/2016 01:12 PM, Tom Schoonjans wrote:
> That’s exactly how I do it though: trial and error :-)

I think I have at least sort of figured out travis-vi. To make it easier 
I've been doing all the experiments on a personal copy of the PLplot 
repo. It is pretty cool to be able to build 5 different versions at the 
same time :).

If anyone is interested, you can see the results of all the tests here:
https://travis-ci.org/HazenBabcock/PLplot/builds

So far I have learned the new fortran95 bindings fail with gfortran4.8 
(and presumably lower). I also had trouble with ada, wxwidgets, lua and 
ocaml, but I'm not sure whether these are dependency issues.

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Continuous Integration

[Hazen Babcock]

Hi Tom,

Any pointers for getting started with continuous integration? I'm 
planning to set this up on the Github PLplot mirror using Travis-CI to 
start.

In particular I'd like to know what you think is the best way to go 
about debugging the Travis scripts? It appears to me that this is going 
to involve lots of cycles of editing, pushing and waiting for Travis 
results, along with a lot of commit noise. Is there a better way?

best,
-Hazen

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] How to build with QT5?

[Hazen Babcock]

On 11/18/2016 02:34 AM, Alan W. Irwin wrote:

On 2016-11-17 20:43-0500 Hazen Babcock wrote:


Sorry, it appears that I was missing the qttools5-dev package.


Glad that "how to build" issue is sorted out.


As an aside it looks like x02c works fine with Qt5 even in -fam mode.


Does that mean valgrind reports no memory management issues?  That is
a pretty reliable measurement of the probability of encountering
segfaults with Qt5, and would be an important improvement compared to
my Qt5 version 5.3.2 from Debian Jessie.


I just meant that it ran without segfaulting. However it does also seem 
to have fewer invalid reads than the Qt4 equivalent.


$ qmake --version
QMake version 3.0
Using Qt version 5.5.1 in /usr/lib/x86_64-linux-gnu

-Hazen

==3178== Memcheck, a memory error detector
==3178== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==3178== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==3178== Command: ./x02c -fam -dev pngqt -o ex2
==3178== 
==3178== Conditional jump or move depends on uninitialised value(s)
==3178==at 0x12B5713D: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30)
==3178==by 0x8DD21D3: ??? (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178==by 0x8DEC9A5: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178==by 0x8DED554: g_signal_emit_by_name (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178==by 0x8DD98F7: g_object_set_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178==by 0x8DD9FCB: g_object_set (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178==by 0x77A2935: ??? (in 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1)
==3178==by 0x772649C: QStyleFactory::create(QString const&) (in 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1)
==3178==by 0x76BF754: QApplication::style() (in 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1)
==3178==by 0x76BFB1C: QApplicationPrivate::initialize() (in 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1)
==3178==by 0x76BFB6E: QApplicationPrivate::construct() (in 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1)
==3178==by 0x7134421: initQtApp(bool) (qt.cpp:104)
==3178== 
==3178== Conditional jump or move depends on uninitialised value(s)
==3178==at 0x908E3F8: g_utf8_offset_to_pointer (in 
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==3178==by 0x12B5A734: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30)
==3178==by 0x12B5AD38: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30)
==3178==by 0x12B5B06E: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30)
==3178==by 0x8DD1FA4: g_closure_invoke (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178==by 0x8DE3AFB: ??? (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178==by 0x8DECD5B: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178==by 0x8DED08E: g_signal_emit (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178==by 0x12CE9B53: gtk_widget_realize (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30)
==3178==by 0x12CEAE67: gtk_widget_set_parent (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30)
==3178==by 0x12B89A32: gtk_fixed_put (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30)
==3178==by 0x8DD50A6: g_cclosure_marshal_VOID__OBJECTv (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178== 
==3178== Conditional jump or move depends on uninitialised value(s)
==3178==at 0x908E425: g_utf8_offset_to_pointer (in 
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==3178==by 0x12B5A734: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30)
==3178==by 0x12B5AD38: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30)
==3178==by 0x12B5B06E: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30)
==3178==by 0x8DD1FA4: g_closure_invoke (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178==by 0x8DE3AFB: ??? (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178==by 0x8DECD5B: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178==by 0x8DED08E: g_signal_emit (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178==by 0x12CE9B53: gtk_widget_realize (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30)
==3178==by 0x12CEAE67: gtk_widget_set_parent (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30)
==3178==by 0x12B89A32: gtk_fixed_put (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30)
==3178==by 0x8DD50A6: g_cclosure_marshal_VOID__OBJECTv (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==3178== 
==3178== Invalid read of size 1
==3178==at 0x51679C0: __strcmp_sse2_unaligned (strcmp-sse2-unaligned.S:24)
==3178==by 0x83C04C

Re: [Plplot-devel] How to build with QT5?

[Hazen Babcock]

On 11/17/2016 07:26 PM, Alan W. Irwin wrote:
>
> Hi Hazen:
>
> My recent set of changes introduced no changes concerning the meaning
> of PLPLOT_USE_QT5.  In fact, my recent tests of those changes (see my
> commit message) show Plplot builds properly here with both
> -DPLPLOT_USE_QT5=ON (i.e., Qt5) and -DPLPLOT_USE_QT5=OFF (i.e, Qt4).
> But in each case I used scripts/comprehensive_test.sh which
> automatically executes cmake in the ideal way, i.e., in an initially
> empty build tree.
>
> In your case, it looks like -DPLPLOT_USE_QT5=ON is being ignored and
> you are getting consistent Qt4 results instead.  (Your cache file
> reports PLPLOT_USE_QT5=OFF and nothing is found that is Qt5 related.)
>
> Is a dirty build tree reflecting previous Qt4 builds causing you the
> present difficulties with attempting to use Qt5?
>
> Of course, if that speculation is not correct, then the next thing you
> should do is look at your complete cmake output starting with an empty
> build tree and pristine source tree to see what it says regarding
> finding Qt5 when you specify -DPLPLOT_USE_QT5=ON.  If our build system
> cannot
> find Qt5 with -DPLPLOT_USE_QT5=ON it forces PLPLOT_USE_QT5 to
> OFF and falls back to looking for and using Qt4 in a consistent way.
>
> So either scenario (dirty build tree or cannot find Qt5) is consistent
> with your current cache file.

Sorry, it appears that I was missing the qttools5-dev package.

As an aside it looks like x02c works fine with Qt5 even in -fam mode.

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] How to build with QT5?

[Hazen Babcock]

How does one get PLplot to build with QT5 now?

This is what I used to do:
cmake -DPLPLOT_USE_QT5=ON ../plplot

However the cmake cache now has the following mistakes (or what appear 
to me to be mistakes):


//Enable pyqt4 Python extension module
ENABLE_pyqt4:BOOL=ON

//Enable pyqt5 Python extension module
ENABLE_pyqt5:BOOL=OFF

..

//Where can the qmake-qt4 library be found
QT_QMAKE_EXECUTABLE:FILEPATH=/usr/bin/qmake-qt4

PyQt4 will not work with Qt5, and qmake-qt4 also seems to be the wrong 
choice for a Qt5 build.


-Hazen
# This is the CMakeCache file.
# For build in directory: /home/hbabcock/Code/plplot-build
# It was generated by CMake: /usr/bin/cmake
# You can edit this file to change values found and used by cmake.
# If you do not want to change any of the values, simply exit the editor.
# If you do want to change a value, simply edit, save, and exit the editor.
# The syntax for the file is as follows:
# KEY:TYPE=VALUE
# KEY is the name of a variable in the cache.
# TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!.
# VALUE is the current value for the KEY.


# EXTERNAL cache entries


//Add extra source-tree consistency checking targets that require
// special tools
ADD_SPECIAL_CONSISTENCY_CHECKING:BOOL=OFF

//Enable build of DocBook documentation
BUILD_DOC:BOOL=OFF

//Build doxygen documentation
BUILD_DOX_DOC:BOOL=OFF

//Build Hershey fonts?
BUILD_HERSHEY_FONTS:BOOL=OFF

//Build shared libraries
BUILD_SHARED_LIBS:BOOL=ON

//Compile examples in the build tree and enable ctest
BUILD_TEST:BOOL=OFF

//Path to a program.
CMAKE_AR:FILEPATH=/usr/bin/ar

//Choose the type of build, options are: None(CMAKE_CXX_FLAGS or
// CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
CMAKE_BUILD_TYPE:STRING=

//Enable/Disable color output during build.
CMAKE_COLOR_MAKEFILE:BOOL=ON

//CXX compiler
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++

//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release builds for minimum
// size.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the compiler during release builds.
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the compiler during release builds with debug info.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//C compiler
CMAKE_C_COMPILER:FILEPATH=/usr/bin/cc

//Flags used by the compiler during all build types.
CMAKE_C_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_C_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release builds for minimum
// size.
CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the compiler during release builds.
CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the compiler during release builds with debug info.
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//Flags used by the linker.
CMAKE_EXE_LINKER_FLAGS:STRING=

//Flags used by the linker during debug builds.
CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING=

//Flags used by the linker during release minsize builds.
CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING=

//Flags used by the linker during release builds.
CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING=

//Flags used by the linker during Release with Debug Info builds.
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING=

//Enable/Disable output of compile commands during generation.
CMAKE_EXPORT_COMPILE_COMMANDS:BOOL=OFF

//Fortran compiler
CMAKE_Fortran_COMPILER:FILEPATH=/usr/bin/gfortran

//Flags for Fortran compiler.
CMAKE_Fortran_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_Fortran_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release builds for minimum
// size.
CMAKE_Fortran_FLAGS_MINSIZEREL:STRING=-Os

//Flags used by the compiler during release builds.
CMAKE_Fortran_FLAGS_RELEASE:STRING=-O3

//Flags used by the compiler during release builds with debug info.
CMAKE_Fortran_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//install location for user executables
CMAKE_INSTALL_BINDIR:PATH=/usr/local/bin

//install location for read-only architecture-independent data
CMAKE_INSTALL_DATADIR:PATH=/usr/local/share

//install location for architecture-dependent files
CMAKE_INSTALL_EXEC_PREFIX:PATH=/usr/local

//install location for C header files
CMAKE_INSTALL_INCLUDEDIR:PATH=/usr/local/include

//install location for info documentation
CMAKE_INSTALL_INFODIR:PATH=/usr/local/share/info

//install location for object code libraries
CMAKE_INSTALL_LIBDIR:PATH=/usr/local/lib

//install location for man documentation
CMAKE_INSTALL_MANDIR:PATH=/usr/local/share/man

//install location for pkg-config *.pc files
CMAKE_INSTALL_PKG_CONFIG_DIR:PATH=/usr/local/lib/pkgconfig

//Install path prefix, prepended onto install directories.
CMAKE_INSTALL_PREFIX:PATH=/usr/local

//Path to a program.
CMAKE_LINKER:FILEPATH=/usr/bin/ld

//Path to a program

Re: [Plplot-devel] ctest failure with Qt file devices

[Hazen Babcock]

On 11/17/2016 04:49 AM, Alan W. Irwin wrote:
>
> So you will want to try that version as well.

I'm still seeing the same problem.

> However, if the example 2 memory management issues continue to show up
> for qt4 (in contradiction to my good valgrind result above), then I
> suspect your Qt4
> library is not a very good one (since I am getting good results with
> the Debian Jessie Qt4 library for all our standard examples).  So I
> don't think it is worth your time trying to figure out this issue which
> is very likely not our problem.
>
> For the record what version of Qt4 and what Linux distro are you
> running?

$ qmake-qt4 --version
QMake version 2.01a
Using Qt version 4.8.7 in /usr/lib/x86_64-linux-gnu

$ uname -a
Linux hbabcock-laptop2 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 
19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.1 LTS
Release:16.04
Codename:   xenial

Back in 2010 we decided that it was a difference between the Gnome and 
KDE desktops.

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] ctest failure with Qt file devices

[Hazen Babcock]

On 11/15/2016 10:47 PM, Hazen Babcock wrote:
>>
>> If I recall correctly example 2 moves through the pages in a unique
>> but legitimate way that other examples do not use so that may be
>> triggering this issue for the qt devices.  So I plan to take a look
>> later when I have finished up some other PLplot issues I am currently
>> dealing with unless you are able to solve this issue first on your own.
>>
>> Assuming you do want to investigate further on your own, I would try
>> compiling with
>>
>> export CFLAGS="-g"
>> export CXXFLAGS="-g"
>>
>> (so the valgrind results properly identify code lines and you can
>> attach a gdb session (if you like) whenever valgrind finds a memory
>> management issue.  Then run valgrind (with --db-attach=yes) on example
>> 2 with familying and a variety of qt devices to see if they all have
>> memory management issues and exactly what part of our qt code is
>> generating those.  My guess is it is something one or all of our qt
>> devices does wrong for the end-of-page processing in familying mode
>> for the unique way example 2 navigates through its two pages.
>
> Apparently --db-attach has been deprecated. My valgrind results are
> attached, but I'm not sure they tell us that much as (naturally) the
> example does not segfault when run in the context of valgrind.
>
> I also tried running it in gdb, where it did segfault with the following
> backtrace:
>
> (gdb) backtrace
> #0  0x7fffedf1012d in gtk_container_add () from
> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
..
> #18 0x00400e5c in main (argc=1, argv=0x7fffdf38) at
> /home/hbabcock/Code/plplot/examples/c/x02c.c:28
>
> One thing that at least looks suspicious is frame #10:
> initQtApp (isGUI=true)
>
> Maybe isGUI should be false for the non-interactive devices?

Never mind, I see that we have previously discussed isGUI and why it 
should be true in 2010 in the thread: "tiffqt device hangs in 
test_noninteractive".

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] ctest failure with Qt file devices

[Hazen Babcock]

On 11/15/2016 03:36 PM, Alan W. Irwin wrote:



This is happening with Qt4, specifically:


OK. That very likely means this is our problem and nothing
to do with Qt4.


[this] command does not segfault:
./x02c -dev pngqt -o ex2.png

But it does segfault in family mode:
./x02c -fam -dev pngqt -o ex2.png


If I recall correctly example 2 moves through the pages in a unique
but legitimate way that other examples do not use so that may be
triggering this issue for the qt devices.  So I plan to take a look
later when I have finished up some other PLplot issues I am currently
dealing with unless you are able to solve this issue first on your own.

Assuming you do want to investigate further on your own, I would try
compiling with

export CFLAGS="-g"
export CXXFLAGS="-g"

(so the valgrind results properly identify code lines and you can
attach a gdb session (if you like) whenever valgrind finds a memory
management issue.  Then run valgrind (with --db-attach=yes) on example
2 with familying and a variety of qt devices to see if they all have
memory management issues and exactly what part of our qt code is
generating those.  My guess is it is something one or all of our qt
devices does wrong for the end-of-page processing in familying mode
for the unique way example 2 navigates through its two pages.


Apparently --db-attach has been deprecated. My valgrind results are 
attached, but I'm not sure they tell us that much as (naturally) the 
example does not segfault when run in the context of valgrind.


I also tried running it in gdb, where it did segfault with the following 
backtrace:


(gdb) backtrace
#0  0x7fffedf1012d in gtk_container_add () from 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0

#1  0x753095ee in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#2  0x7530a61e in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#3  0x7530d4be in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#4  0x752efe01 in QGtkStyle::QGtkStyle() () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#5  0x75276cbd in QStyleFactory::create(QString const&) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#6  0x74f68cce in QApplication::style() () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#7  0x74f69115 in QApplicationPrivate::initialize() () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#8  0x74f692aa in QApplicationPrivate::construct(_XDisplay*, 
unsigned long, unsigned long) ()

   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#9  0x74f69678 in QApplication::QApplication(int&, char**, bool, 
int) ()

   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#10 0x75cf1092 in initQtApp (isGUI=true) at 
/home/hbabcock/Code/plplot/drivers/qt.cpp:104
#11 0x75cf136f in plD_init_rasterqt (pls=0x77dccee0 ) 
at /home/hbabcock/Code/plplot/drivers/qt.cpp:279
#12 0x77b69de1 in plP_init () at 
/home/hbabcock/Code/plplot/src/plcore.c:144
#13 0x77b7b7ce in plGetFam (pls=0x77dccee0 ) at 
/home/hbabcock/Code/plplot/src/plctrl.c:2781
#14 0x75cf2334 in plD_bop_pngqt (pls=0x77dccee0 ) at 
/home/hbabcock/Code/plplot/drivers/qt.cpp:578
#15 0x77b6a027 in plP_bop () at 
/home/hbabcock/Code/plplot/src/plcore.c:211
#16 0x77b97894 in c_plbop () at 
/home/hbabcock/Code/plplot/src/plpage.c:125
#17 0x00400ed9 in demo2 () at 
/home/hbabcock/Code/plplot/examples/c/x02c.c:70
#18 0x00400e5c in main (argc=1, argv=0x7fffdf38) at 
/home/hbabcock/Code/plplot/examples/c/x02c.c:28


One thing that at least looks suspicious is frame #10:
initQtApp (isGUI=true)

Maybe isGUI should be false for the non-interactive devices?

-Hazen
==11600== Memcheck, a memory error detector
==11600== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==11600== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==11600== Command: ./x02c -fam -dev pngqt -o ex2.png
==11600== 
==11600== Invalid read of size 8
==11600==at 0xF022124: gtk_container_add (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.30)
==11600==by 0x7AE65ED: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==11600==by 0x7AE761D: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==11600==by 0x7AEA4BD: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==11600==by 0x7ACCE00: QGtkStyle::QGtkStyle() (in 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==11600==by 0x7A53CBC: QStyleFactory::create(QString const&) (in 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==11600==by 0x7745CCD: QApplication::style() (in 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==11600==by 0x7746114: QApplicationPrivate::initialize() (in 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==11600==by 0x77462A9: QApplicationPrivate::construct(_XDisplay*, unsigned 
long, unsigned long) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==11600==by 0x7746677: QApplication::QApplication(int&, char**, bool, int) 
(in /usr/lib

Re: [Plplot-devel] ctest failure with Qt file devices

[Hazen Babcock]

On 11/15/2016 02:46 AM, Alan W. Irwin wrote:
>>
>> All the file based Qt devices are failing for me in ctest. This is an
>> example error message:
>>
>> test 17
>>   Start 17: examples_pngqt
>>
>> 17: Test command: /bin/bash "-c"
>> "EXAMPLES_DIR=/home/hbabcock/Code/plplot-build/examples
>> SRC_EXAMPLES_DIR=/home/hbabcock/Code/plplot/examples
>> OUTPUT_DIR=/home/hbabcock/Code/plplot-build/ctest_examples_output_dir
>> VC_CTEST_DIRECTORY= ./plplot-test.sh --verbose --front-end=c
>> --device=pngqt"
>> 17: Test timeout computed to be: 1500
>> 17: Testing front-end c
>> 17: x00c
>> 17: x01c
>> 17: x02c
>> 17: ./test_c.sh: line 32: 16690 Segmentation fault  (core dumped)
>> $DEBUG_CMD "$cdir"/x${index}${lang} -dev $device -o
>> "${OUTPUT_DIR}"/x${index}${lang}%n.$dsuffix $options 2> test.error >|
>> "${OUTPUT_DIR}"/x${index}${lang}_${dsuffix}.txt
>> 17/24 Test #17: examples_pngqt ...***Failed0.61 sec
>>
>
> Is this segfault occurring for Qt5 or Qt4?  If the former, my advice is
> to try Qt4 instead.

This is happening with Qt4, specifically:

$ /usr/bin/qmake-qt4 --version
QMake version 2.01a
Using Qt version 4.8.7 in /usr/lib/x86_64-linux-gnu

> My current testing hasn't detected this segfault, but that doesn't
> mean much since that is the nature of memory management issues; they
> sometimes segfault and they sometimes do not.  By the way, the "x02c"
> prompt
> occurs at the start of that portion of the test (see
> plplot_test/test_c.sh.in) so that is
> the example that segfaulted, not x03c.  So you might or might
> not see a segfault with
>
> ./x02c -dev pngqt -o ex2.png
>
> However, a valgrind run on that here (for the Qt5 case) does show
> memory management issues (invalid reads) that do not lead to segfaults
> for me but which lead to segfaults (like you have seen) for others.
> Furthermore, similar valgrind runs on x00c, x01c and x03c shows no
> such memory management issues.  I will take a look at that memory
> management incompatiblity between the qt devices and example 2 _if_
> that issue also shows up for Qt4, but if this is a Qt5-only issue I
> won't bother with it because I attribute (see below) Qt5-only memory
> management issues to the immaturity of Qt5 compared to Qt4.

Thank you for the correction, that command does not segfault:
./x02c -dev pngqt -o ex2.png

But it does segfault in family mode:
./x02c -fam -dev pngqt -o ex2.png

-Hazen

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] ctest failure with Qt file devices

[Hazen Babcock]

Hello,

All the file based Qt devices are failing for me in ctest. This is an 
example error message:

test 17
   Start 17: examples_pngqt

17: Test command: /bin/bash "-c" 
"EXAMPLES_DIR=/home/hbabcock/Code/plplot-build/examples 
SRC_EXAMPLES_DIR=/home/hbabcock/Code/plplot/examples 
OUTPUT_DIR=/home/hbabcock/Code/plplot-build/ctest_examples_output_dir 
VC_CTEST_DIRECTORY= ./plplot-test.sh --verbose --front-end=c --device=pngqt"
17: Test timeout computed to be: 1500
17: Testing front-end c
17: x00c
17: x01c
17: x02c
17: ./test_c.sh: line 32: 16690 Segmentation fault  (core dumped) 
$DEBUG_CMD "$cdir"/x${index}${lang} -dev $device -o 
"${OUTPUT_DIR}"/x${index}${lang}%n.$dsuffix $options 2> test.error >| 
"${OUTPUT_DIR}"/x${index}${lang}_${dsuffix}.txt
17/24 Test #17: examples_pngqt ...***Failed0.61 sec


The equivalent(?) command line seems to work fine:
$ ./x03c -dev pngqt -o ex3.png

This is on a linux system.
Linux Dell-XPS-8100 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

-Hazen

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Error report system plus thread safety

[Hazen Babcock]

On 02/27/2016 10:10 PM, Alan W. Irwin wrote:
> On 2016-02-27 23:22- Phil Rosenberg wrote:
>
>> Perhaps it would be good for Hazen and Alan to start looking
> in more detail at implementing the error code propagation? If there
> are tools to help with that, then maybe it will be easier than I
> suspect.
>
> I am now confident of the return code method because of the
> 'warn_unused_result' gcc attribute capability, but let's not even
> start the substantial work required for this alternative unless it is
> made necessary because you run into some showstopper issue with the C
> exception-based alternative.

Before you begin I would encourage you to read this:

http://stackoverflow.com/questions/14685406/practical-usage-of-setjmp-and-longjmp-in-c

Particularly the 2nd and 3rd answers. As they point out, this is *not* 
C++ exception handling in C, this is just a goto statement. To me that 
would be a showstopper issue. However, who does the work decides, so if 
this approach is still your preference then I won't persist in trying to 
dissuade you.

-Hazen

--
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=272487151&iu=/4140
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Error report system plus thread safety

[Hazen Babcock]

On 02/26/2016 05:18 PM, Alan W. Irwin wrote:
> @Hazen:
>
> Please pay close attention to this ongoing discussion and participate
> in it further because I don't want you to start work on the return
> value approach for reporting errors like you have already volunteered
> to do just in case the (likely) decision is made that we go with error
> reporting based on C exception handling instead.

Don't worry, I promise not to start any time soon..

> On 2016-02-26 17:34- Phil Rosenberg wrote:
>
> [Phil]
 I am a fairly recent convert to exceptions, but I now use them
 throughout my C++ code, because using exceptions totally frees me from
 having to worry about errors. I don't have to worry about checking
 return values or  anything like that, I am free to concentrate on the
 interesting aspects of the code writing, rather than getting bogged
 down in error checking and avoiding memory leaks. But more
 importantly, if used in well styled code, exceptions are bomb proof,
 they actually make it impossible to miss or fail to deal with an
 error.
>>>
>>>
> [Alan]
>>> Is this possibility only available in C++?  If so, it does not help us
>>> with our core C library which does need an error reporting system now.
>>> We do not want to use the the possibility that we _might_ move to C++
>>> in the future for our core library as an excuse for inaction on this
>>> important topic for our current core C library.
>>>
> [Phil]
>> Regarding this point - C can do similar things using the
>> setjmp()/longjmp() function and a resource pool/tracker. It is not as
>> simple to implement as in C++, but I still think it would be much
>> easier to implement and much easier to support than trying to
>> propagate error codes through our internals. I still strongly
>> recommend a read of that book chapter and if you ever feel like
>> experimenting with C++ that book is excellent, although a bit out of
>> date now we have C++11 and beyond.
>> It just dawned on me that we could simply put longjmp(errcode); inside
>> plexit() and then all we need to do is add the code to catch this in
>> the API functions and the job is complete.
>>
>> Anyway please just have a read about exceptions before we make this call.
>
> @Phil:
>
> I promise to do that later today.  But I have to admit you have
> already made a fairly convincing argument for error reporting via C
> exception handling, and if you look at the caller graphs I prepared
> there are some instances (even if we have immediate exit for memory
> emergencies) where the return value approach would be quite
> complicated.

Such as?

Furthermore, from my skimming of
>  it appears that your
> preferred setjmp()/longjmp() approach is usable for C exception
> handling just like you have claimed above.

I still favor the return value based approach. If one was to start again 
from scratch this is the way (I think) the library would be written, so 
I don't see why it would be done differently now. Yes it will probably 
be more work to implement, but I don't think it will be particularly 
hard to maintain as a compiler like gcc is more than happy to warn you 
if you are ignoring returned values. And yes the exit will not be clean, 
as there is likely to be memory that was allocated but not freed. 
However the possibility exists with this approach of going back in the 
future and cleaning all of that up, something which I don't think is 
possible with a setjmp() approach.

Though I guess we could start with the setjmp() approach as a possibly 
quicker way to make the API change and then go back and clean up the 
internals at our leisure to use a return based approach.

-Hazen

--
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=272487151&iu=/4140
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Error report system plus thread safety

[Hazen Babcock]

>
>> I obviously don't have any idea of the size of ephcom, but Plplot
> must have thousands of internal function calls that would need the
> return value checking.
>
> I believe there are some 300 functions in our public and private API,
> and not all of those will be affected by this (because there are no
> error conditions they generate or they need to propagate). So I would
> estimate "hundreds" of functions rather than "thousands" would be
> touched by this propagation effort.
>
> Also, I think the editing task for propagating return codes would be a
> similar effort to the editing task for replacing the call to plexit by
> the generation of the equivalent message to stderr and an immediate
> return with non-zero return code.  Note, the number of plexit calls is
> 220, from the results of
>
> find . -name "*.c" |xargs grep plexit | wc -l
>
> That number is roughly equivalent to the estimate I made above of the
> number of functions that would be affected by the propagation effort.
> That is the basis of my claim that the two efforts would be
> comparable.

There are also a few functions in the API that already return values 
that would have to be changed. So this would also mean updating all of 
the language bindings and probably some of the examples.

> Anyhow, I am convinced by my above estimate that the propagation part
> of the work will require similar effort to the rest of the project, I
> do like the simplicity of the return code method that has proved to be
> so useful in the ephcom case, and I think the above testing method
> will insure the whole effort will give reliable return code results.
> Also, I think we are talking a few weeks of one-man effort rather than
> months to get this done completely. Therefore, I stand willing (early
> in the next release cycle) to make this happen. Of course, many hands
> make light work so I would welcome some help with this project.

I agree with your time estimate. I also agree that the return codes 
approach is the right way to do it, and even if it does end up taking 
longer than expected it will be more than worth the effort. So I'd be 
happy to help. I guess we'd start with a header file containing a list 
of possible error codes, and then split up the editing of the various 
files in the src/ directory between those who volunteer?

-Hazen

--
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=272487151&iu=/4140
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] PyQt5 bindings

[Hazen Babcock]

Hello,

I just added PyQt5 binding to PLplot and a corresponding example, 
examples/python/pyqt5_example.py. It should be enabled if you are using 
Qt5 and you have all the dependencies installed. I tested it and at the 
minimum it works on my linux machine :).

The biggest issue with these bindings is that PyQt5 does not provide any 
way to introspect the sip directory (PYQT_SIP_DIR), so I just used the 
default linux install location. I put in a guess for the default Windows 
install location, but perhaps someone with access to a Windows machine 
can tell me if I got it right?

best,
-Hazen

--
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Qt5 / cmake error

[Hazen Babcock]

On 01/22/2016 02:42 AM, Alan W. Irwin wrote:
> I had success with a build of PLplot against Qt5 some time ago.  But I
> am pretty
> sure that predated May 2015 when "git blame" tells me I introduced
> that PRIVATE keyword in bindings/qt_gui/CMakeLists.txt.  So I would
> try locally removing PRIVATE from the offending line in
> bindings/qt_gui/CMakeLists.txt.  That might introduce some
> overlinking issues, but I don't think you have to be concerned with
> those.

Hi Alan, Greg,

Removing the PRIVATE keyword solved the problem, thanks!

>
> Also, please follow the advice in the first two lines of cmake.txt,
> namely
>
> -- WARNING: CMAKE_VERSION = 3.2.2 is in the range from 3.2 through 3.3.1
> which has
> a compromised find ability that was fixed in 3.3.2.  Please upgrade
> to 3.3.2 or greater.

This was not necessary so I'm just going to stay with my current version 
of cmake for the time being.

-Hazen


--
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Qt5 / cmake error

[Hazen Babcock]

Hello,

As Qt4 is now at least technically no longer supported I thought I might 
spend some time to see if I could get our PyQt bindings to work with 
Qt5. However unfortunately I can't even build PLplot with Qt5 due to a 
cmake error. Any suggestions would be appreciated.


The error message:

CMake Error at bindings/qt_gui/CMakeLists.txt:54 (target_link_libraries):
  The plain signature for target_link_libraries has already been used with
  the target "plplotqt".  All uses of target_link_libraries with a target
  must be either all-keyword or all-plain.

  The uses of the plain signature are here:

   * /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreMacros.cmake:278 
(target_link_libraries)



I used this command in my build directory:
cmake -DPLPLOT_USE_QT5=ON ../plplot > cmake.txt 2>&1

CMake log files attached.

lubuntu 15.10.

> uname -a
Linux Dell-XPS-8100 4.2.0-25-generic #30-Ubuntu SMP Mon Jan 18 12:31:50 
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux


-Hazen
-- WARNING: CMAKE_VERSION = 3.2.2 is in the range from 3.2 through 3.3.1 which 
has
   a compromised find ability that was fixed in 3.3.2.  Please upgrade to 3.3.2 
or greater.
-- The C compiler identification is GNU 5.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- CMake version = 3.2.2
-- CMAKE_SYSTEM_NAME = Linux
-- SH_EXECUTABLE = /bin/bash
-- Checking whether system has ANSI C header files
-- Looking for 4 include files stdlib.h, ..., float.h
-- Looking for 4 include files stdlib.h, ..., float.h - found
-- Performing Test memchrExists
-- Performing Test memchrExists - Success
-- Performing Test freeExists
-- Performing Test freeExists - Success
-- Check for whether ctype.h macros work on characters with the
   high bit set.
-- High-bit characters - work
-- ANSI C header files - found
-- Looking for include file unistd.h
-- Looking for include file unistd.h - found
-- Looking for include file termios.h
-- Looking for include file termios.h - found
-- Looking for include file stdint.h
-- Looking for include file stdint.h - found
-- Looking for crt_externs.h
-- Looking for crt_externs.h - not found
-- Performing Test HAVE_SYS_WAIT_H
-- Performing Test HAVE_SYS_WAIT_H - Success
-- Looking for DIR symbol in sys/types.h;dirent.h
-- Looking for DIR symbol in sys/types.h;dirent.h - found
-- Check for signal return type in 
-- Check for signal handler return type type void  - found
-- Looking for popen
-- Looking for popen - found
-- Looking for usleep
-- Looking for usleep - found
-- Looking for nanosleep
-- Looking for nanosleep - found
-- Looking for mkstemp
-- Looking for mkstemp - found
-- Looking for mkdtemp
-- Looking for mkdtemp - found
-- Looking for mkfifo
-- Looking for mkfifo - found
-- Looking for unlink
-- Looking for unlink - found
-- Looking for _NSGetArgc
-- Looking for _NSGetArgc - not found
-- Looking for isfinite
-- Looking for isfinite - found
-- Looking for finite
-- Looking for finite - found
-- Looking for isnan
-- Looking for isnan - found
-- Looking for isinf
-- Looking for isinf - found
-- Looking for snprintf
-- Looking for snprintf - found
-- SWIG_VERSION = 2.0.12
-- Found Perl: /usr/bin/perl (found version "5.20.2") 
-- WARNING: Perl module XML::DOM not found
-- CMAKE_GENERATOR = Unix Makefiles
-- The CXX compiler identification is GNU 5.2.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: 
/home/hbabcock/Code/plplot-build/language_tests/CXX
-- The CXX compiler identification is GNU 5.2.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for using namespace support
-- Check for using namespace - found
-- Looking for C++ include cmath
-- Looking for C++ include cmath - found
-- Check for broken isnan support in 
-- Check for isnan in  - found
-- Check for using stdint.h with CXX compiler
-- Check for using stdint.h with CXX compiler - ok
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") 
-- Looking for pkg-config - found
-- cxx_compiler_library_pathname_list = 
/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.so;/usr/lib/x86_64-linux-gnu/libm.so;/usr/lib/x86_64-linux-gnu/libc.so
-- Looking for XOpenDisplay in 
/usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
-- Looking for XOpenDisplay in 
/usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found
-- Looking for gethostbyname
-- L

[Plplot-devel] OpenGL driver starter kit

[Hazen Babcock]

Hello,

I am still interested in the idea of an OpenGL driver, however I am not 
that familiar with OpenGL myself. So, in the hopes that this will happen 
I am providing a branch of PLplot with a skeleton for the driver here:

https://github.com/HazenBabcock/PLplot/tree/opengl_driver_2015_10_06

This branch is up to date with PLplot as of today. This driver is 
incorporated into the PLplot build system, it should be able to find the 
OpenGL libraries on your system using cmake, and it will appear in the 
list of drivers available to PLplot. However it lacks any actual OpenGL 
code, all it does it print some messages when called by PLplot. If 
anyone is interested in filling this in that would be great.

-Hazen

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Python, anyone?

[Hazen Babcock]

> Im working on MSYS2 which brings in all of the latest-and-greatest,
> ground-breaking compatibility-crushing versions, of which python is of
> course the worst offender.
>
> I'm trying to get the PyQT4 binding to work in MSYS2.  All of the
> prerequisites
> are ready and I've patched the plplot/cmake scripting to accept the PYQT
> generated via configure-ng.py (as distinct from configure.py)
> http://pyqt.sourceforge.net/Docs/PyQt4/build_system.html#module-PyQt4.pyqtconfig
> The cygwin64 distribution has the up-to-date sip modules, but built with
> configure.py;
> it flies through the pyqt4 bindings without error.
>
> The problem I'm getting is that the generated .cpp files do not compile
> just to demonstrate, the first error:
>
>> ./sipplplot_pyqt4QtExtWidget.cpp: In member function 'void
>> sipQtExtWidget::disconnectNotify(const QMetaMethod&)':
>> ./sipplplot_pyqt4QtExtWidget.cpp:370:41: error: no matching function for
>> call to 'sipQtExtWidget::disconnectNotify(const QMetaMethod&)'
>>   QtExtWidget::disconnectNotify(a0);
>>   ^
>> In file included from
>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qiodevice.h:46:0,
>>   from
>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qdatastream.h:46,
>>   from
>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qmetatype.h:49,
>>   from
>> D:/mingw/msys32/mingw32/include/qt4/QtCore/QMetaType:1,
>>   from
>> D:/mingw/msys32/tmp/bld-32/bindings/qt_gui/pyqt4/sipAPIplplot_pyqt4.h:13,
>>   from
>> D:/mingw/msys32/tmp/bld-32/bindings/qt_gui/pyqt4/sipplplot_pyqt4QtExtWidget.cpp:7:
>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qobject.h:291:18: note:
>> candidate: virtual void QObject::disconnectNotify(const char*)
>>   virtual void disconnectNotify(const char *signal);
>>^
>> D:/mingw/msys32/mingw32/include/qt4/QtCore/qobject.h:291:18: note:   no
>> known conversion for argument 1 from 'const QMetaMethod' to 'const char*'
>
> ===
> Note: On cygwin the generated code (sipplot_pyqt4QtExtWidget.cpp) is
> different:
>
> void sipQtExtWidget::disconnectNotify(const char*a0)
> {
>  sip_gilstate_t sipGILState;
>  PyObject *sipMeth;
>
>  sipMeth =
> sipIsPyMethod(&sipGILState,&sipPyMethods[0],sipPySelf,NULL,sipName_disconnectNotify);
>
>  if (!sipMeth)
>  {
>  QtExtWidget::disconnectNotify(a0);
>  return;
>  }
>And it compiles without error.
> ===
>
>So who's fault is it? is there a switch to be thrown in the qt
> configuration so that the headers are compatible with the
> different code generation?

This looks a lot like this issue in a different project:
https://github.com/Homebrew/homebrew/issues/41464

Which seems to be that sip generates for qt5 but the build uses qt4. 
Unfortunately I have not seen a solution and I also can't find anything 
on the PyQt list about this problem.

Perhaps it is possible to tell sip which version of qt to use?

Does MSYS2 come with both Qt4 and Qt5? Maybe if you hide qt5 sip will do 
the right thing?

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] patch 31 which contains wincairo fixes

[Hazen Babcock]

On 07/06/2015 01:26 PM, Greg Jung wrote:
> I have been using the calls
> -SetWindowLong( aStream->hwnd, GWL_USERDATA, (long) pls );
> +SetWindowLongPtr( aStream->hwnd, GWLP_USERDATA, (LONG_PTR) pls );
>
> in both 32- and 64-bit compiled wincairo application for months, as well as
> in wingcc.  They work.  AFAICT there's
> no reason to maintain #ifdef _WIN64 conditionals as long as you go with
> these calls.
>
> I hadn't noticed the omission of  except it now removes a
> worrisome warning I got
> in 64-bit compilation (the 32-bit comnpilation didn't need this, evidently).

Ok, I just pushed this so let me know if it causes any problems.

-Hazen


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] patch 31 which contains wincairo fixes

[Hazen Babcock]

On 07/04/2015 12:15 PM, Alan W. Irwin wrote:
> Hi Hazen:
>
> A PLplot user has created a patch containing wincairo fixes (see
> ).  As the originator of
> the wincairo device could you please evaluate this 3-line change to
> see whether we should apply it now to master so it will be included in
> the planned 5.11.1 bugfix release?

Hi Alan,

I think these changes are the right thing to do based on reading up on 
Microsoft's documentation and I would just go ahead and apply it. 
However since I no longer have a Windows development box I can't test 
it. The best test would be to make sure that it doesn't break 32 bit 
Windows.

-Hazen


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Bug fix to plbuf.c

[Hazen Babcock]

On 06/14/2015 05:59 PM, Alan W. Irwin wrote:
> On 2015-06-14 13:40-0400 Jim Dishaw wrote:
>
>> []The aqt driver is a mystery.  It does not use the plot buffer
> nor does it look at the nopause member; however, it is an interactive
> driver. It should work with just a NULL in the wait handler because
> the EOP will be called only once.  The dg300 is another example.
>
> Hi Jim:
>
> See cmake/modules/drivers-init.cmake for the status of each device
> driver.  Some of them (e.g., dg300) have been completely retired
> because they are unmaintained and likely not compatible with modern
> PLplot any more.  We should completely remove the source code for
> every retired PLplot device such as dg300 so as not to have old
> incompatible driver code obfuscating the source code for devices that
> are being actively maintained.
>
> @Hazen:
> Have you given up on maintaining aqt, i.e., is it time to retire that
> driver and completely remove its source code?

I am not maintaining it, but I believe that it still works so I would 
not remove it.

-Hazen

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLPlot 6 and C++

[Hazen Babcock]

>
> On 2015-05-22 13:00+0100 Phil Rosenberg wrote:
>
>> Hi All
>> I mentioned this briefly during the previous release cycle, but we all
>> had more pressing things to deal with. Dealing with errors is
>> something we really  need to get a hold on for PLPlot 6 and one of the
>> big drivers for considering a major API change. However, I am certain
>> that the reason why this has been a problem s that propagating those
>> errors back up through many layers of function calls is tedious and
>> error prone so it has been much simpler to simply call exit().
>>
>> Here is one possible solution. We switch the core code to C++ with a C 
>> frontend.
>>
>
> However, let's be clear here the cost of that benefit is
> likely to be considerably higher than you are estimating now.
> For example, there is going to be substantial costs in terms of
> doxygen and DocBook documentation, and also the domestic bindings and
> foreign bindings (e.g., the PDL and Lisp bindings for PLplot) are of
> some concern.  Of course, in theory you could write a perfect C wrapper
> library for the C++ core so bindings on that C wrapper work just as
> well as they do for PLplot 5.  But that C wrapper would really
> have to be perfect and would make the bindings less efficient.  Note,
> I don't want to emphasize that last point too much since reliability
> is much more important to me than speed.  But at some point, I assume
> you will want to address that issue (e.g., for the swig-generated
> bindings) by ignoring the C wrapper and binding directly to the C++
> core instead which adds to the cost of this change.

I agree with Alan that it is not immediately obvious that this approach 
will save a lot of effort. All the API functions are going to have to be 
modified anyway, even if only to return some sort of no error code. This 
in turn will mean updating all the examples and a lot of the 
documentation. So the additional saving might be something like 10% on 
top of this? A C++ solution would also involve adding "extern" to every 
part of the API that we want to expose.

It could be argued that the exercise of dealing with the propagation 
issues might help to clean up issues that were otherwise just papered 
over. I think we'd have to do this anyway in order to take advantage of 
your proposal to use the out of scope array deletion feature of C++, as 
every array in PLplot is now going to have to be a C++ object. This is 
also going to be a lot of work, though we'd face similar cleanup issues 
in C. By my count there are currently 146 calls to plexit() in PLplot 
core, most of which are related to memory allocation.

So I lean slightly towards staying with C, but if others think that C++ 
is the way to go, then that is ok with me and I'll try to help with 
things like updating the examples, documentation, etc.

Some questions:
1. C++ compilers are universal? Are there any major platforms that we 
want to support that do not have readily available C++ support?

2. In my readings on this subject some have mentioned that a C++ 
compiler can be substantially slower? Is this true? Significant?

-Hazen


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] FPE in plfill.c

[Hazen Babcock]

On 05/14/2015 11:42 AM, Hazen Babcock wrote:
> On 05/13/2015 05:50 PM, Alan W. Irwin wrote:
>>
>> Hi Hazen:
>>
>> I have reviewed plfill.c, and the returned intersection from
>> notcrossed is only used when status is zero.  So I have (commit ID =
>> b916d4b) considerably simplified noncrossed to do the PLINT
>> transformation of the intersection and return those values _only_ when
>> status = 0.
>>
>> This change solved all fpe problem for examples 25 and 30, but there
>> are remaining fpe issues for fortran examples 21 and 33.  The logic in
>> noncrossed is pretty bullet-proof now so my prediction is those
>> remaining fpe issues are completely independent of notcrossed or else
>> there is a non-initialized variable somewhere in fortran examples 21
>> and 33. But I look forward to your definitive conclusion concerning
>> those remaining fpe issues.
>
> The issue in example 21 seems to be in the qhull library. I will look
> into building a qhull with debug flag to try and track this one down.
>
> The remaining issue in example 33 is that we are multiplying -2.0e-200
> times 9.9e-201 when calculating iedge[i] in pldrawcn() at line 695 of
> src/plcont.c. The result of this calculation, ~1.0e-400, is smaller than
> what can be represented using floating point numbers. I changed the
> login in pldrawcn() to do the sign determination without doing this
> multiplication. I've just pushed this fix.

Hm, got the signs backwards, hopefully it is correct now.

-Hazen


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] FPE in plfill.c

[Hazen Babcock]

On 05/13/2015 05:50 PM, Alan W. Irwin wrote:
>
> Hi Hazen:
>
> I have reviewed plfill.c, and the returned intersection from
> notcrossed is only used when status is zero.  So I have (commit ID =
> b916d4b) considerably simplified noncrossed to do the PLINT
> transformation of the intersection and return those values _only_ when
> status = 0.
>
> This change solved all fpe problem for examples 25 and 30, but there
> are remaining fpe issues for fortran examples 21 and 33.  The logic in
> noncrossed is pretty bullet-proof now so my prediction is those
> remaining fpe issues are completely independent of notcrossed or else
> there is a non-initialized variable somewhere in fortran examples 21
> and 33. But I look forward to your definitive conclusion concerning
> those remaining fpe issues.

The issue in example 21 seems to be in the qhull library. I will look 
into building a qhull with debug flag to try and track this one down.

The remaining issue in example 33 is that we are multiplying -2.0e-200 
times 9.9e-201 when calculating iedge[i] in pldrawcn() at line 695 of 
src/plcont.c. The result of this calculation, ~1.0e-400, is smaller than 
what can be represented using floating point numbers. I changed the 
login in pldrawcn() to do the sign determination without doing this 
multiplication. I've just pushed this fix.

-Hazen


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] floating point exception in example 29

[Hazen Babcock]

On 05/13/2015 03:58 PM, Alan W. Irwin wrote:
> In my case the only fortran compiler available is gfortran so I don't
> need to choose that.  So instead of the above I set
>
> export FFLAGS='-g -ffpe-trap=invalid,zero,overflow,underflow'
>
> before calling cmake and building the x29f95 and ps targets.
>
> After that, I got the following result
>
> software@raven> examples/f95/x29f -dev psc -o test.psc
>
> Program received signal SIGFPE: Floating-point exception - erroneous
> arithmetic operation.
> [...]
>
> So I confirm there is a floating-point issue for that example, and
> this should be easy for anyone else here to confirm that has access to
> gfortran.  However, I am completely tied up with other PLplot issues
> so I would appreciate it if you pursued and fixed all floating-point
> issues revealed by this method.  But if you are too busy to do that
> yourself, please let this list know so others with more time will be
> motivated to take a crack at it.

The problem seems to come from line 267 in this example. It looks like 
the "sec" argument is not getting passed to the C library correctly? 0.0 
becomes something like 4.2439915819305446e-314, which I think causes the 
later problems. Perhaps there is something wrong with the fortran 
bindings for plctime? I would appreciate it if a fortran expert could 
take a look.

-Hazen


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] FPE in plfill.c

[Hazen Babcock]

Hello Alan, Arjen,

As I mentioned before, the FPE's in x25c, x30c and x33c are all coming 
from the notcrossed() function in plfill.c. Hopefully you can provide 
some insight as the authors. Basically the problem arises in a situation 
where the two lines do not cross, but are not parallel. In this 
situation this function still calculates the x,y intersection. However, 
depending on the position and orientation of the two lines this 
intersection can be way outside the range of values that can be 
represented using (4 byte) integers. Do you recall if functions that 
call this function expect to receive a valid intersection point in this 
case? Or is it ok to just return zero?

-Hazen

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] floating point exception in example 29

[Hazen Babcock]

On 05/12/2015 01:22 PM, Alan W. Irwin wrote:
> On 2015-05-12 09:41-0400 Hazen Babcock wrote:
>>
>> Hm.. example 21 also generates an FPE, but at least in this case it
>> looks like it is coming from the qhull library. And example 29 also
>> generates an FPE, but only the Fortran version not the C version. So,
>> maybe it would be better in the end to add this check to all of the C
>> examples as well?
>
> I sympathize with your desire not to mark up all the examples.  Which
> lead to the thought that if gfortran has an option to report the above
> exceptions without additional code markup, then gcc might have such
> options as well.
>
> A google search on the terms 
> found somehow else had asked that exact question at
> <http://stackoverflow.com/questions/18644168/catch-floating-point-exceptions-using-a-compiler-option-with-c>
>
> I don't understand the answers myself, but perhaps they might be useful
> to you.

I found this as well, which is what led me to the gfortran flag. They 
are saying that such a flag does not currently exist for C.

> If it turns out the answer is currently "no" (i.e., you must mark up
> the examples in order to detect floating-point exceptions with gcc),
> then I think we could probably just stick with gfortran and
> -ffpe-trap=invalid,zero,overflow,underflow.
>
> Of course, the fortran examples go through a lot of additional code
> before finally calling our core C library so this method should detect
> floating-point exceptions in the fortran example implementation, the
> fortran wrapper library code, AND, our core C library.  So we do want
> to solve all of those.  Furthermore, once we have done so then I
> believe the only C floating-point exception left that would go
> undetected would be in the actual C example implementation, i.e., if
> we divided by 0. right in one of the examples.  But we guard against
> such issues in other ways (with the comparisons of PostScript and SVG
> results) so I don't think we need to be concerned about such an issue.
>
> If you agree with my above reasoning that gfortran with
> -ffpe-trap=invalid,zero,overflow,underflow is what we want to do going
> forward to detect floating point exceptions, then I hope you have the
> time to fix all the causes of those exceptions in this release cycle.

I'd add it to the debug build flags for fortran. Perhaps a check is also 
needed that the fortran compiler is gfortran?

-Hazen


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Version 6?

[Hazen Babcock]

This e-mail is to provide a summary of what we had discussed, please let 
me know if I left anything out. I think we had a consensus that the 
following change would be made as part of a possible version 6:

1. All API functions return error codes.


I think we also agreed on these items, which might not actually require 
a major version bump as the actual change to the API is potentially 
small / nil:

2. Thread safety.

3. Improved text handling between core and the drivers.


And there was some discussion about whether this was a good idea:

4. Core handles some text rendering.


Now I think the question is if the effort and disruption involved in (1) 
justifies making the change. I would say that I'm neutral about this. I 
feel that it is the way a modern library should behave. However I'm not 
sure that the fact that PLplot does not currently work this way is 
actually causing a lot of problems for people.

-Hazen


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] floating point exception in example 29

[Hazen Babcock]

>
> On 05/11/2015 06:05 PM, Alan W. Irwin wrote:
>>
>> Hi Hazen:
>>
>> I am glad to hear you have created a topic branch that catches
>> floating point exceptions.  However, I am not keen on pulling a PLplot
>> topic branch from github for the reasons discussed in
>> README.developers.  So could you either share your topic branch using
>> "git format-patch" or else just push it to our official repo yourself?
>> The former is preferred if the work is incomplete (i.e., does not
>> include a cmake option to control when the PLPLOT_ENABLE_FLOAT_EXCEPT
>> macro is #defined). Furthermore, if the work is incomplete, I can
>> finish the cmake aspects of it as promised above and amend your commit
>> accordingly.
>>
>> Once we have implemented an option to check for floating-point
>> exceptions, then that means any of us should be able to confirm the
>> ones you have found and find others in the future due to the continued
>> evolution of our examples.  And, of course, this option should allow
>> us to fix those floating-point exceptions as time permits.
>
> Hi Alan,
>
> Sorry, that branch was not meant for incorporation into PLplot which is
> why I did not follow accepted protocols. I thought it might make it
> easier for others to see the floating point exception problem for these
> 3 examples.
>
> I think we can enable floating point exception trapping more easily
> using the -ffpe-trap option provided by gfortran. This won't require us
> to mark up all of our C examples, though we might instead need to check
> that the fortran compiler is gfortran?
>
> https://gcc.gnu.org/onlinedocs/gfortran/Debugging-Options.html
>
> -ffpe-trap=invalid,zero,overflow,underflow
>
> Compiling PLplot with this fortran flag (CMAKE_Fortran_FLAGS) "worked"
> for me in that it core dumps on the fortran equivalents of the C
> examples I mentioned above. I've attached my CMakeCache.txt file.
>
> -Hazen

Hm.. example 21 also generates an FPE, but at least in this case it 
looks like it is coming from the qhull library. And example 29 also 
generates an FPE, but only the Fortran version not the C version. So, 
maybe it would be better in the end to add this check to all of the C 
examples as well?

-Hazen


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] floating point exception in example 29

[Hazen Babcock]

On 05/11/2015 06:05 PM, Alan W. Irwin wrote:

On 2015-05-11 16:23-0400 Hazen Babcock wrote:


Much time passes during which I never implement this branch as
promised, and it looks like some more floating point exceptions have
crept in. More specifically I'm seeing floating point exceptions in
x25, x30 and x33. The problem seems to be with plgradient() when it
uses a software fallback gradient (I was testing with the xwin driver).

You can pull a branch with floating point exception trapping enabled
for these examples here:
https://github.com/HazenBabcock/PLplot/tree/fpe_x25_x30_x33

The problem is occurring in notcrossed() in plfill.c at line 2040 when
converting from a PLFLT to a PLINT. It looks like fxintersect and
fyintersect can take on values that are too large to be converted to
integers. Checking for this fixes the problem, but maybe this is
indicating some problem upstream?


Hi Hazen:

I am glad to hear you have created a topic branch that catches
floating point exceptions.  However, I am not keen on pulling a PLplot
topic branch from github for the reasons discussed in
README.developers.  So could you either share your topic branch using
"git format-patch" or else just push it to our official repo yourself?
The former is preferred if the work is incomplete (i.e., does not
include a cmake option to control when the PLPLOT_ENABLE_FLOAT_EXCEPT
macro is #defined). Furthermore, if the work is incomplete, I can
finish the cmake aspects of it as promised above and amend your commit
accordingly.

Once we have implemented an option to check for floating-point
exceptions, then that means any of us should be able to confirm the
ones you have found and find others in the future due to the continued
evolution of our examples.  And, of course, this option should allow
us to fix those floating-point exceptions as time permits.


Hi Alan,

Sorry, that branch was not meant for incorporation into PLplot which is 
why I did not follow accepted protocols. I thought it might make it 
easier for others to see the floating point exception problem for these 
3 examples.


I think we can enable floating point exception trapping more easily 
using the -ffpe-trap option provided by gfortran. This won't require us 
to mark up all of our C examples, though we might instead need to check 
that the fortran compiler is gfortran?


https://gcc.gnu.org/onlinedocs/gfortran/Debugging-Options.html

-ffpe-trap=invalid,zero,overflow,underflow

Compiling PLplot with this fortran flag (CMAKE_Fortran_FLAGS) "worked" 
for me in that it core dumps on the fortran equivalents of the C 
examples I mentioned above. I've attached my CMakeCache.txt file.


-Hazen

# This is the CMakeCache file.
# For build in directory: /home/hbabcock/Code/plplot-build
# It was generated by CMake: /usr/bin/cmake
# You can edit this file to change values found and used by cmake.
# If you do not want to change any of the values, simply exit the editor.
# If you do want to change a value, simply edit, save, and exit the editor.
# The syntax for the file is as follows:
# KEY:TYPE=VALUE
# KEY is the name of a variable in the cache.
# TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!.
# VALUE is the current value for the KEY.


# EXTERNAL cache entries


//Add extra source-tree consistency checking targets that require
// special tools
ADD_SPECIAL_CONSISTENCY_CHECKING:BOOL=OFF

//Enable build of DocBook documentation
BUILD_DOC:BOOL=OFF

//Build doxygen documentation
BUILD_DOX_DOC:BOOL=OFF

//Build Hershey fonts?
BUILD_HERSHEY_FONTS:BOOL=OFF

//Build shared libraries
BUILD_SHARED_LIBS:BOOL=ON

//Compile examples in the build tree and enable ctest
BUILD_TEST:BOOL=ON

//Build the testing tree.
BUILD_TESTING:BOOL=ON

//Path to a program.
BZRCOMMAND:FILEPATH=BZRCOMMAND-NOTFOUND

//Path to a program.
CMAKE_AR:FILEPATH=/usr/bin/ar

//Choose the type of build, options are: None(CMAKE_CXX_FLAGS or
// CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
CMAKE_BUILD_TYPE:STRING=Debug

//Enable/Disable color output during build.
CMAKE_COLOR_MAKEFILE:BOOL=ON

//CXX compiler.
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++

//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release builds for minimum
// size.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the compiler during release builds.
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the compiler during release builds with debug info.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//C compiler.
CMAKE_C_COMPILER:FILEPATH=/usr/bin/cc

//Flags used by the compiler during all build types.
CMAKE_C_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_C_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during

Re: [Plplot-devel] floating point exception in example 29

[Hazen Babcock]

On 04/15/2014 07:44 AM, Hazen Babcock wrote:
> On 4/7/2014 11:08 PM, Alan W. Irwin wrote:
>> I have just had a further idea. For comprehensive testing situations
>> it might be good to have the option to call feenableexcept (the C
>> library function that you used to help debug x29c.c that should be
>> available for c99 according to its Linux man page) from within the
>> PLplot library (say as the result of plinit).  If you agree (a) that
>> idea would work and (b) it would be useful, would you be willing to
>> implement it in C for the case when the PLPLOT_ENABLE_FLOAT_EXCEPT C
>> macro is #defined?  If so, I would be willing to do the rest on the
>> CMake side (create a CMake option for this and propagate it to the
>> corresponding C macro for the compilation of the source file where you
>> have implemented the feenableexcept call).
>
> I have tested the idea and it works. I'm not sure about the utility
> though. Based on my tests it already caught the only error in the
> examples that it is going to catch. After the git transition I can
> create a branch that will catch floating point exceptions and you can
> merge it (or not) into the master branch based on your feeling about
> it's utility.

Much time passes during which I never implement this branch as promised, 
and it looks like some more floating point exceptions have crept in. 
More specifically I'm seeing floating point exceptions in x25, x30 and 
x33. The problem seems to be with plgradient() when it uses a software 
fallback gradient (I was testing with the xwin driver).

You can pull a branch with floating point exception trapping enabled for 
these examples here:
https://github.com/HazenBabcock/PLplot/tree/fpe_x25_x30_x33

The problem is occurring in notcrossed() in plfill.c at line 2040 when 
converting from a PLFLT to a PLINT. It looks like fxintersect and 
fyintersect can take on values that are too large to be converted to 
integers. Checking for this fixes the problem, but maybe this is 
indicating some problem upstream?

-Hazen


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Comprehensive testing reports

[Hazen Babcock]

On 04/13/2015 06:29 PM, Alan W. Irwin wrote:
> On 2015-04-13 13:51-0400 Hazen Babcock wrote:
>
>> On 04/12/2015 08:23 AM, Alan W. Irwin wrote:
>>> On 2015-04-11 21:05-0400 Hazen Babcock wrote:
>>>
>>>> It worked fine without the Qt components. Is there an output file that
>>>> I should send?
>>>
>>> Excellent news on the Lubuntu front.
>>>
>>> To answer your question, please send a compressed tarball containing
>>> _all_ environment variables (you can capture a complete list of those
>>> from bash using printenv >& printenv.out); the script output that you
>>> capture with
>>>
>>> scripts/comprehensive_test.sh >& comprehensive_test.sh.out
>>
>> My lubuntu testing results are attached.
>
> I have identified your platform there as Lubuntu without any version
> string.  If you can identify the Lubuntu version you are using, I
> would like to add it to the report.

I believe that it is "14.04.2 LTS"

-Hazen


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Comprehensive testing reports

[Hazen Babcock]

On 04/12/2015 08:23 AM, Alan W. Irwin wrote:




Why do you think these Qt components fail in the tests, but work fine
if they are run independently? What is the testing framework doing
that is not being done from the command line?


My guess is nothing explictly different is being done.  Instead, you
are dealing with a severe memory management issue which can sometimes
(by accident) be symptomless and sometimes can result in segfaults. So
segfaults typically imply severe memory management issues, but the
converse is not always true. The only completely reliable way I know
of to identify severe memory management issues is using valgrind to
run the examples.  If such a valgrind run (say on examples/c/x00c -dev
pngwidget -o test.png -fam) shows severe memory management issues,
then the Qt libraries on Lubuntu are the likely source of this issue.
However, if that valgrind run shows no severe memory management issue,
but you are getting segfaults on the x00 example with ctest (either
run by hand after running "make all" or via the script), then that
would be a strong indication that there is something wrong with either
our ctest setup or our script.


I've attached my some lubuntu valgrind results for pngqt vs pngcairo.

valgrind ./x00c -dev pngqt -o test.png -fam >& png_qt.txt
valgrind ./x00c -dev pngcairo -o test.png -fam >& png_cairo.txt

Severe memory management issues means errors greater than 0 in the final 
ERROR SUMMARY line? Anyway, it looks like there is some problem with Qt 
and QGtkStyle on lubuntu.


-Hazen

==9344== Memcheck, a memory error detector
==9344== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==9344== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==9344== Command: ./x00c -dev pngcairo -o test.png -fam
==9344== 
==9344== 
==9344== HEAP SUMMARY:
==9344== in use at exit: 650,449 bytes in 5,319 blocks
==9344==   total heap usage: 13,519 allocs, 8,200 frees, 4,891,435 bytes 
allocated
==9344== 
==9344== LEAK SUMMARY:
==9344==definitely lost: 2,904 bytes in 6 blocks
==9344==indirectly lost: 13,822 bytes in 564 blocks
==9344==  possibly lost: 5,262 bytes in 97 blocks
==9344==still reachable: 627,349 bytes in 4,646 blocks
==9344== suppressed: 0 bytes in 0 blocks
==9344== Rerun with --leak-check=full to see details of leaked memory
==9344== 
==9344== For counts of detected and suppressed errors, rerun with: -v
==9344== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==9340== Memcheck, a memory error detector
==9340== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==9340== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==9340== Command: ./x00c -dev pngqt -o test.png -fam
==9340== 
==9340== Invalid read of size 4
==9340==at 0x74404DB: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==9340==by 0x7424D60: QGtkStyle::QGtkStyle() (in 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==9340==by 0x73AF570: QStyleFactory::create(QString const&) (in 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==9340==by 0x70C2560: QApplication::style() (in 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==9340==by 0x70C2954: QApplicationPrivate::initialize() (in 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==9340==by 0x70C2A7F: QApplicationPrivate::construct(_XDisplay*, unsigned 
long, unsigned long) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==9340==by 0x70C2E18: QApplication::QApplication(int&, char**, bool, int) 
(in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==9340==by 0x6A95037: initQtApp(bool) (in 
/home/hbabcock/Code/plplot-build/drivers/qt.so)
==9340==by 0x6A952DC: plD_init_rasterqt(PLStream*) (in 
/home/hbabcock/Code/plplot-build/drivers/qt.so)
==9340==by 0x4E58E8A: plP_init (in 
/home/hbabcock/Code/plplot-build/src/libplplot.so.13.0.1)
==9340==by 0x4E5E494: c_plinit (in 
/home/hbabcock/Code/plplot-build/src/libplplot.so.13.0.1)
==9340==by 0x400AE1: main (in 
/home/hbabcock/Code/plplot-build/examples/c/x00c)
==9340==  Address 0x13d0d048 is 8 bytes inside a block of size 10 alloc'd
==9340==at 0x4C2AB80: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9340==by 0x514C839: strdup (strdup.c:42)
==9340==by 0x74404B8: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==9340==by 0x7424D60: QGtkStyle::QGtkStyle() (in 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==9340==by 0x73AF570: QStyleFactory::create(QString const&) (in 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==9340==by 0x70C2560: QApplication::style() (in 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==9340==by 0x70C2954: QApplicationPrivate::initialize() (in 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==9340==by 0x70C2A7F: QApplicationPrivate::construct(_XDisplay*, unsigned 
long, unsigned long) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6)
==9340==by 0x70C2E18: QApplication::QApplication(int&, char**, bool, int) 

Re: [Plplot-devel] Release status: call for comprehensive testing

[Hazen Babcock]

On 04/10/2015 09:06 PM, Alan W. Irwin wrote:
> On 2015-04-10 12:29-0400 Hazen Babcock wrote:
>
>>>
>>> That's a fairly sparse but still acceptable comprehensive test result
>>> for
>>> this release, but to start the next release cycle properly I strongly
>>> encourage everybody here to learn to run the
>>> scripts/comprehensive_test.sh bash script to completion on all
>>> platforms accessible to you (taking the approach that you should
>>> disable any PLplot component that has errors in order to get the
>>> script to complete).  Such tests are encouraged for essentially all
>>> platforms (e.g, MSVC, Cygwin, MinGW/MSYS, MinGW-w64/MSYS2, Mac OS X,
>>> all varieties of Linux distributions, and other Unices).
>>
>> I just tried to run the non-interactive comprehensive tests on lubuntu
>> without success. Perhaps it is because I'm not running the tests
>> properly? The QT devices that are causing the problems work fine if I
>> run them by hand. I looked on the sourceforge wiki but I could not
>> find and instructions on how to do this. Attached is what I tried and
>> the results of the test.
>
> Hi Hazen:
>
> Thanks for helping out with comprehensive testing.
>
> To answer your question, you should look at
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/> in general and
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Comprehensive%20testing>
>
> and
> https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
> in specific for directions and results concerning comprehensive testing.
>
> The script results require no special setup other than what you do for
> your hand-crafted builds.  Greg had similar problems (but on the
> OpenSUSE platform) with segfaults for all Qt related ctest results.
>
> I suspect these severe memory management issues (which sometimes but
> not always will generate segfaults like you and Greg have seen) have
> nothing to do with PLplot but are instead due to bad Qt libraries or
> bad Qt library dependencies on some platforms. In contrast to your
> result and Greg's I have looked hard at qt results with valgrind on
> Debian stable, and they have no severe memory management issues with
> Qt4.8, and I think Andrew has done the same for his various Debian and
> Ubuntu platforms.  Andrew and I do have different severe memory
> management results for the Qt5 case; I get them with the epa_build of
> Qt5, and he does not for several different distros.  But Qt4 has
> always been completely reliable in this regard for us _for the
> platforms we have access to_.  But this is obviously not the case for
> you and Greg.
>
> Anyhow, for now we are just trying to keep track of exactly which
> platforms have good qt results with Qt4.8 and which do not.  However, we
> are
> also interested in exactly which components of PLplot work for all our
> different major configurations (shared libraries/dynamic devices,
> shared libraries/non-dynamic devices, and static libraries/non-dynamic
> devices. Thus, please try to get the script to finish
> with components removed that are giving trouble.  (I gave that same
> advice to Greg).
>
> So, for example, to
> drop everything Qt related you should specify
>
> --cmake_added_options "DEFAULT_NO_QT_DEVICES=ON -DENABLE_qt=OFF"
>
> when attempting to run scripts/comprehensive_testing.sh again.
>
> Once you get that script to complete, we will note in the
> corresponding report on the Wiki exactly which components had to be
> dropped and why.

It worked fine without the Qt components. Is there an output file that I 
should send?

Why do you think these Qt components fail in the tests, but work fine if 
they are run independently? What is the testing framework doing that is 
not being done from the command line?

-Hazen

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Hazen Babcock]

On 04/10/2015 04:54 PM, Andrew Ross wrote:
>
> Hazen,
>
> That's interesting, and at odds with my tests a week or so back on Kubuntu
> 14.10. Can you confirm which flavour and version of Ubuntu you are using?
> Also, I assume this is with Qt4 and not Qt5?
>

Andrew,

This is what I have:
hb ~$ uname -a
Linux hbabcock-laptop2 3.13.0-49-generic #81-Ubuntu SMP Tue Mar 24 
19:29:48 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

hb ~$ qmake --version
QMake version 2.01a
Using Qt version 4.8.6 in /usr/lib/x86_64-linux-gnu

-Hazen


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Version 6: text rendering

[Hazen Babcock]

On 03/21/2015 05:51 PM, Jim Dishaw wrote:
>
>> On Mar 21, 2015, at 1:48 PM, Hazen Babcock  wrote:
>>
>> On 03/20/2015 05:35 PM, Jim Dishaw wrote:
>>>>
>>>> In sum, the technical choice is between the alt approach which
>>>> requires already implemented code in the core with simpler code in the
>>>> unicode-aware drivers and the original approach which allows us to
>>>> drop core code at the expense of more duplicated and more complex text
>>>> processing code in the unicode-aware drivers. And you can use cairo.c
>>>> as a prototype to estimate the driver code savings/simplifications
>>>> that would appear for the non-cairo devices in the alt case.
>>>
>>> I'm actually a fan of both approaches and don't see a pressing need to 
>>> remove either one. The biggest change I would make is to unify the string 
>>> tokenizer. Some cleanup is needed in the Cairo driver because there is a 
>>> lot of unnecessary overhead when handling strings.
>>
>> Sorry, I'm not sure what you mean when you say "unify the string tokenizer". 
>> Do you mean in PLplot core? The drivers should all use a common string 
>> tokenizer? Or something else? I was trying to create what I thought of as a 
>> common string tokenizer with the alt_unicode text pathway, but I don't think 
>> that it worked out that well. I'd like to understand better what you propose.
>>
>
> Both Unicode paths have duplicated the code that converts format strings 
> (e.g. Escape characters) to Unicode. I think it would be more maintainable if 
> we could have one function that does the conversion.  I'm trying to think of 
> a good way to call the appropriate escape functions.
>

How about we replace the alt_unicode path with a "de-tokenizer"? The 
drivers could still parse the string as they do now, but to make the 
text processing logic easier core could provide a function like:

int stringGetNextChar(PLStream *pls, char *a_char, short *is_escape)

which a driver would use like this:

char a_char;
short is_escape;

while(stringGetNextChar(pls, &a_char, &is_escape)){
if(is_escape){
   do something with escape a_char;
}
else{
   do something with a_char;
}
}

This would simplify the proc_str logic in all the drivers and remove a 
lot of unnecessary duplication, which was the goal of the alt_unicode 
path. After constructing the string, core would update pls with the 
necessary information for stringGetNextChar to work.

-Hazen


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Version 6: text rendering

[Hazen Babcock]

On 03/20/2015 05:35 PM, Jim Dishaw wrote:
>>
>> In sum, the technical choice is between the alt approach which
>> requires already implemented code in the core with simpler code in the
>> unicode-aware drivers and the original approach which allows us to
>> drop core code at the expense of more duplicated and more complex text
>> processing code in the unicode-aware drivers. And you can use cairo.c
>> as a prototype to estimate the driver code savings/simplifications
>> that would appear for the non-cairo devices in the alt case.
>>
>
> I'm actually a fan of both approaches and don't see a pressing need to remove 
> either one. The biggest change I would make is to unify the string tokenizer. 
> Some cleanup is needed in the Cairo driver because there is a lot of 
> unnecessary overhead when handling strings.

Sorry, I'm not sure what you mean when you say "unify the string 
tokenizer". Do you mean in PLplot core? The drivers should all use a 
common string tokenizer? Or something else? I was trying to create what 
I thought of as a common string tokenizer with the alt_unicode text 
pathway, but I don't think that it worked out that well. I'd like to 
understand better what you propose.

best,
-Hazen


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Version 6: text rendering

[Hazen Babcock]

On 03/20/2015 03:58 PM, Alan W. Irwin wrote:
> On 2015-03-20 14:31-0400 Jim Dishaw wrote:
>
>>
>> On Mar 20, 2015, at 2:09 PM, "Alan W. Irwin"
>>  wrote:
>>
>>> On 2015-03-20 08:46-0400 Hazen Babcock wrote:
>>>
>>>> 5. Use a library (Freetype?) for rendering text instead of delegating
>>>> this to the driver? The driver would instead be responsible for the
>>>> display of the resulting bitmaps. This would finally solve the problem
>>>> of the text looking slightly different on all the drivers. It would
>>>> also
>>>> make writing new drivers easier as text handling is far and away the
>>>> most difficult thing to implement correctly. Maybe this would not work
>>>> so well with pdf and postscript drivers, so we'd need to preserve the
>>>> driver rendered text option?
>>>
>>> This text rendering approach is too simplified and not what we want at
>>> all. Here is why.
>>
>
>> Having recently dug into the text handling, I think some modest
> changes would be useful.  First, I would cleanup the interface between
> the core and the drivers for freetype and pango.  Second, some code
> refactoring in plcore.c to cleanup the text handling (in particular
> the unicode processing has duplicative code).
>
> To give you some history there, Hazen implemented that
>
> pls->alt_unicode   = 1
>
> alternative for unicode text processing and made that the default for
> the cairo device as a proof of concept that that alternative approach
> worked.  But developers/maintainers of other unicode aware devices did
> not change to his alternate method so he wanted to tear out that
> capability again in the interest of simplicity (like you have asked
> for as well).  However, I convinced him otherwise because I thought
> the lack of change for the other devices was not a reflection on the
> quality of his work/idea for less unicode text processing code in
> drivers but simply due to inertia.  But at this point that inertia
> continues.
>
> So my opinion is we should take the time to truly evaluate which
> approach is best, and if that turns out to be Hazen's alternative
> approach, then start converting all the non-cairo unicode devices to
> that approach with the goal of simplifying their text handling. But if
> it turns out to be the original approach, then we indeed should tear
> out that alternative approach and convert cairo back to the original
> approach (which is easy to do, but not the right thing to do if the
> alternative approach is truly the best one).

Personally I don't like either unicode pathway as they both lead to 
heavy code duplication in the drivers, fiddly driver specific text 
rendering issues that are not always that easy to sort out and the 
sprawl of text rendering across multiple files.

I had forgotten about all the layout issues, etc.., so I agree that 
Freetype as the default is a non-starter, so how about this alternative? 
Unless specifically requested by a driver, text rendering moves to 
PLplot core. The rendering would be handled by looking for the best 
available text rendering option, and then falling back through a series 
of options to the baseline of the hershey fonts. The options might be 
something like this:

1) Is Pango/Cairo available? Use Pango/Cairo to render all the text.
2) Is Qt available? Use Qt to render all the text.
3) Is WxWidgets available? (Though maybe WxWidgets would not work in 
this way?)
4) Is a Windows text layout engine available?
5) Is a OS-X text layout engine available?
6) Is Freetype available?
7) Hershey rendering.

I feel that this would make adding a new drivers a lot simpler and it 
would also concentrate all of the text rendering logic in a single 
place. As a bonus, you would now have nice looking unicode fonts for all 
of the drivers, even ones that don't natively support unicode. One 
problem might be that not all the drivers support rendering bitmaps.

-Hazen


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] OpenGL

[Hazen Babcock]

> From: Norman Goldstein 
>
> I agree, I don't see that plplot would need to spin or in any other way
> manipulate the 3d plots.  It would be up to the programmer to have the
> GL context wrapped in a 3D GL viewer, for example, if that kind of
> functionality is desired.

The big change is that as currently written PLplot itself is doing the 
3D to 2D transformations, then passing the 2D coordinates to the driver, 
so the driver never has access to the original 3D coordinates.

-Hazen


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Version 6?

[Hazen Babcock]

Hello,

Since we are considering a number of changes, such as fixing error 
handling, that would break backwards compatibility anyway I propose that 
we think a bit about all the other things that we might like to change, 
perhaps bringing us to version 6 of PLplot. So, my proposals in no 
particular order:

1. Error handling as has been previously discussed on the list. I 
believe that the standard these days is that the return value of all the 
API functions is either success or some sort of error code. API 
functions that used to return a value would be changed to pass values 
back via a pointer based mechanism.

2. "Do one thing and do it well". PLplot has grown somewhat organically 
over the years and now might be a good time to consider what exactly is 
core (which I think of as just plotting), and what might be better off 
outside of PLplot. This would not necessarily mean just deleting things 
as non-core functionality could instead be moved to auxiliary libraries. 
Two examples:

A. Consider removing the non-plotting related functions from the core 
API. For example, PLplot includes it's own random number generator. I 
know we use this for testing the examples, but this random number 
generator could be moved into a separate auxiliary library that is just 
used for the examples? Another example is that PLplot includes routines 
for command line input of integers and floats. We should take a hard 
look at what is in the API and decide what is truly plotting related and 
what is not.

B. No interactive drivers. I'm not proposing that we just delete them, I 
just feel that the structure is wrong. For example, I think Phil was 
struggling with this a lot when he was working on the wxwidgets driver. 
Things might work better if the "interactive drivers" were instead 
standalone libraries that use PLplot to do graphing, rather than built 
into PLplot core. This way they would also serve as examples of how to 
integrate PLplot into one's own applications, and they could be made 
considerably nicer (with menus, etc.) without effecting PLplot core at 
all. The interactive demos (and other programs that wanted to use them) 
would work by starting the appropriate driver, getting the appropriate 
context from the driver, passing this to PLplot to do the plotting, then 
return control to the driver for interaction, in a fashion similar to 
the way our current ext drivers work. One downside would be that we 
might have to separate the interactive examples from the non-interactive 
examples as they would now work fundamentally differently. Integration 
into environments like octave would also involve some extra steps, you'd 
now have to start your interactive environment of choice, get a plotting 
context and pass this to PLplot for plotting.

4. Use floating point coordinates for drawing operations. I think this 
would simplify things somewhat, at least from a driver perspective as 
there would be no need for the down-scaling that we are currently doing 
to make nice plots with the more modern drivers.

5. Use a library (Freetype?) for rendering text instead of delegating 
this to the driver? The driver would instead be responsible for the 
display of the resulting bitmaps. This would finally solve the problem 
of the text looking slightly different on all the drivers. It would also 
make writing new drivers easier as text handling is far and away the 
most difficult thing to implement correctly. Maybe this would not work 
so well with pdf and postscript drivers, so we'd need to preserve the 
driver rendered text option?

6. Change legend and colorbar API. Sensible defaults would be stored in 
the plstream. You could change these defaults as desired with a few 
different functions rather than rolling everything into a single 
function. This would also make later changes to this part of the API 
less disruptive.

best,
-Hazen


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] OpenGL

[Hazen Babcock]

> From: Norman Goldstein 
>
> Let me know if you would like to discuss sharing the load ...
>
>
>
> On 03/18/2015 02:48 PM, Chris Marshall wrote:
>>
>> Actually it is a work in progress...just slowly.
>>
>> On Mar 18, 2015 12:06 PM, "Norman Goldstein" > > wrote:
>>
>>  What do you think of an OpenGL device, where the user supplies a GL
>>  context, and plplot writes into it with OpenGL primitives -- so,
>>  neither
>>  file-based nor raster-based?  plplot's svg is a non-raster-based,
>>  but is
>>  file-based.

Chris has been interested in this for a while, mostly because it would 
be one of our more OS independent devices as pretty much any OS these 
days supports OpenGL. Ultimately I think it would be similar to the 
Cairo and Qt drivers where you would have a choice of providing (and 
managing) a GL context (extqt, extcairo), or PLplot would do all of this 
for you (qtwidget, xcairo). I'm not sure how far Chris has gotten on 
this project since our last discussion, but we do at least have a 
working outline of the driver including integration into the PLplot 
build system.

I guess I don't foresee spinning 3D plots as this would involve 
extensive changes to PLplot core.

best,
-Hazen


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Hazen Babcock]

On 03/19/2015 03:30 PM, Hazen Babcock wrote:
>> From: Andrew Ross 
>>
>>> The attached patch fixes the memory leak for me. Pressing the close
>>> button
>>> should now behave the same as pressing 'Q', i.e. it will abort the
>>> program and clean up correctly. It looks like this was changed at some
>>> stage in the past, but I don't know why. I guess this would allow a
>>> programme to continue, and to potentially reopen a new xwin window.
>>> If we
>>> want to retain this functionality it will require a bit more thinking
>>> about.
>>
>> Thinking some more about this, I seem to recall the change was made
>> because of interactive bindings. For example, if you are using octave and
>> pressed the close button then the call to plabort would kill your entire
>> octave session which is clearly not desirable. We definitely don't
>> want to
>> apply my patch as is. I need to work through all the tidy up code in
>> xwin.c to check exactly the path that is being followed. The current code
>> is doing the right thing in terms of closing the window and ignoring all
>> further commands to the plplot stream, we just need to ensure that the
>> tidy function is called at the end. A clean way of doing this would be to
>> have multiple levels of stream_closed. 0 = open, 1 = closed, but still
>> need to call tidy, 2 = closed and tidy already called.
>>
>> Only the xwin and cairo drivers set this flag, but it is checked in the
>> core plplot code. I can simply implement this change Alan, but your call
>> whether you want to commit it at this late stage. It should be trivial.
>
> Yes, it was implemented for exactly the reason that you state. I added
> this in September of 2010 (v11159, v11160). I'd appreciate if we did not
> revert to the old behavior which was, in my opinion, very unfriendly.

Sorry for the noise, I see that Andrew has this under control.

-Hazen


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] fixed memory leak plplot-5.10.0 (Andrew Ross)

[Hazen Babcock]

> From: Andrew Ross 
>
>> The attached patch fixes the memory leak for me. Pressing the close button
>> should now behave the same as pressing 'Q', i.e. it will abort the
>> program and clean up correctly. It looks like this was changed at some
>> stage in the past, but I don't know why. I guess this would allow a
>> programme to continue, and to potentially reopen a new xwin window. If we
>> want to retain this functionality it will require a bit more thinking
>> about.
>
> Thinking some more about this, I seem to recall the change was made
> because of interactive bindings. For example, if you are using octave and
> pressed the close button then the call to plabort would kill your entire
> octave session which is clearly not desirable. We definitely don't want to
> apply my patch as is. I need to work through all the tidy up code in
> xwin.c to check exactly the path that is being followed. The current code
> is doing the right thing in terms of closing the window and ignoring all
> further commands to the plplot stream, we just need to ensure that the
> tidy function is called at the end. A clean way of doing this would be to
> have multiple levels of stream_closed. 0 = open, 1 = closed, but still
> need to call tidy, 2 = closed and tidy already called.
>
> Only the xwin and cairo drivers set this flag, but it is checked in the
> core plplot code. I can simply implement this change Alan, but your call
> whether you want to commit it at this late stage. It should be trivial.

Yes, it was implemented for exactly the reason that you state. I added 
this in September of 2010 (v11159, v11160). I'd appreciate if we did not 
revert to the old behavior which was, in my opinion, very unfriendly.

-Hazen


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Fwd: metafiles

[Hazen Babcock]

>>
>> Phil,
>>
>> The problem was that we updated the API and added new functionality that
>> was never included in the metafiles since no-one was supporting it. In
>> the end we took the decision to disable it by default rather than
>> distribute something that didn't work fully. The plrender code is still
>> there in utils/ if you want to take a look. It would be possible to
>> resurrect this is someone was enthusiastic enough.
>>
>> I always had it in the back of my mind to do a complete rewrite to
>> make an object oriented structure storing all the plot information.
>> This would allow complete recreation of a figure, and also allow
>> editing of labels, data, colours etc. My vision was to implement
>> something that would allow creation of proper matlab style graphics
>> in octave, but it would be useful for other things too.
>
> To Andrew and Phil:
>
> I also would strongly encourage some volunteer to do a complete
> rewrite of plmeta and plrender since it is a fundamentally good idea
> to collect all plot data in a compact binary form and dump that form
> to disk to be conveniently rendered later (even years later when new
> devices might be available) by any device driver using plrender.

This is perhaps off-point, but we already have at least 3 drivers that 
can output the complete plot data in a widely accepted, standardized, 
well documented and machine independent form (SVG). This might be better 
than maintaining our own custom binary format file? I could imagine 
solving the wxWidgets problem by using the svg driver to write an svg 
file, then loading it into wxWidgets with something like the wxSVGFileDC 
class.

-Hazen


--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Plplot-devel The current project to upgrade the Fortran interface

[Hazen Babcock]

> From: "Alan W. Irwin" 
> Subject: [Plplot-devel] The current project to upgrade the Fortran
>   interface
> To: Arjen Markus ,  PLplot development list
>   
> Message-ID: 
> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>
> An additional possible goal we have been discussing is whether or not
> to replace the traditional #define  c_ +
> bindings/f95/plstubs.h method with the fortran-iso-c-binding BIND
> method of dealing with Fortran name mangling.  The large advantage of
> this change is it would allow us to get rid of those confusing
> #defines in our primary header file and also get rid of many more name
> complications/obfuscations in bindings/f95/plstubs.h.  The
> disadvantage is BIND was only introduced as part of the Fortran 2003
> standard so the question Arjen is contemplating right now is how wide
> is the support for BIND amongst Fortran compilers.  Between us we have
> tested MSVC and a large number of different flavours of gfortran (for
> Linux, Cygwin, and MinGW/MSYS), and so far so good.

Changing the names in this way would break the cl-plplot Lisp bindings. 
I think it would probably also break at least the following other 
bindings: ada, ocaml, octave and tcl (based on a quick grep for the "c_" 
prefix) as well as the Perl binding. So that might be a large disadvantage..

-Hazen


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] [plplot:plplot] [c77029] - Hazen Babcock: Remove (apparently) unused INCLUDEPATH.

[Hazen Babcock]

On 11/07/2014 01:00 PM, Alan W. Irwin wrote:
> Hi Hazen:
>
> Arguing by analogy with the similar pkg-config case, I don't think
> removing INCLUDEPATH is the correct thing to do in plplotqt.pro (where
> that file is used by qmake to generated compile and link flags for
> users similarly to the way that pkg-config does the same thing from
> information collected in *.pc files).  So I have handled INCLUDEPATH a
> different way in plplotqt.pro(.in). For further discussion see the
> commit message for 03ad89d.  This is my first experience with *.pro
> files so if my analysis of their documentation is incorrect, feel free
> to make further changes.  But regardless of that, please follow up on
> the ToDo item at the end of the commit message (i.e., figure out where
> the best place would be to install plplotqt.pro in the install tree,
> and then implement that installation).

I'm pretty sure that we don't need plplotqt.pro at all. I thought it was 
used during the plplot build process by qmake in order to compile 
libsmokeplplotqt, however as you point out that is not what it's for. 
Since it exists solely for that purpose I don't think it has any 
utility. Other projects that might use our smoke bindings don't need to 
know how to compile this library since it should already be compiled.

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] smoke bindings

[Hazen Babcock]

On 11/05/2014 12:45 PM, Alan W. Irwin wrote:
> On 2014-11-05 12:01-0500 Hazen Babcock wrote:
>
>>> Also, the current log file contains the following:
>>>
>>> plplotqt.h: (96111, 51): Expression expected : ConstructPtr cptr =
>>> qMetaTypeConstructHelper;
>>> plplotqt.h: (96111, 51): Initializer clause expected :
>>> ConstructPtr cptr = qMetaTypeConstructHelper;
>>> plplotqt.h: (96113, 45): Expression expected : DeletePtr dptr =
>>> qMetaTypeDeleteHelper;
>>> plplotqt.h: (96113, 45): Initializer clause expected : DeletePtr
>>> dptr = qMetaTypeDeleteHelper;
>>> plplotqt.h: (96129, 41): Expression expected : SavePtr sptr =
>>> qMetaTypeSaveHelper;
>>
>> Which log are you referring to? I'm not seeing this warning messages.
>
> It appears that smokegen generates the following log file in
> the build tree (at least on my platform):
>
> bindings/qt_gui/smoke/generator.log

Ok, I see that file and I get the same messages. Since it works for what 
I want to do, I'm just going to ignore them.

> If your setup does not create that log file with the above contents,
> maybe the whole thing is an artifact of the really old smokegen
> version I am using from Debian stable.  The smoke-dev-tools package
> that contains the smokegen application has a Debian version number of
> 4:4.8.4-1 which means it corresponds to smoke version 4.8.4.

I think that I have version 4.13.0.

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] smoke bindings

[Hazen Babcock]

On 11/04/2014 09:12 PM, Alan W. Irwin wrote:
> On 2014-11-04 16:35-0500 Hazen Babcock wrote:
>
>>> But if none of the above helps, then the fundamental question you
>>> should ask yourself is whether you also have similar issues for the
>>> hand-crafted smoke bindings you started with.  [...] If not, then I
>>> suggest you look very carefully at the VERBOSE=1 results to see how
>>> our build system is deviating from what you do by hand.
>>
>> Yes, the hand-crafted bindings work. If you are interested, you can
>> read what worked for me (and what I'm trying to duplicate) here:
>> https://github.com/HazenBabcock/cl-plplot/tree/master/commonqt-plot
>
>  From the README.txt file there it appears you put in a symlink to qt.h
>
> As a test I did that locally here as well (to the existing qt.h file in
> the build tree),
> and that change improved the situation!
>
> For example,
>
> nm -a --demangle bindings/qt_gui/smoke/libsmokeplplotqt.so |\
> grep -i pl |\
> wc -l
>
> now shows 52 PLplot-related symbols in the library (compared to 17
> before), and
>
> ldd -r bindings/qt_gui/smoke/libsmokeplplotqt.so
>
> shows no undefined symbols or other issues.
>
> Note, this better result was obtained with the git version of plplotqt.h
>
> software@raven> cat plplotqt.h
> #include "qt.h"
>
> with no extra #defines.
>
> But to me it was incredible that
>
> /usr/bin/smokegen -config /usr/share/smokegen/qt-config.xml \
> -smokeconfig \
> /home/software/plplot/HEAD/plplot.git/bindings/qt_gui/smoke/smokeconfig.xml
> \
> -I"/home/software/plplot/HEAD/plplot.git/bindings/qt_gui/smoke" \
> -I"/home/software/plplot/HEAD/plplot.git/include" \
> -I"/home/software/plplot/HEAD/plplot.git/lib/qsastime" \
> -I"/home/software/plplot/HEAD/plplot.git/lib/nistcd" \
> -I"/home/software/plplot/HEAD/plplot.git/drivers" \
> -I"/home/software/plplot/HEAD/build_dir" \
> -I"/home/software/plplot/HEAD/build_dir/include" -- \
> /home/software/plplot/HEAD/plplot.git/bindings/qt_gui/smoke/plplotqt.h
>
> (the command issued by our build system) cannot find qt.h in
> the "/home/software/plplot/HEAD/plplot.git/include" directory
> specifically mentioned as an -I option.  And (important!) this implies
> none of the above -I options are being honored so your symlink
> workaround is only going to generate an extremely limited result.
>
> I then realized the above was not exactly consistent with the one
> example of a -I option in the above URL which had a space between the
> "-I" and the directory name.  So I tried that form instead, e.g.,
>
> /usr/bin/smokegen -config /usr/share/smokegen/qt-config.xml \
> -smokeconfig \
> /home/software/plplot/HEAD/plplot.git/bindings/qt_gui/smoke/smokeconfig.xml
> \
> -I /home/software/plplot/HEAD/plplot.git/bindings/qt_gui/smoke \
> -I /home/software/plplot/HEAD/plplot.git/include \
> -I /home/software/plplot/HEAD/plplot.git/lib/qsastime \
> -I /home/software/plplot/HEAD/plplot.git/lib/nistcd \
> -I /home/software/plplot/HEAD/plplot.git/drivers \
> -I /home/software/plplot/HEAD/build_dir \
> -I /home/software/plplot/HEAD/build_dir/include -- \
> /home/software/plplot/HEAD/plplot.git/bindings/qt_gui/smoke/plplotqt.h
>
> without the symlink and the result was a much larger number (263) of
> symbols than the 52 found above or 17 found previously with the
> combination of just the symlink and the ignore (no-space) -I options.  So
> it appears the symlink method has been quite limited in what it can
> do, and the above is much more complete (and also passes the ldd -r
> test).
>
> I have committed (commit ids 2b3f9c2 and 0904d30) that build system fix,
> and I look
> forward to some follow up from you.

Thanks! It works for me now too.

> For example, you should look over the smokegen-generated source code
> to see if some of the above -I options are dragging in too much.
> If
> some of them should be removed, then all you have to do is remove the
> corresponding directory name in the include_directories_LIST variable.
>
> Note the latest version of the CMake logic which now means any change
> to that list is done consistently for not only smokegen but also the
> -I options used to build from those generated sources.
>
> Also, the current log file contains the following:
>
> plplotqt.h: (96111, 51): Expression expected : ConstructPtr cptr =
> qMetaTypeConstructHelper;
> plplotqt.h: (96111, 51): Initializer clause expected :
> ConstructPtr cptr = qMetaTypeConstructHelper;
> plplotqt.h: (96113, 45): Expression expected : DeletePtr dptr =
> qMetaTypeDeleteHelper;
&g

Re: [Plplot-devel] smoke bindings

[Hazen Babcock]

On 11/03/2014 02:46 PM, Alan W. Irwin wrote:
> On 2014-11-03 07:40-0500 Hazen Babcock wrote:
>
>>
>> Hi Alan,
>>
>> Returning to this old topic. Thank you for this fix which also enables
>> me to also compile the smoke bindings. Unfortunately however they are
>> "empty" in the sense that they contain no symbols specifically related
>> to PLplot. I was expecting to see symbols containing QtPLDriver,
>> QtPLWidget and QtExtWidget. You can verify this by running:
>>
>> nm -gC libsmokeplplotqt.so
>>
>> It appears to me as though what is happening is that smoke is parsing
>> the include/qt.h file in an environment where PLD_qtwidget and
>> PLD_extqt widget are not defined. I'm not sure why this is happening
>> since these qt devices are getting built. As I had done in a different
>> project, I tried to define these in bindings/qt_gui/smoke/plplotqt.h,
>> but now they are either being ignored or over-written during the build.
>>
>>> more plplotqt.h
>> #define PLD_qtwidget
>> #define PLD_extqt
>> #include "qt.h"
>
> This fixup should have absolutely no effect since qt.h #includes
> plDevs.h which overwrites the above macros.  On the other hand, on my
> platform at least both PLD_qtwidget and PLD_extqt are #defined in
> plDevs.h (as expected), and that should be the case for you as well.
>
> However, if you want to double check that conclusion, the make
> "VERBOSE=1" result will give you the exact series of commands that
> produce the incorrect result.  To analyze how g++ is interpreting the
> macros, what you need to do is repeat by hand the exact g++ build
> command that compiles the generated source code by cutting and pasting
> with the exception that you use macro debug options that are mentioned
> in
> <http://gcc.gnu.org/onlinedocs/gcc-3.4.5/gcc/Debugging-Options.html>.
>
> It's been a while since I used those, but for both the C and C++
> cases, it looks like (from
> <http://danilogiulianelli.blogspot.ca/2013/01/how-to-inspect-expanded-c-macros-with.html>
>
> the options to be added are -E -dD.  I also recall the (large but
> extremely helpful!) results are dumped in the file mentioned in the -o
> option (which is normally the object file produced, but not in this
> case!).
>
> Once you have convinced yourself with the above that the macros are
> being processed correctly by g++, then the next question is why does
> smokegen seem to be ignoring most of qt.h when it generates code
> (which I confirm below).  Of course, one possibility is that smokegen
> has a bug in how it processes macros so that it does not follow how
> g++ processes them, but more likely there is something wrong with our
> configuration of smokegen by our build system, but more about that
> below.
>
> I was concerned that the -g option might be hiding the symbols from
> you so I ran the smokeplplotqt target as reported above.  The nm
> results on my platform confirm the issue you have reported
>
> software@raven> nm -a --demangle
> bindings/qt_gui/smoke/libsmokeplplotqt.so |grep -i pl
> 002022f8 d .got.plt
> 0f00 t .plt
> 0d08 r .rela.plt
> 1aa0 t __smokeplplotqt::xcall_QGlobalSpace(short, void*,
> Smoke::StackItem*)
> 00202470 b __smokeplplotqt::methodMaps
> 00202430 d __smokeplplotqt::methodNames
> 00202492 b __smokeplplotqt::argumentList
> 00202490 b __smokeplplotqt::inheritanceList
> 00202494 b __smokeplplotqt::ambiguousMethodList
> 11a0 t __smokeplplotqt::cast(void*, short, short)
> 00202480 b __smokeplplotqt::types
> 002023e0 d __smokeplplotqt::classes
> 00202462 b __smokeplplotqt::methods
> 00202440 b completed.6092
> 11b0 t delete_plplotqt_Smoke
> 11c0 t init_plplotqt_Smoke
> 00202450 b plplotqt_Smoke
>
> For the VERBOSE=1 case, the messages issued by the
> smokegen command are the following:
>
> using generator "/usr/bin/../lib/smokegen/generator_smoke.so" parsing
> "/home/software/plplot/HEAD/plplot.git/bindings/qt_gui/smoke/plplotqt.h"
> QIODevice::setTextModeEnabled: The device is not open
> Generating SMOKE sources... preparing SMOKE data [plplotqt]
> writing out smokedata.cpp [plplotqt]
> writing out x_*.cpp [plplotqt]
> Done.
>
> The above "device is not open" message seems a bit suspicious.
>
> Also, in bindings/qt_gui/smoke in the build tree smokegen
> generates the file generator.log which contains the following
> line:
>
> plplotqt.h: (3, 0): Unexpected token 'K_DCOP' :
>
> This seems a bit suspi

Re: [Plplot-devel] smoke bindings

[Hazen Babcock]

On 08/28/2014 11:54 PM, Alan W. Irwin wrote:
>
> To take up this old topic again, the above speculation turned out to be
> the issue which
> was extremely easy to fix (commits 022a53b and b6e9afe).
>
> To test this build fix for yourself, use the cmake option
> -DENABLE_smoke=ON (which I currently have defaulted to OFF for the
> build system since this smoke binding should be considered
> experimental until we install at least one run-time test, see below).
>
> Then run
>
> make VERBOSE=1 smokeplplotqt >& smokeplplotqt.out
>
> and all should be well (at least it was for me).
>
> One test I did was
>
> ldd -r bindings/qt_gui/smoke/libsmokeplplotqt.so 2>&1 |less
>
> which showed no undefined symbols.  (Without commit b6e9afe there
> are such undefined symbols).
>
> Please follow up by pushing at least one example that uses this smoke
> binding of libplplotqt so we have a test that this binding actually
> works at run time.

Hi Alan,

Returning to this old topic. Thank you for this fix which also enables 
me to also compile the smoke bindings. Unfortunately however they are 
"empty" in the sense that they contain no symbols specifically related 
to PLplot. I was expecting to see symbols containing QtPLDriver, 
QtPLWidget and QtExtWidget. You can verify this by running:

nm -gC libsmokeplplotqt.so

It appears to me as though what is happening is that smoke is parsing 
the include/qt.h file in an environment where PLD_qtwidget and PLD_extqt 
widget are not defined. I'm not sure why this is happening since these 
qt devices are getting built. As I had done in a different project, I 
tried to define these in bindings/qt_gui/smoke/plplotqt.h, but now they 
are either being ignored or over-written during the build.

 > more plplotqt.h
#define PLD_qtwidget
#define PLD_extqt
#include "qt.h"

Any thoughts on how to proceed?

Thank you,
-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Exit calls and memory management

[Hazen Babcock]

On 9/22/2014 3:37 PM, Alan W. Irwin wrote:
> On 2014-09-22 12:08-0400 Hazen Babcock wrote:
>
>> I think creating a branch on github (or some other public repository) is
>> the only way that you can proceed if you want others to see what you are
>> doing. Though not perhaps ideal, you should be able to rebase master off
>> a public branch.
>
> Since our advice to Phil is completely contradictory, we should get
> this important question of workflow decided for the case of
> experimental topic development work (as opposed to the workflow for
> our more usual less controversial topic development which is normally
> pushed to origin master as soon as the changes by a developer pass his
> own tests).  And once the workflow for this special case of
> experimental development topics is decided, we should document it in
> README.developers.
>
> You are much more experienced with git than me.  However, I thought
> that rebasing a public branch was always a bad idea for the reasons I
> mentioned concerning disappearing commits.  I am positive a number of
> resources I read when we were considering using a rebase workflow
> mentioned this drawback to that approach.
>
> Were those resources overstating the case?

Probably not. However I don't really see a problem with someone pushing 
a private branch of PLplot to a public repo and asking others to have a 
look and make suggestions, as long as everyone else understands that it 
is "read only". Actual collaboration on a branch is going to more 
complicated and I have no experience in this area using a rebase 
workflow. Exchanging patches sound like as good as an approach as any.

-Hazen


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Exit calls and memory management

[Hazen Babcock]

> Message: 5
> Date: Mon, 22 Sep 2014 15:17:36 +0100
> From: Phil Rosenberg 
> Subject: [Plplot-devel] Exit calls and memory management
> To: PLplot development list 
> Message-ID: <218078.55503...@smtp115.mail.ir2.yahoo.com>
> Content-Type: text/plain; charset="windows-1252"
>
> This one is mostly directed at Alan but probably others will be interested 
> and may have comments. Git might also be a big help here, but I'm not sure 
> how it will work so advice from all appreciated.
>
> I have been trying to improve memory management in plplot as part of my 
> attempt to try to remove exit calls. To do this I am removing raw pointer 
> arrays and replacing them with a struct which will give us more object 
> oriented access to memory allocation. I think this will be a generally good 
> thing as the struct can have function pointers which will allow trivial 
> resizing and adding elements. It will also be extendible, to allow further 
> functionality similar to std::vector if we want. Arrays will also know their 
> own size.
>
> However the cost is that arrays in the plstream will all become structs so 
> will need accessing by somearray.mem[index] or maybe 
> somearray.getMem()[index] rather than somearray[index]. This has the 
> potential to break some or all the drivers. Although the fixes might be 
> trivial, I don't have easy access to all the drivers on my windows machine.
>
> I'm therefore looking for a suggestion of how to proceed. I can transfer 
> stuff to my Linux machine, but I'm not sure how best to do that with git. I 
> could create a fork on github so other developers can contribute, but if I 
> create a public fork then we should merge that into the master branch rather 
> than rebase it which I think is not compliant with our current workflow.

I think creating a branch on github (or some other public repository) is 
the only way that you can proceed if you want others to see what you are 
doing. Though not perhaps ideal, you should be able to rebase master off 
a public branch.

If you are interested, Hez or I could add you to the PLplot organization 
on github. Then you could push your branch there. We haven't done 
anything with it yet, so you'll have to create a the repository first.

https://github.com/PLplot

-Hazen


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] git blog

[Hazen Babcock]

> 
> Remember the three file status's (unstaged, staged, and committed)
> that are emphasized so much by the Pro Git book?
> 
> Intellectually I know these distinctions are important, but they still
> caught me by suprise today.  It turns out that both unstaged and
> staged git changes persist between different branch checkouts.  So I
> wasn't paying enough attention to which branch I was on when I looked
> at git status results.  My eyes skipped over that extremely important
> line in the output about the branch, and I saw there was a subset of
> the unstaged changes that I wanted to stage (with git add) and commit.
> So I did that.  The result (much to my surprise and chagrin) was the
> commit was made on the master branch rather than the desired topic
> branch.  This all happened after I had done a similar add and commit
> for a different subset of my changes on the topic branch. The net
> result was a merge from topic branch to master could not be a ff-only
> merge as demanded by our workflow given in README.developers.  I got
> out of that mess by rebasing my topic branch with master then ff-only
> merging my topic branch onto master to continue to maintain a linear
> history for master locally and also for our SF repo when I pushed that
> result.
> 
> In conclusion, to reduce such screwups for yourself, pay close
> attention to the part of "git status" output that identifies the
> branch you have checked out when you are deciding which subset of your
> changes indicated by "git status" you want to add (stage) and commit. 
> If such "wrong branch" commits like above do occur, "git log --oneline
> -5" (or whatever number of commits you need to track back to find the
> common origin commit of master and topic branches) for your master and
> topic branches will help you figure out the mess.  In no case should
> you ever do anything but a ff-only merge with our adopted git workflow
> that is documented in README.developers.

If you have not done this, I would recommend configuring your command prompt so 
it shows the current git branch when you are in git version controlled 
directory. Then you will always know what branch you are on:

www.developerzen.com/2011/01/10/show-the-current-git-branch-in-your-command-prompt/

-Hazen


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Fwd: Re: [Plplot-core] git conversion status

[Hazen Babcock]

On 8/24/2014 9:30 PM, Alan W. Irwin wrote:
>
> DONE.  See 6c81eb2.
>
> The files are called
>
> historical_repository_conversions/README_cvs2svn_conversion
> historical_repository_conversions/README_svn2git_conversion
> historical_repository_conversions/authors.txt
> historical_repository_conversions/diff_git_versus_svn_tree.sh
> historical_repository_conversions/plplot.rules
> historical_repository_conversions/svn_tag2git_tag.sh
>
> In response to your request, the first one contains the overview of the
> cvs2svn conversion
> as gleaned from relevant plplot-devel posts in 2007.
>
> Once you do the branch removal we discussed, you should append a
> corresponding section to that second file describing what you did and
> how branches can be resurrected if needed.

The branches have been replaced with tags and are now gone from the SF 
site. I updated the README_svn2git_conversion file.

-Hazen


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Your recent update to README.developers concerning workflow

[Hazen Babcock]

> From: Arjen Markus 
> Subject: Re: [Plplot-devel] Your recent update to README.developers
>   concerning workflow
> To: PLplot development list 
> Message-ID:
>   <8CF085736108634681FD03EC36E6A0720E6A4FC7@V-EXC-C02.DIRECTORY.INTRA>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi everyone,
>
>
>
> I am trying to push some small changes onto the official repository, using 
> the workflow as documented in the README, but for some reason it fails:
>
>
>
> D:\plplot-svn\plplot-plplot [master]> git push --dry-run origin master
>
> fatal: Could not read from remote repository.
>
>
>
> Please make sure you have the correct access rights
>
> and the repository exists.
>

I think the problem is that you have the wrong repo URL. You need to 
first log in to the SF site and then use the new URL that you see called 
"developer access" or something instead of "read only access". You can 
change the URL or add another remote with the "git remote" command. I've 
no idea why they choose to make this strange distinction, it is not 
intrinsic to git.

-Hazen


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] README suggestion

[Hazen Babcock]

On 8/28/2014 11:24 AM, Alan W. Irwin wrote:
> On 2014-08-25 12:54-0700 Alan W. Irwin wrote:
>
>> On 2014-08-13 10:28-0400 Hazen Babcock wrote:
>>
>>> 1. Like github, SF is displaying the README.txt file. This appears to
>>> have last been modified in 2007. Maybe this should be the same as
>>> README.release? Or maybe it should be updated?
>>
>> Thanks for this suggestion. I ultimately decided to update the README
>> file based on the content of our website.  But when re-reading our
>> website content in preparation for that change I found some areas of
>> www/index.php, www/downloads.php, etc., that needed reorganizing and
>> rewording.  So this has turned into a substantially larger effort than
>> I originally estimated, but I hope to finish the update of the website
>> content and corresponding README file later today.
>
> My README and website changes have been pushed as of d5b1568, and the
> corresponding changes to the website have been uploaded.  Please take
> a critical look at README and http://plplot.sourceforge.net and
> http://plplot.sourceforge.net/downloads.php (where most of the website
> changes occurred) in case you spot any additional changes that should
> be done.

Overall it looks good to me.

In the README file, should I be able to click on the links when viewed here?
http://sourceforge.net/p/plplot/plplot/ci/master/tree/

-Hazen


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Your recent update to README.developers concerning workflow

[Hazen Babcock]

On 8/27/2014 12:09 AM, Alan W. Irwin wrote:
> Here are some questions concerning git capabilities and
> our current workflow that you have documented in README.developers.
>
> Do you think it would be a good idea to change all the "git merge"
> commands in your workflow documentation to use the --ff-only option?
> That is use
>
> git merge --ff-only origin/master
>
> early in your workflow documentation and
>
> git merge --ff-only new_branch
>
> later in that documentation?

I added this.

> And if you like that idea, is there a better way to implement ff-only
> (say with a git config option that applies just to our repo)?

And this, thanks for the suggestions.

-Hazen


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Fwd: Re: [Plplot-core] git conversion status

[Hazen Babcock]

On 8/24/2014 9:30 PM, Alan W. Irwin wrote:
> On 2014-08-17 07:56-0400 Hazen Babcock wrote:
>>
>> This is fine with me. Perhaps the directory should be called something
>> like "historical" and "vcs_conversions", and you could include what
>> was done for the CVS to SVN conversion as well?
>
> DONE.  See 6c81eb2.
>
> The files are called
>
> historical_repository_conversions/README_cvs2svn_conversion
> historical_repository_conversions/README_svn2git_conversion
> historical_repository_conversions/authors.txt
> historical_repository_conversions/diff_git_versus_svn_tree.sh
> historical_repository_conversions/plplot.rules
> historical_repository_conversions/svn_tag2git_tag.sh
>
> In response to your request, the first one contains the overview of the
> cvs2svn conversion
> as gleaned from relevant plplot-devel posts in 2007.

Thank you.

> Once you do the branch removal we discussed, you should append a
> corresponding section to that second file describing what you did and
> how branches can be resurrected if needed.

Ok. I hope to have some time for this in the coming week.

-Hazen



--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Fwd: Re: [Plplot-core] git conversion status

[Hazen Babcock]

On 8/21/2014 8:48 PM, Alan W. Irwin wrote:
> So we were all in agreement that storage (in a file) of the SHA1 id of
> the HEAD commits from each branch to be deleted would be enough to
> guarantee branch resurrection, but it turns out that is incorrect.
> Further reading shows that git automatically garbage collects
> (deletes) all "unreachable" commits after a suitable default period
> (usually 90 days, I think).  So there are lots of warnings in the
> results for google searching for the terms  that
> the techniques only work for a while until garbage collection occurs.

Hm, that is my take on this as well. I agree that if we want to preserve 
the branches then we'll need to tag them. Buried in the comments to the 
first answer to this question is an explanation of how to push the tags 
to the remote repository:

http://stackoverflow.com/questions/2342821/git-branch-deletion

If you are really worried about history preservation then you should 
also implement a server side hook to prevent tag deletion.

-Hazen


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Hazen Babcock]

>
> @Everybody:
> Instead of writing a rebase workflow document myself that we could
> use, I have been looking for something like that written by someone
> else. What do you think of adopting (the quite restrictive) rebase
> workflow outlined in
>  to start?  No
> integration branches other than master.  No published topic branches.
> But dead simple and very much like our previous svn-based workflow.

Looks good to me. I think we should at least make a copy in the project, 
which I volunteer to do once we can commit again.  I'll update 
README.developers unless someone thinks this is better somewhere else.

Also, we need to update our web-page to point to the git repository and 
not the svn repository.

-Hazen


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Hazen Babcock]

Correcting the subject line..

On 8/20/2014 11:29 AM, Hazen Babcock wrote:
> On 8/20/2014 5:51 AM, plplot-devel-requ...@lists.sourceforge.net wrote:
>> Date: Tue, 19 Aug 2014 12:24:54 -0700 (PDT)
>> From: "Alan W. Irwin" 
>
> ..
>
>> In sum, I think rebase-only is not only back on the table for our
>> initial workflow model due to Brad's recommendation of it for that
>> purpose but also likely the final choice (enforced by server-side
>> update hook logic at push time as recommended by Brad).
>
> I'm also ok with rebase only, at least to start. I think it should work
> well enough as the project is not super active so we should not have too
> many problems with "racing to commit". I agree with Phil that this will
> mean that there is only a master branch.
>
> One project that has taken this approach is SBCL:
> http://www.sbcl.org/
>
> Thoughtfully they provide the hook that they use to enforce rebase only
> on their master branch:
> http://sourceforge.net/p/sbcl/sbcl-git-hooks/ci/master/tree/update
>
> -Hazen
>


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Plplot-devel Digest, Vol 99, Issue 16

[Hazen Babcock]

On 8/20/2014 5:51 AM, plplot-devel-requ...@lists.sourceforge.net wrote:
> Date: Tue, 19 Aug 2014 12:24:54 -0700 (PDT)
> From: "Alan W. Irwin" 

..

> In sum, I think rebase-only is not only back on the table for our
> initial workflow model due to Brad's recommendation of it for that
> purpose but also likely the final choice (enforced by server-side
> update hook logic at push time as recommended by Brad).

I'm also ok with rebase only, at least to start. I think it should work 
well enough as the project is not super active so we should not have too 
many problems with "racing to commit". I agree with Phil that this will 
mean that there is only a master branch.

One project that has taken this approach is SBCL:
http://www.sbcl.org/

Thoughtfully they provide the hook that they use to enforce rebase only 
on their master branch:
http://sourceforge.net/p/sbcl/sbcl-git-hooks/ci/master/tree/update

-Hazen


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Fwd: Re: [Plplot-core] git conversion status

[Hazen Babcock]

On 8/17/2014 2:41 AM, Alan W. Irwin wrote:
> On 2014-08-16 22:37-0400 Hazen Babcock wrote:
>>
>> "git reflog doesn't traverse HEAD's ancestry at all. The reflog is an
>> ordered list of the commits that HEAD has pointed to: it's undo
>> history for your repo. The reflog isn't part of the repo itself (it's
>> stored separately to the commits themselves) and isn't included in
>> pushes, fetches or clones; it's purely local."
>
> Thanks for looking further at reflog, but local doesn't sound like what
> I want
> since that would be a single point of failure (e.g., if I am keeping
> this information on my local disk repo, that disk could fail), and
> nobody could access that information other than me.

Now I'm confused, I thought you were against deleting branches in the SF 
repo because you were worried that some variant of the git reflog 
command would cause them to disappear forever from any and all records 
in the SF repo? I was responding specifically to your statement:

"That method does not seem fool-proof.  See the expire subcommand for 
"git reflog"."

If you agree that git reflog is local then perhaps you could what other 
sequence of commands might lead to such a permanent loss of history? Or 
maybe you meant that once the branch is gone you might not be able to 
figure out from the log which SHA corresponded to the head of that 
particular branch? I agree that this could be difficult. Anyway I'm Ok 
with your proposed solution, see below.

> Remember, my basic motivation is to allow access to our history by
> anybody that is interested in the future.  Therefore, I far prefer to
> store the information in a file in the repo since that file is
> available to everyone, automatically backed up by everyone cloning it,
> and even in the unlikely event someone deletes that file in error you
> can still restore it from finding the parent of the associated commit
> in the log that deleted that file.  (For git newbies here, see
> <http://stackoverflow.com/questions/953481/restore-a-deleted-file-in-a-git-repo>.)
>
>
> To make this file proposal concrete, I am suggesting storing the file
> in PLplot_repo_information/README_svn2git_conversion (a directory and
> name that are unlikely to be deleted by accident by anyone) that
> states the commands we used to do the conversion and test it (the
> contents of the AWIREADME file I sent you plus additional
> documentation of the subversion branches that were converted to git
> and then deleted with explicit instructions on how to resurrect each
> one of them). I think we should also store in that directory the 4
> files we used for the conversion, i.e., the two files used with
> svn-all-fast-export, the convert tags bash script that was sourced,
> and my standalone bash script to test the results in that directory.
> Do you see git (or any other) issues with these ideas?

This is fine with me. Perhaps the directory should be called something 
like "historical" and "vcs_conversions", and you could include what was 
done for the CVS to SVN conversion as well? This would also get things 
ready our conversion to the next great thing in version control system 
in 5-10 years :).

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Hazen Babcock]

On 8/16/2014 1:50 PM, Alan W. Irwin wrote:
> On 2014-08-16 06:50-0400 Hezekiah M. Carty wrote:
>
>> I agree with Hazen here - adding hooks on day one seems overkill for
>> the project.  [...]
>> Given that the project and developers are overall new to git I think
>> it would be premature to start stacking automated restrictions on top
>> of our use of the tool.
>
> That said, I appreciate you and Hazen are anxious to get started with
> git for PLplot after such a long wait, and I also feel similarly even
> though I am pretty much still a git newbie.  So I suggest we should
> jointly review my decision (to not allow push to the official repo
> until we get the required modification of the update hook figured out)
> sometime late next week (say roughly in 6 days from now).  That gives
> enough time to find out if Brad King is willing to share his
> implementation, and also to pursue a lot further the backup plan of
> modifying .git/hooks/update(.sample) appropriately ourselves.

Unfortunately all I can report so far is that I have not had much luck 
with the obvious google searches such as "git hook enforce merge only". 
So while presumably this enforcement is possible, it also seems to be rare.

As an aside, an interesting client-side hook to develop would be one 
that automatically runs uncrustify. I know that I'm not very good about 
doing this manually.

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Fwd: Re: [Plplot-core] git conversion status

[Hazen Babcock]

On 8/13/2014 3:16 PM, Alan W. Irwin wrote:
> On 2014-08-13 10:28-0400 Hazen Babcock wrote:
>
>
> That method does not seem fool-proof.  See the expire subcommand for "git
> reflog". Furthermore, some of the PLplot branches are still active
> (e.g., test_cmake) and useful even though I will likely never want to
> merge that material to the master branch.

I've looked at this a little more and I'm not sure that I fully 
understand the concern. You are worried that someone will run "git 
reflog expire" on the master SF repo?  It is not clear that to me that 
this is even possible. This link would suggest not:

http://stackoverflow.com/questions/17857723/whats-the-difference-between-git-reflog-and-log

"git reflog doesn't traverse HEAD's ancestry at all. The reflog is an 
ordered list of the commits that HEAD has pointed to: it's undo history 
for your repo. The reflog isn't part of the repo itself (it's stored 
separately to the commits themselves) and isn't included in pushes, 
fetches or clones; it's purely local."

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Fwd: Re: [Plplot-core] git conversion status

[Hazen Babcock]

On 8/13/2014 4:38 PM, phil rosenberg wrote:
> The impression I get from reading the docs and the post you linked Alan, is 
> that there is a tendency for people coming from svn to forget that git is a 
> distributed vcs. Perhaps some of these branches would be more at home in the 
> various developers own repositories. I cloned the repository today and 
> already generated two branches - partly to see how it works, but partly 
> because it is so useful to be able to do so.

Yes, I think we have agreed that the only branches in the SF repo should 
be "master", "next" and "release". All the other branches can live on 
cloned repos depending on user preference. If multiple people are going 
to work on them then they should be in a shared but "private" repo, not 
in the SF repo.

> That said, if for example you clone the repository now and continue to 
> develop the cmake_test branch, but that branch gets deleted from the SF 
> repository, does that make it really painful to merge it back in? I have a 
> feeling the answer might be yes but I'm not sure.

The fact that it has been removed from theS F repo should not be an 
issue. I don't think this is really any different from a topic branch 
which never existed in the repo in the first place.

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] exit() calls

[Hazen Babcock]

On 8/14/2014 6:00 PM, Phil Rosenberg wrote:
> Hi Hazen
> The approach of just don't call exit and see what happens was also my first 
> thought. Then the first case i looked at was plscmap0n, which attempts to set 
> the number of colours in cmap0, this is called by plspal0, which immediately 
> assumes the call has succeeded and attempts to assign colours to cmap0. If 
> the malloc call actually failed, then the memory is set to null and we'll get 
> a segfault.

I guess I favor an opt-in rather than the current opt-out strategy for 
plexit(). However it is true that both are going to land you in the same 
place, unless you have a special error handler your program is going to 
crash with a (possibly cryptic) error message.

At this point I agree with you that adding an error flag to the stream 
which the user can check is the way to go. Changing all the functions in 
all the bindings would be extremely disruptive.

Cairo and GTK are C I believe, it might be worth a look to see how they 
handle this.

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Trying to understand how git workflow for CMake is enforced

[Hazen Babcock]

On 8/15/2014 2:53 PM, Alan W. Irwin wrote:
> Hi Hazen:
>
> Earlier today I sent an e-mail to Brad King, the CMake git guru (with
> CC to you to keep you fully informed) asking how they implemented the
> enforcement hooks in their git repo to maintain the desired
> --first-parent properties of the integration branches used in their
> workflow.  Assuming we adopt their workflow, then I think it is
> absolutely essential that we get these enforcement hooks in place
> before proceeding further with PLplot development using git so I think
> it is a good idea to make our SF git repo read-only until this
> implementation issue for our workflow is resolved.  I plan to do that
> later today if you don't have any strong objections.

I object, but not strongly. What is the worst thing that can happen? We 
have to delete the repo and start over? Hooks or no hooks, mistakes are 
going to be made and will have to be dealt with, might as well start 
learning how to do that now.

In Arjen's case he would do the following:

git checkout master
git pull
git checkout -b fix_replot_08_15_2014
..
edit files
..
git add -- files
git commit -m "Fixed width issue in replot."

..
check that the fix works
..

git checkout next
git pull
git merge fix_replot_08_15_2014
git push sf-repo next

The only sticking point would be that we don't yet have a next (or a 
release) branch in our repo..

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] exit() calls

[Hazen Babcock]

>
> Hi All
> I have had the exit() calls in Plplot rolling around in the back of my head 
> for a while. They were brought to the fore, recently when I had some code 
> which generated a lot of plots and displayed them all via wxWidgets - except 
> it didn't. The program exited half way through. It turned out that I ran out 
> of memory and this caused a call to plexit which exited my code without even 
> an unhandled exception error, which is what I usually expect with out of 
> memory problems. Also the move to git has got me excited about doing some 
> work.
>
> Obviously the API functions do not return an error code, but we do have the 
> plserror function which allows us to report errors back to the user. The 
> difficulty however is more internal. If the program runs out of memory, but 
> we allow things to continue, then when attempts are made to access the array 
> then we'll get a segfault or similar crash.
>
> As far as I can see we have two solutions:
> 1) Change all internal functions so they return an error code. If another 
> internal function finds it is passed an error code then in must clean up and 
> return this error code - which passes down the chain. This sounds quite 
> difficult as some functions already return values. Also if an internal 
> function calls an API function we break the chain.
> 2) Add an internalerrorcode variable to PLStream. This is reset to 0 when an 
> API call is made, and if a function generates an error then this code and the 
> user's code) get set and the calling function can check this. The downside 
> here is probably a lot of error checking, but?I don't think this can be 
> helped.
>
> I'm in favour of 2), mostly because I haven't thought of any killer problems 
> like 1). Has anyone got any thoughts before I start working on this?

What fraction of the functions would have to changed for (1)? Glancing 
through the API it seems that only a small fraction of them return a 
value. I would guess that most of the work is going to be doing all the 
error checking, which is likely more or less the same for either (1) or 
(2). I thought (1) was the approach that most libraries used, but 
looking at the Cairo, Gtk, WxWidgets and Qt libraries it appears that 
they do not use either. Qt and WxWidgets probably throw more or less 
meaningful exceptions. I'm not sure what Cairo and GTK would do, maybe 
they just segfault?

How about the minimalist change of just removing the exit() from 
plexit()? Yes the program will continue to run, but a modern OS can 
pretty easily deal with any trouble it is likely to cause. And if the 
user really wants the exit behavior then they can implement it in their 
own exit handler.

-Hazen


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Preferred git workflow

[Hazen Babcock]

On 8/14/2014 4:39 AM, phil rosenberg wrote:
> That workflow seems good to me.
>

It also sounds good to me.

-Hazen



--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Fwd: Re: [Plplot-core] git conversion status

[Hazen Babcock]

Sending this to a wider audience. In short, PLplot is now using git for 
version control.

http://sourceforge.net/p/plplot/plplot/ci/master/tree/

-Hazen

 Original Message 
Subject: Re: [Plplot-core] git conversion status
Date: Tue, 12 Aug 2014 16:24:27 -0400
From: Hazen Babcock 
To: plplot-c...@lists.sourceforge.net

On 8/11/2014 6:47 PM, Hazen Babcock wrote:
>
> If there are no additional commits between today and tomorrow I'll clone
> this to SF and change the SVN repo to read-only.

All set now. Our SVN repository is (or should be) read-only under the
"Old Code" tab. Our new git repository is available under the "Code" tab.

Two initial suggestions:
1. Like github, SF is displaying the README.txt file. This appears to
have last been modified in 2007. Maybe this should be the same as
README.release? Or maybe it should be updated?

2. Clean up the repository by pruning off all the branches. Don't worry
they'll still be there if you really want to look at them (as described
here):

http://stackoverflow.com/questions/3640764/can-i-recover-branch-after-the-deletion-in-git

Many projects that I have seen only have a master branch in their
release repository.

-Hazen


--
___
Plplot-core mailing list
plplot-c...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-core





--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] [PATCH] QColor warning when Qt PlPlot widget is created

[Hazen Babcock]

On 7/11/2014 2:38 PM, Alan W. Irwin wrote:
> On 2014-07-03 12:33+0930 Jonathan Woithe wrote:
>
>> Hi all
>>
>> I have a relatively simple Qt program which utilises the PlPlot Qt widget
>> (QtExtWidget).  QtExtWidget is a component of the main application window
>> and as such is constructed during program startup, prior to the
>> calling of
>> QApplication::exec() and before any GUI elements have been made
>> visible with
>> show().  I have noticed that during program startup I will sometimes
>> get the
>> following warnings:
>>
>>  QColor::setRgb: RGB parameters out of range
>>
>> This doesn't appear all the time and seems to be fairly sensitive to
>> timing,
>> making it difficult to debug.  However, after much trial and error I have
>> determined that the warning is triggered from the QtExtWidget
>> constructor.
>> Further exploration showed it was coming from QtPLWidget's constructor
>> (from which QtExtWidget is derived).
>>
>> Looking at the source of QtPLWidget::QtPLWidget() in plqt.cpp, I
>> noticed a
>> call to QApplication::processEvents() which didn't seem right to me.
>> Commenting this out resolves the warning.  Importantly, the warning
>> remains
>> when any of the other Qt functions (such as resize(), QPen()) are
>> commented
>> out.
>>
>> The reason I'm suspicious of this call is that there is no guarantee that
>> any event loop has even been initialised at the time the constructors are
>> called.  Certainly in my case the event loop isn't running because
>> QApplication::exec() has not yet been called at the time of construction.
>> Similarly, the widget tree is not visible at event creation time, so it
>> seems reasonable that some parts of the GUI environment (such as QColor
>> objects) might not have been allocated yet.  At a fundamental level, I
>> expect that the processEvents() call could be triggering a draw of the as
>> yet incompletely constructed widget.  I also recall reading in the
>> past that
>> draw actions cannot be triggered in constructors due to the incomplete
>> nature of the widget being built.
>>
>> Regardless, I can't think of any reason for calling
>> QApplication::processEvents() in the constructor of a Qt widget.  Does
>> anyone know why this call is being made in QtPLWidget's constructor?
>> Based
>> on tests here and the reasons given above I think it should be
>> removed.  The
>> trivial patch to do this is included at the end of this email.
>>
>> What do others think?
>
> I don't understand Qt that well.  However, my own tests with the
> test_interactive target indicate your change is fine so I have
> committed it (revision 13137) with appropriate commentary to the svn
> trunk version (which will end up as our next release).
>
> @Hazen: I thought I better commit this before it got lost.
> However, as our Qt expert feel free to revert this change, if you
> prefer some different solution.

I'm not sure. If it doesn't break anything I guess it is probably ok. It 
looks like this was added by Andrew Ross in commit #10306 for Alban Rochel.

-Hazen


--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] smoke bindings

[Hazen Babcock]

Hello,

I've just committed (r13136) an initial attempt at creating smoke 
bindings for the qtwidget and extqt drivers.

A description of smoke:
https://techbase.kde.org/Development/Languages/Smoke

Basically smoke makes it easy (or at least easier) to write binding for 
Qt and KDE from scripting languages, or from Lisp, which was why I was 
interested. In our case these binding make it easier to integrate the Qt 
drivers into an existing Qt application that is being developed in 
languages such as Perl, Ruby, C# or Lisp.

However, it does not quite work yet and I would appreciate it if someone 
who is more knowledgeable about cmake could take a look at 
bindings/qt_gui/smoke/CMakeLists.txt and suggest what I might be doing 
wrong. Basically what happens is that the program smokegen parses the 
qt.h file to decide how to create the smoke bindings .cpp files. These 
are then linked to create the smoke bindings library, libsmokeplplotqt. 
The problem that I'm having is that it seems to think that it should use 
float for PLFLT instead of double at the generation stage, but then the 
compiler errors out at the linking stage because it doesn't know how to 
convert float* to double*. If I create the smoke bindings by hand 
against the installed PLplot library as described here:

https://github.com/HazenBabcock/cl-plplot/blob/master/commonqt-plot/README.txt

then everything seems to work fine. My guess is that is because in the 
installed version the question of whether PLFLT will be a float or a 
double has already been resolved.

This is the error message that I'm getting:
Scanning dependencies of target smokeplplotqt
[ 93%] Building CXX object 
bindings/qt_gui/smoke/CMakeFiles/smokeplplotqt.dir/smokedata.cpp.o
[ 95%] Building CXX object 
bindings/qt_gui/smoke/CMakeFiles/smokeplplotqt.dir/x_1.cpp.o
/home/hbabcock/OpenSource/plplot_build/bindings/qt_gui/smoke/x_1.cpp: In 
member function ‘void __smokeplplotqt::x_QtPLDriver::x_10(Smoke::Stack)’:
/home/hbabcock/OpenSource/plplot_build/bindings/qt_gui/smoke/x_1.cpp:103:230: 
error: no matching function for call to 
‘__smokeplplotqt::x_QtPLDriver::setGradient(int, int, int, int, unsigned 
char*, unsigned char*, unsigned char*, float*, int)’
 
this->QtPLDriver::setGradient((int)x[1].s_int,(int)x[2].s_int,(int)x[3].s_int,(int)x[4].s_int,(unsigned
 
char*)x[5].s_class,(unsigned char*)x[6].s_class,(unsigned 
char*)x[7].s_class,(float*)x[8].s_class,(int)x[9].s_int);
 
 
 
  ^
/home/hbabcock/OpenSource/plplot_build/bindings/qt_gui/smoke/x_1.cpp:103:230: 
note: candidate is:
In file included from 
/home/hbabcock/OpenSource/plplot-trunk/bindings/qt_gui/smoke/plplotqt.h:1:0,
  from 
/home/hbabcock/OpenSource/plplot_build/bindings/qt_gui/smoke/x_1.cpp:2:
/home/hbabcock/OpenSource/plplot-trunk/include/qt.h:135:18: note: 
virtual void QtPLDriver::setGradient(int, int, int, int, unsigned char*, 
unsigned char*, unsigned char*, PLFLT*, PLINT)
  virtual void setGradient( int x1, int x2, int y1, int y2,
   ^
/home/hbabcock/OpenSource/plplot-trunk/include/qt.h:135:18: note:   no 
known conversion for argument 8 from ‘float*’ to ‘PLFLT* {aka double*}’
/home/hbabcock/OpenSource/plplot_build/bindings/qt_gui/smoke/x_1.cpp: In 
member function ‘virtual void 
__smokeplplotqt::x_QtPLDriver::setGradient(int, int, int, int, unsigned 
char*, unsigned char*, unsigned char*, float*, int)’:
/home/hbabcock/OpenSource/plplot_build/bindings/qt_gui/smoke/x_1.cpp:323:73: 
error: no matching function for call to 
‘__smokeplplotqt::x_QtPLDriver::setGradient(int&, int&, int&, int&, 
unsigned char*&, unsigned char*&, unsigned char*&, float*&, int&)’
  this->QtPLDriver::setGradient(x1, x2, x3, x4, x5, x6, x7, x8, x9);
  ^
/home/hbabcock/OpenSource/plplot_build/bindings/qt_gui/smoke/x_1.cpp:323:73: 
note: candidate is:
In file included from 
/home/hbabcock/OpenSource/plplot-trunk/bindings/qt_gui/smoke/plplotqt.h:1:0,
  from 
/home/hbabcock/OpenSource/plplot_build/bindings/qt_gui/smoke/x_1.cpp:2:
/home/hbabcock/OpenSource/plplot-trunk/include/qt.h:135:18: note: 
virtual void QtPLDriver::setGradient(int, int, int, int, unsigned char*, 
unsigned char*, unsigned char*, PLFLT*, PLINT)
  virtual void setGradient( int x1, int x2, int y1, int y2,
   ^
/home/hbabcock/OpenSource/plplot-trunk/include/qt.h:135:18: note:   no 
known conversion for argument 8 from ‘float*’ to ‘PLFLT* {aka double*}’
make[2]: *** 
[bindings/qt_gui/smoke/CMakeFiles/smokeplplotqt.dir/x_1.cpp.o] Error 1
make[1]: *** [bindings/qt_gui/smoke/CMakeFiles/smokeplplotqt.dir/all] 
Error 2
make: *** [all] Error 2


You'll have to edit the qt.cmake file to ENABLE_smoke. In addition, on 
debian you need the following packages:
smoke-dev-tools
libsmokeqt4-dev

Thank you,
-Hazen


--
Open source business process 

Re: [Plplot-devel] floating point exception in example 29

[Hazen Babcock]

On 4/7/2014 11:08 PM, Alan W. Irwin wrote:
> I have just had a further idea. For comprehensive testing situations
> it might be good to have the option to call feenableexcept (the C
> library function that you used to help debug x29c.c that should be
> available for c99 according to its Linux man page) from within the
> PLplot library (say as the result of plinit).  If you agree (a) that
> idea would work and (b) it would be useful, would you be willing to
> implement it in C for the case when the PLPLOT_ENABLE_FLOAT_EXCEPT C
> macro is #defined?  If so, I would be willing to do the rest on the
> CMake side (create a CMake option for this and propagate it to the
> corresponding C macro for the compilation of the source file where you
> have implemented the feenableexcept call).

I have tested the idea and it works. I'm not sure about the utility 
though. Based on my tests it already caught the only error in the 
examples that it is going to catch. After the git transition I can 
create a branch that will catch floating point exceptions and you can 
merge it (or not) into the master branch based on your feeling about 
it's utility.

best,
-Hazen


--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] floating point exception in example 29

[Hazen Babcock]

On 4/6/2014 10:16 PM, Alan W. Irwin wrote:
> On 2014-04-06 17:35-0400 Hazen Babcock wrote:
>> In the process of converting some of the PLplot demos to Lisp as part of
>> the cl-plplot project I found that example 29 triggers a floating point
>> exception. This is not something that a C compiler will normally report,
>> but you can make it (or at least gcc) more strict about this. I believe
>> that the problem occurs in the plP_wcpcx() function in src/plcvt.c,
>> where we attempt to convert -3.917103e+15 to an integer resulting in an
>> overflow error.
>
> Obviously, the attempted conversion should generate an integer
> overflow, but I frankly don't understand why it generates a
> _floating-point_ exception since clearly -3.917103e+15 is a valid
> floating-point number.  Do you have some mental model for why there
> was a generated floating-point exception in this case?

Sorry, I did not explain that very well. The exception that is triggered 
is FE_INVALID, which I think in this case is caused by the floating 
point number being too large to convert to an integer.

> That question is just to satisfy my curiosity about how you found the
> issue, and the much more important question is why in the world
> numbers like -3.917103e+15 are being generated by example 29?
>
> One possibility is some variable is unintialized so -3.917103e+15
> is just random numerical garbage, but I checked that possibility
> with valgrind and got the following absolutely clean result:
>
> ==19527== Memcheck, a memory error detector
> ==19527== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et
> al.
> ==19527== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright
> info
> ==19527== Command: examples/c/x29c -dev psc -o test.psc
> ==19527== ==19527== ==19527== HEAP SUMMARY:
> ==19527== in use at exit: 0 bytes in 0 blocks
> ==19527==   total heap usage: 2,481 allocs, 2,481 frees, 351,494 bytes
> allocated
> ==19527== ==19527== All heap blocks were freed -- no leaks are possible
> ==19527== ==19527== For counts of detected and suppressed errors, rerun
> with: -v
> ==19527== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
>
> plcvt.c contains code for converting between various plot coordinate
> systems.  Please indicate what device you are using since that
> should affect some of those transformations.

I tested the xwin, xcairo and qtwidget drivers. They all give slightly 
different numbers but they are all around -4.0e15.

> plP_wcpcx converts world coordinates to physical device
> coordinate using the PLINT value of the following transformation
>
> plsc->wpxoff + plsc->wpxscl * x

The exception is triggered by the value of plsc->wpxoff, which is 
~4.0e15. However plsc->wpxscl is also suspiciously large at ~2.0e12, but 
it gets multiplied by x which is 0.0 in the call that causes the exception.

> where all those values being combined together are PLFLT.
>
> It is hard to figure out how an integer physical device coordinate (e.g.,
> pixels) could correspond to -3.917103e+15 so despite the good valgrind
> result I am still wondering whether you are dealing with numerical
> garbage of some kind.

It looks that way, but I'm not having much luck figuring out where this 
garbage is coming from. The crash occurs on the call to plbox() when 
creating page 5, which is the first page of this example that just shows 
a single step.

-Hazen


--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] floating point exception in example 29

[Hazen Babcock]

Hello,

In the process of converting some of the PLplot demos to Lisp as part of 
the cl-plplot project I found that example 29 triggers a floating point 
exception. This is not something that a C compiler will normally report, 
but you can make it (or at least gcc) more strict about this. I believe 
that the problem occurs in the plP_wcpcx() function in src/plcvt.c, 
where we attempt to convert -3.917103e+15 to an integer resulting in an 
overflow error.

The easiest way to see this is to pull my fe_demo branch from here:
https://github.com/HazenBabcock/PLplot

Or you can look at the two files that I modified to demonstrate this issue:
https://github.com/HazenBabcock/PLplot/blob/fe_demo/examples/c/x29c.c
https://github.com/HazenBabcock/PLplot/blob/fe_demo/src/plcvt.c

-Hazen

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] git (again)

[Hazen Babcock]

On 4/2/2014 4:14 AM, Alan W. Irwin wrote:
> On 2014-02-06 06:27-0500 Hazen Babcock wrote:
>
>> On 2/4/2014 5:05 PM, Alan W. Irwin wrote:
>>>
>>> So Hazen, assuming no other core PLplot developer have questions about
>>> the conversion of the official PLplot repo to git would you be willing
>>> to do that conversion (at SourceForge, see below) after I have
>>> finished my timeephem git evaluation, i.e., roughly April 1st?
>>
>> Yes I am willing to do this.
>
> I haven't forgotten this important topic, but since the release of
> 5.10.0 I have obviously been caught up in a number of PLplot
> development issues. So I have had to substantially delay the serious
> look at git (including converting the timeephem project from svn to
> git) that I had planned for March.  Anyhow, it looks like roughly a
> week or so from now I will finally be able to start that serious look.
> Thus, my latest rough estimate is it will likely be May 1st or so when
> I will finally be in a position to give you the go ahead to convert
> the PLplot svn repository to git.

Hi Alan,

That sounds fine to me.

-Hazen



--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Example 27 missing arcs()?

[Hazen Babcock]

Hello,

It appears that the examples web-page for example 27 is missing the 
final graph, the arcs() demonstration graph.

-Hazen

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] git (again)

[Hazen Babcock]

On 2/4/2014 5:05 PM, Alan W. Irwin wrote:
>
> So Hazen, assuming no other core PLplot developer have questions about
> the conversion of the official PLplot repo to git would you be willing
> to do that conversion (at SourceForge, see below) after I have
> finished my timeephem git evaluation, i.e., roughly April 1st?

Yes I am willing to do this.

-Hazen


--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] git (again)

[Hazen Babcock]

> Date: Wed, 5 Feb 2014 16:01:25 -0700
> From: Jerry 
>>>
>>> Here is a related question.  My understanding from superficial reading
>>> is that git users normally have a local repository (unlike the svn
>>> case where there is normally just one repository).  But if someone is
>>> worried about the disk space that is required by that local git
>>> repository, is there also a detached repository mode for git (i.e., so
>>> the user could simply use the SourceForge repository without copying
>>> all of the repository to his own computer)?
>>
>> This is no longer true? I checked out PLplot using git (master branch) and 
>> svn (trunk), which I believe to be roughly equivalent and the sizes are:
>>
>> (svn checkout http://svn.code.sf.net/p/plplot/code/trunk plplot)
>> SVN: 36.2MB (43.8MB on disk)
>>
>> (git clone https://github.com/HazenBabcock/PLplot.git)
>> GIT: 40.1MB (44.0MB on disk)
>
> That's interesting. My superficial understanding of git (also) is that the 
> user stores the entire history of a project locally (with the advantage that 
> checking stuff in and out is very fast). That means that apparently the 
> PLplot history is stored very efficiently since the git size is only a little 
> larger than the svn size. Also, I didn't spend enough time learning git to 
> figure out what advantage there is when updating the master with a local 
> repo--there still must be issues with conflicts. And is there any mechanism 
> to lock a file while it is being edited, since it is checked out from the 
> local repo and the master has no clue of the file's status. I recall we had a 
> discussion of this recently w.r.t. svn where most agreed that conflicts like 
> this are a rare event but there is indeed a locking mechanism of some sort if 
> one chooses to use it.

I think the work flow is that if you are going to work on issue X then 
you create a local branch called issue X. You periodically merge it with 
the master branch, which you keep in sync with the public repository. 
Then when issueX is ready to go you merge this branch back into master, 
resolve any conflicts, make sure it still works as expected and then 
push the updated master to the public repository. I'm not that familiar 
with git's merging abilities since the projects that I'm involved with 
that use it have only a few members at most, so there is not a lot of 
potential for file conflicts.

There is no locking mechanism that I know of.

-Hazen



--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] git (again)

[Hazen Babcock]

On 2/5/2014 12:25 AM, Alan W. Irwin wrote:
>
>> How big will the local copy be? And yes, the learning curve is kinda
> big. I fiddled around some time back with git w.r.t. LyX, the document
> processor. As I recall, the local storage requirements can be large.
>
> @Jerry:
>
> Good question on local size which I hope Hazen is in a position to
> answer.
>
> @Hazen:
>
> Here is a related question.  My understanding from superficial reading
> is that git users normally have a local repository (unlike the svn
> case where there is normally just one repository).  But if someone is
> worried about the disk space that is required by that local git
> repository, is there also a detached repository mode for git (i.e., so
> the user could simply use the SourceForge repository without copying
> all of the repository to his own computer)?

This is no longer true? I checked out PLplot using git (master branch) 
and svn (trunk), which I believe to be roughly equivalent and the sizes are:

(svn checkout http://svn.code.sf.net/p/plplot/code/trunk plplot)
SVN: 36.2MB (43.8MB on disk)

(git clone https://github.com/HazenBabcock/PLplot.git)
GIT: 40.1MB (44.0MB on disk)

I'm pretty sure that there is nothing like a detached repository mode. 
Everything is local as they say.

-Hazen


--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel