Re: [PD-dev] Error when crosscompiling pdlua
Hallo, Martin Peach hat gesagt: // Martin Peach wrote: With dlls you have to export symbols using a def file or /export: statement on the command line (or __declspec(dllexport) in the code with MSVC). On linux all symbols in a shared library are visible by default, it's about the structure of a windows dll versus that of a unix shared library, not gcc. So unless pd.dll is built with sys_loader exposed, I won't be able to build a loader-external, right? If so, then I'll let the MS-Windows-people take over building pdlua. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Error when crosscompiling pdlua
Frank Barknecht wrote: Hallo, Martin Peach hat gesagt: // Martin Peach wrote: With dlls you have to export symbols using a def file or /export: statement on the command line (or __declspec(dllexport) in the code with MSVC). On linux all symbols in a shared library are visible by default, it's about the structure of a windows dll versus that of a unix shared library, not gcc. So unless pd.dll is built with sys_loader exposed, I won't be able to build a loader-external, right? If so, then I'll let the MS-Windows-people take over building pdlua. Usually on Windows you link against pd.lib, not pd.dll, so it ought to work. You will need to include the header file containing sys_loader (except I can't find sys_loader anywhere in the pd source). Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Error when crosscompiling pdlua
Hallo, Martin Peach hat gesagt: // Martin Peach wrote: Frank Barknecht wrote: Martin Peach hat gesagt: // Martin Peach wrote: With dlls you have to export symbols using a def file or /export: statement on the command line (or __declspec(dllexport) in the code with MSVC). On linux all symbols in a shared library are visible by default, it's about the structure of a windows dll versus that of a unix shared library, not gcc. So unless pd.dll is built with sys_loader exposed, I won't be able to build a loader-external, right? If so, then I'll let the MS-Windows-people take over building pdlua. Usually on Windows you link against pd.lib, not pd.dll, so it ought to work. You will need to include the header file containing sys_loader (except I can't find sys_loader anywhere in the pd source). Sorry, it's sys_register_loader in s_loader.c, but not in any header. HCS did a bug report regarding this already. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] strange bug
hi all i encountered a very strange bug, that seems to be very difficult to trace back. although i cannot provide very usuable information at this point (i assume), i just wanted to report it anyway. as i am not a coder and also not experienced in debugging, some of you might have hints and ideas how to proceed. i can reliably crash pd, but only if a fulfill a rather funny set of conditions. creating a [table yoyo 6e+07] pd crashes, but only: -if i first loaded _chat.pd from netpd -if pd is running over jack it doesn't crash, when pd is not connected to jack while instantiating the table. it also doesn't crash, when i first instantiate the [table] and then load _chat.pd. i found out, that it might be related to an external, that _chat.pd is using. loading _chat.pd without the externals makes the bug untriggerable. i haven't shrinked it down to one specific external, but i will do so as soon as i find time. here is the list of externals, that _chat.pd is using (only from zexy and maxlib): netclient v0.3, written by Olaf Matthes [EMAIL PROTECTED] [makesymbol] part of zexy-2.2.0 (compiled: Dec 7 2007) Copyright (l) 1999-2007 IOhannes m zm�nig, forum::f�::uml�te IEM [list2symbol] part of zexy-2.2.0 (compiled: Dec 7 2007) Copyright (l) 1999-2007 IOhannes m zm�nig, forum::f�::uml�te IEM [any2list] part of zexy-2.2.0 (compiled: Dec 7 2007) Copyright (l) 1999-2007 IOhannes m zm�nig, forum::f�::uml�te IEM [symbol2list] part of zexy-2.2.0 (compiled: Dec 7 2007) Copyright (l) 1999-2007 IOhannes m zm�nig, forum::f�::uml�te IEM [drip] part of zexy-2.2.0 (compiled: Dec 7 2007) Copyright (l) 1999-2007 IOhannes m zm�nig, forum::f�::uml�te IEM [lister] part of zexy-2.2.0 (compiled: Dec 7 2007) Copyright (l) 1999-2007 IOhannes m zm�nig, forum::f�::uml�te IEM [glue] part of zexy-2.2.0 (compiled: Dec 7 2007) Copyright (l) 1999-2007 IOhannes m zm�nig, forum::f�::uml�te IEM [table yoyo 6+07] is here only used to make pd reserve a certain amount of memory. the same happens with a number of tables, that uses the same amount of memory. it can also be triggered by loading heavy patches, that cause pd to use the exact same amount of memory. the limit seems to be somewhere around 228MB. i tested it on two computers: pd-0.40.3 / ubuntu dapper / pentium M / 512MB RAM pd-0.40.3 / ubuntu gutsy / amd (can't recall exact model) / 1.5GB RAM and on both i encountered the exact same behaviour. however, someone from #dataflow tried to trigger it as well and failed. actually i don't even know, if it is worth investigating it, since i found a way to use more memory with pd than 228MB. comments appreciated. roman here the output of: valgrind pd -rt -stderr -jack -channels 6 -open /home/roman/netpd/_chat.pd (after instantiating [table yoyo 6e+07]), if this could be of any help: pd: resizebytes() failed -- out of memory ==11536== ==11536== Thread 1: ==11536== Invalid write of size 4 ==11536==at 0x8078C74: word_init (g_scalar.c:27) ==11536== Address 0x4 is not stack'd, malloc'd or (recently) free'd ==11536== ==11536== Process terminating with default action of signal 11 (SIGSEGV) ==11536== Access not within mapped region at address 0x4 ==11536==at 0x8078C74: word_init (g_scalar.c:27) ==11536== ==11536== ERROR SUMMARY: 150 errors from 27 contexts (suppressed: 23 from 1) ==11536== malloc/free: in use at exit: 332,958 bytes in 11,950 blocks. ==11536== malloc/free: 19,862 allocs, 7,912 frees, 242,700,919 bytes allocated. ==11536== For counts of detected errors, rerun with: -v ==11536== searching for pointers to 11,950 not-freed blocks. ==11536== checked 18,409,376 bytes. ==11536== ==11536== LEAK SUMMARY: ==11536==definitely lost: 4,149 bytes in 59 blocks. ==11536== possibly lost: 136 bytes in 2 blocks. ==11536==still reachable: 328,673 bytes in 11,889 blocks. ==11536== suppressed: 0 bytes in 0 blocks. ==11536== Use --leak-check=full to see details of leaked memory. Killed pd_gui: pd process exited ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [-SPAM-] [PD] SQL wrappers
On 12/11/07, Jamie Bullock [EMAIL PROTECTED] wrote: I've been thinking along these lines also. In this pd-sql rethink, there are two things that come out for me: i) We should support the 'query as an argument to the object with placeholders' syntax, AND the 'query passed to an inlet as a message' syntax. ii) We should modularise the functionality of these objects at least into db.conn and db.query type objects, maybe more. (I know you suggested this ages ago!) The design is getting better, the implementation is getting more tricky ;-) Jamie, Could you take a look at the outline I wrote up? I want to make sure that we are all on the same page before doing this. Thanks, Mike ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-1849073 ] pix_record stops recording after 4 frames
Bugs item #1849073, was opened at 2007-12-12 03:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=1849073group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gem Group: v0.40.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: oli44 (oli44) Assigned to: Nobody/Anonymous (nobody) Summary: pix_record stops recording after 4 frames Initial Comment: Bug produced with the help patch of gem/pix_record When trying to record in auto mode or image by image, pix_record records a few frames (at best 4) and send writes [pix_record]: pix_record : movie written to the console. Codecs i tried: mjpeg, mjpa, ffmpeg_mjpg GEM: using MMX optimization GEM: Graphics Environment for Multimedia GEM: ver: 0.91-cvs GEM: compiled: Dec 9 2007 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version) GEM:Chris Clepper GEM:James Tittle GEM:IOhannes m zmoelnig GEM: with help by Guenter Geiger, Daniel Heckenberg, Cyrille Henry, et al. Pd version 0.40.3-extended-20071209 for debian testing -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=1849073group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
