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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
