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)
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) -
Re: [PD-dev] Troubleshooting suggestions
I forgot to tell you want to do to make it crash... Once you are done looking at that subpatch. Close it... Go back to the main window, and hit the button connected to the [send mine-attractor-load-instance]. This should print out a series of four values to the console. Select another from the instance popup (i1, i2, etc.), and hit this again. It should work just fine, no matter how many times you do this. Now go back and open the [pd load-attractor-instance] subpatch in the Attractor-GUI abstraction. Does it crash? There you have it, two downloads, one shitty install, and a crashing program... But hey, thanks. Mike On Dec 5, 2007 2:47 PM, Mike McGonagle <[EMAIL PROTECTED]> wrote: > Ok, I have posted the latest version of the SQLite external to > http://puredata.info/Members/mjmogo > It will be the second one on the list. It is version 0.13 just so you > know. > > I also attached the library stuff that I have been working on. Once you > get that stuff up (and you did ask for code...), you can load up the patch > under the testing folder in Orbit2. Once you do that, you will need to open > up the attractors4.db file. Select the popup to the left, and choose > 'all'. From here, select 'latoocarfian' for the attractor (the popup just to > the right). Once you have done that, select the popup underneath, and choose > one of the instances (i1, i2, etc). > > This is where you will try to open the Attractor-GUI abstraction, and then > the [pd load-attractor-instance] subpatch. This should open without any > troubles. When you open up this window, you will notice the connection > between the 'sql' message box going into the [sqlite] external has been > disconnected. This branch is NOT the offending branch. The one that is > causing troubles is on the other branch of the first [t b b] at the top. > > Any help in pointing to what I could do to troubleshoot this would be > earth-shattering in learning more about PD. And thanks for your help so far. > > > Mike > > (PS, anyone who compiles this on any other platform other than Mac OS X, > if you could forward the makefile you used, I can incorporate it into the > main makefile.) > -- 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] compile pd with cygwin (almost!)
On Dec 5, 2007, at 6:57 AM, Patrice Colet wrote: > Hans-Christoph Steiner a écrit : > >> AFAIK, the watchdog isn't used on Windows anyhow, so I wouldn't >> worry about it. > > I believed that pd-watchdog is existing on windows, and is called > pd.com, they are both related with PID. I've renamed it to watchdog > just for everytime I've asked mysself, "what is this watchdog, what > is this pd.com?" pd.com is a version of pd.exe that opens in a cmd.exe shell so that you can get the logs after Pd crashes. It is not the watchdog AFAIK. >> AFAIK, I think the MinGW and Cygwin sections in will have some >> differences. > > If you want to duplicate code, like with portaudio and portmidi, > but in both configure.in and makefile.in let it be. I'm very far > from being an expert, but for me it doesn't look very nice. For the > moment I've a very light definition of a 'good' code, sometimes > it's better when it is duplicated, sometimes we should rather make > modules. In all case I really would like to know for sure what > would be the best choice before writing the definitive code. Definitely merge them when it makes sense. I was just saying that I think we'll have to still accommodate some minor differences. .hc >> least -mno-cygwin is not used in MinGW. > > using CYGFLAG would just avoid to duplicate everything for mingw. > > also when using g++, -mno-cygwin flag have to be placed > differently, something like " -o -mno-cygwin" . > > Now the problem is the one I've described before, pd.exe is > mysteriously linked to cygwin1.dll, if I rename pdtcl.dll, an > error message pops up to say something like it couldn't find > "pthread_cond_destroy". > > == > >>> > cd ../bin; dllwrap -mno-cygwin --export-all-symbol -- > output-def pdtcl.def > \ > --output-lib=pdtcl.a --dllname=pdtcl.dll ../obj/ > t_tkcmd.o -ldl -lm -lpth > readGC2 -lwsock32 -lwinmm -lole32 -ltcl84 -ltk84 -lstdc++ - > ltk84 -ltcl84 > dllwrap: aucun fichier d'exportation de d'efinitions fourni. > Cr'eation du fichier, mais il ne correspondra pas > n'ecessairement `a ce que vous > d'esirez. > /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/ > bin/ld: AVERTISSE > MENT: ne peut trouver le symbole d'entr'ee > [EMAIL PROTECTED]; utilise par d' > efaut 6d081000 > >> - >> --- "Free software means you control what your computer does. >> Non-free software means someone else controls that, and to some >> extent controls you." - Richard M. Stallman ¡El pueblo unido jamás será vencido! ___ 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
[PD-dev] [ pure-data-Bugs-1844779 ] installation - overwrite files (windows)
Bugs item #1844779, was opened at 2007-12-05 13:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1844779&group_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: pd-extended Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: João Miguel Pais (jmmmp) Assigned to: Hans-Christoph Steiner (eighthave) Summary: installation - overwrite files (windows) Initial Comment: Since pd-ext is a program that gets renewed quite often, it makes some sense that a new installation overwrites the previous one. While installing pd-ext in windows, the program asks at all times if one file should be overwritten - making it necessary to keep the y key pressed for several minutes. An option "always" on the "overwrite file" dialog or a checked option "overwrite all existing files" before the installation starts would make the process easier. Joao -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1844779&group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] compile pd with cygwin (almost!)
Hans-Christoph Steiner a écrit : > AFAIK, the watchdog isn't used on Windows anyhow, so I wouldn't worry > about it. I believed that pd-watchdog is existing on windows, and is called pd.com, they are both related with PID. I've renamed it to watchdog just for everytime I've asked mysself, "what is this watchdog, what is this pd.com?" > AFAIK, I think the MinGW and Cygwin sections in will have some > differences. If you want to duplicate code, like with portaudio and portmidi, but in both configure.in and makefile.in let it be. I'm very far from being an expert, but for me it doesn't look very nice. For the moment I've a very light definition of a 'good' code, sometimes it's better when it is duplicated, sometimes we should rather make modules. In all case I really would like to know for sure what would be the best choice before writing the definitive code. > least -mno-cygwin is not used in MinGW. using CYGFLAG would just avoid to duplicate everything for mingw. also when using g++, -mno-cygwin flag have to be placed differently, something like " -o -mno-cygwin" . > Now the problem is the one I've described before, pd.exe is mysteriously linked to cygwin1.dll, if I rename pdtcl.dll, an error message pops up to say something like it couldn't find "pthread_cond_destroy". == >> cd ../bin; dllwrap -mno-cygwin --export-all-symbol --output-def pdtcl.def \ --output-lib=pdtcl.a --dllname=pdtcl.dll ../obj/t_tkcmd.o -ldl -lm -lpth readGC2 -lwsock32 -lwinmm -lole32 -ltcl84 -ltk84 -lstdc++ -ltk84 -ltcl84 dllwrap: aucun fichier d'exportation de d'efinitions fourni. Cr'eation du fichier, mais il ne correspondra pas n'ecessairement `a ce que vous d'esirez. /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/bin/ld: AVERTISSE MENT: ne peut trouver le symbole d'entr'ee [EMAIL PROTECTED]; utilise par d' efaut 6d081000 > > > > > > > > > "Free software means you control what your computer does. Non-free > software means someone else controls that, and to some extent controls > you." - Richard M. Stallman > > ___ 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=detail&atid=478070&aid=1844526&group_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=detail&atid=478070&aid=1844526&group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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
