On Wed, 12 May 2010, Mathieu Bouchard wrote:
buf = resizebytes(buf, bufsize+1, bufsize);
indeed, oldsize comes before, not after, so,
buf = resizebytes(buf, bufsize, bufsize+1);
as Hans said.
_ _ __ ___ _ _ _ ...
| Mathieu Bouchard, Montréal,
- "Hans-Christoph Steiner" a écrit :
> Arg, this stuff is maddening. If you look at scalar_properties() in
> g_scalar.c, you'll see Miller does the opposite with that resize, the
>
> +1 is in the new size, not the old. I think I'll try it like that.
>
> binbuf_add(bb, argc, ar
- "Mathieu Bouchard" a écrit :
> On Fri, 14 May 2010, patko wrote:
>
> > hey, thank you for the brain touch,
>
> excuse me : the WHAT ?
I'm just enjoying to have people that share braincells on this topic,
because I wouldn't find it by myself.
___
On May 14, 2010, at 10:08 AM, Mathieu Bouchard wrote:
On Fri, 14 May 2010, patko wrote:
but in both cases it doesn't crash anymore.
AND i wanted to say that it's also "luck" that it doesn't crash
anymore.
It would be more instructive and helpful if a programme would crash
every time t
On Fri, 14 May 2010, patko wrote:
but in both cases it doesn't crash anymore.
AND i wanted to say that it's also "luck" that it doesn't crash anymore.
It would be more instructive and helpful if a programme would crash every
time that the code does something wrong, but alas, this is not the
On Fri, 14 May 2010, patko wrote:
hey, thank you for the brain touch,
excuse me : the WHAT ?
this is appending extra characters when [print] argument has more than
seven characters.
eg:
match: bang
NO_matchmÇ&: 234
Well, I hope you understand that this can happen with ANY number of
char
- "patko" a écrit :
> - "Mathieu Bouchard" a écrit :
> >
> >buf = resizebytes(buf, bufsize+1, bufsize);
> >
> > (I hope I didn't make any mistake there... but looks ok to me now).
> >
>
> No mistakes, that's alright with my OS.
>
oupse, I didn't pay attention but it also add ex
hey, thank you for the brain touch,
- "Mathieu Bouchard" a écrit :
> On Thu, 13 May 2010, Hans-Christoph Steiner wrote:
>
> > Or maybe:
> > binbuf_gettext(bb, &buf, &bufsize);
> > strncat(buf, "\0", strlen(buf)-bufsize);
this is appending extra characters when [print] argum
On Thu, 13 May 2010, Mathieu Bouchard wrote:
On Thu, 13 May 2010, Hans-Christoph Steiner wrote:
Or maybe:
binbuf_gettext(bb, &buf, &bufsize);
strncat(buf, "\0", strlen(buf)-bufsize);
strncat will copy at most strlen(buf)-bufsize, but it will also copy at most
strlen("\0") bytes, and
On Thu, 13 May 2010, Hans-Christoph Steiner wrote:
Or maybe:
binbuf_gettext(bb, &buf, &bufsize);
strncat(buf, "\0", strlen(buf)-bufsize);
strncat will copy at most strlen(buf)-bufsize, but it will also copy at
most strlen("\0") bytes, and strlen("\0") is zero, because strlen actua
On Thu, 13 May 2010, Hans-Christoph Steiner wrote:
On May 12, 2010, at 1:43 PM, Mathieu Bouchard wrote:
Instead of removing the line, try prepending it with :
buf = resizebytes(buf, bufsize+1, bufsize);
(I hope I didn't make any mistake there... but looks ok to me now).
Shouldn't this work inst
On May 12, 2010, at 1:43 PM, Mathieu Bouchard wrote:
On Wed, 12 May 2010, patko wrote:
Maybe opening a new topic with "[print] crashes pd" would make it.
the problem is exactly there:
x_interface.c:28 buf[bufsize] = 0;
remove or comment this line, then it won't crash anymore.
I've no clue wha
On May 12, 2010, at 1:43 PM, Mathieu Bouchard wrote:
On Wed, 12 May 2010, patko wrote:
Maybe opening a new topic with "[print] crashes pd" would make it.
the problem is exactly there:
x_interface.c:28 buf[bufsize] = 0;
remove or comment this line, then it won't crash anymore.
I've no clue wha
- "Mathieu Bouchard" a écrit :
> On Wed, 12 May 2010, patko wrote:
> > the problem is exactly there:
> > x_interface.c:28 buf[bufsize] = 0;
> This looks like it's a bug regardless of the OS, although it currently
>
> only shows up on some versions of Windows. What you suggest seems to
On Wed, 12 May 2010, patko wrote:
Maybe opening a new topic with "[print] crashes pd" would make it.
the problem is exactly there:
x_interface.c:28 buf[bufsize] = 0;
remove or comment this line, then it won't crash anymore.
I've no clue what this line stand for.
If you have no clue, then perha
I'm afraid the print source will stay like this unless someone
that knows very well c code explain what's happening, I gave all the keys
but without a dev to end the work, there is nothing else to do.
And I think this is stupid to just 'avoid' to put more than seven characters
in print argument,
i made the suggested change to the [sel] help patch and now have confirmation
on 2 out of 3 i've seen machines with these problems, that the modified patch
no longer crashes pd.
this is a wird problem that would have been extremely hard to find
without your help. thanks!
looking forwar
many thanks, i made the necessary changes to the select help patch and will be
trying this modified patch in the coming days on several machines.
will post updates when i have more.
thanks again.
rene
On May 10, 2010, at 18:28, patko wrote:
>
>
>>
>> just replace "print NO_match" by "prin
matched!
>
> I'm certain the bug come from those lines from x_interface.c:
>
> if (argc)
> {
> t_binbuf *bb = binbuf_new();
> binbuf_add(bb, argc, argv);
> binbuf_gettext(bb, &buf, &bufsize);
This is the kinky line:
> buf[bufsize] = 0;
Now I don't kn
>
> just replace "print NO_match" by "print Nomatch"
>
in fact print doesn't support more than seven characters is argument symbol
the bug is easy to reproduce:
in a new patch create a [print ] object and close, it will crash,
but under certain conditions, it doesn't crash with the v
My friend Dichotomie ( Binary search algorithm )
has helped me out to find out the problem with this patch.
just replace "print NO_match" by "print Nomatch"
it's seems there's a problem with stdout or something like this
I'll try to pay attention to warnings during next compile unless
someone f
The problem is one light year beyond what I've suggested first,
sorry,
it comes from the help patch.
It's very hard to figure out what's going on,
and watching what's happening by modifying things
by hand with a text editor might help to
find out the kinky lines, good luck!
Why not trying out
tested this tonight on one machine running win7.
replacing the pd.dll in the pd/bin folder made pd unable to start
On May 08, 2010, at 16:38, patko wrote:
> I've recently compiled a version of pd-extended
> just replacing pd.dll fixes it, it's attached
>
> - "rene beekman" a écrit :
>
now in the bugtracker, id 2998579
opening the help file for the [sel] object is one way to recreate this crash.
but sel is not the only object
the patch you sent in feb with the [multiselect] object removed from the
"related objects" subpatch does not solve the problem.
i do have (indirect, th
Hello
- "Hans-Christoph Steiner" a écrit :
> I'd like to get this stuff working on Windows 7 too, but I currently
>
> don't have access to a Windows 7 machine. Be sure to submit bug
> reports to the bug tracker, if you haven't already. Also, if you can
I've tried last build of pd-ex
I'd like to get this stuff working on Windows 7 too, but I currently
don't have access to a Windows 7 machine. Be sure to submit bug
reports to the bug tracker, if you haven't already. Also, if you can
narrow down the crash to as small a patch as possible, that makes it
much easier to fi
i reported this problem several months ago.
the suggestion back then was to test nightly builds, which did not work at the
time.
more recent nightly builds did not solve this problem either.
it appears on some laptops running vista or windows7, but not all.
i have so far not been able to recreate
tried it with the nightly build from the 14th
still crashed :(
rene
On Feb 14, 2010, at 19:23, Hans-Christoph Steiner wrote:
>
> 1) try a Pd-extended 0.42.5 nightly build
>
> 2) try this version with the [multiselect] object removed from the "related
> objects" subpatch
>
>
>
>
> .hc
>
1) try a Pd-extended 0.42.5 nightly build
2) try this version with the [multiselect] object removed from the
"related objects" subpatch
select-help.pd
Description: Binary data
.hc
On Feb 14, 2010, at 7:59 AM, rene beekman wrote:
we're having problems running pd-extended 0.41.4 on vi
29 matches
Mail list logo