Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
Le 2012-02-08 à 09:08:00, IOhannes m zmoelnig a écrit : another reason is, that with accessor-functions you can more easily stay binary compatible both backward and forward than with directly accessing the struct. Depends what you think can be changing in the future... sure you can do something like that with structs as well (typecast to different structs depending on the version of the Pd-host), but with accessors it comes for free (well, at least backwards compatibility) ok... then why not accessors, then. fine. Has anyone made a list of all (current) globals yet ? e.g. c++11 (c++? ever tried to compile Pd with a c++ compiler?) I did. I don't recall significant difficulties... it might have been i guess i was exaggerating the use of C++ reserved keywords as variable names and the like. C++ reserved keywords are easy to deal with. They're easy to search-and-replace, or #define away. Some other things are a bit more work, but that's quite tiny compared to most other cases of «translating» between very similar programming languages. In the eighties, people spent a LOT more time porting software from one version of Microsoft BASIC to another version of Microsoft BASIC that was incompatible simply because it was on a different computer brand. but the original suggestion sounded to me like: 'a solution for all our problems is to switch to new C++ features in a "CC=g++ -fdo-what-i-want" manner', and i wanted to object to that. Well, a good reason to «object» to that is simply that C++11 implementations are not ready for use, and even if they were, they'd be so new that they wouldn't be bundled with Ubuntu, Debian, Fink, MinGW nor XCode. Apart from the fact that this feature will not really cure the problem and will create new ones. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
Le 2012-01-26 à 14:45:00, Charles Henry a écrit : When talking about cluster computing, I had someone once ask: "Is that a case where the whole is greater than the sum of its parts?" "It's less. Always less." Depends on how you count it. You may also see it as a bunch of computers in which 0 computer can do task T in time N, but they can join together to form 1 (or more) computer(s) that can do task T in time N or less. In that sense, it's infinitely more powerful. This way of seeing it is much more important in realtime apps than in batch-compute-over-the-weekend apps. It's like how one ninja turtle alone can't beat a certain evil monster, but with teamwork, they can. ;) __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpng12 fix for gridflow.pd_darwin
On Feb 11, 2012, at 12:16 PM, Mathieu Bouchard wrote: > Le 2012-02-11 à 11:31:00, Hans-Christoph Steiner a écrit : > >> I just tried loading gridflow 9.13 on Pd-extended 0.43 on Mac OS X 10.6.8, >> and it couldn't load because it was looking for libpng12.0.dylib inside of >> Pd-extended. The included dylibs are automatically included based on what >> the included objects are linked to, so they are not good to rely on, because >> they can change in a given version. > > GridFlow 9.13 binaries for OSX already comes with libpng12.dylib. > > GridFlow 9.13 source is slightly older, and doesn't include some fixes that I > made when I built the binary package. > > I should really, really release the 9.14 source... > >> So you can easily include libpng12.0.dylib in your gridflow package, here's >> how: > > It's been like that in SVN for no less than 12 months. > > I also vaguely remember trying to compile with libpng14 at first, but that > must have been an older story... I don't remember what had gone wrong. It > seems that either would work with GF (as long as libpng12 is recent enough), > but the headers have to match the lib. I just downloaded gridflow-9.13-macosx104-i386.tar.gz and it was looking for libpng12 at @executable_path/../../lib/libpng.12.0.dylib. .hc I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpng12 fix for gridflow.pd_darwin
Le 2012-02-11 à 11:31:00, Hans-Christoph Steiner a écrit : I just tried loading gridflow 9.13 on Pd-extended 0.43 on Mac OS X 10.6.8, and it couldn't load because it was looking for libpng12.0.dylib inside of Pd-extended. The included dylibs are automatically included based on what the included objects are linked to, so they are not good to rely on, because they can change in a given version. GridFlow 9.13 binaries for OSX already comes with libpng12.dylib. GridFlow 9.13 source is slightly older, and doesn't include some fixes that I made when I built the binary package. I should really, really release the 9.14 source... So you can easily include libpng12.0.dylib in your gridflow package, here's how: It's been like that in SVN for no less than 12 months. I also vaguely remember trying to compile with libpng14 at first, but that must have been an older story... I don't remember what had gone wrong. It seems that either would work with GF (as long as libpng12 is recent enough), but the headers have to match the lib. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpng12 fix for gridflow.pd_darwin
On Feb 11, 2012, at 11:31 AM, Hans-Christoph Steiner wrote: > > I just tried loading gridflow 9.13 on Pd-extended 0.43 on Mac OS X 10.6.8, > and it couldn't load because it was looking for libpng12.0.dylib inside of > Pd-extended. The included dylibs are automatically included based on what > the included objects are linked to, so they are not good to rely on, because > they can change in a given version. > > So you can easily include libpng12.0.dylib in your gridflow package, here's > how: > > cp /Applications/Pd-extended.app/Contents/lib/libpng12.0.dylib \ >/Library/Pd/gridflow/libpng12/ > install_name_tool -id /Library/Pd/gridflow/libpng12/libpng12.0.dylib \ >/Library/Pd/gridflow/libpng12/libpng12.0.dylib > install_name_tool -change @executable_path/../../lib/libpng12.0.dylib \ >@loader_path/libpng12/libpng12.0.dylib \ >/Library/Pd/gridflow/gridflow.pd_darwin > > Now the gridflow/ folder can go into /Library/Pd, ~/Library/Pd or anywhere > really. @loader_path is the path from where gridflow.pd_darwin is loaded. I forgot to say, it will be relocatable once all of the libs in gridflow/libs are set to @loader_path/libs/, i.e. install_name_tool -change \ /Library/Pd/gridflow/libs/libglib-1.2.0.dylib \ @loader_path/libs/libglib-1.2.0.dylib \ /Library/Pd/gridflow/gridflow.pd_darwin .hc "[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] libpng12 fix for gridflow.pd_darwin
I just tried loading gridflow 9.13 on Pd-extended 0.43 on Mac OS X 10.6.8, and it couldn't load because it was looking for libpng12.0.dylib inside of Pd-extended. The included dylibs are automatically included based on what the included objects are linked to, so they are not good to rely on, because they can change in a given version. So you can easily include libpng12.0.dylib in your gridflow package, here's how: cp /Applications/Pd-extended.app/Contents/lib/libpng12.0.dylib \ /Library/Pd/gridflow/libpng12/ install_name_tool -id /Library/Pd/gridflow/libpng12/libpng12.0.dylib \ /Library/Pd/gridflow/libpng12/libpng12.0.dylib install_name_tool -change @executable_path/../../lib/libpng12.0.dylib \ @loader_path/libpng12/libpng12.0.dylib \ /Library/Pd/gridflow/gridflow.pd_darwin Now the gridflow/ folder can go into /Library/Pd, ~/Library/Pd or anywhere really. @loader_path is the path from where gridflow.pd_darwin is loaded. .hc "A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd0.43-extended autobuild jack error
Can you post those patches and how to make them trigger the glitch? Does it
cause any problems, or just post that error message?
.hc
On Feb 11, 2012, at 12:48 AM, patrick wrote:
> hi pd-dev / hans,
>
> (Tcl) UNHANDLED ERROR: bad window path name ".x17413d0"
>while executing
> "wm attributes .x17413d0 -topmost 1 "
>("uplevel" body line 175)
>invoked from within
> "uplevel #0 $cmds_from_pd"JACKerror: JackActivationCount::Signal value = 0
> ref = 4
> JACKerror: JackActivationCount::Signal value = 0 ref = 4
> JACKerror: JackActivationCount::Signal value = 0 ref = 4
>
> many patches are glitching in pd-extended 0.43 (from autobuild):
> 10-02-2012
>
> linux (debian) - 64bit
>
> ___
> Pd-dev mailing list
> Pd-dev@iem.at
> http://lists.puredata.info/listinfo/pd-dev
'You people have such restrictive dress for women,’ she said, hobbling away in
three inch heels and panty hose to finish out another pink-collar temp pool
day. - “Hijab Scene #2", by Mohja Kahf
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-3486757 ] [wiimote] crashes on closing containing patch
Bugs item #3486757, was opened at 2012-02-11 04:53 Message generated for change (Tracker Item Submitted) made by reduzent You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3486757&group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: Nobody/Anonymous (nobody) Summary: [wiimote] crashes on closing containing patch Initial Comment: When closing a patch, that contains a [wiimote] object which is connected to an actual wiimote which is frequently reporting states (acceleration or motionplus enabled), Pd segfaults. Program received signal SIGSEGV, Segmentation fault. 0x0809ad14 in outlet_anything (x=0x0, s=0x81a3600, argc=4, argv=0xb154) at m_obj.c:417 417 for (oc = x->o_connections; oc; oc = oc->oc_next) backtrace: #0 0x0809ad14 in outlet_anything (x=0x0, s=0x81a3600, argc=4, argv=0xb154) at m_obj.c:417 #1 0x00538e56 in wiimote_cwiid_motionplus (x=0x8225d78, mesg=0x8236460) at wiimote.c:465 #2 0x005391dd in wiimote_cwiid_message (x=0x8225d78, mesg=0x8236460) at wiimote.c:572 #3 0x00539281 in wiimote_dequeue (nada=0x0) at wiimote.c:690 #4 0x080a293d in sched_tick (next_sys_time=410255360) at m_sched.c:372 #5 0x080a2b7e in m_pollingscheduler () at m_sched.c:482 #6 0x080a2d67 in m_mainloop () at m_sched.c:568 #7 0x080a347a in sys_main (argc=9, argv=0xb3c4) at s_main.c:302 #8 0x080ab147 in main (argc=9, argv=0xb3c4) at s_entry.c:32 This is with Pd 0.43.1 on Ubuntu 11.04 32bit with wiimote 0.4.svn (rev. 15958) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3486757&group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
