Pd-dev September 2012

pd-dev@lists.iem.at

4 participants
30 discussions

coll object in cyclone broken in 0.43; how to submit fix?
by Miller Puckette 04 Sep '12

04 Sep '12

To Pd developers... In testing the coll object from cyclone/hammer I found some trouble adapting from 0.42 to 0.43. I had no trouble fixing it locally (I'll show a diff below) but would like now to know how I can best make this available to others. Would it be netter that I (a) submit a patch to the tracker (that would work if Hans would then want to apply it to SVN) or should I risk trying to commit to SVN myself (with the risk that I migth do something stupid and mess up the repo)? here's the change, although to patch it upstream I'd want to make the code check the Pd version in runtime so that it will still work for Pd <= 0.42 ) diff externals/miXed/shared/hammer/file.c ~/work/text/coll/ < sys_gui(" pd [concat miXed$name clear \\;]\n"); --- > sys_gui(" pdsend [concat miXed$name clear \\;]\n"); 123c123 < sys_gui(" pd [concat miXed$name addline $lin \\;]\n"); --- > sys_gui(" pdsend [concat miXed$name addline $lin \\;]\n"); 126c126 < sys_gui(" pd [concat miXed$name end \\;]\n"); --- > sys_gui(" pdsend [concat miXed$name end \\;]\n"); 271,272c271,272 < sys_gui(" pd [concat $target path \\\n"); < sys_gui(" [pdtk_enquote $filename] [pdtk_enquote $directory] \\;]\n"); --- > sys_gui(" pdsend [concat $target path \\\n"); > sys_gui(" [enquote_path $filename] [enquote_path $directory] \\;]\n"); 287,288c287,288 < sys_gui(" pd [concat $target path \\\n"); < sys_gui(" [pdtk_enquote $filename] [pdtk_enquote $directory] \\;]\n"); --- > sys_gui(" pdsend [concat $target path \\\n"); > sys_gui(" [enquote_path $filename] [enquote_path $directory] \\;]\n"); thanks Miller

2 2

[ pure-data-Patches-3564457 ] filagra soft 100
by SourceForge.net 03 Sep '12

03 Sep '12

Patches item #3564457, was opened at 2012-09-03 09:28 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3564457&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: documentation Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: filagra soft 100 Initial Comment: filagra soft 100 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3564457&group_…

1 0

[ pure-data-Patches-3485016 ] (Win) allow externals to load DLLs from the same folder
by SourceForge.net 02 Sep '12

02 Sep '12

Patches item #3485016, was opened at 2012-02-06 08:38 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3485016&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: feature >Status: Closed Resolution: Accepted Priority: 7 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: (Win) allow externals to load DLLs from the same folder Initial Comment: In order to have objects like readanysf~ and purest_json work on Windows, they need to include DLLs for libraries like ffmpeg and curl. In order for the DLLs of the objects to load other DLLs from that same folder, SetDllDirectory() needs to be set first. This requires a minimum of Windows XP SP1 (10 years old at this point). There are three patches included, the first sets up the new build system for this, the second sets up makefile.mingw for this. The third is the actual change to s_loader.c. I think MSVC sets WINVER automatically, but just be sure its set to 0x0502 for this to work. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-09-02 12:43 Message: You can always find these patches in the Pd-extended 'patch_series' branch if they seem corrupted. As for git, if you have messed up commits, you can always easily reset your branch back to ignore those messed up commits. Just use 'git branch' to set the branch to a given branch hash: git branch master 731b8721d28bc4ed0c0b533b981b7d3dd1f1df6e ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-08-31 17:21 Message: I think this is now patched (but quite messily so there might be mistakes). Some of it was already part of commit 5dadaf43c9206823b434d11c6cc6c6e6be020dc3 ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-08-31 17:05 Message: I applied this messily - it seems a lot of the edits had already been applied - probably broke stuff but am not sure how to unwind this safely. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-02-19 18:19 Message: drat, the "zip" file attached looks like empty HTML glueball. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3485016&group_…

1 0

[ pure-data-Patches-3521816 ] Setting externals file extension, check for ANDROID platform
by SourceForge.net 01 Sep '12

01 Sep '12

Patches item #3521816, was opened at 2012-04-26 19:25 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&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: Pending >Resolution: Accepted Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Setting externals file extension, check for ANDROID platform Initial Comment: The Android GCC toolchain #defines linux, so the Android specific branch was never being hit. Moving the check above Linux fixes it. Before this patch external extensions ".l_i386" and ".pd_linux" are checked for on Android. This patch will accept either ".l_arm" or ".pd_linux", so the externals built by PdCore will still work. It doesn't address the issue of Android x86. Should probably add a check for arm vs x86 architecture too, but I haven't been able to find documentation of the architecture macros. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-08-31 17:31 Message: accepted (0.44) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-04-30 11:42 Message: I attached a patch for my solution to the problem at hand: Android file extensions. It will also fix file extensions for GNU/Linux on ARM. The original code would make GNU/Linux/ARM use .l_i386. This also adds '.so' as the default extension when the particular case is undefined. I think this is better than having the default be nothing at all, and it should be quite safe since .so is the standard extension for shared libraries on GNU systems, BSD systems, Android, and others. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-04-30 07:36 Message: How about we instead solve the problem listed above in this bug report? I think we should have the add an #else that sets the file extension to ".so". The generic .dll extension has been used for Windows since forever and I don't hear about problems there. And then ditch the __ANDROID__ section and move the ARM arch under the __linux__ section. The file extensions are a mess in terms of accurate naming. __GNU__ and __FreeBSD_kernel__ are not Linux at all, and they are set to use .pd_linux. I don't think the kernel even matters for generic externals, it is probably the libc that matters, so it should be something like .gnu_i386 or .bsd_i386. Or maybe its the binary format that's more important, i.e. .elf_i386 and .mach_i386. Makes me think this approach to naming is just fundamentally flawed. Lastly, IOhannes, the key part that you are missing about .d_fat/.d_ppc is that they do not solve any problems. So something that causes a minor problem, but solves nothing seems pretty worthless to me. Even discussing it as much as we have seems like a waste of time. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-04-30 00:28 Message: for the record, here are the relevant threads i found in the archives: - http://lists.puredata.info/pipermail/pd-list/2009-01/067498.html - http://lists.puredata.info/pipermail/pd-list/2009-07/071476.html as you will see, the only real issue that was ever raised was the increased load-time when adding more and more extensions. all the "other" issues where always referred to as "there are other issues which i don't remember right now, check the archive", without ever giving evidence that there are indeed other issues. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-04-29 20:14 Message: File extensions are very OS-specific. The Linux extensions are fine (except perhaps the l_ia64 being the wrong arch). Mac OS X does not need different ones since you can build universal "fat" binaries. One example of a problem caused by adding more extensions is that it increases the load time since Pd will have to check for more variations on filenames. There are other issues, I don't remember them, but they're in the archives. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-04-29 11:03 Message: My intention in having the wierd extensions was to permit people to distribute patches (such as realizations of pieces) containing in-house externals that can run under any Pd version and any OS. In this context "externs" can be directories containing the various binaries which Pd distinguishes by filename. OTOH, Pd distributions themselves run on a single OS and architecture so don't need the disambiguation, although in my experience it hasn't been harmful (Hans has experienced otherwise in the context of Pd extended though :) So Pd is sort of stuck allowing both types of extensions. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-04-29 10:36 Message: Personally, I think its a waste your time and mine. Its been discussed, check out the archives for the problems it causes. I've long since moved on. We should be putting this energy solving the issue in this tracker, rather than beating the .d_ppc/.d_fat dead horse. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-04-28 10:16 Message: thanks for the respone. ad #1: very few people using .d_ppc/.d_fat is not really creating any "problems", is it? ad #2: will do (though afaict, PdX has a patch that actively removes the functionality; should i create a patch that re-adds the extensions or should i modify (eventually remove) the patch that erroneously removes the extensions? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-04-27 19:32 Message: In response to #1: very few people are using .d_ppc and .d_fat files with Pd vanilla. and #2: patches welcome ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-04-27 08:54 Message: <flames> "Those file extension have a lot of issues as they are, for example, no other program for Darwin/MacOSX uses per-arch file extension"...what exactly is the "lot of issues" here? no other program for Darwin/MacOSX is called "Pd", and still this is no issue. </flames> <moreflames> if Pd-extended ignores binary files that it could happily load and by doing so breaks compatibility with Pd-vanilla, i would say this is a bug in Pd-extended. </moreflames> ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-04-27 07:36 Message: What about just defining '.so' has a possibility if __linux__, __FreeBSD__, __FreeBSD_kernel__, __OpenBSD__ are defined, then people can choose to manage the architecture in their own way. Those file extension have a lot of issues as they are, for example, no other program for Darwin/MacOSX uses per-arch file extensions: they use universal binaries. For this reason , Pd-extended on Mac OS X only uses .pd_darwin and universal binaries and ignores .d_fat and .d_ppc. Also, Pd's .l_ia64 does not actually mean ia64 arch but instead amd64/x86_64, so that file extension is just wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…

1 0

[ pure-data-Patches-3485016 ] (Win) allow externals to load DLLs from the same folder
by SourceForge.net 01 Sep '12

01 Sep '12

Patches item #3485016, was opened at 2012-02-06 08:38 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3485016&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: feature >Status: Pending >Resolution: Accepted Priority: 7 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: (Win) allow externals to load DLLs from the same folder Initial Comment: In order to have objects like readanysf~ and purest_json work on Windows, they need to include DLLs for libraries like ffmpeg and curl. In order for the DLLs of the objects to load other DLLs from that same folder, SetDllDirectory() needs to be set first. This requires a minimum of Windows XP SP1 (10 years old at this point). There are three patches included, the first sets up the new build system for this, the second sets up makefile.mingw for this. The third is the actual change to s_loader.c. I think MSVC sets WINVER automatically, but just be sure its set to 0x0502 for this to work. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-08-31 17:21 Message: I think this is now patched (but quite messily so there might be mistakes). Some of it was already part of commit 5dadaf43c9206823b434d11c6cc6c6e6be020dc3 ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-08-31 17:05 Message: I applied this messily - it seems a lot of the edits had already been applied - probably broke stuff but am not sure how to unwind this safely. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-02-19 18:19 Message: drat, the "zip" file attached looks like empty HTML glueball. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3485016&group_…

1 0

[ pure-data-Patches-3518188 ] support loading [classname] from classname/classname.pd
by SourceForge.net 01 Sep '12

01 Sep '12

Patches item #3518188, was opened at 2012-04-15 08:23 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3518188&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: feature >Status: Pending >Resolution: Accepted Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: support loading [classname] from classname/classname.pd Initial Comment: This patch adds support for loading [classname] from classname/classname.pd to match classname/classname.pd_linux support, which has been around a long time and proven quite useful. The patch adds classname/classname.pd as the last thing to try in the whole loading sequence, so it should not break anything, unless it is relying on the failure of an object to create. One example this patch supports is the [arduino] object, which is implemented as an abstraction. With this patch, everything can be included in a folder called "arduino/" from the help patch, the meta file, and the abstraction itself. This makes installation trivial, just drop the arduino folder in the right place, and also makes the arduino folder show up in the Help Browser. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-08-31 17:18 Message: accepted 0.44 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3518188&group_…

1 0

[ pure-data-Patches-3494768 ] verbose() leaves blank lines when filtered out in Pd window
by SourceForge.net 01 Sep '12

01 Sep '12

Patches item #3494768, was opened at 2012-02-26 08:10 Message generated for change (Settings changed) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3494768&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: Pending Resolution: Accepted Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: verbose() leaves blank lines when filtered out in Pd window Initial Comment: When lines are posted to the Pd window using verbose() and then the Pd window is set to display at a lower level than the verbose() posted at, the lines that were posted using verbose() will be filtered, but will leave a blank line in their place. lines posted with logpost() do not do this. For example, if I post three lines using verbose() like this: verbose(3, "three"); verbose(4, "four"); verbose(3, "three"); Setting the log level to four will show: three four three Setting the log level to 3 will show: three three When it should show: three three I'm assigning this to IOhannes because I think he wrote the current verbose() function. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-08-31 17:10 Message: applied (0.44) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-02-27 06:32 Message: That was quick. The solution makes sense to me. But I think its a bad idea to change to loglevel+4 to loglevel+3. Either leave verbose()'s custom level numbering the same, or make it the same as the Pd window, error(), logpost(), etc.. I still really think the +4 on the loglevel doesn't make sense. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-02-27 04:57 Message: attached is a fix for the problem (thus changing Tracker to 'Patches' and assigning to miller) it also closes the gap between verbose() and post() by applying a loglevel-offset of '3' rather than '4' (so now verbose(0) (loglevel=3) is following post() (loglevel=2) immediately. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-02-27 04:52 Message: the problem comes from the use of endpost() to terminate the message. endpost() doesn't know anything about log-levels, so it tags all LFs as "normal". i can think of 2 ways to fix this: - don't use endpost() to terminate a message, but instead append the "\n" to the message itself (which get's tagged with the log-level) - make endpost() aware of the last used loglevel and terminate any message using this level i'd rather go for the 1st solution, as it doesn't require any global state... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3494768&group_…

1 0

[ pure-data-Patches-3497084 ] fix for open_via_path() declaration headfizz
by SourceForge.net 01 Sep '12

01 Sep '12

Patches item #3497084, was opened at 2012-03-05 09:41 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3497084&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-dev Group: None >Status: Pending >Resolution: Accepted Priority: 7 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: fix for open_via_path() declaration headfizz Initial Comment: m_pd.h says that the parameters for open_via_path() are: "open_via_path(name, ext, dir, ...)" otoh, s_path.c implements the function as "open_via_path(dir, name, ext,...)" also the function is used as (dir, name, ext,...) throughout the code. the attached cosmetic patch fixes the function declaration in m_pd.h, so i don't get headfizz whenever i try to find out why i'm using the function correctly. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-08-31 17:12 Message: done (by hand, not sure when) ---------------------------------------------------------------------- Comment By: Mathieu BOUCHARD (mathieubouchard) Date: 2012-03-06 07:34 Message: Just imagine that the ministry of transportation puts the wrong signs on the autobahn. When it's time to fix them, they call the change «cosmetic». So, of course, they ask a beautician to take care of it. Do any changes to the docs also count as «cosmetic» ? Because help-intro.pd always listed classes that never existed, such as [powtorms~] and [rmstopow~]. I suppose that it's cosmetic too ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3497084&group_…

1 0

[ pure-data-Patches-3494768 ] verbose() leaves blank lines when filtered out in Pd window
by SourceForge.net 01 Sep '12

01 Sep '12

Patches item #3494768, was opened at 2012-02-26 08:10 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3494768&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: Accepted Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: verbose() leaves blank lines when filtered out in Pd window Initial Comment: When lines are posted to the Pd window using verbose() and then the Pd window is set to display at a lower level than the verbose() posted at, the lines that were posted using verbose() will be filtered, but will leave a blank line in their place. lines posted with logpost() do not do this. For example, if I post three lines using verbose() like this: verbose(3, "three"); verbose(4, "four"); verbose(3, "three"); Setting the log level to four will show: three four three Setting the log level to 3 will show: three three When it should show: three three I'm assigning this to IOhannes because I think he wrote the current verbose() function. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-08-31 17:10 Message: applied (0.44) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-02-27 06:32 Message: That was quick. The solution makes sense to me. But I think its a bad idea to change to loglevel+4 to loglevel+3. Either leave verbose()'s custom level numbering the same, or make it the same as the Pd window, error(), logpost(), etc.. I still really think the +4 on the loglevel doesn't make sense. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-02-27 04:57 Message: attached is a fix for the problem (thus changing Tracker to 'Patches' and assigning to miller) it also closes the gap between verbose() and post() by applying a loglevel-offset of '3' rather than '4' (so now verbose(0) (loglevel=3) is following post() (loglevel=2) immediately. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-02-27 04:52 Message: the problem comes from the use of endpost() to terminate the message. endpost() doesn't know anything about log-levels, so it tags all LFs as "normal". i can think of 2 ways to fix this: - don't use endpost() to terminate a message, but instead append the "\n" to the message itself (which get's tagged with the log-level) - make endpost() aware of the last used loglevel and terminate any message using this level i'd rather go for the 1st solution, as it doesn't require any global state... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3494768&group_…

1 0

[ pure-data-Patches-3485016 ] (Win) allow externals to load DLLs from the same folder
by SourceForge.net 01 Sep '12

01 Sep '12

Patches item #3485016, was opened at 2012-02-06 08:38 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3485016&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: feature Status: Open Resolution: None Priority: 7 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: (Win) allow externals to load DLLs from the same folder Initial Comment: In order to have objects like readanysf~ and purest_json work on Windows, they need to include DLLs for libraries like ffmpeg and curl. In order for the DLLs of the objects to load other DLLs from that same folder, SetDllDirectory() needs to be set first. This requires a minimum of Windows XP SP1 (10 years old at this point). There are three patches included, the first sets up the new build system for this, the second sets up makefile.mingw for this. The third is the actual change to s_loader.c. I think MSVC sets WINVER automatically, but just be sure its set to 0x0502 for this to work. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-08-31 17:05 Message: I applied this messily - it seems a lot of the edits had already been applied - probably broke stuff but am not sure how to unwind this safely. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-02-19 18:19 Message: drat, the "zip" file attached looks like empty HTML glueball. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3485016&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 September 2012