Re: [PD-dev] moving iemgui from core to extra
On 14 Dec 2006, at 18:18, Mathieu Bouchard wrote: On Thu, 14 Dec 2006, Hans-Christoph Steiner wrote: I propose moving the IEM GUI objects that are embedded in Pd into the extra folder, compiled as individual files. What's the advantage of doing that? Separation of Concerns: http://en.wikipedia.org/wiki/Separation_of_concerns Separation of language, content, and presentation has to be a good move, no? d ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] moving iemgui from core to extra
padawan12 wrote: On Fri, 15 Dec 2006 13:52:07 +0100 IOhannes m zmölnig [EMAIL PROTECTED] wrote: i am a string advocate Me too, ;-) but those damn symbols can't contain whitespace ?? says who ?? mf.adsr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] moving iemgui from core to extra
On Dec 15, 2006, at 7:52 AM, IOhannes m zmölnig wrote: Hans-Christoph Steiner wrote: As the author of the only modified version of IEMGUI in five years, I say no, we don't need this to happen. It wasn't a question of need. We are all fed ;). Do you have any actual objections? well, i would not do it. i am a string advocate of splitting the pd-core from its objects (as far as this is possible: i don't think of getting rid of [pd], [inlet], [switch~] and friends). but there is no real use in getting IEMGUI's separated when the numberbox, the signal-objects and the math are still part of core pd. however, if you feel the urge to do so and you feel like patching pd-vanilla for each release, go on. you could also do a fork ;-) (it all boils down to: do you have any real benefits from this? or are you just bored and need some work to do oer the holidays ;-) ?) If we are going to have full-fledged namespaces, than this is an essential step. Think C without any #includes or Java without any #imports. Only the bare minimum is in the language itself. Everything else is a library. The embedded iemgui objects are just an easy place to start, they are already one-class per file. This would provide a test case for the idea, and then we can figure out how to separate the rest. As for patching the core, each Pd-extended release has 20+ patches applied. This current one has 22-24, depending on platform (you can see the list in packages/patches). Adding patches is trivial with the patch management in packages/Makefile. .hc [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] moving iemgui from core to extra
If we are going to have full-fledged namespaces, than this is an essential step. Think C without any #includes or Java without any #imports. Only the bare minimum is in the language itself. Everything else is a library. in Python 2.5, Tk is still a configure-time option, which means, TkInter isnt shipped as a seperate library (Even TCL ships Tk seperately). likewise, the JVM from sun includes a GUI as well. the Squeak VM includes a gui, debugger, source code editor, etc. these GUIs may be shipped as nonoptional parts of the core, but presambly they do have their own namespace and installation directory on disk - does this mean we'll be cerating [iemgui/numbox2]'s in patches soon (or [declare import iemgui] or whatever)? my question would be... what do you get out of this change. other than make people's patches slightly harder to build, and have to worry about getting your changes incorporated into miller's version or continually move around files every version bump.. i guess the prefs dialog has a setting for default library imports? ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] moving iemgui from core to extra
On Dec 15, 2006, at 1:54 PM, carmen wrote: If we are going to have full-fledged namespaces, than this is an essential step. Think C without any #includes or Java without any #imports. Only the bare minimum is in the language itself. Everything else is a library. in Python 2.5, Tk is still a configure-time option, which means, TkInter isnt shipped as a seperate library (Even TCL ships Tk seperately). likewise, the JVM from sun includes a GUI as well. the Squeak VM includes a gui, debugger, source code editor, etc. these GUIs may be shipped as nonoptional parts of the core, but presambly they do have their own namespace and installation directory on disk - does this mean we'll be cerating [iemgui/ numbox2]'s in patches soon (or [declare import iemgui] or whatever)? my question would be... what do you get out of this change. other than make people's patches slightly harder to build, and have to worry about getting your changes incorporated into miller's version or continually move around files every version bump.. i guess the prefs dialog has a setting for default library imports? If those files are then included in the extra folder in the pd- vanilla, then there would be no change in how you use it. Pd would just load the file when requested, instead of at startup. On Pd-extended those files would be stuck into a libdir. If you use the prefs file that is included in all of the Pd-extended packages, then this change would be completely transparent, you would do everything the same. Otherwise, the [import], [declare] stuff would need to be used. Then it would mean that Pd would only load the code that you are actually using. That means you can completely ignore any bugs, etc in code that you are not using. This also means that there would be very few reserved words in Pd. Classes compiled into the core are basically reserved words, you can't use them in any other way. .hc Access to computers should be unlimited and total. - the hacker ethic ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] 64-bit Tcl/Tk
Does anyone know anything about the 64-bit support in Tcl/Tk? I was thinking of making 64-bit native G5 and Xeon builds of Pd, once everything is release. That said, does the --enable-threads thing do anything for us? .hc All information should be free. - the hacker ethic ___ 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
Re: [PD-dev] strings
Plus you can use that string format directly with Martin Peach's network objects, AFAIK. .hc On Dec 16, 2006, at 7:16 AM, padawan12 wrote: 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 All information should be free. - the hacker ethic ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
On Fri, 15 Dec 2006, Hans-Christoph Steiner wrote: 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. An advantage using the list-of-bytes approach is that because each character can be represented by a rather large integer, it can be extended to work on lists-of-characters meaning quickly, if there is a [utf8decode] and [utf8encode] to turn bytes into characters and back; also it's a method that is available now and reuses the existing list objects; and it's a method that supports \0 (NUL) characters. Disadvantages are that it takes more time to convert to C strings and back, it takes more space in .pd files, it isn't readable as text in .pd files, it takes up to 4 times more space to represent in .pd files, and exactly 4 times more space in RAM (in the case that just iso-latin-1 is used), and also that you can't make lists of strings like that. (By the time we can have real strings, we can have nested-lists, and the other way around, because they'd use the same mechanisms. whether it's better to make them two types or one type, is a good question.) _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] moving iemgui from core to extra
On Fri, 15 Dec 2006, Hans-Christoph Steiner wrote: On Dec 14, 2006, at 3:25 PM, Mathieu Bouchard wrote: It's not like it's impossible to overwrite methods in [objectmaker]. What is [objectmaker]? what's at the end of the receive-symbol of the same name, that thing that creates all your objectboxes. When you write something in an objectbox, this is where it gets sent. It's the only object in which methods have return-values. You can't use [s objectmaker] directly, because from pd you can't use the return value; instead you send obj messages to canvas. Do you have any actual objections? Yes. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
