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.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

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

On Wed, 4 Mar 2009, Hans-Christoph Steiner wrote:

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.

I very much recommend making a library that can handle both at an expense that is as close as possible to making a library for just one of them.

But I believe that those list abstractions should be made for lists, and not for anythings, which is a dangerous precedent set by [list], because for example it prevents introducing a message "array $1" where $1 would be a send-symbol for an array. (Or it could be called [table]. why are there two names for that concept in pd anyway?)

There could also be a totally Pd-ish string library too.

No idea what that means in your head, sorry... :/

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

On Thu, 5 Mar 2009, Hans-Christoph Steiner wrote:

On Mar 5, 2009, at 11:14 AM, Mathieu Bouchard wrote:

...

I very much recommend making a library that can handle both at an expense that is as close as possible to making a library for just one of them. But I believe that those list abstractions should be made for lists, and not for anythings, which is a dangerous precedent set by [list], because for example it prevents introducing a message "array $1" where $1 would be a send-symbol for an array. (Or it could be called [table]. why are there two names for that concept in pd anyway?)

I think that [array $1( would be better represented by an argument and a matching inlet. I think that's clearer than using [array $1(.

I've never seen an object have two different hot inlets doing the same thing for different types and two different cold inlets doing the same thing for different types. This is probably not what you mean, and if it's not, then you have to know that I'm talking about making classes that each can support both lists and array-names for each of the arguments to an operation. This is what I am talking about, and not about classes that support just arrays.

...

...

There could also be a totally Pd-ish string library too.

No idea what that means in your head, sorry... :/

And I still don't know what that means, sorry again. :(

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

On Thu, 5 Mar 2009, Martin Peach wrote:

Yes it seems to me a string manipulation object like [strncmp] should be able to accept symbols, floats, lists of floats, and messages naming arrays, on any of its inlets that are meant to accept strings.

By floats, you mean a single float representing a single character? If not, then I suppose that any string made of individual float messages would have to be converted to a list of floats first, so that it goes well with all equivalent forms that use a single message per string.

But now, La Question Qui Tue: if you do a [string append] on two strings of different format, what should be the format of the output?

Actually, there's another killer question: if you do a [string append] on two arrays, and that it is agreed that the output should go in an array, in which array does the output go?

Maybe it should be [arrble $1( or [tabray $1( so as not to prefer one over the other.

The problem with that is that the big-endians will think that "arrble" connotes racial discrimination in favour of arrays whereas little-endians will claim that it is "tabray" that is favoured. A more politically correct way of constructing a new term would be by interleaving the letters from both words (inspired by INTERCAL), like "atrarbalye" or "taarbrlaey". This does not really solve the problem but it reduces it by a large factor so that you can conveniently sweep it under the carpet without making too much of an unsightly lump. This is the glory of Psychological Engineering at work.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

On Thu, 5 Mar 2009, Martin Peach wrote:

Mathieu Bouchard wrote:

...

By floats, you mean a single float representing a single character?

Yes single character, any unicode character will fit in a float.

Well, my question was not about whether they'd fit or not in a single float, but rather whether you were talking about supporting sequences of float messages as being a string. I just wanted to make clear that i believe that a message sequence "72,101,108,108,111" should be converted to a single list message "72 101 108 108 111" to make things easier.

But now that I think of it, a float only represents a code-point. In most of the usage of unicode, a code-point = a character, but I've already encountered cases where I typed a character in two parts that are registered as one code-point each. I thought I never would.

...

But now, La Question Qui Tue: if you do a [string append] on two strings of different format, what should be the format of the output?

The first argument of the object would be the name of a table, with a [set( message to change it.

Well, my goal was to come up with an idea of a [string append] that isn't array-centric, for example, or at least, doesn't look like it when you try to use it with something else than arrays. But if the $1 of [string append] means an array name when it's a symbol, then it can't mean a symbol whose letters would be turned into list elements or array elements, for example.

...

Actually, there's another killer question: if you do a [string append] on two arrays, and that it is agreed that the output should go in an array, in which array does the output go?

If it's like a [strcat] it goes into the table named by its first argument, or the most recent [set( message.

Seems good.

I think instead of using zero to terminate the string the destination table should be resized to the length of the resulting string.

Ideally, yeah, many programming languages don't use zero-termination, including a bunch that used to use zero-termination and went away from it. (Those languages that used to still store it as a hidden element in the array, but that's an optimisation trick for interfacing with C, and it doesn't apply if your array is made of floats and not of bytes.)

It would be a lot better if arrays could be resized in more flexible ways. That way, you could gradually add elements to it without fearing of hitting a mountain of redundant reallocations, that is, one per character added in a long sequence of strcats of single chars.

For example, I made an implementation of t_binbuf in which "size" is distinguished from "capacity", and the difference between the two is some padding for future use. The capacity grows by bigger amounts than the size, so that the capacity doesn't have to grow as often. Many programming languages have arrays that work like this. Several of those also have an index for padding at the beginning so that you can gradually chop off elements at the beginning without having to copy the table a bunch of times.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

On Mar 4, 2009, at 9:18 AM, Martin Peach wrote:

Hans-Christoph Steiner wrote:

...

I made [httpget] for fetching webpages into pd:

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.

Any ideas on how to approach the HTML parsing? It seems like using an
xml-based parsing library would be the way to do that. There is detox
in jasch_lib, but I don't know the state of it.

.hc

"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore