-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
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
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;
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
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
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.
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
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
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
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
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
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,
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
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.
14 matches
Mail list logo
