Re: [Plplot-devel] Release plans

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, January 27, 2015 2:17 AM
> To: Arjen Markus; Phil Rosenberg; Jim Dishaw; PLplot development list
> Subject: Release plans
>
> To Arjen, Phil, and Jim:
>
> I am addressing this post mostly to you guys because you are the only ones I 
> am
> aware of that are still working on substantial (i.e., non
> bug-fix) changes for this release cycle.
>
> As release manager, I really appreciate how hard all of you are working on 
> improving
> PLplot in the areas of the Fortran binding, wxwidgets device driver, and 
> plmeta/plbuf.
> And hopefully most or all of your substantial changes will get into the 
> forthcoming
> release (scheduled for February 28th).
>
...

> The criteria you should consider about substantial (i.e, non bug-fix) master 
> branch
> changes at any time but especially this close to release are the following:
>
> 1. Is your change thoroughly tested on Windows and Unix (typically
> Linux) with no build issues and no segfaults at run time?
>
> I think it is fair to say from the topic-branch commits I have seen via git 
> format-patch
> (or other means), that the current state of the fortran binding and wxwidgets 
> rewrites
> qualify on the build question but are disqualified by the run-time part of 
> this criterion,
> but hopefully that will change soon in both cases.
>

The status at the moment (on my development machine) is that there are one or 
two routines not behaving properly and some ten routines that still need to be 
revised.

When that is finished, I will have eliminated the complicated ballet performed 
in the plstubs.h header file and moreover the rather awkward way we pass 
strings at the moment between Fortran and C. I will not have eliminated all the 
pointer arithmetic on the C side. That is better left for a further cleanup - 
if we want that at all.

> 2. Is it better than what it is replacing?  I think it is fair to say from 
> the topic-branch
> commits I have seen the current Fortran binding and wxwidgets rewrites are 
> partially
> disqualified by this criterion, but hopefully that will change soon in both 
> cases.
>
> Users of the Fortran binding rewrite should have an easier time of it (less 
> worries
> about typing of variables) then the current Fortran binding. However, as I 
> have told
> Arjen elsewhere, one of the big motivations for this rewrite is to make the 
> Fortran
> bindings implementation much simpler.  That goal has not been realized yet, 
> and I
> hope to see that change soon.

The bindings will allow the use of single and double precision data from within 
the same library, which is indeed a big advantage for the user. The bindings 
require more code and in that sense it is not an improvement. On the other hand 
we will be using a standard way to deal with the interfacing and that is an 
improvement over the current compiler-dependent way.

>
> My impression is Phil has already achieved one of his desired goals which is a
> greatly simplified and easier to maintain wxwidgets device driver.  Of 
> course, the
> current rendering issues are of concern, but from what Phil has said, he is 
> actively
> working on those so the prospects of meeting this criterion soon look fairly 
> good.
>
> I don't know the status of the plmeta/plbuf changes with regard to these two 
> criteria,
> but I strongly encourage Jim to make his topic branch commits available to the
> plplot-devel list via git format-patch so they can be evaluated by these 
> criteria by
> everybody.
>
>  And similarly for Arjen (who has been communicating with me by tarball
> because he has been having difficulty using git format-patch on Windows).  Can
> someone here give Arjen advice about a good command-line git client to use on
> Windows where the format-patch command "just works"? 
>
I probably have found it in the form of a Cygwin package for dealing with git. 
I have not tried it yet, but I have a feeling it is more to my liking than the 
one that I had which used the PowerShell.

>
> If you cannot meet that deadline, then I suggest you give your highest 
> priority to
> finishing the small changes (such as Jim's plmem.c
> changes) that can be committed to master before that deadline.

Given that the changes to the Fortran bindings are huge (though I have tested 
them on two platforms already - Cygwin and bare Windows), but also the fact 
that the new geographic mapping API is waiting, I think I will postpone work on 
the Fortran bindings for the moment and continue with these much more limited 
changes.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its 

Re: [Plplot-devel] Release plans

[Phil Rosenberg]

