Pd-dev August 2006

pd-dev@lists.iem.at

22 participants
100 discussions

easy way to download the whole shebang
by Hans-Christoph Steiner 13 Aug '06

13 Aug '06

I just thought of a side benefit of the auto-build system. You can now easily download a snapshot of the complete source for MAIN, pd- devel, and pd-extended: rsync -av rsync://128.238.56.50/distros/pd-devel/ pd-devel/ rsync -av rsync://128.238.56.50/distros/pd-extended/ pd-extended/ rsync -av rsync://128.238.56.50/distros/pd-main/ pd-main/ This is not so important on MAIN, but with devel and extended, it simplifies things because you don't have to use tricky cvs commands. .hc ------------------------------------------------------------------------ Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra

6 11

Change to t_class broke class browser?
by Mathieu Bouchard 13 Aug '06

13 Aug '06

Someone changed t_class so that the name of the library would be included in the name of the class. This breaks the class browser (of DesireData) as well as the completions. For example, if I type Ctrl+1 "bord" Tab, i get [gridflow/#border], and if I press Return, I get "can't create" because the only valid name for that object class is [#border]. What's going on? _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

2 2

compile farm emails
by Hans-Christoph Steiner 12 Aug '06

12 Aug '06

I have the error emails working for the compile farm. It only sends an email if the build fails. I was thinking that these emails should go to this list. That way people can know whether their changes have caused any problems on other platforms. How does that sound? .hc ------------------------------------------------------------------------ The arc of history bends towards justice. - Dr. Martin Luther King, Jr.

3 3

Re: [GEM-dev] Feature request: removing or renaming [counter]
by Hans-Christoph Steiner 12 Aug '06

12 Aug '06

I'll second that. I think I remember that IOhannes removed MarkEx from the current builds... .hc On Aug 12, 2006, at 4:03 AM, Frank Barknecht wrote: > Hi, > > while importing Max patches with cyclone I recently was again hit by > the "counter" nameclash: I actually wanted cyclone's counter, but what > I did get was the MarkEx counter, which I had totally forgotten about > and of course, because of this Gem was the last library I disabled > from .pdrc to find out where the wrong counter originated. > > So I have a feature request: I would suggest to remove [counter] > from the default Gem build. > > It is not specific to Gem at all, not used in any help files, not > compatible with the Max [counter] and there already are at least 4 > other [counter] objects. > > Ciao > -- > Frank Barknecht _ ______footils.org_ __goto10.org__ > > _______________________________________________ > GEM-dev mailing list > GEM-dev(a)iem.at > http://lists.puredata.info/listinfo/gem-dev ------------------------------------------------------------------------ There is no way to peace, peace is the way. -A.J. Muste

1 0

List archives down?
by Jamie Bullock 11 Aug '06

11 Aug '06

Hi, Is anyone aware that the list archives are down? I can't access the archives, so I can't check if anyone has already mentioned this ;-) Jamie

1 0

VASP vs plugin~ weirdness
by Michal Seta 10 Aug '06

10 Aug '06

