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

2014-09-23 Thread David MacMahon
Hi, Alan, On Sep 22, 2014, at 12:37 PM, Alan W. Irwin wrote: > 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 whe

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

2014-09-23 Thread Alan W. Irwin
On 2014-09-23 03:30-0700 phil rosenberg wrote: > @Hazen and Alan > I think an email went AWOL from Hazen somewhere, but from Alan's reply I > guess it probably said that we should not be rebasing public branches. I must > confess that I think almost everything I have read about rebasing says do

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

2014-09-23 Thread phil rosenberg
ezekiah M. Carty Sent: Monday, 22 September 2014, 23:00 Subject: Re: [Plplot-devel] Exit calls and memory management On 2014-09-22 16:41-0400 Hazen Babcock wrote: > On 9/22/2014 3:37 PM, Alan W. Irwin wrote: >> On 2014-09-22 12:08-0400 Hazen Babcock wrote: >> >>> I think

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

2014-09-22 Thread Alan W. Irwin
On 2014-09-22 16:41-0400 Hazen Babcock wrote: > 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

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

2014-09-22 Thread Andrew Ross
Phil, This is a laudible plan, however fundamentally it won't remove the exit calls from plplot. The reason is that memory allocation can fail. We always need to check this and fail graceful, returning an error to the calling program and letting it decide how to procede. However we do the mem

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

2014-09-22 Thread 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

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

2014-09-22 Thread Alan W. Irwin
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. Hi Haze

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

2014-09-22 Thread Phil Rosenberg
pointer and use it raw double *arrayraw=array.mem; size_t n = array.size; for (i=0; i Sent: ‎22/‎09/‎2014 16:32 To: "Phil Rosenberg" Cc: "PLplot development list" Subject: Re: [Plplot-devel] Exit calls and memory management Unless the memory calls have changed, the &q

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

2014-09-22 Thread Alan W. Irwin
On 2014-09-22 15:17+0100 Phil Rosenberg wrote: > However the cost [of this change] 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

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

2014-09-22 Thread 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

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

2014-09-22 Thread Jim Dishaw
Unless the memory calls have changed, the "raw pointers" was something I implemented 5+ years ago when I submitted a patch to transition away from temporary files. The design goal I had in mind was speed, to keep the implementation portable, and to make the memory buffers agnostic to the data.