On 27 January 2015 at 08:16, Arjen Markus  wrote:
> Hi Alan,
>
>
>
>> -Original Message-
>> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>> Sent: Tuesday, January 27, 2015 2:17 AM
>> To: Arjen Markus; Phil Rosenberg; Jim Dishaw; PLplot development list
>> Subject: Release plans
>>
>> To Arjen, Phil, and Jim:
>>
>> I am addressing this post mostly to you guys because you are the only ones
>> I am
>> aware of that are still working on substantial (i.e., non
>> bug-fix) changes for this release cycle.
>>
>> As release manager, I really appreciate how hard all of you are working on
>> improving
>> PLplot in the areas of the Fortran binding, wxwidgets device driver, and
>> plmeta/plbuf.
>> And hopefully most or all of your substantial changes will get into the
>> forthcoming
>> release (scheduled for February 28th).
>>
>> The criteria you should consider about substantial (i.e, non bug-fix)
>> master branch
>> changes at any time but especially this close to release are the
>> following:
>>
>> 1. Is your change thoroughly tested on Windows and Unix (typically
>> Linux) with no build issues and no segfaults at run time?
>>
Testing the wxWidgets on Windows and Linux should be no problem,
however I don't have access to a Mac. There are is some Mac specific
code in the wxWidgets driver, which I have left alone, but I don't
know what impact the changes will make. If anyone has a Mac they can
test on that would be really good.


>> 2. Is it better than what it is replacing?  I think it is fair to say from
>> the topic-branch
>> commits I have seen the current Fortran binding and wxwidgets rewrites are
>> partially
>> disqualified by this criterion, but hopefully that will change soon in
>> both cases.
My aim for now is that the rendering results by wxWidgets should be no
worse than after a resize of the window in the current driver. This is
because there are a number of bugs and deficiencies in the buffer that
are coming to light. These are currently being addressed by Jim and
progress is being made. I would refer to these particular changes as
bug fixes as they affect the results of any plreplot call. However
there are a significant number of such bugs and they are not all
trivial changes of a few lines of code so there is more risk than with
smaller changes. When Jim sends me his patches I will look through
them and retest them so hopefully with double checking we won't
introduce any problems.
One thing that I think we will be stuck with is the way rotated text
is at the wrong angle when plreplot is used and the aspect ratio is
not the same as the original. This is probably going to require a
significant change to the buffer and maybe won't get done in time.
Although as Jim is dealing with most of the buffer issues I he can
probably comment further. My intention is to have an escape option to
fix the aspect ratio of the plot so this at least gives a workaround.
>>
>> My impression is Phil has already achieved one of his desired goals which
>> is a
>> greatly simplified and easier to maintain wxwidgets device driver.  Of
>> course, the
>> current rendering issues are of concern, but from what Phil has said, he
>> is actively
>> working on those so the prospects of meeting this criterion soon look
>> fairly good.
All line width issues are now sorted, the only remaining issue is the
3d text rendering. As I mentioned in my previous email, if anyone has
any insider knowledge about how that functions that would be helpful.
Otherwise I will simply try to blindly copy what was done in the old
wxWidgets graphics context backend, which will therefore meet my aim
of "no worse than before."
>>
>> I don't know the status of the plmeta/plbuf changes with regard to these
>> two criteria,
>> but I strongly encourage Jim to make his topic branch commits available to
>> the
>> plplot-devel list via git format-patch so they can be evaluated by these
>> criteria by
>> everybody.
>>
>>  And similarly for Arjen (who has been communicating with me by
>> tarball
>> because he has been having difficulty using git format-patch on Windows).
>> Can
>> someone here give Arjen advice about a good command-line git client to use
>> on
>> Windows where the format-patch command "just works"? 
>>
> I probably have found it in the form of a Cygwin package for dealing with
> git. I have not tried it yet, but I have a feeling it is more to my liking
> than the one that I had which used the PowerShell.

