Pd-dev December 2010

pd-dev@lists.iem.at

19 participants
50 discussions

[ pure-data-Patches-3136644 ] [bugfix] packOSC crashes with bundledepth>32
by SourceForge.net 13 Dec '10

13 Dec '10

Patches item #3136644, was opened at 2010-12-13 18:16 Message generated for change (Tracker Item Submitted) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3136644&group_… 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: 7 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Martin Peach (mrpeach) Summary: [bugfix] packOSC crashes with bundledepth>32 Initial Comment: when creating deeply nested bundles [packOSC] will complain if the bundle-depth is larger than 32 (MAX_BUNDLE_NESTING) this is ok, however, if you then try to close the bundle (with "]"), Pd will segfault. see attached patch to reproduce the problem ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3136644&group_…

1 0

[PATCH] Replace getbytes calls by alloca whenever possible in mrpeach's packOSC.c
by Julien 'Lta' BALLET 12 Dec '10

12 Dec '10

Hello, As said in the title, i submit you a small patch to mrpeach's osc code, to replace calls to getbytes by alloca calls in part of the code that might get called in the soundcard callback. The considered memory sizes are quites small and then won't smash the stack. This removes the need for memory deallocation and reduces the page fault risk as well as the memory allocation time. This is kind of a naive patch, since i don't fully know yet the pd codebase. Any comment would be appreciated. Regards, Lta.

4 6

Re: [PD-dev] [PD] pd-pidip into Debian
by András Murányi 11 Dec '10

11 Dec '10

On Sat, Dec 11, 2010 at 5:17 AM, ydegoyon(a)gmail.com <ydegoyon(a)gmail.com>wrote: > Bernardo Barros wrote: > >> 2010/12/4 Mathieu Bouchard<matju(a)artengine.ca>: >> >> >>> It's because GPL is for hippies, or something. >>> >>> >> It's the other way around. BSD is hippier: >> Someone in Berkley smoked marijuana and said: >> "hey man, let's just give it away, who cares what people will do with it, >> let them turn this into proprietary or whatever". >> >> I don't get this BSD fondness of the PD people.... >> >> _______________________________________________ >> Pd-list(a)iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> > you confuse marijuana with LSD if i can intervene, > it was LSD license at that time, > for a joke that makes sense > > then you are all buried deeply in the same system > that it's useless to talk, really > > ciao, > sevy > What do you know about us? Why do you take the privilege to offend people on this mailing list? When you go to the supermarket, you yell the same things at people? Or you don't go to the supermaket? You don't pay taxes? You don't have have a driver's license, ID card, social security, you didn't go to school "by the system"? I'm afraid what you call "system" is human civilization, and even if you wish to believe otherwise, you are part of it too. And again, you don't know what we do against or for the "system" so pay more respect and don't offend people you don't know shit about. Andras

1 0

Re: [PD-dev] removing non-free code from pure-data SVN
by Xavier Miller 09 Dec '10

09 Dec '10

Hello, I am not a PD developer, but as (amateur) artist and (professional) software developer, I am very sensitive about copyrights and licences. I am a fervent Free Software defender, and I want to accept all licences I have to respect for all software I use. In my Linux distribution (Gentoo Linux), we have to explicitly list what licences we accept, and set its name in a list, after reading it. So, I discover I have installed pd-extended without knowing that non-free or restrictive licences are used, which I would refuse (I don't like licences as PiDip, especially if it is derived from a GPL project but not respecting the GPL licence, for me it's like pirating software). So, yes, please list ALL the licences which are included in PD/PD-extended, especially those that are not compatible with common Open Source / Free licences ! At least users need to know they use non-free parts of software, and use it being aware of it. (I use proprietary software too, and I know its terms). Kind regards, Xavier Miller. Le 08/12/10 21:10, Hans-Christoph Steiner a Ã©crit : > > So we now have two non-free libraries included in the pure-data SVN: > pidip and unauthorized. As far as I understand it, this is in violation > of what SourceForge asks of projects, and also seems to me in violation > of the developers on the pure-data SourceForge, since the rest of the > code there uses free licenses (mostly GPL, BSD-like, and Tcl-like). > > So the question is: should we remove pidip and unauthorized from the > pure-data SVN? > > .hc > > ---------------------------------------------------------------------------- > > > News is what people want to keep hidden and everything else is > publicity. - Bill Moyers > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev(a)iem.at > http://lists.puredata.info/listinfo/pd-dev

5 6

removing non-free code from pure-data SVN
by Hans-Christoph Steiner 09 Dec '10

09 Dec '10

So we now have two non-free libraries included in the pure-data SVN: pidip and unauthorized. As far as I understand it, this is in violation of what SourceForge asks of projects, and also seems to me in violation of the developers on the pure-data SourceForge, since the rest of the code there uses free licenses (mostly GPL, BSD-like, and Tcl-like). So the question is: should we remove pidip and unauthorized from the pure-data SVN? .hc ---------------------------------------------------------------------------- News is what people want to keep hidden and everything else is publicity. - Bill Moyers

