On 2010-06-15 16:16, Mathieu Bouchard wrote:
On Tue, 15 Jun 2010, IOhannes m zmoelnig wrote:
yes, but that's the nature of Pd's development model. furthermore, in reality i suspect GF's [print] to have dependencies on GF, so you would be unable to run this [print] without GF installed.
Every class in GridFlow depends on a common piece of code that implements a partial abstraction layer over the Pd API, involving an extra preprocessor pretending to be SWIG, etc. Furthermore, GF's [print] depends on the grid subsystem and the code of [#print] (which is only able to print grids).
Ideally, Miller would fix atom_string() and I'd delete my [print]. But we don't live in that fairyland.
we've been discussing that at the LAC2008 in cologne, where i proposed an "atom registry" (similar to the class_addnew() concept), where devs could register new atom-types. the idea was to attach a symbolic name to an atom (e.g. "float" or "pdpackage") and in return receive a numeric id (atom.a_type), allowing for multiple externals to use the same atom without having to hardcode the numeric ID (assuming that symbolic names would be less susceptible to clashes than arbitrary numbers; e.g. one could use a dns-like name like "ca.gridflow.grid".
the developer could then also provide an atom2string()-callback, that would allow the atom_string() to make something more meaningful of the new atom, than printing "consistency check failed: atom_string" (without newline). in the worst case (if no callback was provided), atom_string() could at least print the atom-name, e.g. "gem_state at.iem.gem:state at.iem.gem:cache"
it was turned down, as it adds too much complexity to the code for too little advantages...
fgvmasdf IOhannes