Re: [PD] httpget: fun with tcpclient and pdstring
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] httpget: fun with tcpclient and pdstring
On Wed, 4 Mar 2009, Martin Peach wrote: Mathieu Bouchard wrote: 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. For the network objects the lists are made of floats so the type restriction is not important. Right, but when it comes to making reusable classes, you have to choose between type-restricted statically-allocated, and freely-typed stack-allocated, and whatever class you make for processing lists doesn't work on arrays, and whatever class you make for processing arrays doesn't work on lists. Is there any way around that problem? 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 symbol-table is a separate issue. You could make use of lists with mixed floats and symbols freely in lists and always reuse the same symbols, or you could be mixing floats and pointers. 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. I never ever mentioned converting a web page into a bunch of symbols. I'm concerned about the proliferation of list-operations and the duplication between list-operations and array-operations and how it will tend to inflate the number of classes and by default (if the design of classes just goes the usual way) the interfaces of those two sets of classes won't be synchronised with each other, so it will mean more documentation to make and especially more documentation to read. Tables also use half as much memory as lists yeah, but you saw the price of RAM ? ;) _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] httpget: fun with tcpclient and pdstring
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] httpget: fun with tcpclient and pdstring
On Mar 5, 2009, at 11:14 AM, Mathieu Bouchard wrote: 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?) 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(. .hc 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 News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] httpget: fun with tcpclient and pdstring
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] httpget: fun with tcpclient and pdstring
Mathieu Bouchard wrote: 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. 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. Maybe it should be [arrble $1( or [tabray $1( so as not to prefer one over the other. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] httpget: fun with tcpclient and pdstring
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] httpget: fun with tcpclient and pdstring
Mathieu Bouchard wrote: 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. Yes single character, any unicode character will fit in a float. 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. 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. I think instead of using zero to terminate the string the destination table should be resized to the length of the resulting string. 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. But little-endians might just get confused by elbrra and yarbat...I think eylabrarta and yealrbraat would just compound the problem. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] httpget: fun with tcpclient and pdstring
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. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] httpget: fun with tcpclient and pdstring
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] httpget: fun with tcpclient and pdstring
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] httpget: fun with tcpclient and pdstring
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. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] httpget: fun with tcpclient and pdstring
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
Re: [PD] httpget: fun with tcpclient and pdstring
adding this to the GSoC ideas wiki... actually, there's some disabled table-storage code in [pdstring] as well; perhaps I'll get a chance to polish that up sometime soon.. marmosets, Bryan On 2009-03-04 19:01:31, Hans-Christoph Steiner h...@eds.org appears to have written: 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. -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] httpget: fun with tcpclient and pdstring
I made [httpget] for fetching webpages into pd: httpget-help.pd Description: Binary data httpget.pd Description: Binary data .hc http://at.or.at/hans/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
