That might be one solution when using [list trim], but this example actually shows a problem with the type system. Things are supposed to be strictly typed, atoms are either floats, symbols, or pointers. This is an example of an atom that is none of the above. That should not happen, its a bug somewhere.
I updated the example patch with a couple of more relevant examples:
[select 1234] and [route 1234] don't know what to do with this thing either.
.hc
On Oct 28, 2006, at 8:57 AM, padawan12 wrote:
Just checking it's not a problem with [makefilename], it's not. I'd expect an X from trimming any raw X, in other words [list trim] should do nothing to any data that doesn't have "list" at the start. Is that what you would expect?
On Fri, 27 Oct 2006 18:51:37 -0400 Hans-Christoph Steiner hans@eds.org wrote:
A student just discovered this strange behavior. Basically, if you get something that generates a symbolic atom that has numeric data in it, you can then create a mystery type by feeding that thru [list trim]. Don't know exactly where the problem is, but something fishy is going on. My guess is that [list trim] should output a float.
See attached patch:
<mystery_type_after_conversion-more.pd>
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