It's mostly this patch, the sensor input comes from an arduino with a sonar attached. Still at the dangerous stage, implements a minimal http 1.1 server. It's pd-extended 0403 from today's autobuild. Martin
From: Hans-Christoph Steiner hans@eds.org To: "Martin Peach" martin.peach@sympatico.ca CC: pd-dev@iem.at Subject: Re: [PD-dev] string support and generic types Date: Thu, 27 Mar 2008 16:12:01 -0400
On Mar 27, 2008, at 3:22 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
Hey,
IOhannes and Miller worked out a solution for declaring generic types, it didn't sound to hard to implement. For the next Pd- extended release, I think we'll probably should remove the Martin's string patch in favor of this approach.
OK if the new method is implemented first, and documented as well ;) Then I will change [str] to fit. I'm using the str object a lot right now in my pd web server: http://132.205.142.13
Wow, that's nice. Is it Pd-extended per chance? Looking forward to trying that code! :)
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I am fine with leaving the string patch in this release as it is if it will be compatible with a generic approach to defining new atoms types. Can anyone speak to that?
.hc
On Mar 27, 2008, at 4:29 PM, Martin Peach wrote:
It's mostly this patch, the sensor input comes from an arduino with a sonar attached. Still at the dangerous stage, implements a minimal http 1.1 server. It's pd-extended 0403 from today's autobuild. Martin
From: Hans-Christoph Steiner hans@eds.org To: "Martin Peach" martin.peach@sympatico.ca CC: pd-dev@iem.at Subject: Re: [PD-dev] string support and generic types Date: Thu, 27 Mar 2008 16:12:01 -0400
On Mar 27, 2008, at 3:22 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
Hey,
IOhannes and Miller worked out a solution for declaring generic types, it didn't sound to hard to implement. For the next Pd- extended release, I think we'll probably should remove the
Martin's
string patch in favor of this approach.
OK if the new method is implemented first, and documented as
well ;)
Then I will change [str] to fit. I'm using the str object a lot right now in my pd web server: http://132.205.142.13
Wow, that's nice. Is it Pd-extended per chance? Looking forward to trying that code! :)
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
<webserverx.pd>
------------------------------------------------------------------------ ----
Mistrust authority - promote decentralization. - the hacker ethic
Hans-Christoph Steiner wrote:
I am fine with leaving the string patch in this release as it is if it will be compatible with a generic approach to defining new atoms types. Can anyone speak to that?
does the patch still register the "string" keyword? (and in doing so breaks all other objects that use [string( without the string-atomtype?)
fmsdr IOhannes
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I am fine with leaving the string patch in this release as it is if it will be compatible with a generic approach to defining new atoms types. Can anyone speak to that?
does the patch still register the "string" keyword? (and in doing so breaks all other objects that use [string( without the string-atomtype?)
The latest version registers the "blob" keyword instead, but I think it is not necessary for it to register a name at all.
Martin
Martin Peach wrote:
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I am fine with leaving the string patch in this release as it is if it will be compatible with a generic approach to defining new atoms types. Can anyone speak to that?
does the patch still register the "string" keyword? (and in doing so breaks all other objects that use [string( without the string-atomtype?)
The latest version registers the "blob" keyword instead, but I think it is not necessary for it to register a name at all.
exactly! the entire keyword thing is rather a mess anyhow, and i don't think it should be mimicked anywhere. introducing a new atomtype should be enough.
gfmadsr IOhannes
On Apr 5, 2008, at 1:07 PM, IOhannes m zmoelnig wrote:
Martin Peach wrote:
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I am fine with leaving the string patch in this release as it is if it will be compatible with a generic approach to defining new atoms types. Can anyone speak to that?
does the patch still register the "string" keyword? (and in doing so breaks all other objects that use [string( without the string- atomtype?)
The latest version registers the "blob" keyword instead, but I think it is not necessary for it to register a name at all.
exactly! the entire keyword thing is rather a mess anyhow, and i don't think it should be mimicked anywhere. introducing a new atomtype should be enough.
Could either of you make any needed changes directly to the pd-0.40- extended branch? I am not sure I know what needs doing.
For the idea about naming them from LAC, was that just having a central place to claim macro numbers?
.hc
------------------------------------------------------------------------ ----
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
Hans-Christoph Steiner wrote:
Could either of you make any needed changes directly to the pd-0.40-extended branch? I am not sure I know what needs doing.
when do you want to release?
For the idea about naming them from LAC, was that just having a central place to claim macro numbers?
yes.
fngasd#r IOhannes
On Apr 6, 2008, at 4:10 AM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
Could either of you make any needed changes directly to the pd-0.40-extended branch? I am not sure I know what needs doing.
when do you want to release?
By the end of the month. Then we can work on 0.41...
.hc
For the idea about naming them from LAC, was that just having a central place to claim macro numbers?
yes.
fngasd#r IOhannes
------------------------------------------------------------------------ ----
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
On Sat, 5 Apr 2008, IOhannes m zmoelnig wrote:
exactly! the entire keyword thing is rather a mess anyhow, and i don't think it should be mimicked anywhere. introducing a new atomtype should be enough.
What happens to [t], [pack], [unpack], [route] with new atom types? why?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Martin Peach -
Mathieu Bouchard