Hi all, there is some weirdness happening when VASP is being loaded as -lib (ok, perhaps I shouldn't do such things) and [plugin~] is being used. The combination results in a segfault. I had exactly the same issue with [pool] a while back (and it was in fact pointed out to me that I should report this to the list but it slipped my brain). ./MiS

2 2

Re: [PD] building HID from the CVS, errors
by IOhannes m zmoelnig 10 Aug '06

10 Aug '06

David Merrill wrote: > Hello all, hi. i am redirecting this to pd-dev, since i hope this mail will lead to some further dev-specific discussion and hopefully to some usable build system. > > Has anyone else had a problem trying to compile an external from the CVS > source? I just checked out the externals dir from CVS, and wanted to > compile the latest [hid], so after reading the README in the hid > directory, I typed: > > >make INCLUDE=/usr/lib/pd/src PDEXECUTABLE=/usr/bin/pd > > ..and got the following: > > --paste-- [...] > --end paste-- > > Why would the build want a /sigpack, and /zexy directory? And am I > missing a Makefile.buildlayout file? to compile hid (and i guess, any of hans's externals) you need the entire pd-cvs (at the very least you need the "packages" module) downloaded from sourceforge. i agree that this is _very annoying_ at the least. my solution to compile something as simple as [folder_list] was to NOT use hcs's build system at all (i really just wanted to have to download not more than 1MB to get this single object), but instead compile the object with: > gcc -g -O2 -I. -DPD -fPIC -export_dynamic -shared -o folder_list.o -c folder_list.c > gcc -export_dynamic -shared -o folder_list.pd_linux folder_list.o -lm -lc you might try something similar with hid, although things are a bit more complicated here. that's basically the answer to your question, the rest is what i draw as a conclusion: SO: i see the need for a "grand unified build system" for things like pd-extended. but i am not totally sure, whether everything should be sacrificed to pd-extended. naturally, hans has the right to do anything with his code, including forcing anyone trying to build the sources from his part of the repository with any build system he likes. nevertheless, i would recommend a system that would make the best of the two worlds: be able to take advantage of the general pd-extended build system and (at the users option) be able to not have to use the pd-extended build system (probably at the cost of having to do some manual configuration if the maintainer doesn't want to maintain to configuration systems) the simplest solution that comes to my mind is, that one of the 2 systems uses a differently named makefile. since pd-extended's build-system is more likely to be called from a parent makefile (because somebody wants to build the entire pd-extended build-system), i suggest to name this Makefile.extended (or Makefile.buildsystem) anybody wishing to build using the extended build system, would call "make -f Makefile.extended". other users would just do a "make". a more sophisticated method would use a Makefile.extended and a Makefile.simple. the ordinary "Makefile" would first check for the existence of the extended build-system and if present, it would use Makefile.extended, else it would use Makefile.simple. if test -e ../../packages/Makefile.buildlayout then # cool, we can use the extended build system make -f Makefile.extended else # simple fallback make -f Makefile.simple fi what do you think? mfg.adsr IOhannes

6 11

:pserver:gridflow ??
by IOhannes m zmoelnig 09 Aug '06

09 Aug '06

hi all, esp. matju i just noticed, that in the root of the pure-data CVS we have a very nice directory, called ":pserver:anonymous@cvs.gridflow.ca:"; in it there is some gridflow code. since GridFlow is also available in externals/gridflow, is it ok, if i file a request to remove this entire directory from the pure-data repostiroy? or is it mission critical to have it there? mfg.adsr IOhannes

1 0

[ pure-data-Bugs-1536488 ] [vu] Object corrupted at sizes 80-119
by SourceForge.net 08 Aug '06

08 Aug '06

Bugs item #1536488, was opened at 2006-08-08 01:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1536488&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: v0.39.2 Status: Open Resolution: None Priority: 5 Submitted By: Luke Iannini (lukeiannini) Assigned to: Nobody/Anonymous (nobody) Summary: [vu] Object corrupted at sizes 80-119 Initial Comment: The [vu] object shows a single line of its usual full-scale display at any size below 120 (which all seem to go directly to 80 - there are no intermediate values; this is also odd behavior). I've checked this on Miller's 39.2 and Han's extended-39.2-test4 and -38.4. I don't have any other OS's to test this on, so perhaps someone could check this out in Windows and Linux (I am on OS X 10.4.7 2x2G5 and MBP). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1536488&group_…

1 0

Re: Packaging system (WAS Re: [PD] Pd standalone instruments ... )
by hans＠eds.org 08 Aug '06

08 Aug '06

I think this could be a good idea, but it will be quite a bit of work. As long as we share a single build system, I think it will work. The current one is already pretty modular, but it could use more work, like a proper ./configure setup. I am currently in the process of helping Nando @ CCRMA to base his PlanetCCRMA Pd packages off of the extended build system, and its mostly working quite well. But the process is highlighting some areas that need work. .hc On Aug 7, 2006, at 7:02 PM, Alexandre Quessy wrote: > By the way, the PEAR packaging system is very good for handling > versions and dependencies of several files. It works on several OS > (mac/win/*nix) and there is a GUI to make the packages. > > I tought about using that for creating PD packages (externals and > abstractions), but then, we thought that PEAR needs PHP, which is not > installed by default on Win32 nor on most Linux distros. We could > write our own packaing system. It must be about 1000 lines of code. It > could be in Python. I think that would help a lot the community to get > organized. I"d be volunteer to work (in a team) on it if I was sure > the community (and Miller) would accept it. > > Also, I know there exist such package managers that could be used for > that. Maybe not APT : there are some that are more portable. Marc > Lavallée told about about one one day, but I forgot which. > > This thread should be switched to the pd-dev list now... > > aalex > > > > On 8/7/06, Alexandre Quessy <listes(a)sourcelibre.com> wrote: >> On 7/31/06, matthew jones <mj(a)isvr.soton.ac.uk> wrote: >> > > A double-clickable jar-style format would be good to do so >> that you can >> > > include more than one file. >> > >> > I second that! Distribution of patches which include other >> patches, >> > specific abstractions and externals would be peasy and clean >> with some kind >> > of packaged format like that. Then even if these abstractions >> etc were >> > already installed on the user's machine the patch would look for >> anything >> > required within this packaged file first... no longer any >> [scale] confusions >> > or namespace issues! Oh, but then externals are platform >> dependent, so.... >> > hmm patches become dependent too. Right... maybe not the >> optimal solution >> > then? >> >> >> Very good idea !! >> It could be a ZIP file with a XML file, patches and objects in it. >> The >> XML file describes the role of each file in the bundles. Therefore, >> one could wrap externals for, let say, Windose, Mack and Linux, and >> write the ".pdrc" in the xml file. If the externals are missing for >> the current OS, well, it doesn't work and that's it ! An example of >> such a XML file in a TAR.GZ package is the package system of PEAR, >> the >> PHP classes repository. See >> http://www.php-editors.com/pear_manual/developers.packagedef.html >> >> Maybe that's overkill though, but it would kind of compete with >> Max's VSTs. :-P >> >> Cheers, >> >> a >> >> >> >> >> >> > >> > Matt >> > >> > -=-=-=-=-=-=-=-=-=-=-=- >> > http://www.loopit.org >> > -=-=-=-=-=-=-=-=-=-=-=- >> > >> > >> > >> > >> > _______________________________________________ >> > PD-list(a)iem.at mailing list >> > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ >> listinfo/pd-list >> > >> >> >> -- >> Alexandre Quessy >> http://alexandre.quessy.net >> > > > -- > Alexandre Quessy > http://alexandre.quessy.net ------------------------------------------------------------------------ ¡El pueblo unido jamás será vencido!

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 August 2006