Re: [PD-dev] pd and eclipse
Yeah I've been a vi and screen man since... (dreamy blur out effect and the hands of a clock spinning backwards) But I think you just sold vim there Frank. It's a deal. On Wed, 28 Feb 2007 16:51:09 -0600 Kyle Klipowicz [EMAIL PROTECTED] wrote: Hmmm I use vi for terminal stuff, but never tried Vim. If it actually has menus and integrated cut+paste w/ the window manager, that would be swell! I never took the time to learn Emacs because I already had a foothold in Vi. That, and it seems kinda bloated. ~Kyle On 2/28/07, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote: I am not really doing much programming for externals or anything, but it would help my learning to read about different approaches that people may take. Here's how I work, if I do: I use Vim, because I'm used to it and it rocks. ;) (Insert Emacs-Vi flameware here: ... ) I also like to have a Makefile ready, the one from pd/doc/6.externs/makefile is fine. Then I edit the external file in Vim, and if I want to compile I either use Vim's Make current Project icon or the command :make Now this is the time, when make fails because I wrote buggy code. But because Vim is so smart it directly takes me to the point in my code where I have an error because it can read the make output, filter out the file name and line number and directly go there. If I want to see the errors and warnings, I use the :copen and :cclose commands to open and close the error window. I can click on errors there and Vim will transport me to the respective source file and line. Tags are also important. By using Vim's menu entry: Tools-Build Tags File Vim will run ctags to generate a tags file. This quickly lets me navigate the source by using the Jump to this tag and jump back functions to look up code under the cursor. A very useful extension is the taglist.vim plugin, that provides a bird's eye view on the methods and variables in a source file. I don't yet use a debugger directly with Vim, that's something I still need to learn. I use Vim not only for externals but for everything including Python code, HTML stuff, qlists, magazine articles or this mail. Emacs can do all this as well, of course, the choice is just a matter of taste. Just make sure you choose an editor that can be customized a lot, because Pd people like to fiddle. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Cross-compiling for Windows on Debian
On Mon, 22 Jan 2007 15:46:38 +0100 Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: Oops, do I read this correctly, that on Windows (or *for* Windows) I need to have some kind of pd.dll to compile an external? And that means, I need to cross-compile Pd first? Hm, sorry for talking to myself, but it seems I could use a pre-compiled binary from Miller's site (I would have preferred a to use a current pd-extended compiled with GCC, but I couldn't find a zip-file. Are there only installers?) Hi Frank, I was just following your monologue there and wondering, what is rvbap ? Andy Anyways with pointing gcc to the pd.dll inside of that, rvbap.dll finally built and I could even load it running pd.exe with Wine. Seems I'll drink the beer on my own. ;) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
Thanks Hans and IOhan, I think Bryans offering covers most of what is needed, adequate to muddle by until such time when we have real strings. Andy On Fri, 15 Dec 2006 17:41:03 -0500 Hans-Christoph Steiner [EMAIL PROTECTED] wrote: You can do a fair amount of string handling with [list2symbol] and things like that. But yes, it leaves a lot to be desired. Bryan Jurish has taken a different approach, which is to use lists of bytes to represent strings. Might be worth checking out. .hc On Dec 15, 2006, at 2:06 AM, padawan12 wrote: A new and keen developer on the forums has asked - What about text processing in Pd? to which I replied Pd doesn't do strings. I tie myself in knots trying string-like operations sometimes :), so I know its a can of worms, but what are the fundamental limitations surrounding symbol. How do we deal with EOL or NULL and so on, and what about encoding? Did I hear a rumour that better string handling is chalked in for Pd soon? An alphanumeric sort, maybe even a [grep] or [sed]? What would be the best way to introduce the concept of strings to Pd in a consistent and robust way. I see them as lists of symbols without any need for a new type but right now there are pieces of the jigsaw missing. Sorry so many questions, but it's bugging me today. a. ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev All information should be free. - the hacker ethic ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] strings
A new and keen developer on the forums has asked - What about text processing in Pd? to which I replied Pd doesn't do strings. I tie myself in knots trying string-like operations sometimes :), so I know its a can of worms, but what are the fundamental limitations surrounding symbol. How do we deal with EOL or NULL and so on, and what about encoding? Did I hear a rumour that better string handling is chalked in for Pd soon? An alphanumeric sort, maybe even a [grep] or [sed]? What would be the best way to introduce the concept of strings to Pd in a consistent and robust way. I see them as lists of symbols without any need for a new type but right now there are pieces of the jigsaw missing. Sorry so many questions, but it's bugging me today. a. ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] moving iemgui from core to extra
Anything that adds modularity and allows separate compilation has to be a good thing. It seems a logical partition to make too, graphical things should probably have their own space. 2c On Thu, 14 Dec 2006 12:26:32 -0500 Hans-Christoph Steiner [EMAIL PROTECTED] wrote: In a first step towards making Pd a micro-language, I propose moving the IEM GUI objects that are embedded in Pd into the extra folder, compiled as individual files. The only changes needed to make this happen is to rename and move the relevant g_*.c files to extra, renaming the setup() functions accordingly, and changing the makefile. All of these are pretty trivial. Thoughts, comments, objections, improvements? .hc News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] License implications of GPL3
Wow, there's a huge can-o-worms. I'm not going to touch the tin opener other than to say it seems bad, but I don't really understand. From what I remember of commercial law classes you just can't do that with a contract. But then how does a license differ from a contract? For me, I'm very torn over it. On the one hand, practically and realistically I think that you have to either share and shut up or not share at all. In other words it's improper to be adding arbitary personal whims to work you publish and expect the world to sing along. On the other hand I'm so emphatically opposed to crap like digital restrictions management that the CC licenses for my music are decorated with extra clauses making the license void if used on a DRM infected media or channel. Call me a hypocrite, you'd be right, I really don't know how to defend my dualistic position. On Tue, 28 Nov 2006 09:17:58 +0800 Chris McCormick [EMAIL PROTECTED] wrote: Hey All, One interesting consequence of the GPL version 3 is that you are allowed to remove additional clauses from the license on a piece of software that violate the GPL 3. So for example, if a developer has released a Pd library under the GPL version 2 or higher but added their own clauses trying to prevent certain people from using their software in certain ways, under the GPL 3 you will be allowed to remove those additional clauses from the License. http://fsfeurope.org/projects/gplv3/tokyo-rms-transcript (Last paragraph in the section License Compatability) I beleive that this is relevant to one, or maybe two libraries that are used with Puredata. Best, Chris. --- [EMAIL PROTECTED] http://mccormick.cx ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
