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 externals like osc that needs a fPIC i guess that Pd works ok, i am running linux64 a gentoo system and tcl/tk is working. Em Sex, 2006-12-15 às 17:34 -0500, Hans-Christoph Steiner escreveu: 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 Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ 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 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 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. Are we supposed to guess what they are? .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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; double precision floats are different than 64 bit CPUs or applications. FPUs have used 64 bit floats for years regardless of their addressing capabilities. ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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 as text but it's 8
times in 32-bit mode and 16 times in 64-bit mode.
as i think we've discussed before, using ieee floats, which should be
able to losslessly encode a 24 bit integer,
if you want something saveable to a file, pd can only losslessly convert
19.93 bits to decimal.
... but then again, what else are ascii 0x1c-0x1f (28-31 = {fs,gs,rs,us})
for?
When I was a small kid, my parents bought a CGP-115 plotter, and the code
for changing the colour of the stylus was 29. It was in 1983.
it's another ugly hack, would reserve some of the ascii range,
0 is enough to do lists-of-strings because in many ASCII-based systems
it's only ever used to mean end-of-string. It's faster than my nested-list
hack. However, my hack looks more like what the syntax for nested lists
could become if it were not a hack. Essentially my hack is a post-parser
that reinterprets symbol-atoms depending on their parens-content, and
makes it feel like pd has a LISP syntax... sometimes. (It's a
GridFlow-only feature though).
_ _ __ ___ _ _ _ ...
| 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] 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 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.
i count (sizeof(int)+sizeof(float)-1)*strlen(message) wasted bytes
per string object, not counting the selector. as i think we've
discussed before, using ieee floats, which should be able to
losslessly encode a 24 bit integer, that can be tweaked down to
(sizeof(int)+sizeof(float)-1)*strlen(message)/3 on average, but on
my system (32 bit floats), that still amounts to one wasted byte
per character for the representation, and it's hellishly cryptic to
boot.
(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.)
... but then again, what else are ascii 0x1c-0x1f (28-31 =
{fs,gs,rs,us}) for? it's another ugly hack, would reserve some of
the ascii range, and would require additional parsing objects
(potentially constructable with [list]), but it's a possibility,
should anyone actually need nested lists as strings...
please don't get me wrong: i'm all in favor of real strings,
nested lists, and associative arrays - i wrote [pdstring] because i
needed to send some generated text over OSC to someone who could
only interpret ascii values: i'm glad if it's helpful to anyone
besides myself, and i don't see much difficulty in adding support
for low-level c-type string operations ([toupper], [tolower], at
some later point maybe even regexes), but i can't bring myself to
believe that the list-of-bytes approach is really the right way
to do it, although i don't have a better idea at the moment...
One advantage of this approach is that many C string functions like
toupper, tolower, strcat, strcmp, etc. would be pretty easy to
implement in Pd, rather than C. A regexp object in C would be pretty
straightforward.
How about using a selector string for these lists? I suppose that
could cause mayhem since it would make the list into a selector
series and run into all the vagaries of handling them.
.hc
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish.-William Carlos Williams
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
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. 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 capabilities. So does that mean it would be possible to make Pd use 64-bit floats on all CPUs without a major performance hit? .hc Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ 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 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 one-source-file-per-class. If you can't find it, I could write it once more. (Maybe I'm wrong when I have the impression of repeating myself too much.) _ _ __ ___ _ _ _ ... | 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] 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 capabilities. So does that mean it would be possible to make Pd use 64-bit floats on all CPUs without a major performance hit? No, it's only possible to use 32-bit floats because the t_atom structure contains a t_word union, which is often assumed to be the same size as a C pointer; so in 32-bit mode you can only put a 32-bit float in a t_word. If you put a double in t_word, then it becomes 8 bytes, so a t_atom depends 12 or 16 bytes depending on whether t_atomtype gets extended to the same size as the t_word. If it's 12 bytes you may get a slowdown due to non-alignment, and in both cases you have a slowdown because it's more RAM. If t_atom were an opaque type, I know how to make it support 63-bit floats, as well as all the other possible atoms, all in a 8-byte (64-bit) structure, in both 32-bit and 64-bit mode. Note that I really mean 63-bit floats here, and not 64-bit. (The same trick could be applied to shrinking t_atom to 4 bytes in 32-bit mode if using 31-bit floats.) _ _ __ ___ _ _ _ ... | 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 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 move, no? but the IEMGUIs, like the rest of the Pd GUIs, are part of the language. You can't remove them without breaking the code. I have a working version of Pd with the iemguis as externals, so I don't see the breaking the code part, That's not relevant, because we're talking about what it means to separate concerns. I'm trying to make a point about what it means to separate presentation, and how it is that separating IEMGUI does not constitute separating presentation, and I use the removal of IEMGUI as an example, and then you come in and say that you are not removing IEMGUI. What are you talking about? What am *I* talking about? _ _ __ ___ _ _ _ ... | 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] 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 pointer to the first byte of the string, and a length.
Multibyte characters would just be counted as multiple characters when
calculating the length, so the length would be the number of bytes in
the string, not the number of characters.
It looks too easy to me...In m_pd.h, add:
A_STRING
to t_atomtype.
Add
t_string * w_string;
to t_word.
Add the typedef:
typedef struct _string /* pointer to a string */
{
unsigned long s_length; /* length of string in bytes */
unsigned char *s_data; /* pointer to 1st byte of string */
} t_string;
...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 (?),
all the string manipulation objects could be built as externals.
Martin
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
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 provisions for adding any extra atom types. There's no table for registering atom types. Out of 12 assigned numbers for atom types, 5 aren't actually atom types, 4 are radioactive types (SEMI,COMMA,DOLLAR,DOLLSYM), the remaining three have reserved selectors and hardcoded entries in t_class. What's the right way to add a fourth one like that? all the string manipulation objects could be built as externals. What if strings could be automatically cast to symbols for externals that would rather have symbols, and vice-versa? It looks too easy to me... It's because you've only thought about the easy part of the problem. How do you know when a string becomes unused? When do you deallocate the memory? What does this mean for the API used by externals? (including the things that are assumed but not written in m_pd.h) _ _ __ ___ _ _ _ ... | 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] 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, for example.
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_data; /* pointer to 1st byte of string */
} t_string;
Martin
.hc
On Dec 16, 2006, at 5:12 PM, Martin Peach wrote:
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 pointer to the first byte of the string, and a
length. Multibyte characters would just be counted as multiple
characters when calculating the length, so the length would be the
number of bytes in the string, not the number of characters.
It looks too easy to me...In m_pd.h, add:
A_STRING
to t_atomtype.
Add
t_string * w_string;
to t_word.
Add the typedef:
typedef struct _string /* pointer to a string */
{
unsigned long s_length; /* length of string in bytes */
unsigned char *s_data; /* pointer to 1st byte of string */
} t_string;
...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
(?), all the string manipulation objects could be built as externals.
Martin
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
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
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_data; /* pointer to 1st byte of string */
} t_string;
If you're not compiling in 16-bit mode, then there will be 2 or 6 bytes
between the first and second field, so that the second field can be
aligned to a word boundary, supposing that the struct as a whole is itself
aligned to a word boundary. (By word, I strictly mean something that is
the same size as a pointer.)
What I mean is that it's useless to not use the whole a length field that
is not the same size as the pointer field, if you have only those two
fields. If you have more than two fields, then you can put several short
fields in the space of a word (2 or 4).
_ _ __ ___ _ _ _ ...
| 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] 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. But it seems important to avoid symbols as much as possible to avoid filling up the symbol table with symbols that are referenced only once.. Yes, but my reason for wanting this, is that all externals currently available understand symbols but not strings. So, what if you want to make strings as widely used as possible, as easily as possible, and working with all externals currently available in Pd? You make them work as strings when they can, and You make them work as symbols when they must. A string could be considered unused when its length is set to 0. If you want to use a string as a mutable buffer, then you want to be able to have 0-length strings, as a boundary condition: you start with nothing and then add to it. You don't want to have to start with something just because setting the length to 0 would delete it. It seems that you are suggesting that the deallocation would be user-controlled? Then how do you prevent the user from crashing pd? If you use a weak-pointer as an intermediate (like t_gpointer or t_gfxstub), then you still have to manage reference counts. Whatever you do for the user, you have to know more about externals' behaviour than what they tell you now, because right now they don't deallocate atoms explicitly. But if strings are going to be deallocated explicitly and there is not going to be any checks, why not instead make something that will allow users to deallocate symbols. It's about as safe as that and you don't need to introduce a string type. Memory would need to be dynamically allocated in small blocks. What do you mean in small blocks ? The API should return no method for string if the external doesn't implement strings. That's aiming low. Why shouldn't there be any automatic casts between the two? _ _ __ ___ _ _ _ ... | 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