Cygwin git is the version that I use too and I have found it "just
works". Usefully you can also use git daemon from Cygwin to share your
local repo with computers on your lan. It seems to be read only
access, but it helps if you wish to clone your repo to another
computer to test, then you can create a patch to pass the changes back
up.
>
>>
>> If you cannot meet that deadline, then I suggest you give your highest
>> priority to
>> finishing the small changes (such as Jim's plmem.c
>> changes) that can be committed to master before tha

Re: [Plplot-devel] Release plans

[Alan W. Irwin]

On 2015-01-27 10:35- Phil Rosenberg wrote:

> All line width issues are now sorted.

I am very glad to hear that has been cleaned up since those
issues were badly killing the rendered results of everything
I have looked at so far.

> The only remaining issue is the
> 3d text rendering. As I mentioned in my previous email, if anyone has
> any insider knowledge about how that functions that would be helpful.
> Otherwise I will simply try to blindly copy what was done in the old
> wxWidgets graphics context backend, which will therefore meet my aim
> of "no worse than before."

For the old wxwidgets device driver, example 8 affine transformations
were correct for some backends but not others.  For example,

examples/c/x08c -dev wxwidgets -drvopt backend=0

(the basic backend)

gives bad affine transformations very similar to what you have
now with your rewritten device driver while

examples/c/x08c -dev wxwidgets -drvopt backend=2

(the wxGC backend) has good affine transformations.

So assuming that there are no changes on the wxwidgets library
side with the definition of coordinates between the component
of that library used for the backend=2 case on the old wxwidgets
device driver and the component of that library used by
your rewritten device driver, then blindly copying the affine
transformations used for the wxGC case should work.

> My intention is to have the wxWidgets changes complete in the next
> couple of weeks so it is available for testing in advance as you say.

Sounds Good!

Alan

__
Alan W. Irwin

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

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

Linux-powered Science
__

--
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] Do we want to move plAlloc2dGrid(), plFree2dGrid, and plMinMax2dGrid

[Alan W. Irwin]

For reference the question was

> Would you be willing to give your official permission to adapt your
> new approach for the needs of ephcom under the LGPL?

On 2015-01-27 09:12-0500 Jim Dishaw wrote:

> You have my permission though it probably is not really needed
because the algorithm is generic and you are going to be rewriting the
code.

I agree it is a debatable point whether to ask permission in this
case, but I always like to be clear about such issues so thanks for
your permission.

> If you make a generic allocator, then you will need to tweak the
pointer arithmetic to get the layout correct.  I rely on the (float
**) and (float *) types to get the arithmetic correct.  A generic
allocator would need a (UCHAR *) or something similar and if the base
type was not a byte, you need to adjust accordingly.

Yes.

I also think alignment issues must be considered.
>From the malloc man page:

"The malloc() and calloc() functions return a pointer to the allocated
memory that is suitably aligned for any kind of variable."

So that part is OK by definition with regard to alignment, i.e.,
whatever is placed first in the memory area is guaranteed to
be aligned properly regardless of the size of the object.

However, your code mallocs the combination of two different kinds of
objects so to guarantee correct alignment for the longer objects,
those have to be placed first in the memory area.  So, for example, on
a 32-bit machine pointers typically (but not always) have a size of 4
bytes which is obviously shorter than the 8 bytes used for doubles. So
your code would have had misalignment issues for that case (unless the
relevant dimension happened to be even), and to avoid such issues your
original code and my generalization of it need a test on the size of
objects to decide which to place first in the memory area.

When I get these issues sorted out, I will follow up here with a reference
to the updated ephcom code in case someone here wants to use that
same approach for the PLplot 2D arrays.

Alan
__
Alan W. Irwin

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

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

Linux-powered Science
__

--
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] Do we want to move plAlloc2dGrid(), plFree2dGrid, and plMinMax2dGrid

[Andrew Ross]

