hey, thank you for the brain touch,
- Mathieu Bouchard ma...@artengine.ca 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]
- patko colet.patr...@free.fr a écrit :
- Mathieu Bouchard ma...@artengine.ca 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
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
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 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
- Mathieu Bouchard ma...@artengine.ca 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 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,
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 what
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 what
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
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 actually
is
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
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
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
- Mathieu Bouchard ma...@artengine.ca 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
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
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
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 version
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 print
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 r...@raakvlak.net
Hello
- Hans-Christoph Steiner h...@at.or.at 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
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,
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
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
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
select-help.pd
.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
26 matches
Mail list logo
