Re: [PD-dev] Troubleshooting suggestions
Mike McGonagle wrote: Hello all, I have a patch that has started to cause a crash in PD. In trying to figure out exactly what is happening, I reworked the patch, and now each of the smaller chunks of code are in their own subpatch. So, now the patch doesn't ALWAYS crash. Now the only time it crashes is when I open the subpatch containing the offending code, BUT only after that code has been executed at least once. Lets see if I can give an outline... 1. Open the patch. 2. Setup the patch for operation. 3. Call the subpatch that appears to be cause trouble. Everything executes properly and does what it is supposed to do. 4. Open the subpatch that contains the troublesome code, and PD crashes before it can display the patch. Thread 0 Crashed: 0 pd 0x0003cbb0 obj_noutlets + 16 (m_obj.c:549) 1 pd 0xca0c glist_drawiofor + 76 so pd is crashing when it tries to draw an object (most likely: a certain object) since it is unlikely that a normal object (no gui, no gop) will cause the crash (though not impossible; i only assume so, because if it was the case, we would get this bug report more often), so it would be interesting to know which graphical objects are hidden in your subpatch. apart from that, like always: sharing code could help... mfgasd.r IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Troubleshooting suggestions
On Dec 5, 2007 3:34 AM, IOhannes m zmoelnig [EMAIL PROTECTED] wrote: so pd is crashing when it tries to draw an object (most likely: a certain object) since it is unlikely that a normal object (no gui, no gop) will cause the crash (though not impossible; i only assume so, because if it was the case, we would get this bug report more often), so it would be interesting to know which graphical objects are hidden in your subpatch. apart from that, like always: sharing code could help... But that is what is strange about this, I am not using any graphical objects in the subpatch. And the other weirdness is that the first version of the program I wrote, it crashed on the very same leg of code [t b b] | | |Crashes all the time. | Doesn't crash And when I switchted the two legs, the one that was crashing originally still keeps crashing. And as far as the sharing of the code, I only hesitate because it involves one of my externals, and it always seems others are hesitant to compile these things just to test something. I could be wrong... That being said, I am going to post the latest version, and then the offending code. (The other part is that I am also using some stuff in a library that I am developing, so that also needs to be added to the path...) Mike mfgasd.r IOhannes -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Lua object help-path strangeness
Hi Frank, all,
Frank Barknecht wrote:
This doesn't seem to be specific to Lua: pdlua doesn't do anything
regarding help file searches at all, grep help pdlua/src/* yields no
results. So Claude and I suspect it's something with the loader
functionality. Can someone comment on this?
I did some digging through Pd's source code, specifically s_loader.c,
and found the trick to make things loaded by loaders find help patches:
8
/* defined in m_class.c but not exported. */
void class_set_extern_dir(t_symbol *);
8
Use it like this:
8
fd = canvas_open(canvas, name, .lua, dirbuf, ptr, MAXPDSTRING, 1);
if (fd = 0) {
class_set_extern_dir(gensym(dirbuf));
/* Lua-specific loader stuff goes here. */
class_set_extern_dir(s_);
}
8
Seems to work here, at least it finds help patches correctly now. In
pdlua SVN at revision 496.
This is with pd-0.40-3 from Miller's site on Linux, fwiw.
Thanks,
Claude
--
http://claudiusmaximus.goto10.org
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] autoconf renovation
Hans-Christoph Steiner wrote: Hey, Right now, in the 'externals' section, there are many build systems for different sections that reflect the build systems that the given dev used before importing the code into CVS. A couple of these use their own private autoconf setups (pdstring, pdp, pidip, zexy, OSCx, and probably others). I personally think that there should be one central autoconf system for everything. my personal problem with this (as explained at length before), is that i desperately want an external to be self-contained (apart from obvious dependencies like the pd-headers). for me this implies the build-system to be modular and not depend on a an up-level configuration. e.g. if i want to build aconnect external that lives in externals/iem/aconnect/ then i do not want to have to checkout externals/Makefile and what else and depend on a deep directory structure. it should be enough to get externals/iem/aconnect/ and be able to compile the external (without having to know all the compiler and linker flags by heart) i think this is really essential for my use of the externals. having said all that, this doesn't mean that i think it a bad idea to provide information in a centralized manner. the key point however is that the information should be provided to be pulled from a certain external's build-system rather than pushed to it. what i mean by this is: each external should have a self-contained build-system that is able to build the external without any up-level dependencies. however, this build-system should respect environmental variables that are set by an up-stream configuration process, and which is therefore able to guarantee that all externals are actually configured the same way. i don't know yet, how we could handle this generically for a master include-file. (config.h) btw, before the pd-convention i have setup a wiki to discuss exactly this issues http://puredata.info/Members/zmoelnig/pdcon07/BuildIntegration/ mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-1844526 ] [msgfile]: loses content, when end reached (since 2.2.0)
Bugs item #1844526, was opened at 2007-12-05 02:37 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=1844526group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: IOhannes m zm�lnig (zmoelnig) Summary: [msgfile]: loses content, when end reached (since 2.2.0) Initial Comment: the objectclass [msgfile] introduced a bug since version 2.2.0 of zexy. as soon as the last line of [msgfile]'s content is reached, the complete content is lost. see attached patch. -- Comment By: IOhannes m zm�lnig (zmoelnig) Date: 2007-12-05 10:37 Message: Logged In: YES user_id=564396 Originator: NO took responsibility; thanks for the attached patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=1844526group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] compile pd with cygwin
Cygwin1.dll have to be in pd/bin for running, and it require cygwin shell, Puredata into cygwin environment is working greatly even when Gem crashes. $ diff -uw configure.in.old configure.in --- configure.in.old2007-11-04 23:08:24.0 +0100 +++ configure.in2007-12-06 00:25:36.035890800 +0100 @@ -21,6 +21,9 @@ AC_SUBST(OSNUMBER) AC_SUBST(EXTERNTARGET) AC_SUBST(ASIOSRC) +AC_SUBST(PID) +AC_SUBST(CYGDLL) + dnl other defaults @@ -232,6 +235,7 @@ fi STRIPFLAG=-s GUINAME=pd-gui +PID=pd-watchdog if test x$USE_DEBUG_CFLAGS == xyes; then MORECFLAGS=$MORECFLAGS -g @@ -300,7 +304,7 @@ ../portmidi/porttime/ptmacosx_cf.c STRIPFLAG= GUINAME=libPdTcl.dylib - +PID=pd-watchdog # find the Tcl/Tk Frameworks if test -d ../../Frameworks; then @@ -334,10 +338,9 @@ LDFLAGS=$LDFLAGS -weak_framework Jack fi fi - # only Windows uses ASIO, for the rest, set to blank ASIOSRC= - +EXT= if test `uname -s` == MINGW32_NT-5.0; then EXT=dll @@ -368,6 +371,46 @@ GUIFLAGS= fi +if test `uname -s` == CYGWIN_NT-5.1 || \ + test `uname -s` == CYGWIN_NT-5.0 || \ + test `uname -s` == CYGWIN_NT-6.0 ; +then + +EXT=.exe +MORECFLAGS=-mno-cygwin -DPD -DNT -DUSEAPI_PORTAUDIO -DUSEAPI_MMIO -DPA_LIT TLE_ENDIAN -DMSW -DPA19 -DPD_INTERNAL \ +-I/cygdrive/c/Mingw/include -L/cygdrive/c/Mingw/lib \ + -I../portaudio/pa_common -I../portaudio/pablio \ + -I../portaudio/pa_asio -I../asio \ +-mms-bitfields $MORECFLAGS + +CYGDLL=cygwin1.dll$CYGDLL +PDLIB=$PDLIB -lwsock32 -lwinmm -lole32 -ltcl84 -ltk84 -lstdc++ + +SYSSRC=s_audio_pa.c s_audio_pablio.c s_audio_paring.c \ + s_audio_mmio.c s_midi_mmio.c \ +../portaudio/pa_common/pa_allocation.c \ +../portaudio/pa_common/pa_converters.c \ +../portaudio/pa_common/pa_cpuload.c \ +../portaudio/pa_common/pa_dither.c \ +../portaudio/pa_common/pa_front.c \ +../portaudio/pa_common/pa_process.c \ +../portaudio/pa_common/pa_skeleton.c\ +../portaudio/pa_common/pa_stream.c \ +../portaudio/pa_common/pa_trace.c \ +../portaudio/pa_win/pa_win_util.c \ +../portaudio/pa_win/pa_win_hostapis.c \ +../portaudio/pa_win_wmme/pa_win_wmme.c \ +../portaudio/pa_win_ds/pa_win_ds.c \ +../portaudio/pa_win_ds/dsound_wrapper.c + +ASIOSRC=../portaudio/pa_asio/iasiothiscallresolver.cpp \ +../portaudio/pa_asio/pa_asio.cpp ../asio/asio.cpp \ +../asio/asiodrivers.cpp ../asio/asiolist.cpp +STRIPFLAG=--strip-unneeded +GUINAME=pdtcl.dll + PID=pd.com +GUIFLAGS= +fi # support for jack, on either linux or darwin: if test x$jack == xyes; $ diff -uw makefile.in.old makefile.in --- makefile.in.old 2007-11-04 23:08:24.0 +0100 +++ makefile.in 2007-12-06 00:50:20.832765800 +0100 @@ -8,9 +8,11 @@ VPATH = ../obj:./ OBJ_DIR = ../obj BIN_DIR = ../bin -PDEXEC = $(BIN_DIR)/pd EXT= @EXT@ +PDEXEC = $(BIN_DIR)/pd$(EXT) GUINAME= @GUINAME@ +# pd-watchdog or pd.com? +PID= @PID@ prefix = @prefix@ exec_prefix = @exec_prefix@ @@ -36,7 +38,8 @@ LIB = @PDLIB@ WARN_CFLAGS = -Wall -W -Wstrict-prototypes \ --Wno-unused -Wno-parentheses -Wno-switch +-Wno-unused -Wno-unused-parameter -Wno-parentheses -Wno-switch + ARCH_CFLAGS = -DPD CFLAGS = @CFLAGS@ $(ARCH_CFLAGS) $(WARN_CFLAGS) $(CPPFLAGS) $(MORECFLAGS) @@ -45,6 +48,12 @@ SYSSRC += @SYSSRC@ +#windows stuff + +PDDLL = pd.dll + +STRIP = strip --strip-unneeded -R .note -R .comment + ASIOSRC = @ASIOSRC@ ASIOOBJ = $(ASIOSRC:.cpp=.o) @@ -89,21 +98,21 @@ # .PHONY: pd gui externs all - -all: $(PDEXEC) $(BIN_DIR)/pd-watchdog $(BIN_DIR)/$(GUINAME) $(BIN_DIR)/pdsend \ +all: $(BIN_DIR)/$(GUINAME) $(PDEXEC) $(BIN_DIR)/$(PID) $(BIN_DIR)/pdsend \ $(BIN_DIR)/pdreceive $(BIN_DIR)/pd.tk externs bin: $(PDEXEC) $(BIN_DIR)/pd-watchdog $(BIN_DIR)/$(GUINAME) $(BIN_DIR)/pdsend \ $(BIN_DIR)/pdreceive $(BIN_DIR)/pd.tk + $(OBJ) : %.o : %.c - $(CC) $(CFLAGS) $(GFLAGS) $(INCLUDE) -c -o $(OBJ_DIR)/$*.o $*.c + $(CC) $(CFLAGS) $(GFLAGS) -c -o $(OBJ_DIR)/$*.o $*.c $(GOBJ) : %.o : %.c $(CC) $(CFLAGS) $(GFLAGS) $(GINCLUDE) -c -o $(OBJ_DIR)/$*.o $*.c $(ASIOOBJ): %.o : %.cpp - $(CXX) $(CFLAGS) $(INCLUDE) -c -o $(OBJ_DIR)/$*.o $*.cpp + $(CXX) $(CFLAGS) -c -o $(OBJ_DIR)/$*.o $*.cpp pd: $(PDEXEC) @@ -118,25 +127,26 @@ $(CC) $(CFLAGS) $(STRIPFLAG) -o $(BIN_DIR)/pd-watchdog s_watchdog.c $(BIN_DIR)/pdsend: u_pdsend.c $(BIN_DIR) - $(CC) $(CFLAGS) $(STRIPFLAG) -o $(BIN_DIR)/pdsend u_pdsend.c + $(CC) $(CFLAGS) $(STRIPFLAG) -o $(BIN_DIR)/pdsend u_pdsend.c $(LIB) $(BIN_DIR)/pdreceive: u_pdreceive.c $(BIN_DIR) - $(CC) $(CFLAGS) $(STRIPFLAG)
Re: [PD-dev] compile pd with cygwin
Wow, that's awesome! So you are using X11 to display Pd? I am going to try this tonight. Which version of Pd did you try? .hc On Dec 5, 2007, at 7:46 PM, Patrice Colet wrote: Cygwin1.dll have to be in pd/bin for running, and it require cygwin shell, Puredata into cygwin environment is working greatly even when Gem crashes. $ diff -uw configure.in.old configure.in --- configure.in.old2007-11-04 23:08:24.0 +0100 +++ configure.in2007-12-06 00:25:36.035890800 +0100 @@ -21,6 +21,9 @@ AC_SUBST(OSNUMBER) AC_SUBST(EXTERNTARGET) AC_SUBST(ASIOSRC) +AC_SUBST(PID) +AC_SUBST(CYGDLL) + dnl other defaults @@ -232,6 +235,7 @@ fi STRIPFLAG=-s GUINAME=pd-gui +PID=pd-watchdog if test x$USE_DEBUG_CFLAGS == xyes; then MORECFLAGS=$MORECFLAGS -g @@ -300,7 +304,7 @@ ../portmidi/porttime/ptmacosx_cf.c STRIPFLAG= GUINAME=libPdTcl.dylib - +PID=pd-watchdog # find the Tcl/Tk Frameworks if test -d ../../Frameworks; then @@ -334,10 +338,9 @@ LDFLAGS=$LDFLAGS -weak_framework Jack fi fi - # only Windows uses ASIO, for the rest, set to blank ASIOSRC= - +EXT= if test `uname -s` == MINGW32_NT-5.0; then EXT=dll @@ -368,6 +371,46 @@ GUIFLAGS= fi +if test `uname -s` == CYGWIN_NT-5.1 || \ + test `uname -s` == CYGWIN_NT-5.0 || \ + test `uname -s` == CYGWIN_NT-6.0 ; +then + +EXT=.exe +MORECFLAGS=-mno-cygwin -DPD -DNT -DUSEAPI_PORTAUDIO - DUSEAPI_MMIO -DPA_LIT TLE_ENDIAN -DMSW -DPA19 -DPD_INTERNAL \ +-I/cygdrive/c/Mingw/include -L/cygdrive/c/Mingw/lib \ + -I../portaudio/pa_common -I../portaudio/pablio \ + -I../portaudio/pa_asio -I../asio \ +-mms-bitfields $MORECFLAGS + +CYGDLL=cygwin1.dll$CYGDLL +PDLIB=$PDLIB -lwsock32 -lwinmm -lole32 -ltcl84 -ltk84 -lstdc++ + +SYSSRC=s_audio_pa.c s_audio_pablio.c s_audio_paring.c \ + s_audio_mmio.c s_midi_mmio.c \ +../portaudio/pa_common/pa_allocation.c \ +../portaudio/pa_common/pa_converters.c \ +../portaudio/pa_common/pa_cpuload.c \ +../portaudio/pa_common/pa_dither.c \ +../portaudio/pa_common/pa_front.c \ +../portaudio/pa_common/pa_process.c \ +../portaudio/pa_common/pa_skeleton.c\ +../portaudio/pa_common/pa_stream.c \ +../portaudio/pa_common/pa_trace.c \ +../portaudio/pa_win/pa_win_util.c \ +../portaudio/pa_win/pa_win_hostapis.c \ +../portaudio/pa_win_wmme/pa_win_wmme.c \ +../portaudio/pa_win_ds/pa_win_ds.c \ +../portaudio/pa_win_ds/dsound_wrapper.c + +ASIOSRC=../portaudio/pa_asio/iasiothiscallresolver.cpp \ +../portaudio/pa_asio/pa_asio.cpp ../asio/asio.cpp \ +../asio/asiodrivers.cpp ../asio/asiolist.cpp +STRIPFLAG=--strip-unneeded +GUINAME=pdtcl.dll + PID=pd.com +GUIFLAGS= +fi # support for jack, on either linux or darwin: if test x$jack == xyes; $ diff -uw makefile.in.old makefile.in --- makefile.in.old 2007-11-04 23:08:24.0 +0100 +++ makefile.in 2007-12-06 00:50:20.832765800 +0100 @@ -8,9 +8,11 @@ VPATH = ../obj:./ OBJ_DIR = ../obj BIN_DIR = ../bin -PDEXEC = $(BIN_DIR)/pd EXT= @EXT@ +PDEXEC = $(BIN_DIR)/pd$(EXT) GUINAME= @GUINAME@ +# pd-watchdog or pd.com? +PID= @PID@ prefix = @prefix@ exec_prefix = @exec_prefix@ @@ -36,7 +38,8 @@ LIB = @PDLIB@ WARN_CFLAGS = -Wall -W -Wstrict-prototypes \ --Wno-unused -Wno-parentheses -Wno-switch +-Wno-unused -Wno-unused-parameter -Wno-parentheses -Wno-switch + ARCH_CFLAGS = -DPD CFLAGS = @CFLAGS@ $(ARCH_CFLAGS) $(WARN_CFLAGS) $(CPPFLAGS) $ (MORECFLAGS) @@ -45,6 +48,12 @@ SYSSRC += @SYSSRC@ +#windows stuff + +PDDLL = pd.dll + +STRIP = strip --strip-unneeded -R .note -R .comment + ASIOSRC = @ASIOSRC@ ASIOOBJ = $(ASIOSRC:.cpp=.o) @@ -89,21 +98,21 @@ # .PHONY: pd gui externs all - -all: $(PDEXEC) $(BIN_DIR)/pd-watchdog $(BIN_DIR)/$(GUINAME) $ (BIN_DIR)/pdsend \ +all: $(BIN_DIR)/$(GUINAME) $(PDEXEC) $(BIN_DIR)/$(PID) $(BIN_DIR)/ pdsend \ $(BIN_DIR)/pdreceive $(BIN_DIR)/pd.tk externs bin: $(PDEXEC) $(BIN_DIR)/pd-watchdog $(BIN_DIR)/$(GUINAME) $ (BIN_DIR)/pdsend \ $(BIN_DIR)/pdreceive $(BIN_DIR)/pd.tk + $(OBJ) : %.o : %.c - $(CC) $(CFLAGS) $(GFLAGS) $(INCLUDE) -c -o $(OBJ_DIR)/$*.o $*.c + $(CC) $(CFLAGS) $(GFLAGS) -c -o $(OBJ_DIR)/$*.o $*.c $(GOBJ) : %.o : %.c $(CC) $(CFLAGS) $(GFLAGS) $(GINCLUDE) -c -o $(OBJ_DIR)/$*.o $*.c $(ASIOOBJ): %.o : %.cpp - $(CXX) $(CFLAGS) $(INCLUDE) -c -o $(OBJ_DIR)/$*.o $*.cpp + $(CXX) $(CFLAGS) -c -o $(OBJ_DIR)/$*.o $*.cpp pd: $(PDEXEC) @@ -118,25 +127,26 @@ $(CC) $(CFLAGS) $(STRIPFLAG) -o $(BIN_DIR)/pd-watchdog
