Hello again,
Attached I send patches for trunk/drivers/tkwin.c and trunk/drivers/xwin.c
I searched in trunk folder from svn repo ad I found this files
containing PL_MAXPOLY:
trunk/bindings/tk/plr.c
trunk/drivers/tkwin.c
trunk/drivers/xfig.c
trunk/drivers/xwin.c
trunk/src/plarc.c
trunk/src/plbuf.c
Attached I send the (I think) definitive patches for plfill.c and
plgradient.c. I've used the plexit() function if any malloc() fails
for consistency with the rest of the code. I'll try to find the other
sources in wich PL_MAXPOLY appears.
Sorry for the previous wrong patches.
--
On Dec 22, 2010, at 9:05 PM, Maurice LeBrun wrote:
> A cautionary note: PL_MAXPOLY impacts a fair amount of code. Also there are
> heap-vs-stack performance implications -- e.g. directly moving from a fixed
> allocation to a malloc/free each time plfill() is called could suck for the
> many smal
On 2010-12-22 18:59-0800 Alan W. Irwin wrote:
> Andrew, the next chance you have to work on PLplot would you be
> willing to at least start swig-generated octave bindings? I don't
> really understand octave that well, but if you put together some
> typemaps for octave for input PLINT, PLFLT, and
On Thursday, December 23, 2010 at 11:00:26 (-0800) Alan W. Irwin writes:
> Maurice, do you know the origins of the free_mem macro in
> include/plplotP.h? That does deal with the NULL pointer case for
> frees, but it also sets the pointer to NULL after every free so I
> think this macro was mea
Hi Arjen, José, and Maurice:
(I am explicitly addressing Maurice as well since he may know the
origin of the free_mem macro that I discuss below.)
First, I would like to thank José for his plfill and plgradient
patches, and I am glad Arjen is going to apply them. That will make
my further change
On Thursday, December 23, 2010 at 09:28:20 (+0100) José Luis García Pallero
writes:
> Attached I send a patch for svn plfill() that uses malloc/free in case
> of n > PL_MAXPOLY-1. I've used a behavior similar to the function
> plP_plfclp() in plfill.c. plP_plfclp tests if the number of point is
Hi José,
stopping the program in such dramatic circumstances may be the
best option. We have had some discussion recently about the
best policy, but I am what consensus was reached. I suggest
right now we go ahead with your patch and see what corrections
are needed later (running out of memory oug
El día 23 de diciembre de 2010 13:35, Arjen Markus
escribió:
> Hi José,
>
> at a first glance this patch (and the one for plgradient) seems okay.
> Only one tiny thing: I am not sure free() can be used with a NULL
> argument. So, I'd say you have to guard against that. (If no one
> picks this up,
El día 23 de diciembre de 2010 13:41, Arjen Markus
escribió:
> Hi José,
>
> ah, well, personally I detest this type of magic, it means I
> have to remember all these little facts, but it means that
> your patch ought to be applicable as is. I will see to it.
>
> Regards,
>
> Arjen
>
> On 2010-12-2
Hi José,
ah, well, personally I detest this type of magic, it means I
have to remember all these little facts, but it means that
your patch ought to be applicable as is. I will see to it.
Regards,
Arjen
On 2010-12-23 13:39, José Luis García Pallero wrote:
> El día 23 de diciembre de 2010 13:35,
El día 23 de diciembre de 2010 13:35, Arjen Markus
escribió:
> Hi José,
>
> at a first glance this patch (and the one for plgradient) seems okay.
> Only one tiny thing: I am not sure free() can be used with a NULL
> argument. So, I'd say you have to guard against that. (If no one
> picks this up,
Hi José,
at a first glance this patch (and the one for plgradient) seems okay.
Only one tiny thing: I am not sure free() can be used with a NULL
argument. So, I'd say you have to guard against that. (If no one
picks this up, I will)
Regards,
Arjen
On 2010-12-23 09:55, José Luis García Pallero w
El día 23 de diciembre de 2010 09:55, José Luis García Pallero
escribió:
>> On 2010-12-22 22:05-0700 Maurice LeBrun wrote:
>>> A cautionary note: PL_MAXPOLY impacts a fair amount of code. Also there
>>> are
>>> heap-vs-stack performance implications -- e.g. directly moving from a
>>> fixed
>>> al
> On 2010-12-22 22:05-0700 Maurice LeBrun wrote:
>> A cautionary note: PL_MAXPOLY impacts a fair amount of code. Also there
>> are
>> heap-vs-stack performance implications -- e.g. directly moving from a
>> fixed
>> allocation to a malloc/free each time plfill() is called could suck for
>> the
>>
Hi,
On 2010-12-23 06:05, Maurice LeBrun wrote:
>
> A cautionary note: PL_MAXPOLY impacts a fair amount of code. Also there are
> heap-vs-stack performance implications -- e.g. directly moving from a fixed
> allocation to a malloc/free each time plfill() is called could suck for the
> many small
16 matches
Mail list logo
