Re: [PD-dev] float handling in [binfile] for UTF-8 handling
On 2012-01-31 09:41, IOhannes m zmoelnig wrote: On 2012-01-31 00:52, Hans-Christoph Steiner wrote: That does make more sense, so something like [bytes2utf8], etc. utf8 is always a list of bytes. if you get values 255 than it is not utf-8; do you mean unicode points? Assumedly. There's already [wchars2bytes] in pdstring, which will convert wchar_t codepoints to a locale-dependent byte-string, but this is very system dependent. the function u8_toucs() from s_utf8.c should perform *exactly* a unicode-codepoint-string to utf8-byte-string conversion; the function u8_wc_toutf8() converts a single (unicode) character. marmosets, Bryan [apologies for multiple posts; i'm still redistributing my email accounts] -- Bryan Jurish There is *always* one more bug. moocow.bov...@gmail.com -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] general makefile question
morning all, On 2010-12-02 20:18:45, Hans-Christoph Steiner h...@at.or.at appears to have written: On Dec 2, 2010, at 4:16 AM, IOhannes m zmoelnig wrote: On 2010-12-01 23:56, Albert Graef wrote: IOhannes m zmölnig wrote: This is only a convention, of course, but it's part of the GNU Coding Standards i think the curcial part is: If there are C compiler options that must be used for proper compilation of certain files, do not include them in CFLAGS. Users expect to be able to specify CFLAGS freely themselves. and i think this can also be extrapolated for any of the standard flags (CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS) So what do you propose? Maybe I'm misreading this thread, but wasn't there something like: something like 'PD_LDFLAGS=-Wl,--export-dynamic -shared $(LDFLAGS)' and then consequently using $(PD_LDFLAGS) in the linking stage? in IOhannes' original posting? Use of a dedicated internal variable has a lot of precedents (e.g. automake's use of AM_CFLAGS etc.), and should in fact be *more* robust than the status quo... I for one am really sick of build system stuff. What we have works quite well on many platform, but yes, its not perfect. About changes to the template Makefile, last time [snip] Easy does it... please step away from any sharp objects or small furry animals for a moment... OK, now: bugs happen. I read this thread primarily as an attempt to ensure that *fewer* bugs happen in the future, and I think replacing non-standard uses of standard *FLAGS variables in any build system is a worthwhile endeavor in that respect. @IOhannes: sorry about my bogus += suggestion; posted without testing it first :-/ marmosets, Bryan -- Bryan Jurish There is *always* one more bug. jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] general makefile question
moin folks,
On 2010-12-01 18:00:21, IOhannes m zmoelnig zmoel...@iem.at appears to
have written:
what is the canonical way to use the passed FLAGS and at the same time
adding whatever is needed?
something like 'PD_LDFLAGS=-Wl,--export-dynamic -shared $(LDFLAGS)'
and then consequently using $(PD_LDFLAGS) in the linking stage?
That's probably the safest way, but a bit unwieldy... I would tend to
favor:
LDFLAGS += -Wl,--export-dynamic
in the local (pd) Makefile, just in case there happens to be something
important in the caller's (packager's) flags... but maybe the +=
operator is a GNU make extension? Maybe := in the Makefile would work
to append to any predefined LDFLAGS? Or is := also a GNU extension...
I don't really ever write makefiles for anything other than GNU make, so
I'm not too sure...
On 2010-12-01 18:16:47, Hans-Christoph Steiner h...@at.or.at appears
to have written:
But if you really want to have all the possibilities for overriding
things, then go with autotools, especially with automake. They generate
makefiles that have lots of room for customization.
+1
... but I'd like to note that autotools involve a whole new dimension of
headaches with *FLAGS variables. In particular, AC_PROG_CC() sets
CFLAGS=-g -O2 by default for gcc (if it's otherwise unset), which is
not the kind of default I usually prefer. You can reset it explicitly
in configure.ac or Makefile.am (say CFLAGS=-O2), *but* then you lose
any CFLAGS your caller might have actually passed in explicitly (e.g.
CFLAGS=-O32767 -fSuperDuperPooperScooper -WWillRobinson). I usually
work around this with shell hackery in configure.ac -- gory details in
externals/moocow/common/m4/{ax_hack_cflags,ax_pd_external}.m4 ... so
yes: autotools are flexible enough to handle this kind of thing, but not
entirely without wailing and/or gnashing of teeth...
marmosets,
Bryan
--
Bryan Jurish There is *always* one more bug.
jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Unicode works OK with cyrillic :)
morning Ilya, On 2010-08-25 23:26:52, errordevelo...@gmail.com appears to have written: Hello, just to confirm that cyrillic works fine now after git up; ./configure make yippee! but i had to copy ./src/pd into ./bin .. and typing object names is russian gives obj box which is not wide enough .. hmm... that could also be a problem with the utf8 code which maps between logical character lengths and byte lengths... do you have an example patch or an example object name (utf-8 encoded preferably :-) which overflows its box? There may be some potential hiccups with unicode combining diacritic characters (U+0300 - U+036F) -- afaik, these animals should never actually allocate any width for themselves, but rather attach to the most recent normal character. I seem to vaguely recall some fonts and/or renderers though which treat combining diacritics as normal characters (i.e. requiring their own width allocation). I believe I tried some combining diacritics in my utf-8 test patches (I see them a lot these days, most commonly U+0364 = combining latin small letter e), and seem to recall that Tk (8.5) rendered them correctly, but I may be misremembering... may be using different font it would work .. ... which fonts are you using? marmosets, Bryan -- Bryan Jurish There is *always* one more bug. jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Makefile/library template
morning Hans, morning Yves|sevy, On 2010-04-06 19:09:09, Hans-Christoph Steiner h...@at.or.at appears to have written: We don't have it only because no one has made it. Well, it's not 100% plug-and-play, but there *is* a documented example of using autoconf automake to build a pd external which has been available for some time in svn: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/moocow/hello/README.html?content-type=text%2Fhtml searching the list archives for 'automake' also reveals some more on this topic: http://lists.puredata.info/pipermail/pd-dev/2009-03/013156.html http://lists.puredata.info/pipermail/pd-dev/2006-12/008114.html http://lists.puredata.info/pipermail/pd-dev/2007-11/010265.html For most libraries, autoconf is too complicated. This Makefile is for those situations. Agreed. It *ought* to be easier than it currently is, though (if I could only figure out how to hack the extension rule for libtool libraries...) marmosets, Bryan On Apr 6, 2010, at 12:48 PM, ydego...@free.fr wrote: ola, why don't we have an autoconf template? i'm sorry i don't want some libraries to be compiled without autoconf salaam, sevy Hans-Christoph Steiner wrote: I started a wiki page and example library for the Makefile template. Please check it out and give feedback suggestions, etc. http://puredata.info/docs/developer/MakefileTemplate https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/template -- Bryan Jurish There is *always* one more bug. jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] UTF-8 for pd-devel (again)
morning all, attached is a UTF-8 support patch against branches/pd-gui-rewrite/0.43 revision 13051 (HEAD as of an hour or so ago). most of the bulk is new files (s_utf8.c, s_utf8.h), most other changes are in g_rtext.c. It's not too monstrous, and I've tested it again here briefly with some utf-8 test patches (see other attachment), and things appear to be working as expected. if desired, I can check this in; otherwise feel free to do it for me ;-) 2 annoying things here during testing (I don't see how my patches could have caused this, but you never know): (1) all loaded patch windows appear at +0+0 (upper left corner), which with my wm (windowmaker) means the title bar is off the screen, and I have to resort to keyboard shortcuts to get them mouse-draggable, which is a major pain in the wazoo: is this a known bug? (2) I can't figure out how to get at the properties dialog for number, number2, or any other gui-atom objects: should these be working already? marmosets, Bryan On 2010-01-18 23:09:34, Hans-Christoph Steiner h...@eds.org appears to have written: Awesome! If its big and complicated, I say post it to the list first, if not too bad, then just commit. .hc On Jan 18, 2010, at 4:47 AM, Bryan Jurish wrote: moin Hans, moin list, I think perhaps I never actually did post the cleaned-up patch anywhere (bad programmer, no biscuit); I guess I'll check out branches/pd-gui-rewrite/0.43 and try patching my changes in; then I can either commit or just post the (updated) patch. Hopefully no major additional changes will be required, so it ought to go pretty fast. marmosets, Bryan On 2010-01-17 22:57:33, Hans-Christoph Steiner h...@eds.org appears to have written: Hey Bryan, I'd like to try to get your UTF-8 code into pd-gui-rewrite. You mention in this posting back in May that you had the whole thing working. I couldn't find the diff/patch for this. Is it posted anywhere? Do you want to try to check it in yourself directly to the pd-gui-rewrite/0.43 branch? .hc On Mar 20, 2009, at 6:16 PM, Bryan Jurish wrote: morning all, Of course I never really like to see my code wither away in the bit bucket, but I personally don't have any pressing need for UTF-8 symbols, comments, etc. in Pd -- I'm a native English speaker, after all ;-) Also, my changes are by no means the only way to do it (or even the best way); we could gain a little speed by slapping on some more buffers (mostly and possibly only in rtext_senditup()), but since this seems to effect only GUI/editing stuff, I think we can live with a smidgeon of additional cpu time ... after all, it's all O(n) anyways. Really I just wanted to see how easy (or difficult) it would be to get Pd to use UTF-8 as its internal encoding... turned out to be harder than I had thought, but (ever so slightly) easier than I had feared :-/ marmosets, Bryan On 2009-03-20 18:39:06, Hans-Christoph Steiner h...@eds.org appears to have written: I wonder what the best approach is to getting it included. I also think its a very valuable contribution. I think we need to first get the Tcl/Tk only changes done, since that was the mandate of the pd-devel 0.41 effort. Then once Miller has accepted those changes, then we can start with the C modifications there. So how to proceed next, I think is based on how eager you are, Bryan, to getting this in a regular build. One option is making a pd-devel-utf8 branch, another is posting these patches to the patch tracker and waiting for Miller to make his next update with the Pd-devel Tcl-Tk code. Maybe we can get Miller to chime in on this topic. .hc On Mar 13, 2009, at 12:00 AM, dmotd wrote: hey bryan, just a quick note of a appreciation for getting this one out.. i hope it gets picked up in millers build soon.. a very useful and necessary modification. well done! dmotd On Thursday 12 March 2009 08:07:50 Bryan Jurish wrote: moin folks, I believe I've finally got pd-devel 0.41-4 using UTF-8 across the board. So far, I've tested message boxes comments (g_rtext), as well as symbol atoms, and all seems good. I think we can still expect goofiness if someone names an abstraction using a multibyte character when the filesystem isn't UTF-8 encoded (raw 8-bit works for me here too), but I really don't want to open that particular can of worms. So I guess I have 2 questions: (1) what should I call the generic UTF-8 source files? (see my other post) (2) shall I commit these changes to pd-devel/0.41-4, or somewhere else, or just post a diff (ca. 33k, ought to be easier to read now; I've tried to follow the indentation conventions of the source files I modified)? marmosets, Bryan -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
Re: [PD-dev] UTF-8 for pd-devel (again)
moin Hans, moin list, I think perhaps I never actually did post the cleaned-up patch anywhere (bad programmer, no biscuit); I guess I'll check out branches/pd-gui-rewrite/0.43 and try patching my changes in; then I can either commit or just post the (updated) patch. Hopefully no major additional changes will be required, so it ought to go pretty fast. marmosets, Bryan On 2010-01-17 22:57:33, Hans-Christoph Steiner h...@eds.org appears to have written: Hey Bryan, I'd like to try to get your UTF-8 code into pd-gui-rewrite. You mention in this posting back in May that you had the whole thing working. I couldn't find the diff/patch for this. Is it posted anywhere? Do you want to try to check it in yourself directly to the pd-gui-rewrite/0.43 branch? .hc On Mar 20, 2009, at 6:16 PM, Bryan Jurish wrote: morning all, Of course I never really like to see my code wither away in the bit bucket, but I personally don't have any pressing need for UTF-8 symbols, comments, etc. in Pd -- I'm a native English speaker, after all ;-) Also, my changes are by no means the only way to do it (or even the best way); we could gain a little speed by slapping on some more buffers (mostly and possibly only in rtext_senditup()), but since this seems to effect only GUI/editing stuff, I think we can live with a smidgeon of additional cpu time ... after all, it's all O(n) anyways. Really I just wanted to see how easy (or difficult) it would be to get Pd to use UTF-8 as its internal encoding... turned out to be harder than I had thought, but (ever so slightly) easier than I had feared :-/ marmosets, Bryan On 2009-03-20 18:39:06, Hans-Christoph Steiner h...@eds.org appears to have written: I wonder what the best approach is to getting it included. I also think its a very valuable contribution. I think we need to first get the Tcl/Tk only changes done, since that was the mandate of the pd-devel 0.41 effort. Then once Miller has accepted those changes, then we can start with the C modifications there. So how to proceed next, I think is based on how eager you are, Bryan, to getting this in a regular build. One option is making a pd-devel-utf8 branch, another is posting these patches to the patch tracker and waiting for Miller to make his next update with the Pd-devel Tcl-Tk code. Maybe we can get Miller to chime in on this topic. .hc On Mar 13, 2009, at 12:00 AM, dmotd wrote: hey bryan, just a quick note of a appreciation for getting this one out.. i hope it gets picked up in millers build soon.. a very useful and necessary modification. well done! dmotd On Thursday 12 March 2009 08:07:50 Bryan Jurish wrote: moin folks, I believe I've finally got pd-devel 0.41-4 using UTF-8 across the board. So far, I've tested message boxes comments (g_rtext), as well as symbol atoms, and all seems good. I think we can still expect goofiness if someone names an abstraction using a multibyte character when the filesystem isn't UTF-8 encoded (raw 8-bit works for me here too), but I really don't want to open that particular can of worms. So I guess I have 2 questions: (1) what should I call the generic UTF-8 source files? (see my other post) (2) shall I commit these changes to pd-devel/0.41-4, or somewhere else, or just post a diff (ca. 33k, ought to be easier to read now; I've tried to follow the indentation conventions of the source files I modified)? marmosets, Bryan -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology The arc of history bends towards justice. - Dr. Martin Luther King, Jr. -- *** Bryan Jurish Deutsches Textarchiv Berlin-Brandenburgische Akademie der Wissenschaften Jägerstr. 22/23 10117 Berlin Tel.: +49 (0)30 20370 539 E-Mail:jur...@bbaw.de *** ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pkg-config on mingw
moin Hans, bizarre. I had some other problems later which I attributed to pkg-config, but I'm afraid I don't recall the error message, or where they occurred. maybe we should do like the pkg-config folks suggest and try building pkg-config with a static local copy of glib-1.x? marmosets, Bryan On 2009-06-12 22:23:17, Hans-Christoph Steiner h...@at.or.at appears to have written: So I followed August's and Bryan's instructions on using the GTK+ pkg-config binary from here: http://www.gtk.org/download-windows.html When I run it (on two different machines) I get the error Bad file number' .hc News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] moocow readdir plans for Pd-extended 0.41.4
moin Hens, moin all, i haven't been actively working on making readdir compile under win32, but it's near the top of my todo list. afaic, go ahead and release. i think the win32-safety readdir changes ought to be quick and easy, but cf. signature ;-) marmosets, Bryan On 2009-05-13 16:17:42, Hans-Christoph Steiner h...@at.or.at appears to have written: Hey Brian, It looks like you are trying to get readdir going in Windows, based on the build error. I just wanted to know whether you are working on it now, or its a build fluke. I'd like to get an RC1 released, so I am just checking what the status is. I think I'll do an RC1 release without Windows for now, then RC2 will include Windows and hopefully readdir. .hc -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] moocow readdir plans for Pd-extended 0.41.4
moin Hans, I'm surprised it ever did ... that actual build call is wrapped in 2 recursive $(MAKE) calls (as viewed from the $(MAKE) for externals/Makefile), both of which are of the form: $(MAKE) -C somewhere/else myTarget || echo MOO: ... failed ... since 'echo' always succeeds (afaik), these rules should never break anything above them. Also, the MOO: messages are handy for me when grepping through the logs. I started doing this after I did in fact stop all the auto-builds after first adding the 'moocow' target. Since that was far too embarrassing, I decided to do it this way instead ;-) anyhoo, [readdir] may be building on win32 as early as tomorrow (i expect it will, but haven't tested 'cuz i'm too lazy). the win32 version is limping a bit for now (all entries are reported as type 'unknown'), but the guts ought to work. marmosets, Bryan On 2009-05-14 18:52:18, Hans-Christoph Steiner h...@at.or.at appears to have written: The rsyncing freaks out a lot on Winblows... readdir doesn't seem to get built there, but it doesn't stop the build any more. .hc On May 14, 2009, at 3:47 AM, Bryan Jurish wrote: moin Hens, moin all, i haven't been actively working on making readdir compile under win32, but it's near the top of my todo list. afaic, go ahead and release. i think the win32-safety readdir changes ought to be quick and easy, but cf. signature ;-) marmosets, Bryan On 2009-05-13 16:17:42, Hans-Christoph Steiner h...@at.or.at appears to have written: Hey Brian, It looks like you are trying to get readdir going in Windows, based on the build error. I just wanted to know whether you are working on it now, or its a build fluke. I'd like to get an RC1 released, so I am just checking what the status is. I think I'll do an RC1 release without Windows for now, then RC2 will include Windows and hopefully readdir. .hc --Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology Mistrust authority - promote decentralization. - the hacker ethic ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] win32 build farm machine: humble requests
moin Hans, moin all, So most of my packaged externals are (or ought to be) building on win32 now. Missing are [flite] and [gfsm]. I don't know whether libflite builds under mingw, so i'm ignoring that for now. I think [gfsm] ought to build though, since i've successfully built the underlying libgfsm with mingw in the past. From what configure is leaving in the logs though, there appear to be some packages missing on the build farm machine: + libglib-2.x - abstract data structures algorithms without which gfsm wouldn't be - apparently available at: http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.20/glib_2.20.1-1_win32.zip (bin) and http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.20/glib-dev_2.20.1-1_win32.zip (dev) + pkg-config - required; I know it's stupid, but I use this to find libglib-2.x - There would appear to be a win32 binary available at: http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/pkg-config-0.23-2.zip + zlib - optional, but highly recommended - available at: http://www.zlib.net/zlib123-dll.zip - also allegedly included in the msys supplementary tools package Above URLs courtesy of the gtk/glib win32 page: http://www.gtk.org/download-windows.html ... any chance of getting these installed? marmosets, Bryan -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 'externals' bug fixes before the pd-extended 0.41.4 branch
moin Hans, moin all, oops ... many apologies if (as it seems) I was holding up the show with my quoting nightmare ;-) in re: bugfixes: readdir is still not building on win32 (easy to fix, maybe this weekend), flite seems to build almost nowhere but debian, and the last I checked, a number of ubuntu flavors were flaking out (at least with my stuff, but I think the builds were crashing before the 'moocow' target even got called). that said, i certainly have no objections to calling the current state of affairs a release candidate, since I don't know when I'll get around to the fixes; when that happens, I guess we can always point people at the daily builds for the bleeding-edge... marmosets, Bryan On 2009-04-29 19:44:01, Hans-Christoph Steiner h...@at.or.at appears to have written: Ok, now that Bryan got his lovely moocow collection building on Windows, I think we are ready for the first release candidate of Pd-extended 0.41.4. To do that, everything needs to be added to branches/pd-extended 0.41.4. Anyone have any pending bug fixes for the 'externals' section? That's the last section that is not already in the release branch. .hc -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] win32 build farm 'msys.exe' (WAS: symlinks render pdstring unbuildable on MinGW/Windows)
moin all,
Good call, Martin: thanks!
In case anyone else runs into this or something similar, here are some
gory details:
It turns out that both single and double quotes cause ./configure to
spit, and my initial inability to reproduce the error here was just me
being dense, sleepy, etc. It seems that since autoconf's CFLAGS
variable (and its value) has to do double-duty as both a shell (as
called by ./configure) and a make variable, *any* kind of quotes are
graphema non grata, unless you do something horrid like setting
CC=eval gcc ;-)
Contrast the shell script:
| #!/bin/sh
| CFLAGS=-g -D'UglyQuotedMacro=1'
| gcc $CFLAGS conftest.c
with the Makefile:
| CFLAGS=-g -D'UglyQuotedMacro=1'
| a.out: ; gcc $(CFLAGS) conftest.c
for a dummy C file conftest.c:
| int main (void) { return 0; }
... the shell script pukes, but make runs fine, since the make variable
gets passed through an additional shell evaluation. So the problem was
indeed the -D'whatever' macros getting passed into ./configure by make.
Duh...
Not sure how to fix this the right way (or even if that's possible):
for now I'm just assuming that all relevant flags don't contain any
spaces or other characters needing escapes, and that seems to work well
on the build farm machine (tested locale and pdstring only so far).
marmosets,
Bryan
On 2009-04-25 03:13:24, Martin Peach martin.pe...@sympatico.ca appears
to have written:
Bryan Jurish wrote:
This is still stumping me. The win32 build farm machine's config.log is
showing me (for externals/moocow/locale):
configure:2701: gcc \
-DPD -O2 -mcpu=i586 -mtune=pentium3 \
-I/home/pd/auto-build/pd-extended/pd/src \
-Wall -W -ggdb \
-I/home/pd/auto-build/pd-extended/Gem/src \
-mms-bitfields \
-DMSW -DNT -D'O_NONBLOCK=1' -D'srand48(n)=srand((n))' \
-D'drand48()=((double)rand()/RAND_MAX)' -D'bzero(p,n)=memset(p,0,n)' \
-L/home/pd/auto-build/pd-extended/pd/bin \
conftest.c 5
command line:4:1: macro names must be identifiers
command line:5:1: macro names must be identifiers
command line:6:1: macro names must be identifiers
command line:7:1: macro names must be identifiers
I'm guessing here but it looks like the 4th, 5th 6th and 7th defines in
the command line are causing trouble. Indeed they are not identifiers as
such, they are just strings. One thing that looks odd is the single
quote '' instead of the more commonly used . Without knowing what that
particular combo of gcc and shell most enjoys, I would change that and
see what happens next.
--
Bryan Jurish There is *always* one more bug.
jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] win32 build farm 'msys.exe' (WAS: symlinks render pdstring unbuildable on MinGW/Windows)
moin Hans, moin list,
On 2009-04-20 02:10:17, Hans-Christoph Steiner h...@eds.org appears to
have written:
On Apr 19, 2009, at 5:22 AM, Bryan Jurish wrote:
moin Hans,
On 2009-04-18 06:57:53, Hans-Christoph Steiner h...@eds.org appears to
have written:
The bad news is that it seems that my bad diagnosis led you on a wide
goose chase thru the pain of Windows development.
It may or may not have been a bad diagnosis (although it certainly was a
pain ;-) -- I still haven't verified the former, since I don't use (or
understand) all of the auto-build scripts. I'm still kinda hoping
IOhannes might make some headway there...
You don't really need to understand the auto-build scripts, all that
needs to work is this:
cd pure-data/externals
make moocow
make moocow_install
yup, I've understood that bit (and the motivations, I think). I meant
that since the problems arising in 'make moocow' appear to have been
*due to* clever fiendish details of earlier scripts (e.g. use of rsync
rather than svn, the cygwin/mingw dichotomy, etc. etc.), it would have
behooved me to have understood those scripts better (e.g. at all)...
Apparently,
string2any and friends are still not getting built. In fact all of the
'moocow' is empty on Windows.
This is still stumping me. The win32 build farm machine's config.log is
showing me (for externals/moocow/locale):
configure:2701: gcc \
-DPD -O2 -mcpu=i586 -mtune=pentium3 \
-I/home/pd/auto-build/pd-extended/pd/src \
-Wall -W -ggdb \
-I/home/pd/auto-build/pd-extended/Gem/src \
-mms-bitfields \
-DMSW -DNT -D'O_NONBLOCK=1' -D'srand48(n)=srand((n))' \
-D'drand48()=((double)rand()/RAND_MAX)' -D'bzero(p,n)=memset(p,0,n)' \
-L/home/pd/auto-build/pd-extended/pd/bin \
conftest.c 5
command line:4:1: macro names must be identifiers
command line:5:1: macro names must be identifiers
command line:6:1: macro names must be identifiers
command line:7:1: macro names must be identifiers
configure:2704: $? = 1
configure:2742: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME locale
| #define PACKAGE_TARNAME locale
| #define PACKAGE_VERSION 0.02-1
| #define PACKAGE_STRING locale 0.02-1
| #define PACKAGE_BUGREPORT moo...@ling.uni-potsdam.de
| #define PACKAGE locale
| #define VERSION 0.02-1
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2749: error: C compiler cannot create executables
... newline escapes in the gcc call added post-hoc for legibility. The
above call works fine (creating a.exe) by hand on the build farm win32
machine with /cygdrive/c/msys/1.0/bin:/cygdrive/c/MinGW/bin prepended
to PATH, so I can't grok where things might be going wrong, much less
what the macro names must be identifiers errors are all about --
assumedly some of the '-D' flags are giving me grief, but since I can't
reproduce the error, I can't tell which ones or what to do about it.
Anyone have any ideas?
I can't use rdesktop currently, since it's telling me I'd have to kick
out another user (pd).
In a related question, should the auto-build process for the win32
build-farm machine be trying to build everything from the LIB_TARGETS
variable in externals/Makefile? If so, then I must be being pretty
dense, because I can't see where my builds are getting called (I see
install calls, but no configuration or compilation), much less where
they might be failing...
You are correct. Search for 'moocow_install:' in externals/Makefile.
That's where its being called.
Yes, right; but I couldn't see (until the rsync fix/hack was applied)
where the 'moocow' target was getting called, thus recursing into
externals/moocow/extended. That's showing up now, so no worries.
marmosets,
Bryan
--
Bryan Jurish There is *always* one more bug.
jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
[PD-dev] win32 build farm 'msys.exe' (WAS: symlinks render pdstring unbuildable on MinGW/Windows)
moin Hans, On 2009-04-18 06:57:53, Hans-Christoph Steiner h...@eds.org appears to have written: The bad news is that it seems that my bad diagnosis led you on a wide goose chase thru the pain of Windows development. It may or may not have been a bad diagnosis (although it certainly was a pain ;-) -- I still haven't verified the former, since I don't use (or understand) all of the auto-build scripts. I'm still kinda hoping IOhannes might make some headway there... Apparently, string2any and friends are still not getting built. In fact all of the 'moocow' is empty on Windows. Here's the bug report: https://sourceforge.net/tracker/?func=detailaid=2138593group_id=55736atid=478070 I noticed this too, and am currently trying to figure out exactly why. Actually, I didn't really expect any of my externals to build on windows currently, since I was missing test clauses for win32 in ax_pd_external.m4. I've added the test clauses now, and at least win32 on the build farm machine is getting properly recognized, but I'm getting a whole mess of other (stupid) errors which are preventing manual compilation: 'msys.bat' doesn't run on the autobuild machine from the cygwin shell I get when I ssh in: is this (easily) fixable? I can run /cygdrive/c/msys/1.0/bin/sh manually, but it's not really useable as an interactive shell. So far I've been explicitly calling $MSYS_SH ./configure to test, for MSYS_SH=/cygdrive/c/msys/1.0/bin/sh.exe I've tried manually prepending /cygdrive/c/msys/1.0/bin:/cygdrive/c/MinGW/bin to PATH, and that gets me all the mingw programs, but their compiled-in paths (e.g. include paths for gcc) are foobared, since cygwin's pseudo-filesystem doesn't jive with the msys one. In particular, I'm getting: pd...@windowsxp-i386$ sh ./configure \ --with-pd-include=/home/pd/auto-build/pd-extended/pd/src ... checking for string.h... no configure: WARNING: could not find standard C headers -- things may get ugly ... similar problems with linker paths. I've hacked this for now by setting CPPFLAGS and LDFLAGS, and the updated version of pdstring seems to build ok. Part of the problem might be MinGW's very old version of autotools: automake 1.7 and libtool 1.4, which is a big bummer. This shouldn't be a problem, since I've been storing autoconf-generated stuff in svn anyways, and calling AM_MAINTAINER_MODE to ensure that it doesn't get implicitly rebuilt. See the thread [PD-dev] moocow: svn and compilation issues for more details. In a related question, should the auto-build process for the win32 build-farm machine be trying to build everything from the LIB_TARGETS variable in externals/Makefile? If so, then I must be being pretty dense, because I can't see where my builds are getting called (I see install calls, but no configuration or compilation), much less where they might be failing... marmosets, Bryan On Mar 7, 2009, at 5:14 PM, Bryan Jurish wrote: moin Hans, Short version: should be fixed now. package-local links to the common code are now no longer tracked by SVN, but kludged into place by an ./svn-prepare.sh (symlink ;-) in each package directory, alternately by the DIR.autogen_stamp target in extended/Makefile. More comments: see below. On 2009-03-05 23:44:58, Hans-Christoph Steiner h...@eds.org appears to have written: On Mar 5, 2009, at 5:22 PM, Bryan Jurish wrote: On 2009-03-05 21:33:36, Hans-Christoph Steiner h...@eds.org appears to have written: On Mar 4, 2009, at 4:23 PM, Bryan Jurish wrote: On 2009-03-04 05:37:40, Hans-Christoph Steiner h...@eds.org appears to have written: I was just trying to build string2any and friends on Windows for a student, but the symlinks used in moocow are throwing a huge wrench in the process. They show up at .lnk files, and are not links at all. That's because cygwin translates symlinks into Windows shortcuts, aka .lnk. [snip] the rsync -L flag (--copy-links) works for me here, even with a preceding -a (--archive)... does that not work on cygwin? The only times I've ever had problems with -L were symlink cycles (./dir - .), which I certainly am not inserting into the repository. Sorry, I had no intention to insult or demean, I guess I was just terse. No worries; the whole mess really arises from my not having the time to dig around in the automake internals (bad programmer, no biscuit): I'm sure there's a way to get the common code into its own automake+autoconf package, but I haven't figured it out yet. Ideally, I'd like to have an family of automake _PDEXTERNALS targets (analagous to _PROGRAMS, _LIBRARIES, _DATA, etc.), but that's not happening yet; hence the intermediate solution ../common, which goes pretty far towards eliminating the headaches necessary to roll up a new external package or add new functionality to an existing package. The bad news is that its not that simple. I added --no-l --copy-links to cygwin rsync and it still doesn't work. Curioser
Re: [PD-dev] moocow: svn and compilation issues
moin Roman, On 2009-04-06 20:55:10, Roman Haefeli reduzie...@yahoo.de appears to have written: hi all, hi bryan i tried to compile pdstring from moocow from a fresh svn checkout and encountered some issues. - moocow/autoreconf.sh when invoked from shell, it gives the error: ../autoreconf.sh: 3: Syntax error: ( unexpected i guess, that is because it is using the wrong shebang. it runs fine, when the shebang calls bash and not sh, like: #!/bin/bash You're probably right and autoreconf should call bash rather than sh. That said, you shouldn't need to call autoreconf.sh (or any package-local autogen.sh, which serves the same purpose) yourself at all these days. Those scripts are meant to be maintainer-only. - moocow/pdstring/ don't know exactly, if that is intended or not, but there seems to be a confusion with autogenerated files and files checked out from svn. Yup. my instinct tells me, that files, that are generated by some other scripts shouldn't be checked into the repository: when i call './autogen.sh', it will create some files. My instinct (and aesthetics) tell me the same thing. Nonetheless, checking the generated files (Makefile.in, config.h.in, configure ...) into svn is the only way I've found (to date) to get my externals auto-building nicely with the pd-extended build system. Without going into all the gory details, the build farm machines are running so many different versions of automake and autoconf that it made more sense for me just to bite the bullet and check in the generated files. It ain't pretty, but that's how it is. now, when i later run an 'svn update', in the meanwhile those files might have changed in the repository, and svn doesn't want to overwrite the ones, that were generated by the script. Yup. Which is why you probably shouldn't be running autoreconf.sh yourself, unless you really *are* mucking about with configure.ac, Makefile.am and the like. I suppose I probably ought to update the README to reflect this ;-) i am not able to exactly describe what happened, but i just poked around a bit and then it worked. i cannot exactly recall all the commands i tried. anyway, i had to manually 'rm makefile* config*' followed by 'svn update' in order to be able to compile pdstring without errors. I suspect you eventually ran ./svn-prepare.sh, which is the current Ugly Hack which needs to run before things will build; all it really does is (ln -s ../common .); gory details on why it's required are lurking in the pd-dev archives. marmosets, Bryan -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] UTF-8 for pd-devel (again)
morning all, Of course I never really like to see my code wither away in the bit bucket, but I personally don't have any pressing need for UTF-8 symbols, comments, etc. in Pd -- I'm a native English speaker, after all ;-) Also, my changes are by no means the only way to do it (or even the best way); we could gain a little speed by slapping on some more buffers (mostly and possibly only in rtext_senditup()), but since this seems to effect only GUI/editing stuff, I think we can live with a smidgeon of additional cpu time ... after all, it's all O(n) anyways. Really I just wanted to see how easy (or difficult) it would be to get Pd to use UTF-8 as its internal encoding... turned out to be harder than I had thought, but (ever so slightly) easier than I had feared :-/ marmosets, Bryan On 2009-03-20 18:39:06, Hans-Christoph Steiner h...@eds.org appears to have written: I wonder what the best approach is to getting it included. I also think its a very valuable contribution. I think we need to first get the Tcl/Tk only changes done, since that was the mandate of the pd-devel 0.41 effort. Then once Miller has accepted those changes, then we can start with the C modifications there. So how to proceed next, I think is based on how eager you are, Bryan, to getting this in a regular build. One option is making a pd-devel-utf8 branch, another is posting these patches to the patch tracker and waiting for Miller to make his next update with the Pd-devel Tcl-Tk code. Maybe we can get Miller to chime in on this topic. .hc On Mar 13, 2009, at 12:00 AM, dmotd wrote: hey bryan, just a quick note of a appreciation for getting this one out.. i hope it gets picked up in millers build soon.. a very useful and necessary modification. well done! dmotd On Thursday 12 March 2009 08:07:50 Bryan Jurish wrote: moin folks, I believe I've finally got pd-devel 0.41-4 using UTF-8 across the board. So far, I've tested message boxes comments (g_rtext), as well as symbol atoms, and all seems good. I think we can still expect goofiness if someone names an abstraction using a multibyte character when the filesystem isn't UTF-8 encoded (raw 8-bit works for me here too), but I really don't want to open that particular can of worms. So I guess I have 2 questions: (1) what should I call the generic UTF-8 source files? (see my other post) (2) shall I commit these changes to pd-devel/0.41-4, or somewhere else, or just post a diff (ca. 33k, ought to be easier to read now; I've tried to follow the indentation conventions of the source files I modified)? marmosets, Bryan -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] UTF-8 for pd-devel (again)
moin Hans, moin list,
Alright, diff attached. Should be pretty well human-readable, and
comments should be mostly self explanatory (famous last words). A few
changes (or lack thereof) deserve special mention, since they don't
directly relate to UTF-8 handling:
Tk proc pdtk_canvas_editval in src/pdtk_canvas.tcl:
+ SVN HEAD code caused a race condition / loop of 'pdsend pd_editmode'
calls as bound to the menu entry for 'Edit Mode', which made editing
impossible. My reversion to the formerly commented-out code makes
editing possible again, but display and toggle are still buggy. Oddly,
I didn't encounter this bug during the whole debugging process (despite
occasional edits of a test patch), but it does happen here now with both
a clean SVN HEAD version of pd-devel/0.41-4 as well as my cleaned-up
working copy. Maybe all my debug code (not in the diff) was slowing
things down enough to avoid the loop...
Tk variable font_fixed_metrics src/pd.tk:
+ the values here are inconsistent with those in sys_fontlist[] in
s_main.c. My fonts looked much better when I changed the tk variable to
jive with sys_fontlist[]. Also, with the current version, the
pixel-to-character translation code in g_rtext.c doesn't work right (as
of the 3rd or 4th line of text). I haven't included this change in the
diff (except for comments where relevant), since I'm not sure whether
the inconsistency was intensional (e.g. to test font metric computation
and communication)...
new C sources src/s_utf8.h, src/s_utf8.c
+ modified and trimmed versions of the Bezanson code. I actually only
use 3 or 4 functions of these, so it could conceivably be trimmed down
even further; I just cut out the stuff I don't expect to need (escapes,
vprintf, ...). Should remain separate source files though, since
they're needed in both g_rtext.c and g_editor.c.
marmosets,
Bryan
On 2009-03-12 02:03:04, Hans-Christoph Steiner h...@eds.org appears to
have written:
On Mar 11, 2009, at 6:07 PM, Bryan Jurish wrote:
moin folks,
I believe I've finally got pd-devel 0.41-4 using UTF-8 across the board.
So far, I've tested message boxes comments (g_rtext), as well as
symbol atoms, and all seems good. I think we can still expect goofiness
if someone names an abstraction using a multibyte character when the
filesystem isn't UTF-8 encoded (raw 8-bit works for me here too), but I
really don't want to open that particular can of worms.
So I guess I have 2 questions:
(1) what should I call the generic UTF-8 source files? (see my other
post)
I don't quite follow... do you mean there are separate .c files for the
UTF-8 code?
Yes, there is 1 .c and 1 .h file for utf8 handling, in the diff as
s_utf8.[ch]. I was tempted to use z_, but didn't want to be the first ;-)
I guess I am not sure which post you mean.
The one with subject Pd C source prefix conventions?.
(2) shall I commit these changes to pd-devel/0.41-4, or somewhere else,
or just post a diff (ca. 33k, ought to be easier to read now; I've tried
to follow the indentation conventions of the source files I modified)?
If there are major changes to the C code, we'll have to run that by
Miller. He's already more or less accepted the existing pd-devel Tcl
code, so he might be willing to accept these C changes as well. I think
its really important work, especially since Pd-devel also has localized
menus and text.
I'm not sure how major the changes are... they're pretty much
restricted to a few lines in g_editor.c, and a smattering of changes in
g_rtext.c. Most heavily hit was rtext_senditup(), which now has to keep
track of both byte offsets (for C) and logical character offsets (for
Tk). I renamed a few local variables there to help keep track of what
was being counted where. I haven't added any fields to any built-in
structs though, nor changed the interpretation of any existing fields,
parameters, etc., so everything else ought to be pretty much compatible.
If you have the diff, maybe post it here and let's start there.
here it is...
marmosets,
Bryan
--
Bryan Jurish There is *always* one more bug.
jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
Index: src/g_editor.c
===
--- src/g_editor.c (revision 10858)
+++ src/g_editor.c (working copy)
@@ -9,6 +9,7 @@
#include s_stuff.h
#include g_canvas.h
#include string.h
+#include s_utf8.h /*-- moo --*/
void glist_readfrombinbuf(t_glist *x, t_binbuf *b, char *filename,
int selectem);
@@ -1468,8 +1469,9 @@
gotkeysym = av[1].a_w.w_symbol;
else if (av[1].a_type == A_FLOAT)
{
-char buf[3];
-sprintf(buf, %c, (int)(av[1].a_w.w_float));
+/*-- moo: assume keynum is a Unicode codepoint; encode as UTF-8 --*/
+char buf[UTF8_MAXBYTES1];
+u8_wc_toutf8_nul(buf, (UCS4)(av[1].a_w.w_float));
gotkeysym = gensym(buf
[PD-dev] Pd C source prefix conventions?
moin folks, I'm a wee bit embarrassed to have to ask after all this time, but: does anyone have any quick guidelines and/or mnemonics for the prefix conventions of the Pd sources? My intuitions say something like: d_* : DSP stuff g_* : GUI stuff m_* : ? s_* : system stuff (?) x_* : ? ... but I'm rather uncertain. I ask because I'd like to add a few files for generic UTF-8 utilities to the pd-devel branch, and I'm not sure what prefix (if any) to give them, to stay within existing conventions. marmosets, Bryan -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] UTF-8 for pd-devel (again)
moin folks, I believe I've finally got pd-devel 0.41-4 using UTF-8 across the board. So far, I've tested message boxes comments (g_rtext), as well as symbol atoms, and all seems good. I think we can still expect goofiness if someone names an abstraction using a multibyte character when the filesystem isn't UTF-8 encoded (raw 8-bit works for me here too), but I really don't want to open that particular can of worms. So I guess I have 2 questions: (1) what should I call the generic UTF-8 source files? (see my other post) (2) shall I commit these changes to pd-devel/0.41-4, or somewhere else, or just post a diff (ca. 33k, ought to be easier to read now; I've tried to follow the indentation conventions of the source files I modified)? marmosets, Bryan -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology inline: test-utf8-v2.png___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] symlinks render pdstring unbuildable on MinGW/Windows
moin Hans, Short version: should be fixed now. package-local links to the common code are now no longer tracked by SVN, but kludged into place by an ./svn-prepare.sh (symlink ;-) in each package directory, alternately by the DIR.autogen_stamp target in extended/Makefile. More comments: see below. On 2009-03-05 23:44:58, Hans-Christoph Steiner h...@eds.org appears to have written: On Mar 5, 2009, at 5:22 PM, Bryan Jurish wrote: On 2009-03-05 21:33:36, Hans-Christoph Steiner h...@eds.org appears to have written: On Mar 4, 2009, at 4:23 PM, Bryan Jurish wrote: On 2009-03-04 05:37:40, Hans-Christoph Steiner h...@eds.org appears to have written: I was just trying to build string2any and friends on Windows for a student, but the symlinks used in moocow are throwing a huge wrench in the process. They show up at .lnk files, and are not links at all. That's because cygwin translates symlinks into Windows shortcuts, aka .lnk. [snip] the rsync -L flag (--copy-links) works for me here, even with a preceding -a (--archive)... does that not work on cygwin? The only times I've ever had problems with -L were symlink cycles (./dir - .), which I certainly am not inserting into the repository. Sorry, I had no intention to insult or demean, I guess I was just terse. No worries; the whole mess really arises from my not having the time to dig around in the automake internals (bad programmer, no biscuit): I'm sure there's a way to get the common code into its own automake+autoconf package, but I haven't figured it out yet. Ideally, I'd like to have an family of automake _PDEXTERNALS targets (analagous to _PROGRAMS, _LIBRARIES, _DATA, etc.), but that's not happening yet; hence the intermediate solution ../common, which goes pretty far towards eliminating the headaches necessary to roll up a new external package or add new functionality to an existing package. The bad news is that its not that simple. I added --no-l --copy-links to cygwin rsync and it still doesn't work. Curioser and curioser. I just tried an rsync from linux (with symlinks) to cygwin with -a --no-l --copy-links here, and I got copies of the symlinks rather than windoof shortcuts. Can you point me at the (script containining the) full rsync call so I can test that here? There is nothing you have to do here, I just thought it'd be nice to have those externals included in Windows. Here are the logs, it seems it doesn't find the compiler properly: http://bxmc.poly.edu/pdlab/moocow_log.txt http://bxmc.poly.edu/pdlab/config.log 403 forbidden not really important though, since the AC_CONFIG_LINKS() symlinks aren't the problem. What I don't understand is why this code needs such a complicated build system? As far as I can tell, it is mostly pretty standard C code. If you're asking that now, it's probably a good thing I didn't delegate external building to libtool ;-) It's (mostly) not the *code* which needs automake, it's *me* who wants it. Having 'distcheck' and 'dist' targets generated auto-magically is really outrageously spiffy. And with the shared code, building a new external in an existing package is as easy as setting a couple of make variables: pdexterns_PROGRAMS += myexternal myexternal_SOURCES = myexternal.c mycommon.c mycommon.h ... and automake takes care of the rest (make, make install, make uninstall, ...). Creating a new external package using this system is pretty easy too: see the SVN directory externals/moocow/hello for a complete working tutorial, or its README here: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/moocow/hello/README.txt?view=markup The ./configure options are there for debugging, support for multiple installations of Pd on the same machine, as well as support for pd-extended (e.g. --enable-object-externals). autotools support for use environment variables (CFLAGS, CPPFLAGS, etc.) is really handy too, e.g. for messing with optimization debugging flags. I wish every external build system would support these. That said, in some cases the code actually *does* require some platform-dependent initialization in ./configure. [locale] for instance checks for definitions of all of the LC_* variables it supports, [flite] needs to know where to find the libflite include files, as well as how to link to libflite: this is exactly the kind of thing autoconf was made to handle, and which it does quite elegantly. I find that in the long run, simple Makefiles are the least work overall. To each his own, I suppose, or maybe I'm missing something. If I were maintaining only 1 or 2 external packages (or a single global build system ;-), I think I might tend to agree. As it is, I think the autotools beat copy+paste Makefiles (which I still use a lot, e.g. for my LaTeX documents, which rarely need to be synchronized or updated once the paper has been written) hands down. Are automake+autoconf+autoheader overkill for my externals? Sure they are: I think
Re: [PD-dev] symlinks render pdstring unbuildable on MinGW/Windows
moin Hans, On 2009-03-05 21:33:36, Hans-Christoph Steiner h...@eds.org appears to have written: On Mar 4, 2009, at 4:23 PM, Bryan Jurish wrote: On 2009-03-04 05:37:40, Hans-Christoph Steiner h...@eds.org appears to have written: I was just trying to build string2any and friends on Windows for a student, but the symlinks used in moocow are throwing a huge wrench in the process. They show up at .lnk files, and are not links at all. That's because cygwin translates symlinks into Windows shortcuts, aka .lnk. So symlinks will never work on Windows. uh, *which* symlinks exactly are you referring to? trunk/externals/moocow/pdstring/m4 trunk/externals/moocow/pdstring/pdexternal.am argh. these are svn:special links. Just so I understand, what form does the huge wrench take? Does the whole auto-build fail, or just the moocow/ packages? The whole thing is run in MSYS/MinGW except for the rsync, which is run in Cygwin. Running rsync in MSYS did not work for me, I could not get it going, no matter how hard I tried. Most of it ran, but there were some technical details which I forget. Basically, dealing with Windows is a massive pain in the butt. agreed. The other thing is that the new code is actually copied to the build server using rsync rather than svn. rsync has the very handy -- delete feature, meaning rsyncing leaves you with a perfect recreation of the original with the additions and subtractions. That would not be easy to do with svn and make clean. Unfortunately, rsync is very aware of symlinks. I tried to make it copy the symlinks target instead, but that didn't work. the rsync -L flag (--copy-links) works for me here, even with a preceding -a (--archive)... does that not work on cygwin? The only times I've ever had problems with -L were symlink cycles (./dir - .), which I certainly am not inserting into the repository. So basically, moocow is the only build system included in Pd-extended that relies on symlinks, ok. so I am guessing the easiest path forward is to not use symlinks or not support Windows. I'm not convinced. Instead of using symlinks, the build system should just use the paths to the shared files. I don't know automake, but that is possible with other build tools, so it seems likely to work there too. I understand your concerns, and I do wish my externals to remain compatible with pd-extended builds even on (shudder) windoof. And yes, of course referencing paths outside the project root directory is possible with automake. My issues are not with the possibility (heck, it's *possible* to write a C compiler entirely in DOS .BAT, but who would want to?), but rather portability and ease of maintainability (i.e. I'm lazy). Unfortunately, I don't see any good way to keep my code centralized *and* still maintain independent self-contained external packages which play (mostly) nicely together with the pd-extended build system *without* using either svn:special symlinks or svn:externals [snip] With makefiles you can use include instead of symlinks, so I am sure that automake has a similar functionality. Again: of course it does. Actually, I find the suggestion that I might not have though of this mildly insulting. I don't think it was meant to be; guess I'm just a bit peevish today. Sorry. You could make pdexternal.am just a file that includes the common file, and nothing else. Yes I could, but it wouldn't solve anything. I realize you probably don't really care about the details of my build subsystem, but please try to understand at least this much: as soon as I include ../common/pdexternal.am (regardless of whether that happens in ./Makefile.am or ./pdexternal.am), I no longer have a self-contained and independent package. Same goes for the -I m4 (rsp. -I ../common/m4) option to aclocal, as declared in Makefile.am. Try this, and automake's 'distcheck' target explodes, and the 'dist' target produces a package which is incomplete (doesn't contain anything from ../common and cannot be used for further autotools-sensitive development without that code). So it's not as simple as include, given my desire to continue to maintain self-contained and independent packages (in addition to supporting the pd-extended build system). Possibilities I see, all of which are unsatisfying in one way or another: I could svn-copy the common stuff into each and every quasi-independent external package that uses it, but that results in precisely the kind of maintainance snafu I wrote pdexternal.am co to avoid, since changes in ../common/x then wouldn't get propagated to ./x without another explicit SVN copy operation to each package dir . ... unsatisfying. Essentially the same applies to multiple copies of the common code within SVN, which is even uglier (for SVN itself). Re make: I can't even write (standard package-local ./Makefile) make targets for the 'common' stuff, because much
Re: [PD-dev] symlinks render pdstring unbuildable on MinGW/Windows
moin Hans, On 2009-03-04 05:37:40, Hans-Christoph Steiner h...@eds.org appears to have written: I was just trying to build string2any and friends on Windows for a student, but the symlinks used in moocow are throwing a huge wrench in the process. They show up at .lnk files, and are not links at all. That's because cygwin translates symlinks into Windows shortcuts, aka .lnk. So symlinks will never work on Windows. uh, *which* symlinks exactly are you referring to? do have an error message or a make log or a config.log for me? SVN can handle symlinks with the svn:special property, and according to the Subversion FAQ (http://subversion.tigris.org/faq.html#symlinks): the Subversion repository has no internal concept of a symlink. It stores a versioned symlink as an ordinary file with an 'svn:special' property attached. The svn client (on unix) sees the property and translates the file into a symlink in the working copy. Win32 has no symlinks, so a win32 client won't do any such translation: the object appears as a normal file. The most recent SVN book says much the same about svn:special symlinks. ... so I wonder how you managed to get .lnk files out of svn at all, if indeed that is what's happening... ... or am I creating symlinks somewhere with AC_CONFIG_LINK? I don't think I am anymore (but I'll check), and even that should default to something safe on the configuring system (copy for win32, according to the autoconf docs), so I don't really know what is going wrong where. [grep -r AC_CONFIG_LINKS pdstring/*] pdstring/configure.ac:AC_CONFIG_LINKS([src/any2string-help.pd:src/any2bytes-help.pd]) pdstring/configure.ac:AC_CONFIG_LINKS([src/string2any-help.pd:src/bytes2any-help.pd]) ... oops: ok, I guess I am calling AC_CONFIG_LINKS() too (therefore the behavior sounds like a bug in cygwin, but that's beside the point I guess) -- this would be easy to replace e.g. with svn:special symlinks (preferred) or an automake install-local target or whatever, but I still need to know if any of the svn:special symlinks are exploding on you as well (e.g. pdstring/m4, pdstring/pdexternal.am, pdstring/src/mooPdUtils.h)... If the svn:special symlinks are going sour, maybe you should try a different svn client? If AC_CONFIG_LINKS() is exploding, then maybe you need to run ./configure in a different shell environment (MSYS?) ? Instead of using symlinks, the build system should just use the paths to the shared files. I don't know automake, but that is possible with other build tools, so it seems likely to work there too. I understand your concerns, and I do wish my externals to remain compatible with pd-extended builds even on (shudder) windoof. And yes, of course referencing paths outside the project root directory is possible with automake. My issues are not with the possibility (heck, it's *possible* to write a C compiler entirely in DOS .BAT, but who would want to?), but rather portability and ease of maintainability (i.e. I'm lazy). Unfortunately, I don't see any good way to keep my code centralized *and* still maintain independent self-contained external packages which play (mostly) nicely together with the pd-extended build system *without* using either svn:special symlinks or svn:externals (repository-internally, but still svn:externals, which I seem to recall has been deprecated for use with pd-extended auto-builds), unless I create a second copy of each external package in the repository for pd-extended builds, which contains copies of all shared code (and all other code), and which has to be explicitly published, rather than built from the straight SVN sources I use. I suppose the SVN catch-phrase copies are cheap could seem to suggest just such a solution, but it strikes me as kludgy... then again, checking autotools-generated files (configure, Makefile.in) into SVN strikes me as kludgy too, and I'm already doing that, so maybe I should just bite the bullet... Thoughts, comments, criticism, flames welcome ;-) marmosets, Bryan ps - it appears now that I've spent this whole evening I had planned to use for working on utf-8 for pd-devel typing emails and wiki pages... maybe tomorrow ;-) -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-2501709 ] [any2string] converts non-ascii chars to negative values
moin iohannes, moin all, On 2009-01-14 10:09:15, IOhannes m zmoelnig zmoel...@iem.at appears to have written: SourceForge.net wrote: Bugs item #2501709, was opened at 2009-01-12 17:17 what about having a third argument: 0=signed, 1=unsigned ? also easy, but a bit klunky ... maybe an additional object [any2ustring] for unsigned chars? would the u in [any2ustring] mean unsigned or unicode? argh argh argh... point taken. marmosets, Bryan -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] PdLab installation request: glib-2.0
moin Hans, moin list, I've got the gfsm externals building here in a pd-extended-friendly sort of way using a static local copy of the libgfsm sources by default. According to the PdLab logs, the build is still failing (http://autobuild.puredata.info/auto-build/2008-12-01/logs/2008-12-01_01.51.47_linux_debian-stable-i386_pd-extended_run-automated-builder.txt): /bin/sh ../../libtool --tag=CC --mode=compile gcc ... -c -o gfsmCommon.lo gfsmCommon.c gcc ... -c gfsmCommon.c -o gfsmCommon.o In file included from gfsmCommon.c:23: ./gfsmCommon.h:32:18: error: glib.h: No such file or directory Apparently, libglib-2.0 isn't installed on this machine (and probably not on the other PdLab machines either). Would it be possible to install it? The relevant debian packages are: libglib2.0-0 libglib2.0-data libglib2.0-dev Also required for the full configuration build process are: libtool (debian package libtool-1.4) pkg-config (debian package pkg-config) Again, these missing packages cause no fatal errors to the pd-extended build process as a whole, they just mean that the gfsm externals don't get built (which they never really did before, so probably no one is missing them). peace, love, marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] moocow/libgfsm error on Fedora
morning Hans, morning list, On 2008-11-18 21:18:41, Hans-Christoph Steiner [EMAIL PROTECTED] appears to have written: On Nov 18, 2008, at 5:09 AM, Bryan Jurish wrote: On 2008-11-18 02:32:57, Hans-Christoph Steiner [EMAIL PROTECTED] appears to have written: Anyone know why moocow is dying on Fedora with this error: gcc -DHAVE_CONFIG_H [...] -c atom_alphabet.c In file included from atom_alphabet.c:28: ./atom_alphabet.h:32:18: error: gfsm.h: No such file or directory ... and the build process continues (without crashing) ... ... so aside from the (admittedly ugly, but otherwise inconsequential for the rest of the build process) errors, what's the problem? I could take the gfsm externals out of the list of 'moocow' build targets for pd-extended (since libgfsm isn't likely to be installed anywhere but on my own machines), but it ought to build successfully whenever libgfsm is installed, and it is freely available (LGPL, from me: http://www.ling.uni-potsdam.de/~moocow/projects/gfsm). I suppose I could also pack a local version of libgfsm into pd-gfsm and build it with the externals, or move it to sourceforge and use svn:externals, etc. etc. ... but that all seems like overkill to me... anyone have an opinion? Hey, Since libgfsm isn't included in any package management systems that I checked (Debian, Ubuntu, Fedora, Fink), I think it makes sense to include the libgfsm code in the pure-data SVN. The weird thing is that AFAIK, libgfsm is not installed on any of the build farm machines, but this error only seems to happen on the Fedora 8 machine. nope. same stuff happens elsewhere too, e.g. i386-debian-stable (http://autobuild.puredata.info/auto-build/2008-11-16/logs/2008-11-16_01.49.38_linux_debian-stable-i386_pd-extended_run-automated-builder.txt) line 17342: gcc -DHAVE_CONFIG_H [...] -c atom_alphabet.c In file included from atom_alphabet.c:28: ./atom_alphabet.h:32:18: error: gfsm.h: No such file or directory I'll want to experiment a bit with recursive autoconf/automake stuff before I can include libgfsm in the pd svn, but all things considered, I think you're right and that's the best solution for the time being. Optimally, pd-gfsm would always use its own version of libgfsm, to insulate against unforseen gfsm API changes... hmm... marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to compile pdstring from moocow?
moin Roman, I suspect that your CFLAGS aren't getting defined properly; in particular, I suspect you are missing an -I$PD_SRC, where $PD_SRC is the directory containing your m_pd.h. If this suspicion is correct, you should have seen something like the following from ./configure: checking for m_pd.h... no configure: WARNING:-- configure: WARNING: could not find PD header file 'm_pd.h' configure: WARNING: -- things might get ugly. configure: WARNING:-- and `./configure --help` should have produced something like: bash$ ./configure --help `configure' configures pdstring 0.06 to adapt to many kinds of systems ... Optional Packages: --with-pd-include=DIR PD include directory (default=NONE) ... Some influential environment variables: ... CPPFLAGS C/C++/Objective C preprocessor flags, e.g. -Iinclude dir if you have headers in a nonstandard directory include dir ... Report bugs to [EMAIL PROTECTED]. So, there are various ways of setting this flag when calling ./configure, e.g.: bash$ ./configure --with-pd-include=$PD_SRC or: bash$ ./configure CPPFLAGS=-I$PD_SRC or: bash$ export CPPFLAGS=-I$PD_SRC; ./configure or (less pedantically correct but ought to work anyways, at least for pdstring): bash$ ./configure CFLAGS=-I$PD_SRC ... that said, your m_pd.h ought to be found auto-magically by ./configure, unless you have it in a non-standard location. By default, my ./configure scripts look for m_pd.h only in the c preprocessor's default include path (e.g. /usr/include, /usr/local/include, ...). I used to try to guess where the pd was installed by looking for /usr/local/pd, /usr/local/lib/pd, etc., but that got hairy for pd-extended builds, so now you have to either install m_pd.h in a default location (I use /usr/local/include, and I think pd-vanilla does too), or tell ./configure where to look. If problems persist, please send me (or post) the file config.log produced by ./configure. marmosets, Bryan On 2008-08-12 19:41:11, Roman Haefeli [EMAIL PROTECTED] appears to have written: hi all i followed the README.cvs file included and when doing 'make' i get: Making all in config ... gcc pdstring.c -o pdstring pdstring.c:41: error: expected ',' or ';' before 'PACKAGE_VERSION' In file included from pdstring.c:62: any2string.c:76: error: expected ',' or ';' before 'PACKAGE_VERSION' In file included from pdstring.c:63: string2any.c:59: error: expected ',' or ';' before 'PACKAGE_VERSION' ... i am on ubuntu hardy i686, which uses comes with gcc version 4.2.3 I foresee no problems with your system: I just did a test build here at work on a debian box with gcc 4.2.3. -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to compile pdstring from moocow?
moin all, I take it all back (well, some of it at any rate). Looks like m_pd.h isn't the only problem after all -- you're missing at least one other compiler flag too... On 2008-08-13 00:52:13, Martin Peach [EMAIL PROTECTED] appears to have written: Roman Haefeli wrote: hi all i followed the README.cvs file included and when doing 'make' i get: Making all in config make[1]: Entering directory `/home/roman/pd-svn/externals/moocow/pdstring/config' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/roman/pd-svn/externals/moocow/pdstring/config' Making all in src make[1]: Entering directory `/home/roman/pd-svn/externals/moocow/pdstring/src' make all-recursive make[2]: Entering directory `/home/roman/pd-svn/externals/moocow/pdstring/src' make[3]: Entering directory `/home/roman/pd-svn/externals/moocow/pdstring/src' gcc pdstring.c -o pdstring pdstring.c:41: error: expected ',' or ';' before 'PACKAGE_VERSION' In file included from pdstring.c:62: any2string.c:76: error: expected ',' or ';' before 'PACKAGE_VERSION' In file included from pdstring.c:63: string2any.c:59: error: expected ',' or ';' before 'PACKAGE_VERSION' make[3]: *** [pdstring] Error 1 make[3]: Leaving directory `/home/roman/pd-svn/externals/moocow/pdstring/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/roman/pd-svn/externals/moocow/pdstring/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/roman/pd-svn/externals/moocow/pdstring/src' make: *** [all-recursive] Error 1 i am on ubuntu hardy i686, which uses comes with gcc version 4.2.3 For some reason PACKAGE_VERSION is defined here: externals\build\src\any2string.c(1):#define PACKAGE_VERSION CVS I think it should properly be defined in a .h file that is #included by the above files. PACKAGE_VERSION ought to get defined in externals/moocow/pdstring/src/config.h via autoheader. Still, the redefinition shouldn't cause any (major) headaches unless you try to compile with -Werror, which Roman is not. Your observation brings to light another Truly Odd Thing, however: config.h only gets included if autoconf and autoheader are playing together nicely: in this case, the gcc call should include the argument -DHAVE_CONFIG_H, which the above make log shows is not the case. So apparently, config.h isn't getting included, PACKAGE_VERSION isn't getting defined, and the errors we're seeing are plain old lexical errors from the C compiler. Curioser and curioser... Roman, please do send along a copy of your config.log when you get a chance ;-) also the output (stdout and stderr) of ./autogen.sh and ./configure would be helpful: bash$ (sh ./autogen.sh ./configure make) 21 | tee build.log marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to compile pdstring from moocow?
moin Roman, On 2008-08-13 13:22:07, Roman Haefeli [EMAIL PROTECTED] appears to have written: how can i compile moocow then? I'm feeling quite compiled enough already, thanks ;-) i tried: ./autogen.sh ./configure make this (above) is the official way to do it: calling this from e.g. externals/moocow/pdstring ought to build cleanly on normal(TM) systems. and: cd pd-svn/externals make moocow ... this looks like a pd-extended build idiom to me. The pd-extended build rules for my externals don't really do anything more than iterate (./autogen.sh ./configure make), in a more or less error-tolerant, autobuild-safe sort of way. The pd-extended rules I wrote expect certain make variables to be set which are only really valid for pd-extended builds though, so I think you're asking for trouble going the make moocow route, unless in the course of a whole pd-extended build (I still have to check out why and how those builds are failing). Using the first method (./autogen.sh ./configure make) is your best bet. and both give a lot of errors. Have you tried building from the pre-packaged sources on my pd page? http://www.ling.uni-potsdam.de/~moocow/projects/pd If these compile but the SVN sources don't, there might be a compatibility problem with your auto-tools (automake, autoconf, autoheader). marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Problems w' Ratts on Windows
moin Daniel, ... forwarding to pd-dev ... On 2008-07-02 01:17:53, daniel c. howe [EMAIL PROTECTED] appears to have written: Hi Brian I re-installed a newer binary of pd-ext and added your dll... And pd said: -- ratts: Realtime Analog Text-To-Speech externals v0.07 by Bryan Jurish ratts: Based on text-to-speech code by Nick Ing-Simmons and Jon Iles ratts: and PD external code by Orm Finnendahl and Travis Newhouse ratts: compiled by pddev on Mon Jun 30 16:26:18 EDT 2008 well, that looks right at least... do I assume correctly that you started pd with -lib ratts? (or included ratts in the Startup dialog of pd-extended?) Seems like that did the trick! Nice work... Now what would be great is either the help files or a simple example... the help files don't need to be compiled at all. they're included in the ratts source distribution; to get them installed, just do: $ cp $RATTS_SOURCE_ROOT/src/*-help.pd /pdext/doc/5.reference I tried using the attached patch (rattsass.pd), but get the usual errors about not being able to create the other objects... (I'm guessing they are packaged in the .dll??) [see msgs below], or maybe I am missing something obvious?? (FYI: my pd-install is in C:\pdext and the extras in C:\pdext\extra) well, they ought to be. ratts is a multi-object external, so all of the objects ought to be bundled into the single ratts.dll. Now I seem to recall a lot of discussion on the list that multi-object libraries are deprecated for pd-extended (this being one reason I don't use pd-extended); not sure if this means they don't work at all, or if there's some extra magic that needs to be applied. @list: can anyone enlighten me here? pps. I still can't get PD to compile on this machine, even following the Msys/MinGW instructions as closely as possible [http://puredata.info/docs/developer/mingw]) so couldn't test your new configure script... :( this sounds like a question for the list... im(ns)ho, you're likely to have fewer headaches in the long run if you compile yourself. I'm still using an old-ish version of pd-vanilla, and I've never seen it produce anything like the log below. looks useful and intuitive though: i guess this is the hexloader stuff folks on the list have been on about :-) when i first wrote ratts, i included a multi-object build mode which might help (if indeed pd-extended absolutely refuses to accept multi-object externals (which I would consider a bug), but unfortunately suspect may be the case); i have no idea though whether that build mode still works. I'll try it out at home later today... until then, perhaps the listers can enlighten us further? === input channels = 2, output channels = 2 input channels = 2, output channels = 2 1 devices in, 1 devices out tried C:\\pdext\\dch\\guessphones.dll and failed tried hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,00,25,00,2f,00,46,00,6f,00,6e,00,74,00,73,00,00,00\\guessphones.dll and failed tried C:\\pdext\\extra\\guessphones.dll and failed tried C:\\pdext\\dch\\guessphones\\guessphones.dll and failed tried hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,00,25,00,2f,00,46,00,6f,00,6e,00,74,00,73,00,00,00\\guessphones\\guessphones.dll and failed tried C:\\pdext\\extra\\guessphones\\guessphones.dll and failed tried C:\\pdext\\dch\\guessphones.pd and failed tried hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,00,25,00,2f,00,46,00,6f,00,6e,00,74,00,73,00,00,00\\guessphones.pd and failed tried C:\\pdext\\extra\\guessphones.pd and failed tried C:\\pdext\\dch\\guessphones.pat and failed tried hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,00,25,00,2f,00,46,00,6f,00,6e,00,74,00,73,00,00,00\\guessphones.pat and failed tried C:\\pdext\\extra\\guessphones.pat and failed guessphones ... couldn't create [isomorphic search error messages for other ratts objects expunged] error: inlet: expected '' but got 'bang' ... you might be able to track this down from the Find menu. ... (repeated) marmosets, Bryan (addendum): i just tried a single-object ratts build for pd-extended/linux here at work, and everything seems to be working as expected. the multi-object build mode is broken though (missing some -lm flags it seems); I'll get on that tonight. -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Problem Compiling Ratts on Cygwin
moin Daniel, moin list ... cc'ing this message to pd-dev, as discussed ... for those of you listers who may have missed the beginning of this discussion (e.g. pretty much all of you), we're trying to get [ratts] built on a windoof box, without much success. not being a windoof user myself, i'd appreciate any tips anyone could offer regarding external compilation on such machines; in particular CFLAGS, LDFLAGS, LIBS, etc etc... some relevant snippets of the discussion to date follow... On 2008-06-29 01:00:15, daniel c. howe [EMAIL PROTECTED] appears to have written: Bryan Jurish wrote: moin Daniel, it just occurred to me that pd builds on cygwin are notoriously difficult: did you actually get pd to build and run? Quoting from http://puredata.info/docs/developer/WindowsXPI386 : Pd doesn't build in Cygwin. You have to use MSYS. nope, wasnt able to get it to build via cygwin... so just running a binary so far hmm, where did you get the binary? are you sure it wasn't built e.g. with MSYS (or worse yet with MSVC) and not with cygwin at all? for msys builds i could potentially try out some of these hacks myself on the pd build farm machine: are you maybe running a pd-extended build? at any rate, assuming you got pd built on cygwin, it would help to know how the standard externals got built (a make log from pd/src and especially pd/extra would be helpful here): this should give us a good idea of the flags used. ... again, for msys builds, we could probably lift the relevant flags from the pd-extended build system. same error after running autogen: == ratts.c:1: warning: -fPIC ignored for target (all code is position independent) ok, we can leave out -fPIC, but it shouldn't hurt to leave it in... gcc -O2 -fno-strict-aliasing -fPIC -Wall -Winline -o ratts.dll -export_dynam ic -shared parwave.o klatt_frame.o elements.o squeue.o dsqueue.o rholmes.o phfea t.o pd_holmes.o alhash.o phtoelm.o pd_phtoelm.o darray.o phoneutils.o trie.o tex t.o english.o saynum.o ratts_keyval.o suspect.o ASCII.o klatt~.o holmes.o holmes -feat.o holmes-mask.o phones2holmes.o guessphones.o number2text.o rattshash.o ra ttstok.o toupper.o spellout.o ratts.o klatt_frame.o:klatt_frame.c:(.text+0x19): undefined reference to `_gensym' klatt_frame.o:klatt_frame.c:(.text+0x2a): undefined reference to `_gensym' klatt_frame.o:klatt_frame.c:(.text+0x3b): undefined reference to `_gensym' klatt_frame.o:klatt_frame.c:(.text+0x4c): undefined reference to `_gensym' klatt_frame.o:klatt_frame.c:(.text+0x5d): undefined reference to `_gensym' klatt_frame.o:klatt_frame.c:(.text+0x6e): more undefined references to `_gensym' follow klatt_frame.o:klatt_frame.c:(.text+0x304): undefined reference to `_error' same ol' linker error, likely due to missing linker flags (e.g. -export_dynamic -shared for linux externals) ... whatever cygwin builds call pd externals (what's the extension of e.g. $PD_ROOT/extra/expr.* ?). [EMAIL PROTECTED] /cygdrive/c/pd $ ls extra/expr* extra/expr-help.pd extra/expr.dll extra/expr~.dll extra/expr~: LICENSE.txt makefile vexp.lib vexp_fun.obj vexp_if.pd_linux_o README.txt vexp.cvexp.obj vexp_fun.pd_linux_o expr.dll vexp.exp vexp.pd_linux_o vexp_if.c fts_to_pd.h vexp.hvexp_fun.c vexp_if.obj odd... looks like you've got both .dll and .lib. afaik, .lib is a static library and .dll a dynamic one. pd externals are (at least on linux and osx) dynamic libraries: i'm guessing .dll is the way to go... anyone on the list know why both .lib and .dll get built on windoof? also, what the heck are the .pd_linux_o files we're seeing here? afaik, pd (vanilla) doesn't build or require any libraries (except maybe -lm). i don't use pd-extended, so i can't tell you there... if there are any global pd libraries, you'll probably need to link them in. these are the libs I find in pd: === [EMAIL PROTECTED] /cygdrive/c/pd $ find . -name *.lib -print ./bin/asiolib.lib ./bin/pd.lib ./bin/pdtcl.lib ./bin/pthreadVC.lib ./bin/tcl84.lib ./bin/tclstub84.lib ./bin/tk84.lib ./bin/tkstub84.lib ./extra/bonk~/bonk~.lib ./extra/choice/choice.lib ./extra/expr~/vexp.lib ./extra/fiddle~/fiddle~.lib ./extra/loop~/loop~.lib ./extra/lrshift~/lrshift~.lib ./extra/pique/pique.lib ./extra/sigmund~/sigmund~.lib ./lib/asio/asiolib.lib ./src/pthreadVC.lib ... so you might need to link in any or all of the libs in bin/ ... getting the order right could be tricky though. in general, gcc likes highest-level libraries left-most in the list. my guess would be something like -lpd -lpdtcl -ltk84 -ltkstub84 -ltcl84 -ltclstub84 -lasiolib -lpthreadVC ... but I might be wrong. I seem to get that same error no matter what order I use... though if I add a non-existent library, it chokes on that... also if I add pd.lib as the last
Re: [PD-dev] Problem Compiling Ratts on Cygwin
On 2008-06-30 12:31:27, Hans-Christoph Steiner [EMAIL PROTECTED] appears to have written: Check out trunk/externals/Makefile, that's where the stuff is for building Pd-extended on MinGW. By the linker errors, it looks like you are not linking to the pd.dll. excellent; thanks, Hans! On Jun 30, 2008, at 10:56 AM, Bryan Jurish wrote: moin Daniel, moin list ... cc'ing this message to pd-dev, as discussed ... for those of you listers who may have missed the beginning of this discussion (e.g. pretty much all of you), we're trying to get [ratts] built on a windoof box, without much success. [snip] -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Compiling and debugging flext external on Debian linux
moin Pablo, looks like something (SoundFile?) is trying to free a NULL pointer (blk=0x0); possibly an initialization bug... have you checked the constructor? marmosets, Bryan On 2008-06-12 20:23:53, Pablo Vanwoerkom [EMAIL PROTECTED] appears to have written: I've been having trouble running the DEBUG-SINGLE binary of an external that uses flext. [snip] *Below is the error I am getting when I try to load a soundfile in the puredata patch that uses the soundspotter external:* = Program received signal SIGSEGV, Segmentation fault. 0x9d879480 in flext_root_single::operator delete (blk=0x0) at source/flsupport.cpp:173 173 size_t bytes = *(size_t *)ori; Current language: auto; currently c++ *And the backtrace is:* = #0 0x9d879480 in flext_root_single::operator delete (blk=0x0) at source/flsupport.cpp:173 #1 0x9d8723f9 in operator delete (blk=0x0) at source/flsupport.h:103 #2 0x9d86b1c2 in SoundFile::loadSound (this=0x82597f4) at soundspotter3/SoundFile.cpp:31 #3 0x9d86b2d1 in SoundFile::sfOpen (this=0x82597f4, inFileName=0x82597b8 /media/docs/capstone/audioclips/HummedScale_Don.wav) at soundspotter3/SoundFile.cpp:21 #4 0x9d86ca16 in soundspotter::m_milt (this=0x823a154, argc=1, argv=0xbfc0958c) at soundspotter3/DriverFlext.cpp:103 #5 0x9d86cfeb in soundspotter::flext_c_m_milt (c=0x823a154, argc=1, argv=0xbfc0958c) at soundspotter3/DriverFlext.h:55 #6 0x9d87e08a in flext_base_single::TryMethTag (this=0x823a154, lst=0x823a4ac, tag=0x823f578, argc=1, argv=0xbfc0958c) at source/flmsg.cpp:37 #7 0x9d87e4ba in flext_base_single::FindMeth (this=0x823a154, inlet=0, s=0x823f578, argc=1, argv=0xbfc0958c) at source/flmsg.cpp:146 #8 0x9d87e67d in flext_base_single::CbMethodHandler (this=0x823a154, inlet=0, s=0x823f578, argc=1, argv=0xbfc0958c) at source/flmsg.cpp:184 #9 0x9d87ec84 in flext_base_single::cb_px_anything (c=0x8239d98, s=0x823f578, argc=1, argv=0xbfc0958c) at source/flproxy.cpp:32 #10 0x080aa5d6 in pd_typedmess () #11 0x082432c8 in ?? () #12 0xbfc09336 in ?? () #13 0xbfc09792 in ?? () #14 0x0010 in ?? () #15 0x0004 in ?? () #16 0x in ?? () = ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- *** Bryan Jurish Deutsches Textarchiv Berlin-Brandenburgische Akademie der Wissenschaften Jägerstr. 22/23 10117 Berlin Tel.: +49 (0)30 20370 539 E-Mail:[EMAIL PROTECTED] *** ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] autotools magic for externals?
moin Claude,
On 2007-11-29 20:10:19, Claude Heiland-Allen
[EMAIL PROTECTED] appears to have written:
So, is there a set of macros I can drop into my acinclude.m4 that
provide a nice auto-n00b-friendly environment as a base for creating a
configure.ac and a Makefile.am for a Pd external that requires some
libraries?
I don't think so. I ask occasionally on the list if there are any m4
programmers lurking about to help setting up something like you
describe, but so far no one has bitten, and I haven't got around to
learning m4 myself yet.
I've been trying to use autotools (autoconf and friends) to build pdlua,
but have ended up in a world of pain and deleted my experiments out of
frustration. I tried to understand the system used in
CVS/externals/moocow/, but the wizardry was somewhat beyond me. Even
more so with the Gem system.
I can't speak for gem's build system, but the autotools conventions in
externals/moocow/* are most definitely to be considered *hacks* (rather
than wizardry ;-) ... for example in 'readdir':
configure.ac or configure.in:
+ the stuff under how to hack automake EXEEXT conventions says it
all: automake-1.4 handles the $(EXEEXT) make variable differently than
automake-1.9, but I'm not sure when exactly the change occurred. The
big idea is that pd externals are built with automake _PROGRAMS
targets, but they also need to be installed with a .pd_whatever
extension. So I use EXEEXT to tell automake what that extension is
+ the lines:
PD_OBJECT_EXTERNALS=readdir${buildext}
AC_SUBST(PD_OBJECT_EXTERNALS)
just substitute @PD_OBJECT_EXTERNALS@ into Makefile from Makefile.am.
You don't need it or anything like it if you know what all your sources
and targets are: I sometimes use PD_OBJECT_EXTERNALS to differentiate
between library and single-object builds (e.g. in pdstring/).
+ the directory arguments checks should be self explanatory
+ the stuff under machine-dependent flags is borrowed (mostly) from
pd's own configure.in, and can probably be left untouched.
config/ subdir:
+ I put autotools-specific stuff here, to avoid cluttering up other
distribution root or source directories
src/ subdir:
+ The guts: set EXEEXT and build externals as pdexterns_PROGRAMS
targets (which is valid since configure.ac did AC_SUBST(pdexternsdir)).
+ pd-style compiler flags are gathered into AM_CPPFLAGS, AM_CFLAGS, and
readdir_LDFLAGS (if you have other libraries to link to, put them in
myprog_LDADD, e.g. readdir_LDADD = -lfoo -lbar).
... in general, there's probably a lot of junk hanging around in the
various files that you don't need, but (probably) won't hurt ;-)
Certainly ignore and/or delete any rules about $(PODS), unless you're
generating README files out of README.pod in perl's pod format.
If you have specific difficulties and/or questions about my autotools
hacks, don't hesitate to ask -- I freely admit that they're ugly and
cryptic, but they're actually quite adaptable...
marmosets,
Bryan
--
Bryan Jurish There is *always* one more bug.
[EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd Strings
morning all, One (potential) problem with strings-as-arrays (as has been pointed out before) is a gross waste of space: for IEEE-754 floats, sizeof(float)=4, which is 3 bytes wasted for a single 8-bit character. We could do some devious byte-packing and pointer-casting in one or more externals to attenuate the problems, but that gets very cryptic very quickly (I actually tried this with [pdstring] (which wastes even *more* memory by using one atom per character), but decided against it in the interests of clarity and flexibility)... I think it's definitely worth a go however... marmosets, Bryan On 2007-11-14 08:13:03, Hans-Christoph Steiner [EMAIL PROTECTED] appears to have written: Using arrays as strings is an interesting idea. I don't think non- ascii charsets should be too big a deal, they are decently supported right now, without even trying :). The Pd floats should store UTF-16 fine, which really covers basically everything. By the time UTF-32 is used much, Pd will be using 64-bit floats. .hc On Nov 14, 2007, at 12:43 AM, Miller Puckette wrote: HI all, I don't have answers to all these, but I'm sure that adding a string ytpe to Pd isn't the roght way to handle these problems. But specifically: 1. spaces in symbols are a parsing/formatting problem, not a data type problem; 2. use arrays as strings as I proposed; 3. I have to think about that one some more (!) and 4. one thing is dealing with non-ascii character sets, although there are likely to be many more problems to adress. On Tue, Nov 13, 2007 at 11:57:06PM -0500, Chris McCormick wrote: Hi, I have deleted Miller's reply where he said that he's not that interested in adding a string type to Pd, but I'd like to ask him a couple of questions regarding that response, if that's ok. 1. How do you propose to solve the 'spaces in file path' issue without a string type? Or are you content with that restriction? 2. How do you suggest that people deal with the symbol table pollution issue mentioned before on this list, when they are doing operations processing lots and lots of symbol-strings in Pd? Let me know if you want more information about this issue. 3. Will a [symbol2list] ever make it into Pd canonical so that people can split long symbols on a character, like the zexy external that does this? It seems strange that you can concatenate symbols, but not split them apart again. 4. Can anyone else help me with a concise summary of other string/Pd issues I haven't thought of? Thanks for taking the time to read and reply. Best, Chris. -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pd-extended / mingw32_nt-5.1_windowsxp-i386
moin moin, it seems that my externals are not building nicely for pd-extended under mingw32. The logs say (linebreaks introduced to avoid mailer mangling): make \ -C /home/pd/auto-build/pd-extended/externals/moocow/extended \ pd_src=/home/pd/auto-build/pd-extended/pd \ CFLAGS=-DPD -O2 -mcpu=i586 -mtune=pentium3 \ -I/home/pd/auto-build/pd-extended/pd/src \ -Wall -W -ggdb -mms-bitfields \ -DMSW -DNT -D'O_NONBLOCK=1' -D'srand48(n)=srand((n))' \ -D'drand48()=((double)rand()/RAND_MAX)' \ -D'bzero(p,n)=memset(p,0,n)' \ build.stamp \ || echo moocow: WARNING: build failed make[3]: Entering directory \ `/home/pd/auto-build/pd-extended/externals/moocow/extended' make[3]: *** No rule to make target `flite.build_stamp', needed by \ `build.stamp'. Stop. make[3]: Leaving directory \ `/home/pd/auto-build/pd-extended/externals/moocow/extended' moocow: WARNING: build failed The build.stamp target is a literal that depends on a finite number of generated targets (deque.build_stamp, sprinkler.build_stamp, etc.); the rules for these are generated with GNU make macros and the $(eval $(call ...)) idiom. I thought I was safe using GNU make-isms for the pd-extended build: is this known to be a Bad Idea for mingw32/winxp? Alternately, can anyone give me a rundown on the precise system configuration of the build machine (in particular, which version of make is it running?) so that I can try and debug things from here? marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Build integration
moin, On 2007-08-04 03:25:22, Hans-Christoph Steiner [EMAIL PROTECTED] appears to have written: On Aug 3, 2007, at 2:04 AM, Bryan Jurish wrote: On 2007-08-03 08:23:14, Hans-Christoph Steiner [EMAIL PROTECTED] appears to have written: i removed 'moocow' from LIB_TARGETS again. I'll test extensively here before adding it again. many apologies! Don't worry about removing it unless you don't have time to fix it within a few days. Then I'd start to nag ;) We've all broken the nightly builds before, you're not the first :D. It's there to make our lives easier, not harder. thanks -- i've gotten the whole shamozzle to build here now, and put moocow back in LIB_TARGETS; I'll check the logs again tomorrow to see if it's breaking anywhere, although a veritable plethora of (||true)s ought to ensure that doesn't happen this time ;-) I think it would make a lot of sense for the existing Pd-extended build system to be replaced with a proper automake/autoconf system that was used throughout. Anyone know of any example projects with many modules that are handled using autotools? i know i've seen recursive autotools projects, but none jumps to mind immediately... maybe apache? ardour? xorg? at any rate, the relevant autoconf macro appears to be AC_CONFIG_SUBDIRS. in automake, the relevant variable is SUBDIRS, which is allowed to be a macro substitution ([EMAIL PROTECTED]@) marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Build integration
moin moin, On 2007-08-03 08:23:14, Hans-Christoph Steiner [EMAIL PROTECTED] appears to have written: The global variables $(pd_src) are defined in packages/ Makefile.buildlayout: pd_src = $(cvs_root_dir)/pd so m_pd.h is in $(pd_src)/src ack. i saw that my additions had broken the pd-extended daily build yesterday, so i removed 'moocow' from LIB_TARGETS again. I'll test extensively here before adding it again. many apologies! http://puredata.info/Members/zmoelnig/pdcon07/BuildIntegration unified conventions for handling machine-specific optimization flags (- march= and friends). [snip] ... I'd like to motion for the establishment of some convention here. We should use a standard method for this kind of thing, like autoconf. This would another advantage of a unified build system. This mostly works with Pd-extended now, but it could be handled much better. in fact, one of my major beefs with autoconf is that the AC_PROG_CC macro insists on (re-)setting CFLAGS (on gcc systems, it gets re-set to -g -O2). I work around it by caching and re-instantiating the value before and after AC_PROC_CC... so even with autoconf, we would need either (a) hacks or (b) explicit variable name semantics conventions, if we want (as I would like) to be able to lug machine-local flags around in the environment. marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Build integration (was: Re: any2string problem)
moin all, On 2007-08-02 04:28:44, Hans-Christoph Steiner [EMAIL PROTECTED] appears to have written: On Aug 1, 2007, at 1:30 AM, IOhannes m zmoelnig wrote: i simply cannot keep track whether my changes to my code affect all of these systems. i am happy if it compiles with mine. Right. So what we need (im(ns)ho) is a least-common-denominator sort of way to dispatch to variant build systems. I couldn't agree more, we should have one build system for everything. Right now, the only functional option for that is the current Pd-extended build system. Agreed. Hence my long-intended stay-up-late-hacking session yesterday, during which I believe to have snuck (most of) my externals into the pd-extended system. The tricks I used rely on the pd-extended build using GNU make, but it looks like there are a number of other GNU-isms in externals/Makefile, so I feel safe there (feel free to object, of course). I wound up (mostly) just delegating the build from the moocow targets in externals/Makefile to conventional targets (build, install, clean) in externals/moocow/extended/Makefile, which in turn just call (./autogen.sh; ./configure; make; make install) with (hopefully) suitable arguments. The same basic technique could be made to work more systematically, *especially* if GNU make is ensured ($(eval $(call ...)) is your friend!) One thing I'm uncertain of (never having built the whole pd-extended from scratch) is what is supposed to live in the $(pd_src) variable; or rather, where m_pd.h is supposed to live in relation to $(pd_src)/. I've gone with the assumption that m_pd.h lives in $(pd_src) directly. Please let me know if I should use e.g. $(pd_src)/src instead. http://puredata.info/Members/zmoelnig/pdcon07/BuildIntegration I've added a few thoughts to this page -- I hope you don't mind. In particular, one of the major itches I've had when compiling a new pd version or installing on a new machine is the lack of unified conventions for handling machine-specific optimization flags (-march= and friends). I think that any specification for a new|old|hybrid build architecture should take this into account, at best without requiring users to edit a file that itself lives in CVS. Thomas Grill's flext system is one way to handle this sort of thing, but I'd most like to see it handled by environment variables (e.g. CFLAGS, or maybe PD_CFLAGS) and make's ?= and += operators... again, feel free to object and to kick my wiki paragraph into /dev/null if you think that's where it belongs... Of course, any CFLAGS passed down from the global build options might get lost, clobbered, or just ignored by local builds: that should be allowed, but I'd like to motion for the establishment of some convention here. marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] any2string problem
moin moin, On 2007-08-01 05:05:27, Hans-Christoph Steiner [EMAIL PROTECTED] appears to have written: On Jul 31, 2007, at 4:21 PM, Bryan Jurish wrote: also, i seem to recall hearing or reading recently something to the effect that multiple-object libraries are deprecated -- is there any knock-down drag-out argument why this should be so? This has been discussed quite a bit on the lists and at the Pd Con 1. Here's the basic synopsis with the problems with the multi-class-single-file libs: 1) no way to sort out name conflicts 2) every object is loaded regardless of whether it's used. 3) does not work with namespaces (i.e. [moocow/any2string]) (2) is certainly true. That's the whole point of multi-object libraries, isn't it? I think it can even be advantage, if a large shared codebase is used by multiple objects in a library (take gfsm as an example: a full static build takes almost 3 times the memory of a dynamic one: memory is cheap, but that's no excuse for inefficiency!) Frankly, I just don't believe (1) or (3) is actually the case. I'll grant that multi-object libraries don't get you either (1) or (3) for free (as the filesystem does), i.e. without changes to the pd core, but they're most definitely solveable problems. (OK... I admit I don't really want to solve them either, but I'd prefer to hunker down on fixing the real problems than to see Pd go the way of java just because it seems like the path of least resistance)... Plus once libdir format is more flushed out, there will also be embedded help, examples, etc. and a common library format regardless of which language the objects are written in (Pd, C, etc.) This is all great, but I don't think any of it actually conflicts with multi-object libraries -- you'd just have a multilib as an external in its own directory: so what? marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] any2string problem
moin again, On 2007-07-31 09:43:21, IOhannes m zmoelnig [EMAIL PROTECTED] appears to have written: Hans-Christoph Steiner wrote: There is a glitch in any2string that is stopping Pd-extended from building: i fixed that yesterday. thanks! and it is rather a glitch in the assumptions the externals/build/src/ makes than in the pdstring, which just builds perfectly. i don't wish to agitate slumbering canines, but it would be nice if the externals/build system and pdstring (also gfsm, readdir, etc) played nicely with one another. I keep putting off writing default externals/build-compatibile makefiles, basically because I think there's got to be a better way to do it, most likely involving automake|autoconf. any m4 hackers on the list these days? also, i seem to recall hearing or reading recently something to the effect that multiple-object libraries are deprecated -- is there any knock-down drag-out argument why this should be so? marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] any2string problem
moin all, sorry, my bad -- probably just due to a missing HAVE_CONFIG_H preprocessor define ... I'll add a fix when I get home this evening... marmosets, Bryan On 2007-07-31 02:33:42, Hans-Christoph Steiner [EMAIL PROTECTED] appears to have written: There is a glitch in any2string that is stopping Pd-extended from building: cc -DPD -O2 -pipe -fsigned-char -mpowerpc-gfxopt -I/home/pd/auto- build/pd-extended/pd/src -Wall -W -ggdb -DUNIX -Dunix -fPIC -o /home/ pd/auto-build/pd-extended/externals/build/src/any2string.o -c /home/ pd/auto-build/pd-extended/externals/build/src/any2string.c In file included from /home/pd/auto-build/pd-extended/externals/build/ src/any2string.c:1: /home/pd/auto-build/pd-extended/externals/build/src/../../moocow/ pdstring/src/any2string.c:76: error: expected ‘,’ or ‘;’ before ‘PACKAGE_VERSION’ -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] any2string problem
moin all, warning: idle pontifications follow ;-) On 2007-07-31 20:04:34, Hans-Christoph Steiner [EMAIL PROTECTED] appears to have written: On Jul 31, 2007, at 12:56 AM, Bryan Jurish wrote: moin again, On 2007-07-31 09:43:21, IOhannes m zmoelnig [EMAIL PROTECTED] appears to have written: and it is rather a glitch in the assumptions the externals/build/src/ makes than in the pdstring, which just builds perfectly. i don't wish to agitate slumbering canines, but it would be nice if the externals/build system and pdstring (also gfsm, readdir, etc) played nicely with one another. I keep putting off writing default externals/build-compatibile makefiles, basically because I think there's got to be a better way to do it, most likely involving automake|autoconf. any m4 hackers on the list these days? also, i seem to recall hearing or reading recently something to the effect that multiple-object libraries are deprecated -- is there any knock-down drag-out argument why this should be so? ... I still haven't heard a solid argument for this one ... sorry if i missed it on the list previously -- anything in particular I should search the archives for? I realize that autoloading only currently works (in vanilla pd at least) for object-named externals (which is why I try to build a dummy library object into my libraries (a la johannes' dummy [zexy] object))... are there other instabilities or issues i'm not aware of? Even if it's just a matter of makefile pattern matching, I could understand it ... (although I wouldn't actually qualify makefile pattern matching as a knock-down drag-out argument)... I make no claims that what exists is a great system. But it is far better than anything else that exists. I freely admit that the pd-extended build architecture is certainly a working and unified system, and as such is indeed far preferable to the veritable chaos of disparate conventions otherwise employed by the various external authors (myself included) -- everybody seems to pretty much roll their own. Indeed, the externals/build directory has saved me personally a good deal of wailing and gnashing of teeth, for which i am eternally ( 3.4e+38 temporal units of your choice) grateful. I'm also pretty happy with the pure-make approach in build/src: I certainly prefer it to SCons or other make alternatives. If someone wants to replace the whole thing that would be great, as long as they first do it outside of the existing system to prove it works, then it could be integrated into the main builds. There also has to be a solid, long term commitment from some devs to maintain it. Aye. There's the rub. Not having the time myself to dive into an alternative, I should probably just keep my big mouth shut, however... I haven't, so... There are various reasons (including historical) for the various build conventions floating about in externals/, and the pd-extended build has to co-exist somehow with all of them (at least, with all of those which feed into pd-extended)... and it would seem to me that a hierarchical build procedure (e.g. recursive descent with make) would be preferable to the glob-and-guess technique in externals/build/src, and to the monolithic externals/Makefile: it would allow library builds (to which I'm partial) as well as leaving maintainance of pd-extended build support entirely within the domain of the individual externals' maintainers... but that's just wishful thinking... I'll try and see how to weasel my conventions into externals/Makefile without breaking anything ;-) As for maintaining your code in the existing Pd-extended build system, no one is obligated. But if you add your code/library to it, then you need to maintain what you have setup, IMHO. If you want your code to be distributed and work with Pd-extended, then you'll want to maintain it within the Pd-extended build system. Agreed. By the same token, though, it should be clear which bits have been set up by whom -- just another reason for hierarchical builds, really... marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pdstring's crashing
moin [ij]ohannes, moin all, egad... obviously, you've had a look at the code (which I hadn't recently until reading your mail)... looking at it now, all I can think of is that for some reason, text hasn't actually got anything but junk in it (although that would probably lead to double-free or corruption errors... and text ought to be filled by the binbuf_gettext() call [which should at least return getbytes(0) -- calloc(1,1) in pathological cases] ... any2string_anything() adds the text-terminating NUL itself, so strlen() oughtn't to be goofing up either... so that's probably not it :-/)... is there maybe anything fiendishly tricky about the strings you're converting? i've successfully used multiple concurrent parallel [any2string]s fed by speech-rate sentence lists and feeding into a single [sendOSC] for hours at a time without seeing anything like this -- and that patch tested ok a few months ago (maybe for a 1/2 hour)... very strange... ... all that said, there's got to be a better way to do the conversion than to delegate the conversion to binbuf_gettext(): all that allocation and de-allocation at every message just makes my skin crawl... maybe we should find a better way to do it... or just use Martin's string patches ;-) marmosets, Bryan On 2007-07-24 23:14:32, IOhannes m zmölnig [EMAIL PROTECTED] appears to have written: moin i get weird random crashes when using [any2string] of bryan's pdstrings library. unfortunately i have not been able to reproduce them reliably (as a matter of fact it only crashes halfway through our performance :-() we have spent some time now in tracking the error down, but to real avail. the only thing that is rather sure is, that it crashes in the freebytes(text) call in any2string_anything() with ***glibc detected *** free(): invalid next size(fast): 0x0823e3f0 *** nevertheless i cannot find anything wrong. has anybody else experienced this before? bryan? any insights would be helpful i'll file a bug-report later... -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pdstring's crashing
moin again, having had a closer look, i'm 99.9% certain that my code is at fault here (said error is typically produced by writing beyond an array's bounds); so now I've stopped writing the trailing NUL to the string populated by binbuf_gettext() -- there might still be a bounds problem with other dynamically allocated arrays (x-x_argv comes to mind), but since freebytes(text) is failing, text looks like the prime suspect to me... the new code has been checked into cvs as externals/moocow/pdstring v0.04 ... let me know if it works (or doesn't)... and send me some sequence of inputs that reproduces the error if you can find one... marmosets, Bryan On 2007-07-24 23:14:32, IOhannes m zmölnig [EMAIL PROTECTED] appears to have written: crashes in the freebytes(text) call in any2string_anything() with ***glibc detected *** free(): invalid next size(fast): 0x0823e3f0 *** -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pdstring's crashing
moin Martin, Yep, I just had another glimpse at your [str] code too, and noted the recent change ;-) I suppose the best workaround for [any2string] is probably going to be pre-allocation too, but it's too late for me to implement that tonight; maybe tomorrow... marmosets, Bryan On 2007-07-25 01:00:48, Martin Peach [EMAIL PROTECTED] appears to have written: Bryan Jurish wrote: all that allocation and de-allocation at every message just makes my skin crawl... maybe we should find a better way to do it... or just use Martin's string patches ;-) When I made the [str] external that uses the string atom, I found that constantly reallocating/resizing memory eventually crashed pd so I ended up just allocating a big wad of space up front for each [str]. If the user can set the initial size of this memory then the amount of wasted ram may be minimized, but the default is quite large. Martin -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] sending data out using sprintf
moin Alain, I've never passed pointers around between externals myself, but... On 2007-06-22 04:57:35, [EMAIL PROTECTED] appears to have written: I am trying to send some data out of an outlet using a symbol pointer. I have tried using sprintf like martin suggested with little succes. I am sure I am the one doing something wrong. I am getting a pointer symbol but I am not able to convert the pointer back. In external#1 I have: The out IplImage *frame; char symstr[10]; t_symbol *sym; sprintf(symstr, %p, frame); sym = gensym(symstr); outlet_symbol(x-m_outFrames, sym); With this I get an address like: symbol 0x1159da0 ... looks kosher to me ... ...but on the conversion in external#2 I get the problem. The conversion looks like: The in--- IplImage *in_frame; x-in_frame = (IplImage *)atol(s-s_name); post(frame %s, x-in_frame); post(symbol %s,s-s_name); ...with this I get this: frame (null) symbol 0x1159da0 first of all, you probably want to post(frame %p, x-in_frame), rather than %s. Second, in the docs for my atol (here under linux|glibc), I see: -- Function: long int atol (const char *STRING) This function is similar to the `strtol' function with a BASE argument of `10', except that it need not detect overflow errors. The `atol' function is provided mostly for compatibility with existing code; using `strtol' is more robust. ... so if your atol() is similar, then trying to convert a hex string to a pointer with atol() is an exercise in futility (since in general, 10!=16). strtol() ought to work better, auto-detetcting the hex-iness of the string by its '0x' prefix. You might also just want to roll out the big guns and use the %x format to scanf(), but strtol() is likely to be the better way to go. marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] string type for pd
moin Martin, On 2007-02-04 00:40:03, Martin Peach [EMAIL PROTECTED] appears to have written: Bryan Jurish wrote: at any rate, a thousand thanks for your work, and I'm looking forward to playing with real strings in pd! Good to know I've done something useful for once! I guess my question now is whether it's best to have a single [str] object with lots of selectors for different functions a la [list] as I did in str.c, or a bunch of objects like [str_join] [str_split] all in a str library, or individual objects in flatspace. I myself am partial to multiple objects, for semantic and coding-aesthetic reasons, but I can see that the parallel to [list] could be a motivation for the single-object approach. As to the question of library vs. a flat collection of single-object externals, I suppose the question is just how much of a common codebase would the various objects need? you could also even make multiple build targets (ext13 style) for the library and the flat collection, leaving the choice up to the user... marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] string type for pd
morning Martin, morning list, just a note: I've patched the pd-0.40-2 source re-compiled here (separate build, not related to my flext problems mentioned in another thread;-)), and I'm still triggering the #error at line 11 of str.c (apparently induced because !defined(t_string)), despite the fact that my (patched) m_pd.h (which is being properly (#include)d does in fact include the relevant typedef. I'm running gcc-4.1.2 on debian-unstable/x86, and it seems that here, typedef...t_string does *not* in fact #define t_string in the preprocessor sense (a small test program confirms this). [str] builds fine if I comment out the #ifndef...#endif, but I hereby humbly suggest finding a better method to test for pd-internal string support (either a real preprocessor macro defined with #define in the patched m_pd.h or an autoconf-style test compile, which is probably way overboard, but at least wouldn't require a new patch)... at any rate, a thousand thanks for your work, and I'm looking forward to playing with real strings in pd! marmosets, Bryan On 2007-01-27 17:53:19, Martin Peach [EMAIL PROTECTED] appears to have written: I have implemented a string type for Pure Data as well as a [str] object that uses it. [snip] -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
On 2006-12-17 03:09:19, Martin Peach [EMAIL PROTECTED] appears to have written: A string could be considered unused when its length is set to 0. Memory would need to be dynamically allocated in small blocks. The API should return no method for string if the external doesn't implement strings. ... which wouldn't get us true strings in the mathematical sense of a free monoid Alphabet,concat(), since the empty string is the identity element for concat()... marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
moin Martin, moin list, On 2006-12-17 21:46:50, Martin Peach [EMAIL PROTECTED] appears to have written: Bryan Jurish wrote: On 2006-12-17 03:09:19, Martin Peach [EMAIL PROTECTED] appears to have written: A string could be considered unused when its length is set to 0. Memory would need to be dynamically allocated in small blocks. The API should return no method for string if the external doesn't implement strings. ... which wouldn't get us true strings in the mathematical sense of a free monoid Alphabet,concat(), since the empty string is the identity element for concat()... Yes, I agree there should be no restriction on empty strings. I also think there is no need to destroy strings except when the patcher is closed, so it's not really an issue. if by destroy you mean de-allocation of the string struct itself (i assume you do; your suggestion looks a lot like a glib GString btw, which is im(ns)ho a good general purpose c string struct), and if a string therefore winds up being just something like a symbol with a volatile value (i.e. doesn't get written to the symbol table), then i agree. what i think we need to avoid with strings (i don't think anyone has suggested otherwise, i'm just stating the obvious) is symbol-style permanent allocation for every string *value*. string variables could/should be handled like any other pd atom: the external which creates them is responsible for (de-)allocation, which would wind up doing what you suggest and freeing any allocated memory when the responsible object is destroyed (provided the object doesn't leak memory, but i think we can assume c programmers are used to keeping track of such things -- ymmv). in fact, this is how [any2string] handles things, in its ugly list-of-floats way... marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
autools build (was: [PD-dev] branch-v0-39-2-extended created)
On 2006-12-14 01:34:07, Hans-Christoph Steiner [EMAIL PROTECTED] appears to have written: On Dec 13, 2006, at 3:41 AM, Bryan Jurish wrote: yup, i use a hacked Makefile.am for my pd externals, because the builtin targets (install, uninstall, dist, clean, etc.) are so darned handy. still, there's no reason why i couldn't pack in a default makefile as well. Perhaps an even better approach would be to help me figure out how to do everything with autoconf and automake, replacing externals/Makefile. eek. well, i've now read the README and had a look at the developer docs on puredata.org, but i'm still a bit baffled as to how the whole build system hangs together (haven't spent much time perusing the actual makefiles yet). as to using the autotools for building pd externals, using my current conventions, I'd estimate that it's actually more effort (for the developer) than tailoring the 'template' section of externals/Makefile: basically, what I do (well, the relevant bits anyways) for a new external library (see pdstring or gfsm for examples) is the following [might not be very helpful, but i had to refresh my memory, so here it is]: in configure.in [now officially configure.ac, but I'm lazy]: + add configure arguments using AC_ARG_WITH: --with-pd-dir=DIR * default=/usr/local/pd * sets $(pddir) and $(pddocdir), for installation --with-pd-extdir=DIR * default=$PD_DIR/externs * sets $(pdextternsdir), for installation --with-pd-include=DIR * default=$PD_DIR/src * sets $(pdincludedir), for compiler flags + sanity check for m_pd.h with AC_CHECK_HEADER + (do whatever checks are necessary for the external: gfsm, etc.) + set machine-dependent compiler flags and PDEXT (copied from pd's own configure.in) + if the package supports multiple-external-library and single-file build modes, add arguments for selection and set a variable (i use PD_OBJECT_EXTERNALS) that gets used in src/Makefile.am to set pdexterns_PROGRAMS ~ there's actually no such argument in pdstring, but there could be in src/Makefile.am: + major ugly nasty hack: set EXEEXT=.$(PDEXT) ~ so I can use *_PROGRAMS targets to for externals + easy stuff (similar to Makefile 'template' tailoring): ~ set pdexterns_PROGRAMS (pdexterns_EXTRA_PROGRAMS) to the externals I (might) want to build ~ set pdexterns_DATA to any abstractions I want to install ~ set pddoc_DATA to any help patches I want to install ~ set myextern_SOURCES to the actual source files for 'mylibrary' ~ adopt compiler and linker flags into AM_CPPFLAGS, AM_CFLAGS, AM_CXXFLAGS, mylibrary_LDFLAGS ~ add distributed pd patches to EXTRA_DIST ... i also use a config/ subdir (AC_CONFIG_AUX_DIR) to keep the autotools files out of the package root directory, but that's more hindrance than help for a template-like system, and shouldn't really make any difference at all. that having been said, i think the right way to do it would actually be to write a small common set of m4 macros that developers could just call from configure.(in|ac) and use in Makefile.am, analagous to AM_INIT_AUTOMAKE() or AM_PROG_LIBTOOL(); call it something like 'PUREDATA_BUILD_INIT()', which could take care of all of the configure.(in|ac) manipulations, as well as the various FLAGS variables. Heck, maybe we could even use libtool directly... setting EXEEXT=.$(PDEXT) is very very ugly, i admit. the right thing to do here (im(ns)ho) would really be just to tweak the automake $(whatever_)PROGRAMS expansion code into something like $(whatever_)PDEXTERNS. The default install dir for _PDEXTERNS targets could then be set to $(pdexternsdir) [vs. $(bindir) for _PROGRAMS], so just setting PDEXTERNS = any2string string2any would suffice. Similarly for documentation (PDDOCS?), abstractions (PDPATCHES?), etc. A default configure.in could even be made available which performs all of the basic configuration (AC_PROG_CC, AM_INIT_AUTOMAKE, PUREDATA_BUILD_INIT), for those who don't need/want additional autoconf checks. getting all of that to work properly and transparently would be pretty heavy on the m4 coding side, and I've only ever used m4 in a very rudimentary capacity (stupid string substitution). it would have advantages (centralized administration of compiler flags for known architectures, conventional default directories, install, uninstall, dist, distcheck targets, etc. etc.), but sounds like more than i can personally chew at the moment [cf. signature] ;-) marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] branch-v0-39-2-extended created
morning Hans, morning list, On 2006-12-13 07:04:37, Hans-Christoph Steiner [EMAIL PROTECTED] appears to have written: If you want to use the Pd-extended build system, its currently just a plain Makefile. No fancy ./configure or automake stuff, (tho it would be nice if there was). Basically, just copy the template section in externals/Makefile and edit it so that your code compiles and is installed into the right places. I tried briefly with your code, but there is was stuff done by auto tools. yup, i use a hacked Makefile.am for my pd externals, because the builtin targets (install, uninstall, dist, clean, etc.) are so darned handy. still, there's no reason why i couldn't pack in a default makefile as well. many thanks for the tip -- i'll try adding some default makefiles (and probably config.h etc.) when compiling on the new machine once I get it... marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pool files: UTF-8 encoding
morning Thomas, Hans-Christoph, and list, On 2006-11-30 03:20:56, Hans-Christoph Steiner [EMAIL PROTECTED] appears to have written: locales is the library and tool that handles that stuff, IIRC. You'll want to look into the env vars LANG, LC_ALL, etc. I think that's supposed to be system-wide, but with all those grabbag distros based on the Linux kernel, you never know who implemented what and how in their bit. afaik, locale.h doesn't handle any character set translation; it just ensures that isalpha() co. work sensibly. there's also no guarantee that the current input and/or display modes will conform to the value of $LANG, but i agree that $LANG is probably the safest information source for the user's preferred encoding. On Nov 29, 2006, at 4:37 PM, Thomas Grill wrote: Is there an API function to query this encoding i don't know which function(s) to use, but you might also look at the registry and encoding fields of the currently selected X font. is there a system function to convert from/to UTF-8? i don't think there's anything like a universally applicable system function guaranteed to work everywhere, but i use librecode for character set translation on linux. i've also heard good reports about iconv, but have never used it directly myself. marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
