Andrew
Yes that's exactly what I would do - use C++ internally, then have a C
layer that interfaced outwards with error codes. I must confess to
only recently realizing how amazingly useful C++ features like
throwing errors and smart pointers are. But I now rely on them so much
I actually genuinely
Phil,
The same thought had also crossed my mind. This is a more modern way to
handle errors. You would need the C interface to catch the exceptions and
return an error code since not all of our languages would handle them.
This might require C++ -> C -> some thing else which is not pretty
either.
Yeah it's something I've been thinking about too. But not a fun task.
To be honest I was starting to think that the least intrusive method
would be to convert everything to C++, with a C frontend and use
try-catch blocks with throw. Well I'm joking - sortof.
But yes this has caused me major pain
On Mar 19, 2015, at 4:03 PM, Andrew Ross
wrote:
> On Thu, Mar 19, 2015 at 03:30:21PM -0400, 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
>>
On Thu, Mar 19, 2015 at 09:09:27AM -0700, Alan Irwin wrote:
> On 2015-03-19 09:08- Andrew Ross wrote:
>
> >
> >>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.
On Thu, Mar 19, 2015 at 03:30:21PM -0400, 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 w
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
> 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 th
On 2015-03-19 09:08- Andrew Ross wrote:
>
>> 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 do
On Thu, Mar 19, 2015 at 09:08:21AM +, Andrew Ross wrote:
>
> > 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
Great! That confirms we are looking at exactly the same bug. Thanks for
the prompt response. I think I now know how to fix it. The same issue also
seems to occur with the xcairo driver.
Andrew
On Thu, Mar 19, 2015 at 02:08:38AM -0700, Norman Goldstein wrote:
> During my testing, I was using the
During my testing, I was using the close button (X) to close the window.
Just now, I reran the xwin test by hitting "return" to close the window,
and this produced a core dump!
Thanks for looking into all this stuff. Let me know if I can
help.
Regards,
Norm
On 03/19/2015 01:56 AM, Andrew Ro
> 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
> program
Norman,
Thanks. This confirms that you are not using dynamic drivers. This
explains why your fix works for you and coincides with my experiments.
Just one further confirmation - were you closing the plplot window using
the close button (X) on the window, or by pressing return / 'Q'?
Your testing
Sorry, I just got back in ...
OK, I certainly bow to your more extensive insight to the plplot big
picture.
For the record, here is how I configured plolot:
cmake -DENABLE_ocaml=OFF -DCMAKE_BUILD_TYPE=Debug. -DBUILD_TEST=ON .
Attached, is the cmake log.
I see that the default isENABLE_DYN
On 2015-03-18 23:39- Andrew Ross wrote:
> I'm a little uneasy about applying this patch so late in the release cycle
> in case there are any unforseen consequences. The current situation will
> result in a memory leak when closing the window with the button, but since
> this is on exit anyway
On Wed, Mar 18, 2015 at 11:10:20PM +, Andrew Ross wrote:
> On Wed, Mar 18, 2015 at 10:57:33PM +, Andrew Ross wrote:
> > On Wed, Mar 18, 2015 at 12:59:18AM -0700, Alan Irwin wrote:
> > > @Andrew: There are some really interesting release implications here,
> > > and if you feel Norman's fix
On Wed, Mar 18, 2015 at 10:57:33PM +, Andrew Ross wrote:
> On Wed, Mar 18, 2015 at 12:59:18AM -0700, Alan Irwin wrote:
> > @Andrew: There are some really interesting release implications here,
> > and if you feel Norman's fix (ideally in git am form as I have
> > requested from him below) or so
On Wed, Mar 18, 2015 at 12:59:18AM -0700, Alan Irwin wrote:
> @Andrew: There are some really interesting release implications here,
> and if you feel Norman's fix (ideally in git am form as I have
> requested from him below) or some other variant of it you like is a
> no-brainer please go ahead and
On 2015-03-18 11:05-0700 Norman Goldstein wrote:
> It turns out the psc core dump was easy to fix:
> Set the flag in the PLStream after closing the file
> in ps.c . The three tests were good:
> xwin, psc and svg
>
> So, I am ready to submit the updated
> plcore.c and ps.c
>
> Perhaps, though, o
On 2015-03-18 09:59-0700 Norman Goldstein wrote:
> I downloaded the latest source code:
>
> git clone git://git.code.sf.net/p/plplot/plplot plplot.git
>
> Confirmed the memory leak is still in this version.
> (some headache, since the debug library did not get the "d' suffix)
Yes, we are dropping
It turns out the psc core dump was easy to fix:
Set the flag in the PLStream after closing the file
in ps.c . The three tests were good:
xwin, psc and svg
So, I am ready to submit the updated
plcore.c and ps.c
Perhaps, though, other devices need a fix
similar to the ps.c, above.
Here is the o
I downloaded the latest source code:
git clone git://git.code.sf.net/p/plplot/plplot plplot.git
Confirmed the memory leak is still in this version.
(some headache, since the debug library did not get the "d' suffix)
The fix eliminates this memory leak, and no others originate in plplot.
Other t
@Andrew: There are some really interesting release implications here,
and if you feel Norman's fix (ideally in git am form as I have
requested from him below) or some other variant of it you like is a
no-brainer please go ahead and push it (see my further comment on the
release delay implications a
I noticed that at the end of plSelectDev(), in plcore.c,
a couple more fields of the PLStream
needed to be filled in (feedback from valgrind :-)),
so I added these two lines at line 3230:
plsc->tidy = (void*) dispatch_table[dev - 1]->pl_tidy;
plsc->tidy_data = (void*) plsc;
I expect the
25 matches
Mail list logo
