On Sep 10, 2011, at 3:01 PM, Mathieu Bouchard wrote:
On Tue, 6 Sep 2011, [email protected] wrote:
The disaster would be if Pd tried to guess what the user intends
based on some general idea of what Pd is 'for'. For instance I've
been working on an xbee external where I need to specify numbers
like 0x0a060123 for the remote address. I do that by interpreting
the symbol as a 64-bit integer internally but I would not expect
any other external to do this unless it needs to.
The xbee external uses a function that shows that it expects to read
a symbol where you gave it the 0x0a060123 symbol. Therefore Pd would
not do any implicit conversion, because it's being requested to give
a symbol atom as a symbol.
However, if ever 0x0a060123 is to be parsed as a float (that's a
different issue, actually), then xbee would be getting 168165667
rounded to 168165664 and then it would be implicitly converted to
gensym("168165664"). But that's a parser difference, and not a
difference of implicit type conversions. The solution would be to
backslash it or doublequote it.
Perhaps it is confusing because we are talking about several related
propositions at once :
* implicit conversion to replace type mismatch errors
* getting atom_string to write backslashes to files and to
messageboxes,
to match what the parser can already do
* modifying both the parser and atom_string, to change the meaning of
doublequotes
and AFAIK, no-one talked about adding support for aztec numerals or
parsing «half-dozen» as meaning {A_FLOAT,6}.
I'm thinking now to first try a more python style approach, and have
something like str() and float() rather than automatic conversions. I
implemented this in two objects that are meant to replace [symbol] and
[float], [symbol2] and [float2]. Here's the library:
https://github.com/pd-projects/newtype
There is definitely a universally valid way of converting a symbol to
a float because Pd converts strings to floats both when receiving
floats from the GUI and when reading floats from the .pd file. I
implemented this in a test file and I think it matches Pd's
implementation in every case that I could think of:
https://github.com/pd-projects/newtype/blob/master/test_symbol2float.c
Converting from a float to a symbol in the code is simple, that's just
sprintf(buf, "%g"), its in the code a lot, like in atom_string() and
atom_getsym().
As for all the \ cases, I don't really know how to handle \n, \t, etc.
yet. As for unicode chars, I think we should just support unicode
completely then people put the actual character rather than the \0x234
form. We have full unicode support for a lot of left-to-right
alphabets. Things like Chinese, arabic, etc. have issues with box
sizing, but the characters show up correctly.
.hc
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
