Re: [PD-dev] strings

On Sat, 16 Dec 2006, Martin Peach wrote: What if strings could be automatically cast to symbols for externals that would rather have symbols, and vice-versa? I have written an external asc2sym that takes lists of bytes and splits them into symbols based on the argument(s) which are characters.

Re: [PD-dev] strings

On Sat, 16 Dec 2006, Martin Peach wrote: Yes, and it's also easier to limit strings to word (16-bit) lengths, while 8-bit is too short. So a t_string would look like: typedef struct _string /* pointer to a string */ { unsigned short s_length; /* length of string in bytes */ unsigned char *s_d

Re: [PD-dev] strings

Mathieu Bouchard wrote: On Sat, 16 Dec 2006, Martin Peach wrote: ...so a string atom would have a_type = A_STRING and a_w = a_w.w_string, which points to a t_string containing the length and a pointer to the string. If pd is otherwise able to handle atom types it doesn't know about (?), I

Re: [PD-dev] strings

Hans-Christoph Steiner wrote: The one problem I can think of here is that you can only have 19 bits of precision in Pd's 32-bit t_float. So having a length of 32 bits would cause problems if trying to deal with string length using t_floats. I could see this happening in a loop in Pd space, f

Re: [PD-dev] strings

On Sat, 16 Dec 2006, Martin Peach wrote: ...so a string atom would have a_type = A_STRING and a_w = a_w.w_string, which points to a t_string containing the length and a pointer to the string. If pd is otherwise able to handle atom types it doesn't know about (?), It's not. There are no pro

Re: [PD-dev] strings

The one problem I can think of here is that you can only have 19 bits of precision in Pd's 32-bit t_float. So having a length of 32 bits would cause problems if trying to deal with string length using t_floats. I could see this happening in a loop in Pd space, for example. .hc On Dec 16

Re: [PD-dev] strings

I think it would be most efficient to have a string type be a length followed by that many unsigned chars, similar to a Pascal string but with the length being something like a 32-bit integer. It would not be added to pd's symbol list. The atom whose type was string would have to contain a poin

Re: [PD-dev] moving iemgui from core to extra

On Sat, 16 Dec 2006, Hans-Christoph Steiner wrote: On Dec 16, 2006, at 2:52 PM, Mathieu Bouchard wrote: On Fri, 15 Dec 2006, Plans Casal David wrote: Separation of Concerns: http://en.wikipedia.org/wiki/Separation_of_concerns Separation of language, content, and presentation has to be a good mo

Re: [PD-dev] moving iemgui from core to extra

On Dec 16, 2006, at 2:52 PM, Mathieu Bouchard wrote: On Fri, 15 Dec 2006, Plans Casal David wrote: 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, compi

Re: [PD-dev] moving iemgui from core to extra

On Fri, 15 Dec 2006, Hans-Christoph Steiner 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. C/C++'s #includes don't have anything to do with namespaces. C doesn't have any, and C++ allows you

Re: [PD-dev] moving iemgui from core to extra

On Fri, 15 Dec 2006, Plans Casal David wrote: 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 t

Re: [PD-dev] strings

On Fri, 15 Dec 2006, Chris McCormick wrote: On Thu, Dec 14, 2006 at 01:47:58PM -0500, Mathieu Bouchard wrote: On Fri, 15 Dec 2006, padawan12 wrote: Did I hear a rumour that better string handling is chalked in for Pd soon? Huh??

Re: [PD-dev] 64-bit Tcl/Tk

On Sat, 16 Dec 2006, Hans-Christoph Steiner wrote: On Dec 16, 2006, at 12:18 PM, chris clepper wrote: The 64 bit buzzword refers to memory addressing; double precision floats are different than 64 bit CPUs or applications. FPUs have used 64 bit floats for years regardless of their addressing c

Re: [PD-dev] moving iemgui from core to extra

On Sat, 16 Dec 2006, Hans-Christoph Steiner wrote: On Dec 15, 2006, at 8:02 PM, Mathieu Bouchard wrote: On Fri, 15 Dec 2006, Hans-Christoph Steiner wrote: Do you have any actual objections? Yes. Are we supposed to guess what they are? You could guess using mail archives what I think about

Re: [PD-dev] 64-bit Tcl/Tk

On Dec 16, 2006, at 12:18 PM, chris clepper wrote: On 12/16/06, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote: -fPIC is on by default on Mac OS X, so that's easy. Having 64-bit floats is quite nice on the interface side because it means you can have large integers in Pd, like timestamps.

Re: [PD-dev] strings

On Dec 16, 2006, at 4:55 AM, Bryan Jurish wrote: morning, On 2006-12-16 01:40:03, Mathieu Bouchard <[EMAIL PROTECTED]> appears to have written: On Fri, 15 Dec 2006, Hans-Christoph Steiner wrote: An advantage using the list-of-bytes approach is that because each character can be represente

Re: [PD-dev] strings

On Sat, 16 Dec 2006, Bryan Jurish wrote: On 2006-12-16 01:40:03, Mathieu Bouchard <[EMAIL PROTECTED]> appears to have written: i count (sizeof(int)+sizeof(float)-1)*strlen(message) wasted bytes per string object, not counting the selector. Oh yeah, sorry, the occupied space is up to 4 times

Re: [PD-dev] 64-bit Tcl/Tk

On 12/16/06, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote: -fPIC is on by default on Mac OS X, so that's easy. Having 64-bit floats is quite nice on the interface side because it means you can have large integers in Pd, like timestamps. The 64 bit buzzword refers to memory addressing; d

Re: [PD-dev] moving iemgui from core to extra

On Dec 15, 2006, at 8:02 PM, Mathieu Bouchard wrote: 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 o

Re: [PD-dev] 64-bit Tcl/Tk

-fPIC is on by default on Mac OS X, so that's easy. Having 64-bit floats is quite nice on the interface side because it means you can have large integers in Pd, like timestamps. .hc On Dec 16, 2006, at 1:24 AM, glauber alex dias prado wrote: Except for some problems compiling some extern

Re: [PD-dev] strings

morning, On 2006-12-16 01:40:03, Mathieu Bouchard <[EMAIL PROTECTED]> appears to have written: On Fri, 15 Dec 2006, Hans-Christoph Steiner wrote: 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 w