On Tue, Jan 27, 2015 at 12:17:22PM -0800, Alan Irwin wrote:
> For reference the question was
> 
> > Would you be willing to give your official permission to adapt your
> > new approach for the needs of ephcom under the LGPL?
> 
> On 2015-01-27 09:12-0500 Jim Dishaw wrote:
> 
> > You have my permission though it probably is not really needed
> because the algorithm is generic and you are going to be rewriting the
> code.
> 
> I agree it is a debatable point whether to ask permission in this
> case, but I always like to be clear about such issues so thanks for
> your permission.
> 
> > If you make a generic allocator, then you will need to tweak the
> pointer arithmetic to get the layout correct.  I rely on the (float
> **) and (float *) types to get the arithmetic correct.  A generic
> allocator would need a (UCHAR *) or something similar and if the base
> type was not a byte, you need to adjust accordingly.
> 
> Yes.
> 
> I also think alignment issues must be considered.
> >From the malloc man page:
> 
> "The malloc() and calloc() functions return a pointer to the allocated
> memory that is suitably aligned for any kind of variable."
> 
> So that part is OK by definition with regard to alignment, i.e.,
> whatever is placed first in the memory area is guaranteed to
> be aligned properly regardless of the size of the object.
> 
> However, your code mallocs the combination of two different kinds of
> objects so to guarantee correct alignment for the longer objects,
> those have to be placed first in the memory area.  So, for example, on
> a 32-bit machine pointers typically (but not always) have a size of 4
> bytes which is obviously shorter than the 8 bytes used for doubles. So
> your code would have had misalignment issues for that case (unless the
> relevant dimension happened to be even), and to avoid such issues your
> original code and my generalization of it need a test on the size of
> objects to decide which to place first in the memory area.
> 
> When I get these issues sorted out, I will follow up here with a reference
> to the updated ephcom code in case someone here wants to use that
> same approach for the PLplot 2D arrays.

The sane way round this is make two allocations, one for the array of 
pointers and one for all the data. This is still a lot more efficient 
than the current multiple allocation approach, but still always 
guarantees correct alignment etc.

Andrew

--
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] Do we want to move plAlloc2dGrid(), plFree2dGrid, and plMinMax2dGrid

[Alan W. Irwin]

On 2015-01-27 21:39- Andrew Ross wrote:

> The sane way round this [potential misalignment issue] is make two 
> allocations, one for the array of
> pointers and one for all the data. This is still a lot more efficient
> than the current multiple allocation approach, but still always
> guarantees correct alignment etc.

Hi Andrew:

I also saw your two mallocs idea suggested somewhere in my recent
reading, and I have not seen Jim's single malloc alternative (or my
aligned variant of it) mentioned anywhere other than here. 
Nevertheless, the aligned variant of Jim's idea is guaranteed to work
and does have the small advantage that the destructor (in Phil's
terminology) is simply a call to free that requires no special routine
to free the two memory areas.  Note the ephcom API is quite small
(currently only 14 functions with 3 of those strongly deprecated). 
Therefore reducing that API to only 11 functions (by replacing two variants
of the 2d constructor by one, and by dropping the two special
destructor functions) seems like a simplification that will make the
API slightly easier to learn for someone who is just starting with
ephcom.

You will be amused to learn that I first "discovered" alignment issues
in 1970 or so in conjunction with Fortran common blocks.  The solution
in that case was always to put the largest objects first in the common
block.  So it seems quite natural to me to do that in the present case
as well.  But your two malloc idea may seem more sane to those
without such historical Fortran experience.  :-)

Whatever I finally decide to do, I will be careful to define 2D array
types (like Phil's idea) to help discourage users from relying on
internal implementation details.

Alan

__
Alan W. Irwin

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

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

Linux-powered Science
__

--
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] Do we want to move plAlloc2dGrid(), plFree2dGrid, and plMinMax2dGrid

[Phil Rosenberg]

Hi Alan
I know we are way off topic here, but how come you are reallocating so
often? Perhaps you might be interested in memory pools, or object
oriented style C or even C++ for saving you some of those allocations.

Phil


