On Mar 4, 2009, at 11:46 AM, Martin Peach wrote: > Mathieu Bouchard wrote: >> On Wed, 4 Mar 2009, Martin Peach wrote: >> >>> That's nice. Now we need some html parsing objects so the pages go >>> into the patch and not the pd window. It works well if the >>> received pages are loaded into a table. I made tabfind to search a >>> table for a string. Tables seem more efficient than lists and less >>> volatile. >> >> Lists are volatile because they are (typically) stack-allocated or >> in any way their contract of use makes (argc,argv) only valid >> during the call... so you could use a heap-allocated argv but >> modify it between calls and it would still make the list data have >> a stack-wise accessibility. >> >> Because lists are volatile, they need to be copied by any object >> that wants to keep them. It's actually worse than that, as objects >> used recursively have to watch out for what they can deallocate. >> It's not like you could make [list] be faster without complicating >> it... and this includes plain data-recursion as well too (set cold- >> inlet of an object while its cold-inlet has still a job pending on >> the stack). >> >> Tables can be much faster but they also need to be statically- >> allocated (or dynamically-patched!), and they are type-restricted >> (where you can't say that any element slot may contain any atom one >> decides at runtime), and you have to find names for the tables >> because they can't be anonymous. > > Tables also use half as much memory as lists because they are mainly > an array of floats, while a list of floats is actually an array of > atoms, each atom comprising a tag indicating that it contains a > float as well as the float itself. > For the network objects the lists are made of floats so the type > restriction is not important. > Also a table can be reused and resized and its contents never get > added to the symbol list so there's no constantly increasing memory > involved. The typical web page has a huge amount of irrelevant text > that would quickly clog the symbol table, so it's more efficient to > extract the relevant bits before converting any of it to a symbol.
It seems that we should have a string.h for tables then. That would be a good starting point, just make a library that is just Pd interpretations of all the string.h strcpy, etc. functions, but have them operate on arrays and maybe lists of floats too. There could also be a totally Pd-ish string library too. .hc ---------------------------------------------------------------------------- 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list