Pd-dev May 2003

pd-dev@lists.iem.at

24 participants
34 discussions

CVSROOT commits send email
by Hans-Christoph Steiner 18 May '03

18 May '03

I set up the SourceForge CVS to send an email to pd-dev if any commits are made to any of the files in CVSROOT. Since these are admin files that effect everything in the CVS, and they are rarely changed, I thought it would be prudent to have everyone notified of changes there. Now if we decide on a pd-commits list somewhere, we can have all commits send an email with a diff to that list. .hc

1 0

ACLs are in and ready to go
by Hans-Christoph Steiner 17 May '03

17 May '03

So after a little suspense of installing a feature that has the power to lock everyone out of the CVS, I am happy to say that cvs_acls is now configured and working with a minimal set of ACLs (one really, just to test it out). Right now, cvs_acls defaults to 'avail', meaning default write access for everything. Then we can lock down individual directories as requested. I made an access list that restricts 'gem' to the GEM devs to test this out (this directory is defunct anyway, no?). So if you aren't cclepper, dheck, ggeiger, tigital, or zmoelnig then you should see "**** Access denied: Insufficient Karma (eighthave|gem)" Here's an example session: hans@sla:/<1>gem>cat > test testing commitimg to gem. should be blocked hans@sla:/<1>gem>cvs add test cvs server: scheduling file `test' for addition cvs server: use 'cvs commit' to add this file permanently hans@sla:/<1>gem>cvs ci -m "testing ACLs" test **** Access denied: Insufficient Karma (eighthave|gem) cvs server: Pre-commit check failed cvs [server aborted]: correct above errors first! The next thing to do once we get used to the idea is to restrict access to the ACL file to only the sourceforge admins, so people can't go in and add themselves to the ACLs. I just wanted to make sure its working fine before attempting something that has a decent likelyhood of locking us out permanently if the right mistakes were made. (It would require a SourceForge support request to fix it if we did get locked out). So send your ACL requests to me, and I'll start putting them in. .hc

1 0

CVS commit mailing list
by Hans-Christoph Steiner 17 May '03

17 May '03

I am starting to set up cvs_acls now and I thought about setting up syncmail as well, which sends all commits to a mailing list. I could just go ahead and set up a list for this on the SourceForge site, or we could have it on iem.at. My only concern is that the pd-dev list currently isn't being archived so perhaps this one wouldn't be either, and it would be helpful to have these lists archived. Which brings us to another issue: there seems to have been some rumblings about moving the pure-data CVS to IEM because of SourceForge issues in Europe. This seems to make sense if we have the site and the lists hosted there, and IEM is willing to support it. .hc

1 0

usages of 't_gotfn'
by Michael McGonagle 17 May '03

17 May '03

Hello all, I have a single function (lyapunov) that I need to be able to use across several different externals, each with a different object struct. I am not really sure if this is the correct way to implement this, but my function (lyapunov) needs to be able to call a function within the externals. So, in doing this, I have created the following prototype for my function: double lyapunov(void *frac, t_gotfn calc, int v_cnt, double *vars); 'frac' is a pointer to the external object that is calling 'lyapunov', this will be passed to the 'calc' callback. Basically, code for this looks like: calc(frac); Pretty basic. I originally was trying to use 't_method' for the type of 'calc', but the compiler kept complaining that the number of arguments passed to the callback was incorrect. So, now with the type of 't_gotfn', everything compiles and appears to run as expected. So, my question: Is there a more appropriate way of doing this? Also, is there a potential problem with portability of this technique? I am on Mac OS X, but these externals need to run "EVERYWHERE"! Thanks, Mike

1 0

A Mac OS X makefile (or something a little better)
by Michael McGonagle 16 May '03

16 May '03

Hello everyone, It seems that there still isn't an "accepted" method for makefiles to use on Mac OS X for externals. I was looking at Miller's makefiles from the externals in .37, it is as follows (extracted from the Mac OS X portion): .c.pd_darwin: cc $(DARWINCFLAGS) $(LINUXINCLUDE) -o $*.o -c $*.c cc -bundle -undefined suppress -flat_namespace -o $*.pd_darwin $*.o rm -f $*.o Other external makefiles (for Mac OS X) change the last line, and add one more: rm -f $*.o ../$*.pd_darwin ln -s $*/$*.pd_darwin .. This last line, from what I can tell, seems to assume that all external source files will be stored under the "extra" folder, or at least in a folder "relative" to where the source is stored and where the external binary is stored (or linked). It also assumes that the external is stored in a folder by the same name as the external, itself. (This is not a big deal, just another "hidden" dependancy). This is not done on other Unix Platform makefile processes. So why is it done for Mac OS X? It just adds to the "configuration" confusion. From other discussions of this topic, a suggestion was made to change the second line of Miller's to: cc -bundle -bundle_loader <path_to_PD> -flat_namespace -o $*.pd_darwin $*.o <other_object_files_to_include> I would think that it would be possible to still use the "link" above, but it would be nice if the '..' were changed to the "target" directory. Does anyone have other ideas? Thanks, Mike

2 1

devel_0_36 / flext simd
by Thomas Grill 16 May '03

16 May '03

Hi all, i realized that the thread-safety of the pd clock routines (in the cvs devel_0_36 branch) was not yet complete. I updated these things appropriately. Please check if it's ok now. Another thing: When a friend of mine tried to compile flext with MSVC++ we stumbled over the fact that the special compiler update package for inline SIMD instruction is needed. How can i check at compile time that the compiler package for VC++ is installed? best greetings, Thomas

1 0

Re: [PD-dev] [GEM-dev] a new list
by IOhannes zmoelnig 16 May '03

16 May '03

rat(a)telecoma.net wrote: > hi IOhannes, > > ich wuerde auch gerne subscribieren, > ist das moeglich ? > > ah i have forgotten to send the URL of the subscription interface: http://iem.at/cgi-bin/mailman/listinfo/gem-dev mfg.asd.r IOhannes

1 0

[GEM-dev] a new list
by IOhannes zmoelnig 16 May '03

16 May '03

hi all. i have just made a new mailing-list for Gem-developpers: gem-dev(a)iem.at this is because there is afr to much traffic on both the pd-list and the pd-dev-list for me to follow (right now, because of lack of time) i have subscribed all the regular gem-developpers (on sourceforge) to this list (but it is free for anyone to join) the main intention right now (for me) is to discuss things for the coming (when ?) new-release of Gem mfg.bvfsd.as IOhannes

1 0

sf.net (was: [PD] pure-data.org)
by Krzysztof Czaja 15 May '03

15 May '03

great news, Frank and Guenter, thanks! If possible, I would go in with the 4 libraries hosted here (cyclone, xeq, vex, and toys). Since these share common code, they might need gathering under an umbrella directory, like Thomas' (in any case, better make the tree after some thinking -- hate those zombie dirs in cvs...) Hope this sounds ok to you. If so, I will make the import next week. Krzysztof Frank Barknecht wrote: ... > guenter geiger hat gesagt: // guenter geiger wrote: > > >>Actually thats true. When I set up the site I had to choose a license, >>that led me to the conclusion that all the software has to be under >>that license. But obviously this is wrong, so lets change that as fast >>as possible. > > > I now changed it to: > "A lot of the externals here are currently GPL'd, but the only > requirement we have is, that your code has an Open Source license"

3 2

Re: [GEM] update && Re: [PD-dev] [GEM] update
by zmoelnig＠iem.at 15 May '03

15 May '03

hi. i just wrote an answer, then the phone-jack plugged itself out of my modem- connector, and it was gone. i hope i can recall everything. Zitiere chris clepper <cclepper(a)artic.edu>: > >hi all. > > > >just commited one or two changes to the cvs. > >1. Pixes/pix_texture now has automatic yuv2rgb conversion (on > >non-mac's -- i couldn't get my nvidia to texture yuv422-maps > >correctly) > > that's too bad. without being able to upload the yuv texture a fair > amount of the speed gain is lost. which is true, but it should have been read: "i couldn't yet get my nvidia to texture yuv422-maps" (note the *yet*) and i haven't yet found any(!) documentation. however, there is the speed gain that comes from the mere smaller amount of data. and at least, all the yuv things do work at least without too much hazzle. > > it sort of defeats the purpose of runtime checking if you have to add > compiler -D options to get it to work for each check. that's why > that code is in there. would a solution be to disable runtime checks > on Windows and Linux? on linux you can check for this in the > configure script but I don't know how you would get around this for > binaries on Windows (apart from having multiple versions for each > vendor, ugh). surely the game developers get around this because if > MS only uses GL 1.1 then there would be no point in developing games > like Unreal or Doom or high-end modelling apps on Windows. i think you hae got something wrong. it's simple: differentiate between compilation time and runtime. compilation-time: all the defines i am using for the ifdefs merely come from the GL/gl.h-headers, so there is no need for "-D" flags. i just cannot use "glEnable(GL_TEXTURE_RECTANGLE_NVX)" if i do not have the nvidia-openGL-headers installed. so i have to ifdef it (and i think it is very sophisticated to ifdef it with GL_TEXTURE_RECTANGLE_NVX) run-time: checks for openGL-extensions work very well under linux (and i guess under windows too, otherwise the whole openGL-standard would be pointless in redmont). but unfortunately i can (successfully) check for extensions at runtime, although they have not been present during compilation. for instance, if i do not use the nvidia-openGL-headers, a check for GL_NV_texture_rectangle (or whatever it is called, cannot remember now exactly) will still return "1" if you are using a recent nvidia-driver. but then GemMan::rectangle_supported is true, which will lead to execution of some code (in pix_texture) that is plainly producing unwanted results, like black textures. so one solution would be to check for the extension *and* #ifdef all the rectangle-code in pix_texture. the other one (which is easier to add later and easier to read anytime (because #ifdef's are not really code-reader-friendly) is to check only for a certain extension if the feature is supported at compilation time. that's why i have #ifdef'ed some parts in GemMan.cpp furthermore: please do not remove #ifdef's if they do not break anything. if they do, please add some comment in the code why you don't want it there. generally i don't like prepocessor-defines and only add them, if i need it to compile. > > >3. Copied yuv/[yuv_emboss] to Pixes/[pix_emboss] (to have one true > >yuv-effect for testing) > >however, that was what i meant in one of my previous mails: yuv2pix > >is not yet finished since there are a lot of yuv-effects... > > why yuv_emboss? it doesn't really work so well if i recall...;) yes, i noticed, that it did something i didn't really expect... > >How do you handle installation ? > that's the tricky part. i would like to have an installer script for > OSX too, which could be done via unix script or AppleScript. maybe unix-shell-scripts would be better, because it's more multi-platform and it could be shared across the various un*xes. but then under linux the thing is either handled by "make install" or the package-manager (which refers to "make install" > > i guess it's ok to have those calls in filmNEW, they just require > ifdefs to keep things straight. i put an ifdef in pix_filmNEW since > i'm not compiling the non-OSX classes. all the classes should well compile under all OS's (although the preprocesser would maybe strip them to the plain dummy class film (whÃch wouldn't be able to load anything) but it is true that i haven't quite done it that way, but made lot's of #ifdef's around the lib-dependent code. mfg.as.rd IOhannes

3 2

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 May 2003