3 2

[ pure-data-Bugs-3131312 ] garray_get() not implemented
by SourceForge.net 07 Dec '10

07 Dec '10

Bugs item #3131312, was opened at 2010-12-07 11:54 Message generated for change (Tracker Item Submitted) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3131312&group_… 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: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: garray_get() not implemented Initial Comment: m_pd.h declares a function garray_get() which seems to be meant to retrieve values from an arbitrary array: EXTERN t_float garray_get(t_garray *x, t_symbol *s, t_int indx); unfortunately, this function is nowhere implemented! please either remove the function declaration or implement it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3131312&group_…

1 0

[ pure-data-Patches-3125858 ] Mac OS X key-command/focusin problem when opening patches
by SourceForge.net 07 Dec '10

07 Dec '10

Patches item #3125858, was opened at 2010-12-02 21:31 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3125858&group_… 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: puredata Group: bugfix Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: Mac OS X key-command/focusin problem when opening patches Initial Comment: Miller and I have been banging our heads against the Mac OS X-only bug where the menubar would get focus and flash when you hit keys, but the key command wouldn't work or do anything else. It turns out that it is caused by the 'grab' command in the ::pdwindow::busygrab proc. If you comment that out, then this bug goes away. Odd that it only affects Mac OS X... The grab function is used to put up the busy cursor when Pd is loading a patch, and it also locks the user out of trying to do things, like edit a patch, while 'pd' is busy trying to load the patch. This works by forcing the focus to be on the Pd window while 'pd' is busy. It seems to work like a charm on X11 and Windows, but on Mac OS X, it causes the new windows to not get the FocusIn message, and therefore not set itself up properly. This patch changes how the busy grab/release is done, as well has how pd-gui declares the patch loaded. hopefully things are easier to use without bugs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3125858&group_…

1 0

[ pure-data-Patches-3125858 ] Mac OS X key-command/focusin problem when opening patches
by SourceForge.net 07 Dec '10

07 Dec '10

Patches item #3125858, was opened at 2010-12-02 21:31 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3125858&group_… 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: puredata Group: bugfix Status: Open Resolution: None >Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: Mac OS X key-command/focusin problem when opening patches Initial Comment: Miller and I have been banging our heads against the Mac OS X-only bug where the menubar would get focus and flash when you hit keys, but the key command wouldn't work or do anything else. It turns out that it is caused by the 'grab' command in the ::pdwindow::busygrab proc. If you comment that out, then this bug goes away. Odd that it only affects Mac OS X... The grab function is used to put up the busy cursor when Pd is loading a patch, and it also locks the user out of trying to do things, like edit a patch, while 'pd' is busy trying to load the patch. This works by forcing the focus to be on the Pd window while 'pd' is busy. It seems to work like a charm on X11 and Windows, but on Mac OS X, it causes the new windows to not get the FocusIn message, and therefore not set itself up properly. This patch changes how the busy grab/release is done, as well has how pd-gui declares the patch loaded. hopefully things are easier to use without bugs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3125858&group_…

1 0

Re: [PD-dev] GUI plugins
by András Murányi 05 Dec '10

05 Dec '10

2010/9/13 Hans-Christoph Steiner <hans(a)at.or.at> > > Hey András, > > Since we are in bug fixing mode for 0.43, now is a good time to test your > GUI plugins, so we can make sure that they work in 0.43. Your > plugins-plugin.tcl is a good example. > > .hc > OK, you'll find plugins-plugin rewritten and attached. Later i'll add it to the wiki too... Now i'd rewrite my other plugins, and the first would be a simple one binding fullscreen to F11 - but it seems keypresses are already captured and i cannot get a hold of F11 any more from TCL. Is that right or am i just lost? Andras

2 1

general makefile question
by IOhannes m zmoelnig 04 Dec '10

04 Dec '10

during the debian packaging of externals i once more stumbled across one of my many problems with make, which i was never able to solve in a satisfactory way. it is: the Makefile uses CFLAGS and LDFLAGS to set crucial flags to the build process e.g. LDFLAGS uses "-Wl,--export-dynamic -shared" to build shared libraries (in our case: externals) however, some meta build processes (like debian packaging) explicitely set these FLAGS to what they think are good optimization/debugging defaults e.g. make get's called like $ /usr/bin/make LDFLAGS="" CFLAGS="-I/usr/local/include" this however effectively disables all the settings done within the Makefile, which leads to not passing "-Wl,--export-dynamic -shared" to the linker, leading to a fatal error when linking. 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? this is such a fundamental thing that i'm sure there has to be an elegant solution to this but i never came across one. the PD_LDFLAGS seems a bit like a kludge to me. fgmsdr IOhannes

7 15

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev December 2010