Pd-dev February 2011

pd-dev@lists.iem.at

11 participants
53 discussions

sourceforge cleanup
by IOhannes m zmoelnig 10 Feb '11

10 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi all, i want to inform you, that i have done a routine cleanup of our developers at sourceforge. 18 people, who have not committed anything within the last two (2) years, were contacted on the 2011-01-20 (that was also the deadline for the 2 years period), that they are scheduled for removal within one (1) week, if they do not oppose. after that i got into contact with 3 people opposing to their removal, and 3 people aggreing to their removal. today (after 3 weeks of waiting rather than 1 as promised), i have revoked developer status of the following inactive members: aschix, chr15m, chunlee, david_merrill, grholzi, j45ch, krzyszcz, mjmcgonagle, morellid, olafmatt, reakin, xovo those who do check their fingers, might notice that 2 developers are missing. i consider them still pending: ggeiger, of puredata fame, who has not yet answered (and it's technically more complicated to remove an admin than an ordinary developer); and ix9 who had a bouncing email address (but who might be reachable via IRC) mfgadr IOhannes PS: that's the original mail body i sent to all those devs: <snip> Hi, you are a registered developer at the "pure-data" sourceforge project, which means that you have write access to the repository hosted there. our project currently has 43 registered developers, some (18) of them being inactive. as the administrator of the project, i would like to reduce the number of developers to the active ones. since you haven't committed anything within the last two (2) years, you are considered to be "inactive", and therefore i would like to remove you from the list of developers. if you ever feel like you need developer status (=write access to the repository) again, just send an email to the pd-dev mailinglist. the list of inactive developers has been assembled in an half-automated way. so if you feel that this is totally unjustified, please tell me within the next week and i will not remove you from the list of active-developers mfg.asdr IOhannes </snip> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1TuSQACgkQkX2Xpv6ydvRYdQCg2kCx9iT6DSqL3BPKU25pOjdB 7Z4AoI7xx4M5hXCA0Qnlk7qX8hsNakWY =aDqD -----END PGP SIGNATURE-----

2 1

[ pure-data-Patches-3177183 ] readanysf~ makefile fixes
by SourceForge.net 10 Feb '11

10 Feb '11

Patches item #3177183, was opened at 2011-02-10 10:14 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3177183&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: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: august black (augmentus) Summary: readanysf~ makefile fixes Initial Comment: while packaging readanysf~ for debian, i had to apply several fixes to make this work cleanly. here are the issues: #1 temporary .o files are stored in a ./objs/ directory, which does not exist in the released package (i see it is in SVN though) i added rules to the makefile to create this directory if non-existant (and delete it on "clean" as debian doesn't like it if "clean" leaves traces around) #2 the Makefile sets CFLAGS (and LDFLAGS); these common variables are frequently overriden by build-systems (such as the debian package builder); since the flags in the CFLAGS are crucial for successfull builds, overriding these flags will break the build-system. i fixed it so the Makefiloe uses PD_CFLAGS and append (the unset) CFLAGS to this variable: this way users can define their preferred optimization using CFLAGS and the build will still succeed (btw, you should actually use PD_CXXFLAGS/CXXFLAGS for c++ flags) #3 you are setting "-fPIC" conditionally only for 64bit systems; is there a reason to not use it on all systems (including 128bit)? debian builds on a zillion of platforms and usually "-fPIC" is applied throughout. #4 OS-detection code only handles Linux & Darwin; bad thing here is, that it assumes everything Darwin that is not Linux; afaics, this is meant as a boolean discrimination (you don't really expect UNAME to be not "Darwin" on any OSX, do you?), which i inverted (so that everything is Linux that is not Darwin): this is important on Debian as UNAME might be "Linux", "GNU/kFreeBSD" or "GNU"(Hurd) and everything is dealt the same. it would be nice if these changes could be incorporated into upstream. ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-02-10 10:33 Message: since the patch for the 0.42 release does not work for the current SVN, i uploaded both. the SVN14891 patch additionally contains following changes: - use {PD_}CXXFLAGS instead of {PD_}CFLAGS - use "$(CXX)" instead of "g++" also it doesn't remove the ./objs directory on "clean", but still creates it if neccessary ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3177183&group_…

1 0

[ pure-data-Patches-3177183 ] readanysf~ makefile fixes
by SourceForge.net 10 Feb '11

10 Feb '11

Patches item #3177183, was opened at 2011-02-10 10:14 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3177183&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: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) >Assigned to: august black (augmentus) Summary: readanysf~ makefile fixes Initial Comment: while packaging readanysf~ for debian, i had to apply several fixes to make this work cleanly. here are the issues: #1 temporary .o files are stored in a ./objs/ directory, which does not exist in the released package (i see it is in SVN though) i added rules to the makefile to create this directory if non-existant (and delete it on "clean" as debian doesn't like it if "clean" leaves traces around) #2 the Makefile sets CFLAGS (and LDFLAGS); these common variables are frequently overriden by build-systems (such as the debian package builder); since the flags in the CFLAGS are crucial for successfull builds, overriding these flags will break the build-system. i fixed it so the Makefiloe uses PD_CFLAGS and append (the unset) CFLAGS to this variable: this way users can define their preferred optimization using CFLAGS and the build will still succeed (btw, you should actually use PD_CXXFLAGS/CXXFLAGS for c++ flags) #3 you are setting "-fPIC" conditionally only for 64bit systems; is there a reason to not use it on all systems (including 128bit)? debian builds on a zillion of platforms and usually "-fPIC" is applied throughout. #4 OS-detection code only handles Linux & Darwin; bad thing here is, that it assumes everything Darwin that is not Linux; afaics, this is meant as a boolean discrimination (you don't really expect UNAME to be not "Darwin" on any OSX, do you?), which i inverted (so that everything is Linux that is not Darwin): this is important on Debian as UNAME might be "Linux", "GNU/kFreeBSD" or "GNU"(Hurd) and everything is dealt the same. it would be nice if these changes could be incorporated into upstream. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3177183&group_…

1 0

[ pure-data-Patches-3177183 ] readanysf~ makefile fixes
by SourceForge.net 10 Feb '11

10 Feb '11

Patches item #3177183, was opened at 2011-02-10 10:14 Message generated for change (Tracker Item Submitted) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3177183&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: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Nobody/Anonymous (nobody) Summary: readanysf~ makefile fixes Initial Comment: while packaging readanysf~ for debian, i had to apply several fixes to make this work cleanly. here are the issues: #1 temporary .o files are stored in a ./objs/ directory, which does not exist in the released package (i see it is in SVN though) i added rules to the makefile to create this directory if non-existant (and delete it on "clean" as debian doesn't like it if "clean" leaves traces around) #2 the Makefile sets CFLAGS (and LDFLAGS); these common variables are frequently overriden by build-systems (such as the debian package builder); since the flags in the CFLAGS are crucial for successfull builds, overriding these flags will break the build-system. i fixed it so the Makefiloe uses PD_CFLAGS and append (the unset) CFLAGS to this variable: this way users can define their preferred optimization using CFLAGS and the build will still succeed (btw, you should actually use PD_CXXFLAGS/CXXFLAGS for c++ flags) #3 you are setting "-fPIC" conditionally only for 64bit systems; is there a reason to not use it on all systems (including 128bit)? debian builds on a zillion of platforms and usually "-fPIC" is applied throughout. #4 OS-detection code only handles Linux & Darwin; bad thing here is, that it assumes everything Darwin that is not Linux; afaics, this is meant as a boolean discrimination (you don't really expect UNAME to be not "Darwin" on any OSX, do you?), which i inverted (so that everything is Linux that is not Darwin): this is important on Debian as UNAME might be "Linux", "GNU/kFreeBSD" or "GNU"(Hurd) and everything is dealt the same. it would be nice if these changes could be incorporated into upstream. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3177183&group_…

1 0

Re: [PD-dev] access to pd compile farm
by Hans-Christoph Steiner 10 Feb '11

10 Feb '11

My guess is that you need to add another level to the PD_PATH, since your library is two levels off of externals, ie replace ../../pd with ../../../pd .hc On Feb 9, 2011, at 7:01 PM, David Doukhan wrote: > HI Hans, i still have the same problem: > > mingw cannot find the lib pd.... > i can't investiguate the problem now, so i removed cw_binaural from > the main makefile, and i'll check this out friday or saturday... > it's 1AM, i give courses tomorow morning, and play euphonium live at > night... need some rest. > > see ya! > > 2011/2/9 David Doukhan <david.doukhan(a)gmail.com>: >> it works now! >> >> 2011/2/9 David Doukhan <david.doukhan(a)gmail.com>: >>> I've just tried to log through ssh to the machine >>> and i got the following message: >>> >>> rudk% ssh -L3389:localhost:3389 pddev(a)128.238.56.60 >>> Permission denied (publickey,keyboard-interactive). >>> >>> do you think it means my key has not been added yet, or that someone >>> is already connected to the machine? >>> >>> >>> 2011/2/9 Hans-Christoph Steiner <hans(a)at.or.at>: >>>> >>>> Yup, that's what I guessed :-D This machine works differently, >>>> so read the >>>> wiki page: >>>> http://puredata.info/docs/developer/WindowsXPI386 >>>> >>>> Since we've had a back and forth conversation via email, that's >>>> enough for >>>> me. This password is needed to access the GUI, but you can't use >>>> the >>>> password without your ssh key. THe GUI password is: >>>> fixwindowsplease >>>> >>>> One request, I don't know if the pddev account has perms to >>>> install things, >>>> but in any case, please don't run 'make install' at all. >>>> Everything is >>>> manually managed there, so it would be very hard to tell if any >>>> stray files >>>> are put where they might interfere. >>>> >>>> One thing that makes life easy on MinGW is that all the libs are >>>> installed >>>> into /usr/local, so no special flags or env vars. Remember, >>>> you'll have to >>>> use rdesktop to build with MinGW. >>>> >>>> .hc >>>> >>>> On Feb 9, 2011, at 4:17 PM, David Doukhan wrote: >>>> >>>>> <off-list> >>>>> Hi, >>>>> As you can guess, i'm asking the access to the compile farm to >>>>> understand why my code is not compiling on mingw. >>>>> If it seems enough secure to you, I can call you by phone. >>>>> >>>>> </off-list> >>>>> >>>>> 2011/2/9 Hans-Christoph Steiner <hans(a)at.or.at>: >>>>>> >>>>>> If no one has any objections, I'll go ahead and add your key. >>>>>> If you >>>>>> want >>>>>> to access the GUI of the Windows box, necessary to use MinGW/ >>>>>> MSYS, you'll >>>>>> need to contact me off-list to figure out a secure way of >>>>>> getting it to >>>>>> you >>>>>> (voice chat, IM/OTR, pgp, etc.) >>>>>> >>>>>> .hc >>>>>> >>>>>> On Feb 9, 2011, at 3:39 PM, David Doukhan wrote: >>>>>> >>>>>>> hi, >>>>>>> Could someone add me to the compile farm? >>>>>>> my public key is attached to the mail. >>>>>>> >>>>>>> see ya! >>>>>>> >>>>>>> -- >>>>>>> David Doukhan >>>>>>> <id_rsa.pub>_______________________________________________ >>>>>>> Pd-dev mailing list >>>>>>> Pd-dev(a)iem.at >>>>>>> http://lists.puredata.info/listinfo/pd-dev >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------------- >>>>>> >>>>>> If nature has made any one thing less susceptible than all >>>>>> others of >>>>>> exclusive property, it is the action of the thinking power >>>>>> called an >>>>>> idea, >>>>>> which an individual may exclusively possess as long as he keeps >>>>>> it to >>>>>> himself; but the moment it is divulged, it forces itself into the >>>>>> possession >>>>>> of everyone, and the receiver cannot dispossess himself of it. >>>>>> - >>>>>> Thomas Jefferson >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> David Doukhan >>>> >>>> >>>> >>>> ---------------------------------------------------------------------------- >>>> >>>> If nature has made any one thing less susceptible than all others >>>> of >>>> exclusive property, it is the action of the thinking power called >>>> an idea, >>>> which an individual may exclusively possess as long as he keeps >>>> it to >>>> himself; but the moment it is divulged, it forces itself into the >>>> possession >>>> of everyone, and the receiver cannot dispossess himself of >>>> it. - >>>> Thomas Jefferson >>>> >>>> >>>> >>> >>> >>> >>> -- >>> David Doukhan >>> >> >> >> >> -- >> David Doukhan >> > > > > -- > David Doukhan ---------------------------------------------------------------------------- ¡El pueblo unido jamás será vencido!

1 0

access to pd compile farm
by David Doukhan 09 Feb '11

09 Feb '11

hi, Could someone add me to the compile farm? my public key is attached to the mail. see ya! -- David Doukhan

2 1

difference between t_canvas and t_pd
by Rich E 08 Feb '11

08 Feb '11

I can't remember, are questions related to pd's C API appropriate for pd-list, or are they better asked here? It seems that everyone who responds to those questions is on this list just as much, anyway. I have been mucking around with opening and closing pd patches using API calls instead of pd's messaging system. The reason for this is that I would like to be able to manage (open/close) multiple instances of a patch, and be able to send each copy of the patch a unique message via its $0 argument (see http://www.mail-archive.com/pd-list@iem.at/msg41648.html). So far, the method has been to hack glob_evalfile to look like: t_canvas *glob_evalfile(t_pd *ignore, t_symbol *name, t_symbol *dir) { t_pd *x = 0; /* even though binbuf_evalfile appears to take care of dspstate, we have to do it again here, because canvas_startdsp() assumes that all toplevel canvases are visible. LATER check if this is still necessary -- probably not. */ t_canvas *x_canvas = 0; int dspstate = canvas_suspend_dsp(); binbuf_evalfile(name, dir); while ((x != s__X.s_thing) && (x = s__X.s_thing)) { x_canvas = canvas_getcurrent(); vmess(x, gensym("pop"), "i", 1); } pd_doloadbang(); canvas_resume_dsp(dspstate); return x_canvas; } The only addition is that x_canvas is retrieved before x is 'popped' off of pd's global stack, and is then returned, giving me a handle to close that particular patch with something like: canvas_menuclose(x_canvas, 0); But I realize that in global_evalfile, t_pd and x_canvas point to the same address space. This leads me to ask, what is the difference between these two pointers? Is t_canvas a t_pd along with variables for its graphical nature? Mathieu also pointed to me (as I was using the first set of these) that canvas_setcurrent() and canvas_unsetcurrent() are aliases of pd_pushsym() and pd_popsym(). Is there a good reason to use one over the other? Last question: Does anyone see a way that I could get the value of x in glob_evalfile above without changing the function? I don't think it is a dangerous change (and it looks like I could just hand x.gl_pd to canvas_menuclose, thereby not really needing a t_canvas pointer), but I would of course prefer to not change the API if possible. Cheers, Rich

2 6

[ pure-data-Patches-3109768 ] [bugfix] gop patch name uneditable after disabling gop
by SourceForge.net 08 Feb '11

08 Feb '11

Patches item #3109768, was opened at 2010-11-15 22:10 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3109768&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: Ivica Ico Bukvic (ico_bukvic) Assigned to: Miller Puckette (millerpuckette) Summary: [bugfix] gop patch name uneditable after disabling gop Initial Comment: Last lingering GOP bug (after all previous GOP bugfixes that I submitted have been applied). Namely, when: 1) open a new patch and create [pd something] 2) right-click on object's properties, enable both GOP and "hide text" options and click on OK/Apply 3) the object will revert to its original object-like appearance and will be open-able but its name (text) will not be editable 4) right-clicking on its properties shows that both "hide text" and GOP are still enabled This is because disabling GOP function does not reset hidetext variable. Following patch fixes this. ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-02-08 12:15 Message: i attached a simple fix for the problem that deals with it in the tcl domain. this applies (only) to 0.43. file: 0001-disabling-GOP-should-also-disable-hidetext.patch created for 0.43.0test4 this obsoletes ico's "gop_patch_20101115" (which i leave here for reference) ---------------------------------------------------------------------- Comment By: Ivica Ico Bukvic (ico_bukvic) Date: 2010-11-15 22:11 Message: Forgot to mention, this applies to 0.42.5 branch of both pd and pd-extended. It has not been tested against 0.43. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3109768&group_…

1 0

[ pure-data-Patches-3081084 ] [0.43] Compose key (Multi_key) and Dead Keys don't work
by SourceForge.net 08 Feb '11

08 Feb '11

Patches item #3081084, was opened at 2010-10-04 21:17 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3081084&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: [0.43] Compose key (Multi_key) and Dead Keys don't work Initial Comment: Starting with 0.43 I can't use any accented letters anymore because the Compose key (Multi_key) and the Dead Keys are not supported anymore. However, single-keystroke accented letters do work. The new problem is strictly with multi-keystroke letters (not counting shift and altgr). With Pd 42 those keys work correctly, on the condition that you have either a 8-bit charset and/or -lib gridflow. ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-02-08 12:01 Message: dead keys here work fine (if i enable them, which i usually don't) linux/debian, 0.43.0test4 ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-11-21 22:30 Message: I forgot to add, I can type a wide number of unicode characters using 0.43 on Mac OS X 10.5.8 and Tcl/Tk 8.5.8. I am using a US keyboard and the Alt/Option key to type them. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-11-21 22:28 Message: Can you give us more info, like which OS you are using and which keyboard? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3081084&group_…

1 0

[ pure-data-Patches-3106837 ] [bugfix] paste/undo/redo sometimes leaves patchcords below
by SourceForge.net 08 Feb '11

08 Feb '11

Patches item #3106837, was opened at 2010-11-10 20:47 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3106837&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: pd-extended Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ivica Ico Bukvic (ico_bukvic) >Assigned to: Hans-Christoph Steiner (eighthave) Summary: [bugfix] paste/undo/redo sometimes leaves patchcords below Initial Comment: Affects only pd-extended 0.42.5 (may also affect 0.43--has not been tested). ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-02-08 11:24 Message: the problem only applies to Pd-extended (hence i re-assign it to hans), as with pd-vanilla, all msg- and obj-boxes are transparent (non-filled), thus there is no real problem with the layer-depth of cords vs objects. furthermore, i actually fail to see the problem anyhow: why do you think it is a bug if the cord is drawn on top of the object? isn't this what you usually get anyhow? ---------------------------------------------------------------------- Comment By: Ivica Ico Bukvic (ico_bukvic) Date: 2010-11-12 17:50 Message: Small update to the patch to remove redundant redrawing when duplicating objects. ---------------------------------------------------------------------- Comment By: Ivica Ico Bukvic (ico_bukvic) Date: 2010-11-10 20:49 Message: Ugh... How does one edit the Details once the file has been uploaded? At any rate, it is all explained in the test pd patch so please consult the attached patchcord_test.pd ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3106837&group_…

1 0

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 February 2011