[PD-dev] Trouble with memory+pointers
Hi devs, I'm trying to rewrite some of my externals to be a bit more effe\icient, clear up after themselves and generally work more smoothly. I started with maskxor, because I really need this to work for the ICMC, and it's not working properly in certain situations. So I borrowed some code from zexy/src/drip.c and rewrote it. It compiled OK, but crashes PD. Can anyone tell me what is wrong with my code, and how to fix it? Best, Ed Lone Shark Aviation out now on http://www.pyramidtransmissions.com http://www.myspace.com/sharktracks - Yahoo! Answers - Get better answers from someone who knows. Tryit now. maskxor.tgz Description: 2539302602-maskxor.tgz ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd external-window crash
Jamie,
I am running thru your 2004 apple developer posts.
http://lists.apple.com/archives/carbon-development/2004/Jan/msg00318.html
I am trying to figure out how you solved the carbon windowing issue you had
with Gem for my
external but you never posted a solution. What did you finaly do to get it
working? I am looking at the
GemWinCreateMac.cpp but cant find the solution.
Thanks,
Alain
From: [EMAIL PROTECTED]
Date: 2007/06/25 Mon AM 09:18:44 EDT
To: pd-dev@iem.at
Subject: Re: [PD-dev] Pd external-window crash
Well it looks like if I get a Gemwin opened first, then I can open an
opencv window without a
crash...
It seems like the window is made using Carbon. Is there any special way
Pd handles Carbon
windows that would cause this stall?
This is my last hurdle. I have my externals working but in order to use the
carbon window I have to
open a gemwin first(not very profecional). I am using an opencv function
for windowing that looks
like this:
CV_IMPL int cvNamedWindow( const char* name, int flags )
{
int result = 0;
CV_FUNCNAME( cvNamedWindow );
if (!wasInitialized)
cvInitSystem(0, NULL);
// to be able to display a window, we need to be a 'faceful' application
// http://lists.apple.com/archives/carbon-dev/2005/Jun/msg01414.html
static bool switched_to_faceful = false;
if (! switched_to_faceful)
{
ProcessSerialNumber psn = { 0, kCurrentProcess };
OSStatus ret = TransformProcessType (psn,
kProcessTransformToForegroundApplication );
if (ret == noErr)
{
SetFrontProcess( psn );
switched_to_faceful = true;
}
else
{
fprintf(stderr, Failed to tranform process type: %d\n, (int)
ret);
fflush (stderr);
}
}
__BEGIN__;
WindowRef outWindow = NULL;
OSStatus err = noErr;
RectcontentBounds = {100,100,320,440};
CvWindow* window;
UInt wAttributes = 0;
int len;
const EventTypeSpec genericWindowEventHandler[] = {
{ kEventClassMouse, kEventMouseMoved},
{ kEventClassMouse, kEventMouseUp},
{ kEventClassMouse, kEventMouseDown},
{ kEventClassWindow, kEventWindowClose },
{ kEventClassWindow, kEventWindowBoundsChanged }//FD
};
if( !name )
CV_ERROR( CV_StsNullPtr, NULL name string );
if( icvFindWindowByName( name ) != 0 ){
result = 1;
EXIT;
}
len = strlen(name);
CV_CALL( window = (CvWindow*)cvAlloc(sizeof(CvWindow) + len + 1));
memset( window, 0, sizeof(*window));
window-name = (char*)(window + 1);
memcpy( window-name, name, len + 1 );
window-flags = flags;
window-signature = CV_WINDOW_MAGIC_VAL;
window-image = 0;
window-last_key = 0;
window-on_mouse = 0;
window-on_mouse_param = 0;
window-next = hg_windows;
window-prev = 0;
if( hg_windows )
hg_windows-prev = window;
hg_windows = window;
wAttributes = kWindowStandardDocumentAttributes |
kWindowStandardHandlerAttribute |
kWindowLiveResizeAttribute;
err = CreateNewWindow (
kDocumentWindowClass,wAttributes,contentBounds,outWindow);
if (err != noErr)
fprintf(stderr,Error while creating the window\n);
SetWindowTitleWithCFString(outWindow,CFStringCreateWithCString
(NULL,name,kCFStringEncodingASCII));
if (err != noErr)
fprintf(stdout,Error SetWindowTitleWithCFString\n);
window-window = outWindow;
err = InstallWindowEventHandler(outWindow,
NewEventHandlerUPP(windowEventHandler),
GetEventTypeCount(genericWindowEventHandler), genericWindowEventHandler,
outWindow,
NULL);
ShowWindow( outWindow );
result = 1;
__END__;
return result;
}
It seems to me that if this works outside of Pd then there must be something
Pd needs in order to
display a carbon window properly. It seems that the faceful stuff was
written in to prevent this from
happening but it doesnt work in Pd. I have been digging thru the Gem code to
find out how it does it
but it is so intertwined with the openGL code that I cant seem to figure out
how it displays a carbon
window corectly. Anyway if anyone has any ideas let me know. Until I figure
this out I will be
opening
up a gemwin along with my external:(.
Alain
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Trouble with memory+pointers
Ed Kelly wrote:
Hi devs,
I'm trying to rewrite some of my externals to be a bit more
effe\icient, clear up after themselves and generally work more
smoothly. I started with maskxor, because I really need this to work
for the ICMC, and it's not working properly in certain situations.
So I borrowed some code from zexy/src/drip.c and rewrote it. It
compiled OK, but crashes PD. Can anyone tell me what is wrong with my
code, and how to fix it?
I guess because you don't initialize the pointers the first time. Your
maskxor_new has:
SETFLOAT(x-masking.maskr[0], 0);
SETFLOAT(x-masking.maskl[0], 0);
SETFLOAT(x-masking.maskxor[0], 0);
...but x-masking.maskr etc. don't yet point to anything, they were
declared as:
t_atom *maskxor, *maskl, *maskr;
...but not given any value. If it doesn't crash right there it will do
so when you try to free the pointers:
if (x-masking.maskl) {
freebytes(x-masking.maskl, x-lengthl * sizeof(t_atom));
x-masking.maskl = 0;
x-lengthl = 0;
}
Martin
Best,
Ed
Lone Shark Aviation out now on http://www.pyramidtransmissions.com
http://www.myspace.com/sharktracks
Yahoo! Answers - Get better answers from someone who knows. Try it now
http://uk.answers.yahoo.com/;_ylc=X3oDMTEydmViNG02BF9TAzIxMTQ3MTcxOTAEc2VjA21haWwEc2xrA3RhZ2xpbmU.
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] Trouble with Memory and Pointers
Hallo, switching to pd-dev ... Ed Kelly hat gesagt: // Ed Kelly wrote: I'm trying to rewrite some of my externals to be a bit more efficient, clear up after themselves and generally work more smoothly. I started with maskxor, because I really need this to work for the ICMC, and it's not working properly in certain situations. So I borrowed some code from zexy/src/drip.c and rewrote it. It compiled OK, but crashes PD. Can anyone tell me what is wrong with my code, and how to fix it? No idea how to fix it, but I know where it crashes by compiling with -g and not stripping the external: [Switching to Thread -1211164992 (LWP 2541)] 0xb73f5bd7 in maskxor_new (s=0x0, fmode=4.89521765e-34) at maskxor.c:226 226 SETFLOAT(x-masking.maskr[0], 0); (gdb) bt #0 0xb73f5bd7 in maskxor_new (s=0x0, fmode=4.89521765e-34) at maskxor.c:226 #1 0x0809fcd6 in pd_typedmess () #2 0x080b3404 in sys_load_lib () Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Trouble with memory+pointers
So... if I initialize the pointers the first time they are used, maybe that
will help. It makes sense that the _new routine would be causing the problem,
since it crashes when I load the object (PD disappears...)
I'll try it!
Ta,
Ed
Martin Peach [EMAIL PROTECTED] wrote: Ed Kelly wrote:
Hi devs,
I'm trying to rewrite some of my externals to be a bit more
effe\icient, clear up after themselves and generally work more
smoothly. I started with maskxor, because I really need this to work
for the ICMC, and it's not working properly in certain situations.
So I borrowed some code from zexy/src/drip.c and rewrote it. It
compiled OK, but crashes PD. Can anyone tell me what is wrong with my
code, and how to fix it?
I guess because you don't initialize the pointers the first time. Your
maskxor_new has:
SETFLOAT(x-masking.maskr[0], 0);
SETFLOAT(x-masking.maskl[0], 0);
SETFLOAT(x-masking.maskxor[0], 0);
...but x-masking.maskr etc. don't yet point to anything, they were
declared as:
t_atom *maskxor, *maskl, *maskr;
...but not given any value. If it doesn't crash right there it will do
so when you try to free the pointers:
if (x-masking.maskl) {
freebytes(x-masking.maskl, x-lengthl * sizeof(t_atom));
x-masking.maskl = 0;
x-lengthl = 0;
}
Martin
Best,
Ed
Lone Shark Aviation out now on http://www.pyramidtransmissions.com
http://www.myspace.com/sharktracks
Yahoo! Answers - Get better answers from someone who knows. Try it now
.
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Lone Shark Aviation out now on http://www.pyramidtransmissions.com
http://www.myspace.com/sharktracks
-
Yahoo! Answers - Get better answers from someone who knows. Tryit now.___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Trouble with memory+pointers
Splendid! It doesn't crash any more. It doesn't work either, but at least I'm
in more familiar debugging territory! Thanks.
I used a x-firstl, x-firstr and x-firstx variables that were tested and set,
so that the first time each list is initialized, the first thing that happens
is e.g.
x-masking.maskl = getbytes(n * sizeof(t_atom));
and then the freebytes is used the second, third, fourth etc times.
Cheers,
Ed
Martin Peach [EMAIL PROTECTED] wrote: Ed Kelly wrote:
Hi devs,
I'm trying to rewrite some of my externals to be a bit more
effe\icient, clear up after themselves and generally work more
smoothly. I started with maskxor, because I really need this to work
for the ICMC, and it's not working properly in certain situations.
So I borrowed some code from zexy/src/drip.c and rewrote it. It
compiled OK, but crashes PD. Can anyone tell me what is wrong with my
code, and how to fix it?
I guess because you don't initialize the pointers the first time. Your
maskxor_new has:
SETFLOAT(x-masking.maskr[0], 0);
SETFLOAT(x-masking.maskl[0], 0);
SETFLOAT(x-masking.maskxor[0], 0);
...but x-masking.maskr etc. don't yet point to anything, they were
declared as:
t_atom *maskxor, *maskl, *maskr;
...but not given any value. If it doesn't crash right there it will do
so when you try to free the pointers:
if (x-masking.maskl) {
freebytes(x-masking.maskl, x-lengthl * sizeof(t_atom));
x-masking.maskl = 0;
x-lengthl = 0;
}
Martin
Best,
Ed
Lone Shark Aviation out now on http://www.pyramidtransmissions.com
http://www.myspace.com/sharktracks
Yahoo! Answers - Get better answers from someone who knows. Try it now
.
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Lone Shark Aviation out now on http://www.pyramidtransmissions.com
http://www.myspace.com/sharktracks
-
Yahoo! Answers - Get better answers from someone who knows. Tryit now.___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