On 27 January 2015 at 22:20, Alan W. Irwin  wrote:
> On 2015-01-27 21:39- Andrew Ross wrote:
>
>> The sane way round this [potential misalignment issue] is make two 
>> allocations, one for the array of
>> pointers and one for all the data. This is still a lot more efficient
>> than the current multiple allocation approach, but still always
>> guarantees correct alignment etc.
>
> Hi Andrew:
>
> I also saw your two mallocs idea suggested somewhere in my recent
> reading, and I have not seen Jim's single malloc alternative (or my
> aligned variant of it) mentioned anywhere other than here.
> Nevertheless, the aligned variant of Jim's idea is guaranteed to work
> and does have the small advantage that the destructor (in Phil's
> terminology) is simply a call to free that requires no special routine
> to free the two memory areas.  Note the ephcom API is quite small
> (currently only 14 functions with 3 of those strongly deprecated).
> Therefore reducing that API to only 11 functions (by replacing two variants
> of the 2d constructor by one, and by dropping the two special
> destructor functions) seems like a simplification that will make the
> API slightly easier to learn for someone who is just starting with
> ephcom.
>
> You will be amused to learn that I first "discovered" alignment issues
> in 1970 or so in conjunction with Fortran common blocks.  The solution
> in that case was always to put the largest objects first in the common
> block.  So it seems quite natural to me to do that in the present case
> as well.  But your two malloc idea may seem more sane to those
> without such historical Fortran experience.  :-)
>
> Whatever I finally decide to do, I will be careful to define 2D array
> types (like Phil's idea) to help discourage users from relying on
> internal implementation details.
>
> Alan
>
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
>
> --
> 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

--
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] Release plans

[Jim Dishaw]

I have attached a patch for the plmem.c change.  This was part of a larger 
patch that I sent to Phil for testing, but I saw your email about wanting to 
get things tested sooner than later.


plmem.patch
Description: Binary data


Also, I will try to test plplot on the Mac and let you know if there are any 
issues.  Do you prefer I try the master branch or the branch that I have been 
making changes with?

On Jan 27, 2015, at 6:34 AM, "Alan W. Irwin"  wrote:

> On 2015-01-27 10:35- Phil Rosenberg wrote:
> 
>> All line width issues are now sorted.
> 
> I am very glad to hear that has been cleaned up since those
> issues were badly killing the rendered results of everything
> I have looked at so far.
> 
>> The only remaining issue is the
>> 3d text rendering. As I mentioned in my previous email, if anyone has
>> any insider knowledge about how that functions that would be helpful.
>> Otherwise I will simply try to blindly copy what was done in the old
>> wxWidgets graphics context backend, which will therefore meet my aim
>> of "no worse than before."
> 
> For the old wxwidgets device driver, example 8 affine transformations
> were correct for some backends but not others.  For example,
> 
> examples/c/x08c -dev wxwidgets -drvopt backend=0
> 
> (the basic backend)
> 
> gives bad affine transformations very similar to what you have
> now with your rewritten device driver while
> 
> examples/c/x08c -dev wxwidgets -drvopt backend=2
> 
> (the wxGC backend) has good affine transformations.
> 
> So assuming that there are no changes on the wxwidgets library
> side with the definition of coordinates between the component
> of that library used for the backend=2 case on the old wxwidgets
> device driver and the component of that library used by
> your rewritten device driver, then blindly copying the affine
> transformations used for the wxGC case should work.
> 
>> My intention is to have the wxWidgets changes complete in the next
>> couple of weeks so it is available for testing in advance as you say.
> 
> Sounds Good!
> 
> Alan
> 
> __
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
> 
> Linux-powered Science
> __

--
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] Release plans

[Alan W. Irwin]

Jim said:

> Also, I will try to test plplot on the Mac and let you know if there
are any issues.

In my opinion we have been skating on thin ice for a long time with
Mac OS X because of our lack of testing on that platform so your tests of
that platform would be answering an important need.

> Do you prefer I try the master branch or the
branch that I have been making changes with?

Please test the master branch at least to start with.

For that branch I suggest the most convenient thing to do from your
perspective is simply to run the scripts/comprehensive_test.sh script.
I have just created some documentation for that script in the
Comprehensive Testing section of
 which should
be of help to you.

Good luck, and let us know how your Mac OS X platform testing work
goes.

Alan
__
Alan W. Irwin

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

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

Linux-powered Science
__

--
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