Re: [PD] re . xml-rpc client

[Georg Holzmann]

Hallo!

> Thanks Georg . I saw this patch but it doesn't really have any explanation 
> associated with it that I can see.
> Also one would have to run another script in Python or something to make the 
> xml-rpc calls if I understand it correctly.

No, this is just an example in python...

> Is that correct? I was wondering if there was an external with the xml-rpc 
> library included to avoid having to use anything 
> along with PD. In the ideal case one would use only PD as the client and be 
> able to contact a remote xml-rpc server directly.

Yes, I think thats the idea - however, you have to replace the calls 
from the python example with the equivalent calls from your desired 
language - I'm sorry, I only used it in python so far, so I can't give 
an example ...

So maybe the best is to simply try to reprogram this python example in 
your language (if you have problems just post them) - then this could be 
also added as an example ...

LG
Georg

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Moveable Type - powered by Pd

[Kyle Klipowicz]

As a follow up, I just read a nice little comment toward the end of
this blog post by David Byrne:
http://journal.davidbyrne.com/2007/12/12062007-embedd.html

Congrats!

~Kyle

On Dec 5, 2007 11:18 PM, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote:
>
> It is running PDa 0.4 for sound and custom python to control the text:
>
> http://gige.xdv.org/pda/
>
> it uses these boards:
>
> http://www.embeddedarm.com/epc/ts7250-spec-h.html
>
> It uses this distro of linux:
>
> http://www.embeddedarm.com/linux/main.htm
>
> We are currently writing a paper about it for a conference, which we
> hope will be published.  It will cover the whole thing in more
> technical detail.
>
> .hc
>
>
> On Dec 5, 2007, at 9:59 PM, palmieri, ricardo wrote:
>
> > hi hans.
> >
> > this screens is  a comercial product, or a special project?
> > do u have more info about it?
> >
> > ah
> > is alex posada in the earstudio moveable type album?
> >
> > hasta.
> >
> > palmieri
> >
> > 2007/12/5, Hans-Christoph Steiner <[EMAIL PROTECTED]>:
> >>
> >> In case anyone is interested, there is now a newspaper article with a
> >> video about this piece:
> >>
> >> http://www.nytimes.com/2007/10/25/arts/design/25vide.html
> >>
> >> .hc
> >>
> >> On Nov 16, 2007, at 4:24 PM, Hans-Christoph Steiner wrote:
> >>
> >>>
> >>> If any of you happens to be in New York City, drop by the lobby of
> >>> the new New York Times building.  It's open to the public, and
> >>> there is a great installation there.  The sound is all powered by
> >>> Pd and the text handling and sequencing was done with Python.
> >>>
> >>> http://earstudio.com/projects/moveable_type.html
> >>>
> >>> Moveable Type
> >>> Mark Hansen and Ben Rubin
> >>> (in progress, to be completed in fall, 2007)
> >>>
> >>> "Moveable Type, by New York artist Ben Rubin and U.C.L.A. associate
> >>> professor Mark Hansen, is an artwork commissioned for the ground-
> >>> floor lobby of The New York Times Building in New York City. When
> >>> complete, it will be a dynamic portrait of The Times. Statistical
> >>> methods and natural-language processing algorithms will be used to
> >>> parse the daily output of the paper (news, features, editorials)
> >>> and the archives, as well as the activity of visitors to
> >>> NYTimes.com (browsing, searching, commenting). The resulting
> >>> refracted view of The Times will be displayed on 560 vacuum-
> >>> fluorescent display screens installed in the lobby."
> >>>
> >>> I'll post more on this when I get it, like video would be nice...
> >>>
> >>> .hc
> >>>
> >>> 
> >>> --
> >>> --
> >>>
> >>>   ¡El pueblo unido jamás será vencido!
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
> >> -
> >> ---
> >> 
> >>
> >> '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
> >>
> >
> >
> > --
> > ricardo palmieri
> > # 1185833173
> > [palm.estudiolivre.org]
> > [skype:palmieriricardo]
> > [jabber: [EMAIL PROTECTED]
> > [msn: [EMAIL PROTECTED]
> > [linux user # 392484]
>
>
>
> 
> 
>
> Looking at things from a more basic level, you can come up with a
> more direct solution... It may sound small in theory, but it in
> practice, it can change entire economies. - Amy Smith
>
>
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>



-- 
-

 -
  - --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] re . xml-rpc client

[jim ruxton]

Hallo!

>> Thanks I looked at that but it wasn't clear to me how I could connect to
>> an external server such as
>> http://xmlrpc-c.sourceforge.net/api.sample.php with this. Do I need to
>> run a python script along with the patch? Is there a help file some
>> where?

>Well, there is an help pach: look in /externals/iem/iemxmlrpc
>  (I think not a help patch, but an example patch).
> And you should be able to use that with any other language than python ...

>LG
>Georg

Thanks Georg . I saw this patch but it doesn't really have any explanation 
associated with it that I can see.
Also one would have to run another script in Python or something to make the 
xml-rpc calls if I understand it correctly.
Is that correct? I was wondering if there was an external with the xml-rpc 
library included to avoid having to use anything 
along with PD. In the ideal case one would use only PD as the client and be 
able to contact a remote xml-rpc server directly.
I guess this isn't currently available or perhaps I just don't understand 
iemxmlrpc?
Thanks,
Jim

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Is it possible to rotate particles?

[PSPunch]

Marius,

Added one extra array to your patch and I've achieved
pretty much all I needed. thanks! sample attached.

Thank god the IDs don't continue to increment..
Preparing a 'round robin' table for this could've made
things a lot more messy.


--
David Shimamoto


You want to use part_info for that. and it depends on what you want to 
relate the rotation to... if you just relate it to age or position or 
ID, then it is easy, but if you want a different random rotation speed 
for each particle, that's more difficult. I only can think of using a 
table for that, but I am not so sure, if this would be fast... and then 
use a combination of ID and everytime when the age is 1 write new 
values. I attach a patch that does this, but I think you probably don't 
need to do it so complicated.

marius.

PSPunch wrote:

Hi all,


Taking a break from audio processing for a while, I am lately
appreciating playing around with GEM.

I was wondering if there is an object that can add random rotation to
each particle, or whither this was possible at all.
I am imagining that the program internally contains the location and
vector of each particle. If there is no array tracking the rotation (and
maybe a rotation vector) of each particle, perhaps this is not possible
easily.

My initial goal is to render the particles as geos and have each
rotate at different speeds.

Any ideas appreciated.
Thanks.


--
David Shimamoto

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list








part_rotate2.pd
Description: application/puredata
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] hardcore nerd question

[Uğur Güney]

# I hardly remember a story of Isaac Asimov in which he says that if such a
device exists there can not be any privacy. Every conversation could be
listened to by other one. But I think Asimov's device is related to visuals
too, but the idea is similar...
-ugur-

On Dec 11, 2007 3:47 PM, Andy Farnell <[EMAIL PROTECTED]> wrote:

>
>
> In a sci-fi story I once read, an inventor creates a device that can
> listen
> into the past by recovering long passed conversations from the thermal
> heat
> in a building.
>
> The author has totally slipped my mind. Does anyone remember this story
> and who wrote it?
>
> Cheers,
>
> Andy
>
> --
> Use the source
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Is it possible to rotate particles?

[marius schebella]

You want to use part_info for that. and it depends on what you want to 
relate the rotation to... if you just relate it to age or position or 
ID, then it is easy, but if you want a different random rotation speed 
for each particle, that's more difficult. I only can think of using a 
table for that, but I am not so sure, if this would be fast... and then 
use a combination of ID and everytime when the age is 1 write new 
values. I attach a patch that does this, but I think you probably don't 
need to do it so complicated.

marius.

PSPunch wrote:

Hi all,


Taking a break from audio processing for a while, I am lately
appreciating playing around with GEM.

I was wondering if there is an object that can add random rotation to
each particle, or whither this was possible at all.
I am imagining that the program internally contains the location and
vector of each particle. If there is no array tracking the rotation (and
maybe a rotation vector) of each particle, perhaps this is not possible
easily.

My initial goal is to render the particles as geos and have each
rotate at different speeds.

Any ideas appreciated.
Thanks.


--
David Shimamoto

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list



#N canvas 597 62 611 571 10;
#X msg 35 70 create;
#X msg 60 90 destroy;
#X obj 169 18 gemhead;
#X obj 168 85 part_head;
#X msg 88 116 1;
#X msg 96 142 0;
#X text 278 259 set the number per frame;
#X text 333 280 set the age to kill at;
#X msg 290 201 0 0.2 0 0.3;
#X msg 377 200 0.2 0 0 0.3;
#N canvas 87 154 247 179 Gem.init 0;
#X msg 118 81 reset;
#X obj 118 113 outlet;
#X obj 118 48 t b b;
#X obj 116 18 loadbang;
#X connect 0 0 1 0;
#X connect 2 1 0 0;
#X connect 3 0 2 0;
#X restore 66 194 pd Gem.init;
#X obj 168 132 part_size 1;
#X obj 168 254 part_source 5;
#X obj 169 382 separator;
#X obj 169 408 translate 1 0 0 0;
#X obj 169 431 color;
#X obj 169 471 scale;
#X msg 278 518 draw line;
#X msg 257 105 2;
#X obj 170 502 rotateXYZ;
#X text 375 400 this is rather velocity;
#X text 379 416 than rotation;
#X obj 279 498 loadbang;
#X obj 170 537 square 0.2;
#X msg 263 380 \$1 \$2 0;
#X obj 169 56 rotateXYZ;
#X obj 168 205 part_color;
#X msg 200 180 1 0 0;
#X msg 252 180 0 0 1;
#X text 254 362 we don't allow particles spread along the z-axis;
#X msg 257 76 1;
#X obj 168 306 part_info;
#X obj 29 443 tabwrite asdf;
#X obj 53 468 tabread asdf;
#X obj 29 416 random 360;
#X obj 29 340 swap;
#X obj 35 217 gemwin 50;
#X obj 168 229 part_velocity sphere 0 0.1 0 0.1;
#X obj 168 279 part_killold 100;
#X obj 38 493 table asdf 500;
#X obj 29 369 <= 1;
#X obj 29 393 sel 1;
#X connect 0 0 36 0;
#X connect 1 0 36 0;
#X connect 2 0 25 0;
#X connect 3 0 11 0;
#X connect 4 0 36 0;
#X connect 5 0 36 0;
#X connect 8 0 37 2;
#X connect 9 0 37 2;
#X connect 10 0 36 0;
#X connect 11 0 26 0;
#X connect 12 0 38 0;
#X connect 13 0 14 0;
#X connect 14 0 15 0;
#X connect 15 0 16 0;
#X connect 16 0 19 0;
#X connect 17 0 23 0;
#X connect 18 0 11 1;
#X connect 19 0 23 0;
#X connect 22 0 17 0;
#X connect 24 0 14 2;
#X connect 25 0 3 0;
#X connect 26 0 37 0;
#X connect 27 0 26 1;
#X connect 28 0 26 2;
#X connect 30 0 11 1;
#X connect 31 0 13 0;
#X connect 31 1 33 0;
#X connect 31 1 35 0;
#X connect 31 2 24 0;
#X connect 31 3 15 1;
#X connect 31 5 16 1;
#X connect 31 6 35 1;
#X connect 33 0 19 3;
#X connect 34 0 32 0;
#X connect 35 0 40 0;
#X connect 35 1 32 1;
#X connect 37 0 12 0;
#X connect 38 0 31 0;
#X connect 40 0 41 0;
#X connect 41 0 34 0;
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Is it possible to rotate particles?

[PSPunch]

Hi all,


Taking a break from audio processing for a while, I am lately
appreciating playing around with GEM.

I was wondering if there is an object that can add random rotation to
each particle, or whither this was possible at all.
I am imagining that the program internally contains the location and
vector of each particle. If there is no array tracking the rotation (and
maybe a rotation vector) of each particle, perhaps this is not possible
easily.

My initial goal is to render the particles as geos and have each
rotate at different speeds.

Any ideas appreciated.
Thanks.


--
David Shimamoto

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] symbolatom: why does it not allow to type spaces?

[Chris McCormick]

On Mon, Dec 10, 2007 at 09:25:56PM +0100, Roman Haefeli wrote:
> before i change my policy about using externals in netpd, i would like
> to ask (probably miller?), if there is a chance, that symbolatom is
> changed accordingly in the future?

When I asked about spaces in symbols on the pd-dev list Miller's reply
was: "1. spaces in symbols are a parsing/formatting problem, not a data
type problem." So that would indicate that he sees it as a problem that
must be fixed. Be good if someone could submit a nice clean patch to
fix the parsing problem and see if he accepts it.

Another similar reply to the issue of symbol table saturation was "2. use
arrays as strings as I proposed;" which isn't currently possible in your
use-case because the symbol input box itself won't let you input spaces
to even get them into an array.

Best,

Chris.

---
http://mccormick.cx

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Hans-Christoph Steiner]

What we really need is regression testing, I think that would make it  
easier to convince Miller to accept patches, and would be a great  
tool for finding bugs.  Matju started that project, any word on that  
Matju?  I'd love to see that in action. :D

.hc

On Dec 10, 2007, at 5:33 PM, Martin Peach wrote:

> It probably would end up in vanilla if there was a demand for it,  
> although Miller doesn't seem to like the idea, needs more  
> convincing ;)
>
> Martin
>
> Mike McGonagle wrote:
>> To: "Martin Peach" <[EMAIL PROTECTED]>
>> CC: pd-list@iem.at
>> Subject: Re: [PD] [psql] object hand-holding
>> Date: Mon, 10 Dec 2007 14:17:20 -0600
>>
>> Is this something that is part of PD Vanilla? I would like to be  
>> able to
>> have this external running there.
>> Thanks,
>>
>> Mike
>>
>>
>> On 12/10/07, Martin Peach <[EMAIL PROTECTED]> wrote:
>> >
>> > If you have applied the "add string support" patch you can use  
>> the blob
>> > atom, which is essentially a pointer to, and the length of, a  
>> binary
>> > string.
>> > The string can be anything at all.
>> >
>> > Martin
>> >
>> >
>> > Mike McGonagle wrote:
>> > >To: pd-list@iem.at
>> > >Subject: Re: [PD] [psql] object hand-holding
>> > >Date: Mon, 10 Dec 2007 13:29:16 -0600
>> > >
>> > >On a different note, has anyone given any thought to handling  
>> Blobs? I
>> > know
>> > >that in SQLite, they store the data as binary strings, but I am  
>> not quite
>> > >certain how the external would handle the actual data going  
>> into and
>> > coming
>> > >out of it.
>> > >Mike
>> >
>> >
>> > >___
>> > >PD-list@iem.at mailing list
>> > >UNSUBSCRIBE and account-management ->
>> > >http://lists.puredata.info/listinfo/pd-list
>> >
>> >
>> >
>>
>>
>> --
>> Peace may sound simple—one beautiful word— but it requires  
>> everything we
>> have, every quality, every strength, every dream, every high ideal.
>> —Yehudi Menuhin (1916–1999), musician
>
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list




 


All mankind is of one author, and is one volume; when one man dies,  
one chapter is not torn out of the book, but translated into a better  
language; and every chapter must be so translated -John Donne



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] symbolatom: why does it not allow to type spaces?

[Hans-Christoph Steiner]

On Dec 10, 2007, at 6:48 PM, Roman Haefeli wrote:

> On Mon, 2007-12-10 at 16:34 -0500, Mathieu Bouchard wrote:
>> On Mon, 10 Dec 2007, Roman Haefeli wrote:
>>  (or am i
>>> overseeing something?).
>>
>> It would only break externals that rely on lack of spaces in any  
>> way, and
>> only if supposing that you weren't already using some other way of
>> producing the spaces.
>>
>> about spaces, those that break are: [netsend], [print],  
>> [textfile], ...
>> anything using atom_string().
>
> ah, yes i am overseeing. thank you for mentioning them. to be added:
> labels in iemguis, when saved.
>
> but these are things that already would break now and it is  
> possible to
> create symbols containing spaces in pd, it's just not as easy as just
> using a symbolbox. fact is, that people do it anyway, so why trying to
> prevent them?
>
> i didn't know that [print] would be affected. in what way is it
> affected? at least visually it doesn't seem to be.
>
> i encounter that ' ' is treated in a non-comprehensibly special way,
> since other characters such as ';' or ',' are escaped by symbolatom  
> (or
> by pd, i don't know) and can be used, atltough they have a meaning  
> in pd
> as well (like 'space' has). wouldn't it be more consistent, if ' ',  
> ','
> and ';' would be treated the same way?

A simple fix for allowing spaces is making the label be based on a  
list rather than a symbol.  This is what I am doing tkwidgets.  But  
for the iemguis, I'm not sure it would work since it might break  
backwards compatibility.

.hc



>
> roman
>
>
>
>   
> ___
> Telefonate ohne weitere Kosten vom PC zum PC: http:// 
> messenger.yahoo.de
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



 


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



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: [psql] object hand-holding

[Mike McGonagle]

On 12/10/07, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote:
>
> Cool, that sounds like a good idea.  I probably got it from you. :)  Maybe
> you are already doing this, but a query could also send a message out of the
> status outlet to say how many results were found (i.e. [results 5().  This
> number could be routed to trigger an [until] or other such behaviors.
>  (using the completion bang to stop [until] probably makes more sense
> though).
>


I could be wrong on other databases, but sqlite doesn't return the count of
the number of result sets found. And as far as using an [until] object, you
could still hook up the bang sent out the status outlet to the until so that
it would shut it down when needed.

Mike
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] hardcore nerd question

[Andy Farnell]

In a sci-fi story I once read, an inventor creates a device that can listen
into the past by recovering long passed conversations from the thermal heat
in a building. 

The author has totally slipped my mind. Does anyone remember this story
and who wrote it?

Cheers,

Andy

-- 
Use the source

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] RIP Stockhausen

[beau]

He'll be missed, but the music will live on:
http://flickr.com/photos/cypod/2094889566/


On Dec 11, 2007 5:15 AM, Andy Farnell <[EMAIL PROTECTED]> wrote:
>
> Siriusly though...
>
> I seem to recall Newton was something of an occultist.  Einstein
> and many other scientists share beliefs in supernatural entities.
> Does that really effect the value of their work?
>
> By all accounts Stockhausen was an arrogant man, which perhaps
> explains his clumbsy explanations due to unwillingness to research
> and study others.
>
> But, whatever you think of the man and his ravings, the work stands
> on its merits because it confirms hypotheses and has predictive utility.
> That makes it science. Probably more so than Art imho.
>
> What kinda makes him great, but also a bit sad, is what he achieved was
> in isolation, like many who fall into the cracks between the pillars
> of established thought.
>
> andy
>
>
>
>
>
>
> On Mon, 10 Dec 2007 22:41:32 +0100
> Yvan Vander Sanden <[EMAIL PROTECTED]> wrote:
>
>
> > Andy Farnell wrote:
> > > Of course he will always be remembered as an avant garde composer,
> > > but much of Stockhausens greatness is missed by artists who saw him as
> > > a pseudo-scientist and scientists who dismissed him as an artist.
> > > He was both at different times. A lack of rigor and precise voclabulary
> > > hides his contribution to psychoacoustics, he basically provided
> > > experimental support to Gabors theories, yet he is not mentioned once
> > > in critcal textbooks like McAdams and Bigand.
> > >
> > And of coruse we must not forget he came from sirius to explain us all
> > that :-)
> >
> > ___
> > PD-list@iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > http://lists.puredata.info/listinfo/pd-list
>
>
> --
> Use the source
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] RIP Stockhausen

[Andy Farnell]

Siriusly though...

I seem to recall Newton was something of an occultist.  Einstein
and many other scientists share beliefs in supernatural entities. 
Does that really effect the value of their work?

By all accounts Stockhausen was an arrogant man, which perhaps
explains his clumbsy explanations due to unwillingness to research
and study others.

But, whatever you think of the man and his ravings, the work stands
on its merits because it confirms hypotheses and has predictive utility.
That makes it science. Probably more so than Art imho.

What kinda makes him great, but also a bit sad, is what he achieved was
in isolation, like many who fall into the cracks between the pillars
of established thought.

andy






On Mon, 10 Dec 2007 22:41:32 +0100
Yvan Vander Sanden <[EMAIL PROTECTED]> wrote:

> Andy Farnell wrote:
> > Of course he will always be remembered as an avant garde composer,
> > but much of Stockhausens greatness is missed by artists who saw him as
> > a pseudo-scientist and scientists who dismissed him as an artist.
> > He was both at different times. A lack of rigor and precise voclabulary
> > hides his contribution to psychoacoustics, he basically provided
> > experimental support to Gabors theories, yet he is not mentioned once
> > in critcal textbooks like McAdams and Bigand.
> >   
> And of coruse we must not forget he came from sirius to explain us all 
> that :-)
> 
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list


-- 
Use the source

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] symbolatom: why does it not allow to type spaces?

[Roman Haefeli]

On Mon, 2007-12-10 at 16:34 -0500, Mathieu Bouchard wrote:
> On Mon, 10 Dec 2007, Roman Haefeli wrote:
>  (or am i
> > overseeing something?).
> 
> It would only break externals that rely on lack of spaces in any way, and 
> only if supposing that you weren't already using some other way of 
> producing the spaces.
> 
> about spaces, those that break are: [netsend], [print], [textfile], ... 
> anything using atom_string().

ah, yes i am overseeing. thank you for mentioning them. to be added:
labels in iemguis, when saved.

but these are things that already would break now and it is possible to
create symbols containing spaces in pd, it's just not as easy as just
using a symbolbox. fact is, that people do it anyway, so why trying to
prevent them?

i didn't know that [print] would be affected. in what way is it
affected? at least visually it doesn't seem to be.

i encounter that ' ' is treated in a non-comprehensibly special way,
since other characters such as ';' or ',' are escaped by symbolatom (or
by pd, i don't know) and can be used, atltough they have a meaning in pd
as well (like 'space' has). wouldn't it be more consistent, if ' ', ','
and ';' would be treated the same way?

roman




___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Hans-Christoph Steiner]

On Dec 10, 2007, at 2:19 PM, Mike McGonagle wrote:




On 12/10/07, Jamie Bullock <[EMAIL PROTECTED]> wrote:
PREPARE uses the '$' character as its placeholder identifier, and '$1'

Jamie, after thinking about this, I don't think we should worry  
about the specifics of the characters that we use, as long as we  
can agree on what gets entered into a PD message box, the specific  
instance of the external ('sqlite', 'psql', etc.) can handle the  
conversion to what the specific database uses.


From what I have seen on this thread, is it right that the '?'  
syntax does NOT have an identifier following it? I think it would  
be very helpful if we use identifiers in the SQL if only to make  
the binding to the proper datatypes easier, as per my last email.


It seems many things use the "?" alone as the unnamed placeholder,  
but I only saw MySQL using ?name for named placeholders.  It does  
seem like a nicer syntax rather than using a different character.   
Perhaps, we should follow pgsql and use "$" and "$name", since "$" is  
already a marker for replacement vars in Pd.  I suppose that could  
get confusing in something like:


SELECT id, ABS(($duration - $1)/$2) AS error FROM datatable ORDER BY  
error LIMIT 1


.hc




Mike

--
Peace may sound simple—one beautiful word— but it requires  
everything we have, every quality, every strength, every dream,  
every high ideal.

—Yehudi Menuhin (1916–1999), musician
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
listinfo/pd-list




 



If nature has made any one thing less susceptible than all others of  
exclusive property, it is the action of the thinking power called an  
idea, which an individual may exclusively possess as long as he keeps  
it to himself; but the moment it is divulged, it forces itself into  
the possession of everyone, and the receiver cannot dispossess  
himself of it.- Thomas Jefferson



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: [psql] object hand-holding

[Hans-Christoph Steiner]

On Dec 10, 2007, at 3:57 PM, Mike McGonagle wrote:




On 12/10/07, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote:
(What is the "hold" inlet, by the way?)


It's a hot inlet that has been misspelled...

It would be really nice to be able to have inlets for the sql  
placeholders, but I couldn't think of a clean way to do it.  We  
could try the dynamic allocation like you say here, I don't know if  
I have a specific objection to it, but it could get weird.  Since  
the SQL inlet has to be cold to support the comma hack, then these  
dynamic inlets  shouldn't be hot since they are the right of a cold  
inlet.   But that's not a big deal.



And if you want placeholders to have inlets, then we are back to  
putting the SQL into the object creation arguments, like:


[sqlite insert into table (id, name) values (:id, :name)]

While I don't think it is a bad idea, it does restrict a particular  
instance of a database object to only a single type of message, and  
it would have to be done at creation time of the object.


Should we allow both methods of entering SQL? One done at creation  
time, the other one done on the fly?


Also, I don't know if any objects do this kind of dynamic inlet  
creation after the object itself has been instantiated.  It might  
not even be possible.  I figure that you can easily make a subpatch  
or abstraction around the SQL message generation, then manage the  
inlets there.  Perhaps not ideal, but it's not difficult to do and  
follows existing practice.



I would think that an object having the ability to change its  
inlets on the fly would NOT be possible, as the inlets may change  
so much, as to lose a connection when it is recreated.


OR, could we possibly do something like this

[sqlite :id(f) :name(s)]

Which would create an instance with 4 inlets, the first 'hot' inlet  
would accept all the control messages, the next (x number) would  
represent the bound inlets for the placeholders, and the last would  
be the inlet for the incoming SQL statement. Would it be an error  
if the incoming SQL statement didn't have the same placeholders  
defined in it? Or should it be allowed to operate as any other?


This kind of thing could be done in a separate "query" object, like  
what's included in the "sqlwrappers", and [sqlite]/[psql] would still  
represent the database itself.  Having the objects structured this  
way means that Matju could write his [expr] SQL query too, and they  
would work with the different SQL database objects (sqlite, psql,  
mysql).


As for the SQL binding, I was thinking it would happen inside of  
the object, binding the placeholder names to the selectors.  As  
long as there wasn't any new input on the SQL inlet, then the SQL  
statement wouldn't need to be recompiled.



My thought too...

Another question I just thought of it how to handle returning  
multiple results from s single query.  If it followed the  
[textfile] style, then you would have to bang to get each  
individual result, then keep banging until you get a bang on the  
status/second outlet, meaning the query was done.  I think this  
could work.


This is already what I have been doing. Basically, as we are  
working now, the SQL would get input on the right inlet, then if  
any binding were needed, that would be done, and when the next bang  
occurs, the query is submitted, and the first result set is  
returned. Any subsequent bang would return the next result set. And  
when the result sets have been exhausted, it would send a bang out  
the "status" outlet to indicate the sets are done.


Cool, that sounds like a good idea.  I probably got it from you. :)   
Maybe you are already doing this, but a query could also send a  
message out of the status outlet to say how many results were found  
(i.e. [results 5().  This number could be routed to trigger an  
[until] or other such behaviors.  (using the completion bang to stop  
[until] probably makes more sense though).


.hc




Mike

.hc

-- 
--


There is no way to peace, peace is the way.   - A.J. Muste






--
Peace may sound simple—one beautiful word— but it requires  
everything we have, every quality, every strength, every dream,  
every high ideal.

—Yehudi Menuhin (1916–1999), musician




 



"[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] RIP Stockhausen

[Andy Farnell]

On Mon, 10 Dec 2007 22:41:32 +0100
Yvan Vander Sanden <[EMAIL PROTECTED]> wrote:

  
> And of coruse we must not forget he came from sirius to explain us all 
> that :-)

No way? A or B? I can't stand those wankers from Sirius B with their "our 
star's brighter
than yours" crap. Or was he a scientologist, where do they come from again?

> 
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list


-- 
Use the source

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Hans-Christoph Steiner]

On Dec 10, 2007, at 2:55 PM, Mathieu Bouchard wrote:

> On Mon, 10 Dec 2007, Jamie Bullock wrote:
>> On Mon, 2007-12-10 at 12:18 -0500, Mathieu Bouchard wrote:
>>> This almost *never* happens.
>> I take your point, but I think you are exaggerating slightly.
>
> Not in this context. We're only looking at the average query; I  
> don't even mean an actual query, but statistics about queries. If  
> only 10% of them don't have arguments, then unless there's a huge  
> difference in object count (which there is not), it doesn't make  
> much of a difference on the total object count. And that is only  
> supposing that you need something like an extra [bang] before your  
> sql query to prevent [psql] from getting non-bang messages.
>
>> I just looked at the code for a database driven web app I worked  
>> on recently. It uses 30 queries, 3 of which have no variables. Out  
>> of these three only one doesn't 'overlap' with other queries and  
>> therefore can't be refactored. Maybe 1 in 30 is almost never?
>
> Yes. to contrast this, 3% wouldn't be "almost never" if, for  
> example, the issue was whether to support something at all, or not.  
> In that case, if the cost of a workaround is 50x the wanted  
> feature, or if a workaround is impossible, it can weigh a lot in  
> the design priorities.
>
>> Good point! I think Hans' recent suggestion addresses the problem. It
>> also occurs to me that for Postgres at least, we have the PREPARE
>> statement, which addresses the optimisation and injection issues you
>> have raised. Technically [psql] already supports PREPARE except that
>> PREPARE uses the '$' character as its placeholder identifier, and  
>> '$1'
>> can't be passed around as a symbol in Pd. I think it might be
>> interesting to use the '?' notation currently under discussion as an
>> interface to PREPARE though.
>
> The '?' notation is either MySQL-specific or PerlDBI-specific or  
> both. By PerlDBI I mean any database interface (in any language)  
> following's Perl DBI package closely enough. I guess that if you  
> use DBI-over-Postgres, then it replaces all ? by $ automatically.

The other somewhat common style that I saw in my searches was printf  
patterns (%s, %f, etc).  In Pd, [makefilename], [makesymbol],  
[sprintf], and perhaps others use this syntax.  The single ? notation  
seems to be supported by at least these, if you want to call that  
"specific":  Qt, PerlDBI, Perl's DBD::Pg, RubyDBI, PHP PDO, Java  
JDBC, MySQL, Oracle.

I think it is quite important to reuse existing syntax rather than  
introducing new syntax.  Minimal syntax is really one of Pd's biggest  
strengths.  Since these lines would be pure SQL, I think it would be  
appropriate to use a common SQL syntax.

I just had a thought, SQL injection relies on being able to send semi- 
colons in text fields.  You can't transmit a semicolon in a message  
in Pd, and if you don't provide a means to explicitly send a semi- 
colon to the query (e.g. [addsemi( to the hot inlet), then no one  
will ever be able to send a semi-colon to [sqlite]/[psql]. Pd would  
always interpret the semi-colon before the object received it on its  
cold inlet.  AFAIK, that eliminates basically all of the really bad  
SQL injection attacks.

.hc

>
> $ alone can be used in pd as long as it is not followed by a digit,  
> but I wouldn't encourage that, if it's not used in a [expr] way,  
> because the use of '$' alone would prevent you from later  
> supporting an [expr] syntax in a way compatible with yourself.
>
> Using $f1 or $s1 in [expr] style, or perhaps $e1 to mean "any  
> atom" (e stands for "element"), would be useful, though less  
> required than the placeholder feature itself.
>
>  _ _ __ ___ _  _ _ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC  
> Canada___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



 


   http://at.or.at/hans/



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Hans-Christoph Steiner]

On Dec 10, 2007, at 3:30 PM, Mike McGonagle wrote:




On 12/10/07, Mathieu Bouchard <[EMAIL PROTECTED]> wrote:
But it requires multiple logins, perhaps many at once, which might be
wasteful. For sharing database connections between several [psql]
objects, what do you think would be the best ways to do it? This is
supposing that several different database connections can still be
used at once, as specified in the patches.

In one of the early prototypes I wrote for this, I set it up so  
that the connections were shared. Basically, when an object tried  
to open a connection, it would check if there was already one open,  
and if so, it would use that. Else it would create a new  
connection, which would then get stored in the global connection  
object.


One thing that I would be curious about would be any collisions in  
using a shared object, but I also think that should be something  
left to think about in building the PD patch.


It is useful to represent the pieces in Pd space, so you can  
understand what's going on.  That's one reason why I advocate having  
the core object represent the connection to the database rather than  
a query.  Otherwise, it's starts to become more like Max/MSP's mega- 
objects (coll, zl, etc) that are really like mini-applications than  
programming.


There still can be query objects, they would just be designed to feed  
to the core database objects.  These query objects would then be  
usable if we maintain the same interface.


.hc


 



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] [psql] object hand-holding

[Martin Peach]

It probably would end up in vanilla if there was a demand for it, although 
Miller doesn't seem to like the idea, needs more convincing ;)


Martin

Mike McGonagle wrote:

To: "Martin Peach" <[EMAIL PROTECTED]>
CC: pd-list@iem.at
Subject: Re: [PD] [psql] object hand-holding
Date: Mon, 10 Dec 2007 14:17:20 -0600

Is this something that is part of PD Vanilla? I would like to be able to
have this external running there.
Thanks,

Mike


On 12/10/07, Martin Peach <[EMAIL PROTECTED]> wrote:
>
> If you have applied the "add string support" patch you can use the blob
> atom, which is essentially a pointer to, and the length of, a binary
> string.
> The string can be anything at all.
>
> Martin
>
>
> Mike McGonagle wrote:
> >To: pd-list@iem.at
> >Subject: Re: [PD] [psql] object hand-holding
> >Date: Mon, 10 Dec 2007 13:29:16 -0600
> >
> >On a different note, has anyone given any thought to handling Blobs? I
> know
> >that in SQLite, they store the data as binary strings, but I am not 
quite

> >certain how the external would handle the actual data going into and
> coming
> >out of it.
> >Mike
>
>
> >___
> >PD-list@iem.at mailing list
> >UNSUBSCRIBE and account-management ->
> >http://lists.puredata.info/listinfo/pd-list
>
>
>


--
Peace may sound simple—one beautiful word— but it requires everything we
have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician




___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] symbolatom: why does it not allow to type spaces?

[Hans-Christoph Steiner]

On Dec 10, 2007, at 3:25 PM, Roman Haefeli wrote:

>
> On Mon, 2007-12-10 at 15:03 -0500, Mathieu Bouchard wrote:
>
>>
>>print: symbol real\ people\ want\ to\ use\ spaces!
>
> definitely. the first question i hear from people using netpd/pd the
> first time is: 'how can i type spaces?' yet i decided to not add  
> another
> dependency for netpd just because of this rather silly restriction.  
> but
> since it seems, that the lack of spaces is really troubling users,  
> i am
> unsure, whether i should change that policy.

I think it would be awesome to have a real IRC or Jabber client in Pd  
and use it in netpd.  That's why I am writing the tkwidgets library,  
so that we can have nice, familiar, OS-native widgets in Pd.  netpd's  
chat would be a great test case for the new [entry], which isn't  
written yet, but wouldn't take long.  You could try [tkwidgets/text]  
it works pretty well now, and is quite customizable (there is still a  
couple bugs tho).

.hc

> since one can even open a file containing spaces in the path from  
> pd, it
> would actually make sense, if symbolatom would support that. i can't
> think of a case, where supporting spaces would break anything (or am i
> overseeing something?).
> before i change my policy about using externals in netpd, i would like
> to ask (probably miller?), if there is a chance, that symbolatom is
> changed accordingly in the future?
>
> roman
>
>
>
>
>   
> ___
> Telefonate ohne weitere Kosten vom PC zum PC: http:// 
> messenger.yahoo.de
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



 


I spent 33 years and four months in active military service and  
during that period I spent most of my time as a high class muscle man  
for Big Business, for Wall Street and the bankers.  - General  
Smedley Butler



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] RIP Stockhausen

[Yvan Vander Sanden]

Andy Farnell wrote:
> Of course he will always be remembered as an avant garde composer,
> but much of Stockhausens greatness is missed by artists who saw him as
> a pseudo-scientist and scientists who dismissed him as an artist.
> He was both at different times. A lack of rigor and precise voclabulary
> hides his contribution to psychoacoustics, he basically provided
> experimental support to Gabors theories, yet he is not mentioned once
> in critcal textbooks like McAdams and Bigand.
>   
And of coruse we must not forget he came from sirius to explain us all 
that :-)

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: [psql] object hand-holding

[Mathieu Bouchard]

On Mon, 10 Dec 2007, Hans-Christoph Steiner wrote:

Also, I don't know if any objects do this kind of dynamic inlet creation 
after the object itself has been instantiated.  It might not even be 
possible.


It's possible, and I've done it, except for the bit of disconnecting every 
wire connecting to deleted inlets. I think that it's just 2 more lines of 
code, but I haven't tried, especially as we don't have any use for it 
anymore, as we are replacing LtiLib support by OpenCV support, which 
doesn't need that trick.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] array indirection

[Phil Stone]

A glorious hack, Jean-Yves!  This should work well for what I am
envisioning.  One strange thing, though:  if you move the subpatch (that
displays the selected array), the other array is visible underneath it.
I wonder what's up with that?

Thanks for the solution, Jean-Yves (and Chuck for suggesting it was
possible in the first place).


Phil

Chuckk Hubbard wrote:
> Well-done, that looks like the perfect solution.  I did notice these
> functions mentioned in the code, with xmargin and ymargin as arguments
> of a longer function call, but I hadn't followed up to see what else
> went in the message.
> I believe this is your answer, Phil.
>
> Another one for msg-docs, I think.
>
> -Chuckk
>
> On Dec 10, 2007 1:11 PM, Jean-Yves GRATIUS <[EMAIL PROTECTED]> wrote:
>   
>> Hi,
>>  I have tried to change graph-on-parents settings by message for displaying
>> different arrays, it seems to work..
>>  I did'nt test it with large tables.
>>  (included patch : switchingGOPtables.pd).
>>
>>  Jean Yves Gratius 
>>
>>
>>  Chuckk Hubbard a écrit :
>>
>>
>> On Dec 9, 2007 10:50 PM, Phil Stone <[EMAIL PROTECTED]> wrote:
>>
>> Hi Chuck,
>>
>>  I think you're right; there's no way to avoid the copying.  It's good to
>>  dream, though.  :-)
>>
>>  I have done some experimenting, and I think I'm on to something.  If
>>  you create a graph from the put menu, then right-click and select
>>  Open; and then Put an array on the opened subpatch, you can see the
>>  red outline where you can decide what will be graphed-on the parent
>>  graph.
>>
>>  It would not be too hard to send editmode and mouse movement messages
>>  to that canvas to move arrays around inside it; and it probably would
>>  actually be more efficient than copying.  But I also notice that the
>>  graph subpatch has, in its options, an x and y margin, which moves the
>>  red outline.  IF it's possible to change these values with messages,
>>  it could be trivial to move that red outline to cover several
>>  well-placed arrays, meaning that the graph would indeed switch arrays
>>  like you want.
>>  I started to look at the Pd code to see if I can find such a message
>>  mentioned; if I find it I'll let you know.
>>
>>  -Chuckk
>>
>>
>>
>>
>> Chuckk Hubbard wrote:
>>
>> It would be possible, if not CPU-efficient, to have them all hidden in
>>  table objects, and simply use tabread and tabwrite to copy them to the
>>  skeleton array when you want to switch.  You would only need one
>>  tabread and tabwrite pair, just different ways to specify the target
>>  of tabread.
>>  I would envision binding the tab key to page through them.
>>
>>  But it is possible to put several arrays in one graph which makes me
>>  wonder if there might even be a pure GUI way to do it.  Kind of makes
>>  me want to take a look...
>>
>>  -Chuckk
>>
>>  On Dec 8, 2007 10:26 PM, Phil Stone <[EMAIL PROTECTED]> wrote:
>>
>>
>> This probably fits into the category of a wish for PD; I think there's
>>  no way to do it currently, but I'd love to be proven wrong!
>>
>>  I'd like to be able to change the data an array points to rather than
>>  actually change the data in the array.  The scenario which me think of
>>  this is, I'd like to have a display of a currently-selected waveform
>>  (which could be one of many pre-allocated arrays).  It would be
>>  wonderful to have a level of indirection where the display-array can be
>>  given a new address [object reference?] to one of the various
>>  pre-allocated arrays, after which it redraws itself.
>>
>>  I suppose this unleashes all the evils of pointers (multiple references
>>  to memory, etc.), but it would a serious advantage, performance-wise,
>>  for the scenario I'm envisioning.
>>
>>  I also think it would be very cool if arrays could act as buttons...but
>>  that's a different subject.
>>
>>
>>  Phil Stone
>>  pkstonemusic.com
>> 


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Mathieu Bouchard]

On Mon, 10 Dec 2007, Mike McGonagle wrote:

In one of the early prototypes I wrote for this, I set it up so that the 
connections were shared. Basically, when an object tried to open a 
connection, it would check if there was already one open, and if so, it 
would use that. Else it would create a new connection, which would then 
get stored in the global connection object.


I think that the first argument of [psql] could be a receive-symbol, 
followed by the query itself. Then [psql] would not use the receive-symbol 
to send messages to, it would look at the receiver directly, checking that 
it's a [psql.connection] object, and then calling a function of that 
object directly, and get called back when a response is received. This is 
quite close to how [tabread] works except it inserts a [delay] before the 
result. It's how [tabread] would work if it were trying to access an array 
on another computer.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] symbolatom: why does it not allow to type spaces?

[Mathieu Bouchard]

On Mon, 10 Dec 2007, Roman Haefeli wrote:


since one can even open a file containing spaces in the path from pd, it
would actually make sense, if symbolatom would support that. i can't
think of a case, where supporting spaces would break anything (or am i
overseeing something?).


It would only break externals that rely on lack of spaces in any way, and 
only if supposing that you weren't already using some other way of 
producing the spaces.


about spaces, those that break are: [netsend], [print], [textfile], ... 
anything using atom_string().


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Hans-Christoph Steiner]

On Dec 10, 2007, at 1:42 PM, Jamie Bullock wrote:

>
> On Mon, 2007-12-10 at 12:18 -0500, Mathieu Bouchard wrote:
>
>>
>> This almost *never* happens. As long as what you do in Pd is regular
>> read-write activities involving tables that contain data that you  
>> only
>> want to see a small part of at a time, you need variable atoms in  
>> almost
>> any query:
>>
>>select person from attendance where chatroom=?
>>select chatroom from attendance where person=?
>>select * from users where user=?
>>select * from chatrooms where chatroom=?
>>
>> apps more likely to have invariable queries are apps that started  
>> small,
>> stayed small, and will never be expanded.
>
> I take your point, but I think you are exaggerating slightly. I just
> looked at the code for a database driven web app I worked on recently.
> It uses 30 queries, 3 of which have no variables. Out of these three
> only one doesn't 'overlap' with other queries and therefore can't be
> refactored. Maybe 1 in 30 is almost never? Anyhow - I agree that I
> probably can't argue the case for the [psql]-style of operation on the
> grounds of reduced object count :-|
>
>>> True, this is a good argument for the [expr]-style SQL object.  
>>> Although
>>> there may be other ways to provide some protection against injection
>>> like allowing the user to lock the number of statements in the  
>>> query.
>>
>> checking the number of statements is not enough: what about a  
>> value like:
>> (including quotes)
>>
>>'or'1
>>
>> put inside this statement:
>>
>>delete from users where username='$1'
>>
>> this query will delete the complete table.
>
> Good point! I think Hans' recent suggestion addresses the problem. It
> also occurs to me that for Postgres at least, we have the PREPARE
> statement, which addresses the optimisation and injection issues you
> have raised. Technically [psql] already supports PREPARE except that
> PREPARE uses the '$' character as its placeholder identifier, and '$1'
> can't be passed around as a symbol in Pd. I think it might be
> interesting to use the '?' notation currently under discussion as an
> interface to PREPARE though.

So PostgreSQL doesn't support placeholders in normal SQL queries?   
That's a bummer.  It seems that those languages that I sited chose  
the Oracle standard for placeholders (? and :name).  According to  
this, MySQL uses ?name and MS SQL Server uses @name.  MySQL can use  
@name if $old_syntax is turned on.  MySQL should use plain "?" but I  
don't know about MS SQL Server (who's really going to use that with  
Pd anyway ;)

http://forums.mysql.com/read.php?38,122041,122187#msg-122187

So the syntax seems to be less standard than I thought.  Man, SQL is  
a mess.

.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] [psql] object hand-holding

[Hans-Christoph Steiner]

On Dec 10, 2007, at 1:43 PM, Mike McGonagle wrote:




On 12/10/07, Mathieu Bouchard <[EMAIL PROTECTED]> wrote:
On Mon, 10 Dec 2007, Mike McGonagle wrote:

> Could someone please explain that IMPORTANCE of worrying about SQL
> injection? Just how would it effect users of PD?

We don't know what pd users will do with [psql]. Do you?


I guess what I am getting at is that I don't see how we can prevent  
people from using this maliciously. If they are creating the SQL  
and putting the data into it, how can we stop them from being  
idiots? Are you saying that we need to do data checking prior to  
the data being sent to the server? Or maybe I am not understanding  
what you are getting at...


Using the placeholder stuff will stop SQL injection attacks.  The  
interfaces we've discussed shouldn't make a difference in terms of  
security as long as the placeholder stuff is properly implemented.


.hc


 



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



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: [psql] object hand-holding

[Mike McGonagle]

On 12/10/07, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote:
>
> (What is the "hold" inlet, by the way?)
>


It's a hot inlet that has been misspelled...

It would be really nice to be able to have inlets for the sql placeholders,
> but I couldn't think of a clean way to do it.  We could try the dynamic
> allocation like you say here, I don't know if I have a specific objection to
> it, but it could get weird.  Since the SQL inlet has to be cold to support
> the comma hack, then these dynamic inlets  shouldn't be hot since they are
> the right of a cold inlet.   But that's not a big deal.
>


And if you want placeholders to have inlets, then we are back to putting the
SQL into the object creation arguments, like:

[sqlite insert into table (id, name) values (:id, :name)]

While I don't think it is a bad idea, it does restrict a particular instance
of a database object to only a single type of message, and it would have to
be done at creation time of the object.

Should we allow both methods of entering SQL? One done at creation time, the
other one done on the fly?

Also, I don't know if any objects do this kind of dynamic inlet creation
> after the object itself has been instantiated.  It might not even be
> possible.  I figure that you can easily make a subpatch or abstraction
> around the SQL message generation, then manage the inlets there.  Perhaps
> not ideal, but it's not difficult to do and follows existing practice.
>


I would think that an object having the ability to change its inlets on the
fly would NOT be possible, as the inlets may change so much, as to lose a
connection when it is recreated.

OR, could we possibly do something like this

[sqlite :id(f) :name(s)]

Which would create an instance with 4 inlets, the first 'hot' inlet would
accept all the control messages, the next (x number) would represent the
bound inlets for the placeholders, and the last would be the inlet for the
incoming SQL statement. Would it be an error if the incoming SQL statement
didn't have the same placeholders defined in it? Or should it be allowed to
operate as any other?

As for the SQL binding, I was thinking it would happen inside of the object,
> binding the placeholder names to the selectors.  As long as there wasn't any
> new input on the SQL inlet, then the SQL statement wouldn't need to be
> recompiled.
>


My thought too...

Another question I just thought of it how to handle returning multiple
> results from s single query.  If it followed the [textfile] style, then you
> would have to bang to get each individual result, then keep banging until
> you get a bang on the status/second outlet, meaning the query was done.  I
> think this could work.
>

This is already what I have been doing. Basically, as we are working now,
the SQL would get input on the right inlet, then if any binding were needed,
that would be done, and when the next bang occurs, the query is submitted,
and the first result set is returned. Any subsequent bang would return the
next result set. And when the result sets have been exhausted, it would send
a bang out the "status" outlet to indicate the sets are done.

Mike

.hc
>
>
> 
>
> There is no way to peace, peace is the way.   -A.J. Muste
>
>
>
>



-- 
Peace may sound simple—one beautiful word— but it requires everything we
have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: [psql] object hand-holding

[Mike McGonagle]

On 12/10/07, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote:
>
> (What is the "hold" inlet, by the way?)
>


It's a hot inlet that has been misspelled...

It would be really nice to be able to have inlets for the sql placeholders,
> but I couldn't think of a clean way to do it.  We could try the dynamic
> allocation like you say here, I don't know if I have a specific objection to
> it, but it could get weird.  Since the SQL inlet has to be cold to support
> the comma hack, then these dynamic inlets  shouldn't be hot since they are
> the right of a cold inlet.   But that's not a big deal.
>


And if you want placeholders to have inlets, then we are back to putting the
SQL into the object creation arguments, like:

[sqlite insert into table (id, name) values (:id, :name)]

While I don't think it is a bad idea, it does restrict a particular instance
of a database object to only a single type of message, and it would have to
be done at creation time of the object.

Should we allow both methods of entering SQL? One done at creation time, the
other one done on the fly?

Also, I don't know if any objects do this kind of dynamic inlet creation
> after the object itself has been instantiated.  It might not even be
> possible.  I figure that you can easily make a subpatch or abstraction
> around the SQL message generation, then manage the inlets there.  Perhaps
> not ideal, but it's not difficult to do and follows existing practice.
>


I would think that an object having the ability to change its inlets on the
fly would NOT be possible, as the inlets may change so much, as to lose a
connection when it is recreated.

OR, could we possibly do something like this

[sqlite :id(f) :name(s)]

Which would create an instance with 4 inlets, the first 'hot' inlet would
accept all the control messages, the next (x number) would represent the
bound inlets for the placeholders, and the last would be the inlet for the
incoming SQL statement. Would it be an error if the incoming SQL statement
didn't have the same placeholders defined in it? Or should it be allowed to
operate as any other?

As for the SQL binding, I was thinking it would happen inside of the object,
> binding the placeholder names to the selectors.  As long as there wasn't any
> new input on the SQL inlet, then the SQL statement wouldn't need to be
> recompiled.
>


My thought too...

Another question I just thought of it how to handle returning multiple
> results from s single query.  If it followed the [textfile] style, then you
> would have to bang to get each individual result, then keep banging until
> you get a bang on the status/second outlet, meaning the query was done.  I
> think this could work.
>

This is already what I have been doing. Basically, as we are working now,
the SQL would get input on the right inlet, then if any binding were needed,
that would be done, and when the next bang occurs, the query is submitted,
and the first result set is returned. Any subsequent bang would return the
next result set. And when the result sets have been exhausted, it would send
a bang out the "status" outlet to indicate the sets are done.

Mike

.hc
>
>
> 
>
> There is no way to peace, peace is the way.   -A.J. Muste
>
>
>
>



-- 
Peace may sound simple—one beautiful word— but it requires everything we
have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Hans-Christoph Steiner]

Very nice, thanks for making the example, I linked to it from the  
wiki page.


.hc

On Dec 10, 2007, at 11:30 AM, Mike McGonagle wrote:

Hans, I still have yet to learn about the WIKI stuff, but I posted  
a Inlet Proxy example on my page ( http://puredata.info/Members/ 
mjmogo ). I don't know if you want to just put a link, or move the  
file to the Proxy page you created, either way works for me.


Thanks,

Mike


On Dec 10, 2007 10:05 AM, Hans-Christoph Steiner < [EMAIL PROTECTED]>  
wrote:


On Dec 9, 2007, at 9:53 PM, Mathieu Bouchard wrote:

> On Sun, 9 Dec 2007, Mike McGonagle wrote:
>
>> Well, this is not something that is within reach of many people.
>> We need to understand not just PD's internals, but how flext uses
>> them, and we also need to know how to integrate these things with
>> the extended nightly builds. Not quite certain how many people
>> know ALL of these things. Probably only a handful, and it would
>> appear that none of them are interested in getting flext working.
>
> GridFlow also uses proxy inlets. There are simpler examples of
> proxy inlets within pd itself. E.g. all [list] objects have it.
>
> Basically you need to create another object that will be the
> "slave" of your main object, and then create an inlet that will use
> that object. The second argument of inlet_new is for that: the
> inlet appears on the first argument's box, but messages will be
> sent to the second argument's object. In that case you pass 0,0 for
> the other arguments (which are usually symbols, but here are null
> pointers to mean "not applicable")

I started a pdpedia page on the topic, please add anything useful:

http://wiki.puredata.info/en/proxy_objects

.hc


-- 
--



I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers.  - General
Smedley Butler





--
Peace may sound simple—one beautiful word— but it requires  
everything we have, every quality, every strength, every dream,  
every high ideal.

—Yehudi Menuhin (1916–1999), musician




 



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] [psql] object hand-holding

[Mike McGonagle]

On 12/10/07, Mathieu Bouchard <[EMAIL PROTECTED]> wrote:
>
> But it requires multiple logins, perhaps many at once, which might be
> wasteful. For sharing database connections between several [psql]
> objects, what do you think would be the best ways to do it? This is
> supposing that several different database connections can still be
> used at once, as specified in the patches.


In one of the early prototypes I wrote for this, I set it up so that the
connections were shared. Basically, when an object tried to open a
connection, it would check if there was already one open, and if so, it
would use that. Else it would create a new connection, which would then get
stored in the global connection object.

One thing that I would be curious about would be any collisions in using a
shared object, but I also think that should be something left to think about
in building the PD patch.


Mike


  _ _ __ ___ _  _ _ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada




-- 
Peace may sound simple—one beautiful word— but it requires everything we
have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: [psql] object hand-holding

[Hans-Christoph Steiner]

On Dec 10, 2007, at 2:07 PM, Mike McGonagle wrote:




-- Forwarded message --
From: Mike McGonagle <[EMAIL PROTECTED]>
Date: Dec 10, 2007 1:07 PM
Subject: Re: [PD] [psql] object hand-holding
To: [EMAIL PROTECTED]



On 12/10/07, Jamie Bullock <[EMAIL PROTECTED]> wrote:
Good point! I think Hans' recent suggestion addresses the problem. It
also occurs to me that for Postgres at least, we have the PREPARE
statement, which addresses the optimisation and injection issues you
have raised. Technically [psql] already supports PREPARE except that
PREPARE uses the '$' character as its placeholder identifier, and '$1'
can't be passed around as a symbol in Pd. I think it might be
interesting to use the '?' notation currently under discussion as an
interface to PREPARE though.


One of the things that I have been reading on this is that when you  
use these 'pre-complied' SQL statements, you need to 'bind' each of  
the variables with their types to a specific function. (Also, I  
kind of like the ':' syntax, as it puts a name to the data within  
the statement.) I also think that we would need to do something like



[insert into table (id, name) values (:id, :name) ( <-- sent to the  
cold inlet

[bind :id float( <-- sent to hold inlet
[bind :name symbol( <-- sent to hold inlet


[:id 1 ( <-- sent to hold inlet
[:name john ( <-- sent to hold inlet
[bang ( <-- sent to hold inlet

and then we would be able to put all the data into the database  
with the expected types. At least SQLite and libdbi use these  
'bind' functions to associate the expected datatype with the input  
data.


(What is the "hold" inlet, by the way?)

It would be really nice to be able to have inlets for the sql  
placeholders, but I couldn't think of a clean way to do it.  We could  
try the dynamic allocation like you say here, I don't know if I have  
a specific objection to it, but it could get weird.  Since the SQL  
inlet has to be cold to support the comma hack, then these dynamic  
inlets  shouldn't be hot since they are the right of a cold inlet.
But that's not a big deal.


Also, I don't know if any objects do this kind of dynamic inlet  
creation after the object itself has been instantiated.  It might not  
even be possible.  I figure that you can easily make a subpatch or  
abstraction around the SQL message generation, then manage the inlets  
there.  Perhaps not ideal, but it's not difficult to do and follows  
existing practice.


As for the SQL binding, I was thinking it would happen inside of the  
object, binding the placeholder names to the selectors.  As long as  
there wasn't any new input on the SQL inlet, then the SQL statement  
wouldn't need to be recompiled.


Another question I just thought of it how to handle returning  
multiple results from s single query.  If it followed the [textfile]  
style, then you would have to bang to get each individual result,  
then keep banging until you get a bang on the status/second outlet,  
meaning the query was done.  I think this could work.


.hc

 



There is no way to peace, peace is the way.   -A.J. Muste


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] symbolatom: why does it not allow to type spaces?

[Roman Haefeli]

On Mon, 2007-12-10 at 15:03 -0500, Mathieu Bouchard wrote:

> 
>print: symbol real\ people\ want\ to\ use\ spaces!

definitely. the first question i hear from people using netpd/pd the
first time is: 'how can i type spaces?' yet i decided to not add another
dependency for netpd just because of this rather silly restriction. but
since it seems, that the lack of spaces is really troubling users, i am
unsure, whether i should change that policy.
since one can even open a file containing spaces in the path from pd, it
would actually make sense, if symbolatom would support that. i can't
think of a case, where supporting spaces would break anything (or am i
overseeing something?). 
before i change my policy about using externals in netpd, i would like
to ask (probably miller?), if there is a chance, that symbolatom is
changed accordingly in the future?

roman

  



___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Mike McGonagle]

Is this something that is part of PD Vanilla? I would like to be able to
have this external running there.
Thanks,

Mike


On 12/10/07, Martin Peach <[EMAIL PROTECTED]> wrote:
>
> If you have applied the "add string support" patch you can use the blob
> atom, which is essentially a pointer to, and the length of, a binary
> string.
> The string can be anything at all.
>
> Martin
>
>
> Mike McGonagle wrote:
> >To: pd-list@iem.at
> >Subject: Re: [PD] [psql] object hand-holding
> >Date: Mon, 10 Dec 2007 13:29:16 -0600
> >
> >On a different note, has anyone given any thought to handling Blobs? I
> know
> >that in SQLite, they store the data as binary strings, but I am not quite
> >certain how the external would handle the actual data going into and
> coming
> >out of it.
> >Mike
>
>
> >___
> >PD-list@iem.at mailing list
> >UNSUBSCRIBE and account-management ->
> >http://lists.puredata.info/listinfo/pd-list
>
>
>


-- 
Peace may sound simple—one beautiful word— but it requires everything we
have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] symbolatom: why does it not allow to type spaces?

[Mathieu Bouchard]

On Mon, 10 Dec 2007, Roman Haefeli wrote:


why does the symbolatom not allow the user to enter spaces? or in other
words: why is there a restriction, if it can be circumvented by using
[makefilename]? people do it anyway, so why prohibit it in the first
place?


I don't know. In DesireData, if I connect a symbolbox to a [print], and 
type something, I get something like this in the console:


  print: symbol real\ people\ want\ to\ use\ spaces!

 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Hans-Christoph Steiner]

On Dec 10, 2007, at 11:43 AM, Frank Barknecht wrote:

> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>
>> On Dec 10, 2007, at 6:14 AM, Thomas Grill wrote:
>>
>>> Frank Barknecht schrieb:
  But as
 everyone knows that I don't really understand why a DB external
 has to
 be a C/C++ external, I'll better be quiet now. ;)


>>> Right. Over and out
>>
>> Basically, only C and Pd externals have proven easy to manage.
>
> lua is a C external (or rather a loader) and it's very easy to manage.
> Once the lua loader is built for your system (trivial on Linux and
> probably just as trivial on OS-X and MS-Windows, but I don't have
> access to these systems) a lua objectclasses is the equivalent to an
> abstraction, which especially means, that it's just as easily changed
> and edited by its users without every needing to recompile anything.

 From what I hear from Marius' struggles with pdlua, it's definitely  
not trivial, and I would say, I probably wouldn't call it easy  
either.  I intend to help Marius get pdlua into Pd-extended, then  
it'll be easy and hopefully even trivial to use.

.hc




 


"Free software means you control what your computer does. Non-free  
software means someone else controls that, and to some extent  
controls you." - Richard M. Stallman



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Mathieu Bouchard]

On Mon, 10 Dec 2007, Jamie Bullock wrote:


Fair enough, I think I was probably stretching the point about using the
[psql]-style of database connectivity requiring less objects.
However, it's perfectly possible to have multiple [psql] instances
connected to the same database, so the routing problem is a bit of a
moot point.


But it requires multiple logins, perhaps many at once, which might be 
wasteful. For sharing database connections between several [psql] 
objects, what do you think would be the best ways to do it? This is 
supposing that several different database connections can still be 
used at once, as specified in the patches.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Mathieu Bouchard]

On Mon, 10 Dec 2007, Jamie Bullock wrote:

On Mon, 2007-12-10 at 12:18 -0500, Mathieu Bouchard wrote:

This almost *never* happens.

I take your point, but I think you are exaggerating slightly.


Not in this context. We're only looking at the average query; I don't even 
mean an actual query, but statistics about queries. If only 10% of them 
don't have arguments, then unless there's a huge difference in object 
count (which there is not), it doesn't make much of a difference on the 
total object count. And that is only supposing that you need something 
like an extra [bang] before your sql query to prevent [psql] from getting 
non-bang messages.


I just looked at the code for a database driven web app I worked on 
recently. It uses 30 queries, 3 of which have no variables. Out of these 
three only one doesn't 'overlap' with other queries and therefore can't 
be refactored. Maybe 1 in 30 is almost never?


Yes. to contrast this, 3% wouldn't be "almost never" if, for example, the 
issue was whether to support something at all, or not. In that case, if 
the cost of a workaround is 50x the wanted feature, or if a workaround is 
impossible, it can weigh a lot in the design priorities.



Good point! I think Hans' recent suggestion addresses the problem. It
also occurs to me that for Postgres at least, we have the PREPARE
statement, which addresses the optimisation and injection issues you
have raised. Technically [psql] already supports PREPARE except that
PREPARE uses the '$' character as its placeholder identifier, and '$1'
can't be passed around as a symbol in Pd. I think it might be
interesting to use the '?' notation currently under discussion as an
interface to PREPARE though.


The '?' notation is either MySQL-specific or PerlDBI-specific or both. By 
PerlDBI I mean any database interface (in any language) following's Perl 
DBI package closely enough. I guess that if you use DBI-over-Postgres, 
then it replaces all ? by $ automatically.


$ alone can be used in pd as long as it is not followed by a digit, but I 
wouldn't encourage that, if it's not used in a [expr] way, because the use 
of '$' alone would prevent you from later supporting an [expr] syntax in a 
way compatible with yourself.


Using $f1 or $s1 in [expr] style, or perhaps $e1 to mean "any atom" (e 
stands for "element"), would be useful, though less required than the 
placeholder feature itself.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Martin Peach]

If you have applied the "add string support" patch you can use the blob 
atom, which is essentially a pointer to, and the length of, a binary string. 
The string can be anything at all.

Martin


Mike McGonagle wrote:
>To: pd-list@iem.at
>Subject: Re: [PD] [psql] object hand-holding
>Date: Mon, 10 Dec 2007 13:29:16 -0600
>
>On a different note, has anyone given any thought to handling Blobs? I know
>that in SQLite, they store the data as binary strings, but I am not quite
>certain how the external would handle the actual data going into and coming
>out of it.
>Mike


>___
>PD-list@iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>http://lists.puredata.info/listinfo/pd-list



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] symbolatom: why does it not allow to type spaces?

[Roman Haefeli]

hi 

why does the symbolatom not allow the user to enter spaces? or in other
words: why is there a restriction, if it can be circumvented by using
[makefilename]? people do it anyway, so why prohibit it in the first
place?

roman






___ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: 
http://mail.yahoo.de


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Mathieu Bouchard]

On Mon, 10 Dec 2007, Mike McGonagle wrote:


I guess what I am getting at is that I don't see how we can prevent people
from using this maliciously.


Using true placeholders or other form of automatic quoting.

If they are creating the SQL and putting the data into it, how can we 
stop them from being idiots?


If you have automatic quoting, you don't even have to think about who is 
an idiot and who isn't. I don't want to think about who's an idiot and who 
isn't. I don't want you to think about it.


Are you saying that we need to do data checking prior to the data being 
sent to the server?


If you quote your data properly then you don't need to check whether the 
data will garble the query's syntax or not. Therefore, no, I don't think 
what you need to do on the data is a "check"... though at the character 
level, you have to "check" in order to know which chars have to be 
replaced.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Mike McGonagle]

On a different note, has anyone given any thought to handling Blobs? I know
that in SQLite, they store the data as binary strings, but I am not quite
certain how the external would handle the actual data going into and coming
out of it.
Mike
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] array indirection

[Chuckk Hubbard]

Well-done, that looks like the perfect solution.  I did notice these
functions mentioned in the code, with xmargin and ymargin as arguments
of a longer function call, but I hadn't followed up to see what else
went in the message.
I believe this is your answer, Phil.

Another one for msg-docs, I think.

-Chuckk

On Dec 10, 2007 1:11 PM, Jean-Yves GRATIUS <[EMAIL PROTECTED]> wrote:
>
>
> Hi,
>  I have tried to change graph-on-parents settings by message for displaying
> different arrays, it seems to work..
>  I did'nt test it with large tables.
>  (included patch : switchingGOPtables.pd).
>
>  Jean Yves Gratius 
>
>
>  Chuckk Hubbard a écrit :
>
>
> On Dec 9, 2007 10:50 PM, Phil Stone <[EMAIL PROTECTED]> wrote:
>
> Hi Chuck,
>
>  I think you're right; there's no way to avoid the copying.  It's good to
>  dream, though.  :-)
>
>  I have done some experimenting, and I think I'm on to something.  If
>  you create a graph from the put menu, then right-click and select
>  Open; and then Put an array on the opened subpatch, you can see the
>  red outline where you can decide what will be graphed-on the parent
>  graph.
>
>  It would not be too hard to send editmode and mouse movement messages
>  to that canvas to move arrays around inside it; and it probably would
>  actually be more efficient than copying.  But I also notice that the
>  graph subpatch has, in its options, an x and y margin, which moves the
>  red outline.  IF it's possible to change these values with messages,
>  it could be trivial to move that red outline to cover several
>  well-placed arrays, meaning that the graph would indeed switch arrays
>  like you want.
>  I started to look at the Pd code to see if I can find such a message
>  mentioned; if I find it I'll let you know.
>
>  -Chuckk
>
>
>
>
> Chuckk Hubbard wrote:
>
> It would be possible, if not CPU-efficient, to have them all hidden in
>  table objects, and simply use tabread and tabwrite to copy them to the
>  skeleton array when you want to switch.  You would only need one
>  tabread and tabwrite pair, just different ways to specify the target
>  of tabread.
>  I would envision binding the tab key to page through them.
>
>  But it is possible to put several arrays in one graph which makes me
>  wonder if there might even be a pure GUI way to do it.  Kind of makes
>  me want to take a look...
>
>  -Chuckk
>
>  On Dec 8, 2007 10:26 PM, Phil Stone <[EMAIL PROTECTED]> wrote:
>
>
> This probably fits into the category of a wish for PD; I think there's
>  no way to do it currently, but I'd love to be proven wrong!
>
>  I'd like to be able to change the data an array points to rather than
>  actually change the data in the array.  The scenario which me think of
>  this is, I'd like to have a display of a currently-selected waveform
>  (which could be one of many pre-allocated arrays).  It would be
>  wonderful to have a level of indirection where the display-array can be
>  given a new address [object reference?] to one of the various
>  pre-allocated arrays, after which it redraws itself.
>
>  I suppose this unleashes all the evils of pointers (multiple references
>  to memory, etc.), but it would a serious advantage, performance-wise,
>  for the scenario I'm envisioning.
>
>  I also think it would be very cool if arrays could act as buttons...but
>  that's a different subject.
>
>
>  Phil Stone
>  pkstonemusic.com
>
>
>  ___
>  PD-list@iem.at mailing list
>  UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
>
>
>
>
>
>
>
>
> #N canvas 303 9 704 687 10;
> #N canvas 0 524 610 502 subpatch 0;
> #X obj 201 120 cnv 15 200 150 empty empty empty 20 12 0 14 -233017
> -66577 0;
> #X obj 200 321 cnv 15 200 150 empty empty empty 20 12 0 14 -233017
> -66577 0;
> #N canvas 0 0 450 300 graph4 0;
> #X array table2 100 float 1;
> #A 0 0 0 0 0.0714288 0.157143 0.171429 0.257144 0.314287 0.342858 0.42
> 0.457145 0.514288 0.557145 0.62 0.657145 0.73 0.714288 0.757146
> 0.757146 0.771431 0.785717 0.785717 0.785717 0.83 0.83 0.814289
> 0.814289 0.814289 0.814289 0.814289 0.814289 0.814289 0.814289 0.814289
> 0.83 0.757146 0.614288 0.514287 0.414287 0.378573 0.342858 0.257144
> 0.21 -0.471431 -0.52 -0.62 -0.62 -0.62 -0.62
> -0.62 -0.62 -0.585717 -0.571431 -0.557145 -0.542859 -0.514288
> -0.52 -0.485716 -0.47143 -0.450002 -0.428573 -0.414287 -0.42
> -0.392859 -0.385716 -0.357144 -0.328573 -0.285715 -0.21 0.114286
> 0.142858 0.228572 0.242858 0.27143 0.31 0.314287 0.328573 0.328573
> 0.328573 0.328573 0.328573 0.328573 0.328573 0.328573 0.328573 0.31
> 0.257144 0.171429 0.142858 0.128572 0.114286 0.128572 0.171429 0.228572
> 0.242858 0.257144 0.257144 0 0 0;
> #X coords 0 1 99 -1 200 140 1;
> #X restore 200 330 graph;
> #N canvas 0 0 450 300 graph3 0;
> #X array table1 100 float 1;
> #A 0 0 0 0 0 0 0 0 0 0.0142856 0.0571424 0.

Re: [PD] [psql] object hand-holding

[Mike McGonagle]

On 12/10/07, Jamie Bullock <[EMAIL PROTECTED]> wrote:
>
> PREPARE uses the '$' character as its placeholder identifier, and '$1'


Jamie, after thinking about this, I don't think we should worry about the
specifics of the characters that we use, as long as we can agree on what
gets entered into a PD message box, the specific instance of the external
('sqlite', 'psql', etc.) can handle the conversion to what the specific
database uses.

>From what I have seen on this thread, is it right that the '?' syntax does
NOT have an identifier following it? I think it would be very helpful if we
use identifiers in the SQL if only to make the binding to the proper
datatypes easier, as per my last email.


Mike
-- 
Peace may sound simple—one beautiful word— but it requires everything we
have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Jamie Bullock]

On Mon, 2007-12-10 at 09:55 -0600, Mike McGonagle wrote:

> 
> Well, Jamie, at the same time, I think that Mathieu might be refering
> how the output is handled from the 'sql' external. That is the part
> that would make having just a single instance of a database object
> difficult at best to work with. From some of the early tests that I
> have done, I have pretty much always assumed that each instance would
> be outputing a different result set. If you only used one database
> object, you would have to figure out how to route all the result sets.
> 

Fair enough, I think I was probably stretching the point about using the
[psql]-style of database connectivity requiring less objects.

However, it's perfectly possible to have multiple [psql] instances
connected to the same database, so the routing problem is a bit of a
moot point. 


> Could someone please explain that IMPORTANCE of worrying about SQL
> injection? Just how would it effect users of PD?

It is certainly important in any situation where you would want to do
variable substitution on queries using data sent to your Pd instance
over a network. Some people might use Pd in this way via a web interface
for example.

Jamie

-- 
www.postlude.co.uk


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Fwd: [psql] object hand-holding

[Mike McGonagle]

-- Forwarded message --
From: Mike McGonagle <[EMAIL PROTECTED]>
Date: Dec 10, 2007 1:07 PM
Subject: Re: [PD] [psql] object hand-holding
To: [EMAIL PROTECTED]



On 12/10/07, Jamie Bullock <[EMAIL PROTECTED]> wrote:
>
> Good point! I think Hans' recent suggestion addresses the problem. It
> also occurs to me that for Postgres at least, we have the PREPARE
> statement, which addresses the optimisation and injection issues you
> have raised. Technically [psql] already supports PREPARE except that
> PREPARE uses the '$' character as its placeholder identifier, and '$1'
> can't be passed around as a symbol in Pd. I think it might be
> interesting to use the '?' notation currently under discussion as an
> interface to PREPARE though.



One of the things that I have been reading on this is that when you use
these 'pre-complied' SQL statements, you need to 'bind' each of the
variables with their types to a specific function. (Also, I kind of like the
':' syntax, as it puts a name to the data within the statement.) I also
think that we would need to do something like


[insert into table (id, name) values (:id, :name) ( <-- sent to the cold
inlet
[bind :id float( <-- sent to hold inlet
[bind :name symbol( <-- sent to hold inlet


[:id 1 ( <-- sent to hold inlet
[:name john ( <-- sent to hold inlet
[bang ( <-- sent to hold inlet

and then we would be able to put all the data into the database with the
expected types. At least SQLite and libdbi use these 'bind' functions to
associate the expected datatype with the input data.


Mike




Jamie
>
> --
> www.postlude.co.uk
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>



-- 
Peace may sound simple—one beautiful word— but it requires everything we
have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician


-- 
Peace may sound simple—one beautiful word— but it requires everything we
have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Mike McGonagle]

On 12/10/07, Mathieu Bouchard <[EMAIL PROTECTED]> wrote:
>
> On Mon, 10 Dec 2007, Mike McGonagle wrote:
>
> > Could someone please explain that IMPORTANCE of worrying about SQL
> > injection? Just how would it effect users of PD?
>
> We don't know what pd users will do with [psql]. Do you?



I guess what I am getting at is that I don't see how we can prevent people
from using this maliciously. If they are creating the SQL and putting the
data into it, how can we stop them from being idiots? Are you saying that we
need to do data checking prior to the data being sent to the server? Or
maybe I am not understanding what you are getting at...

Mike


  _ _ __ ___ _  _ _ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada




-- 
Peace may sound simple—one beautiful word— but it requires everything we
have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Jamie Bullock]

On Mon, 2007-12-10 at 12:18 -0500, Mathieu Bouchard wrote:

> 
> This almost *never* happens. As long as what you do in Pd is regular 
> read-write activities involving tables that contain data that you only 
> want to see a small part of at a time, you need variable atoms in almost 
> any query:
> 
>select person from attendance where chatroom=?
>select chatroom from attendance where person=?
>select * from users where user=?
>select * from chatrooms where chatroom=?
> 
> apps more likely to have invariable queries are apps that started small, 
> stayed small, and will never be expanded.

I take your point, but I think you are exaggerating slightly. I just
looked at the code for a database driven web app I worked on recently.
It uses 30 queries, 3 of which have no variables. Out of these three
only one doesn't 'overlap' with other queries and therefore can't be
refactored. Maybe 1 in 30 is almost never? Anyhow - I agree that I
probably can't argue the case for the [psql]-style of operation on the
grounds of reduced object count :-|

> > True, this is a good argument for the [expr]-style SQL object. Although
> > there may be other ways to provide some protection against injection
> > like allowing the user to lock the number of statements in the query.
> 
> checking the number of statements is not enough: what about a value like: 
> (including quotes)
> 
>'or'1
> 
> put inside this statement:
> 
>delete from users where username='$1'
> 
> this query will delete the complete table.

Good point! I think Hans' recent suggestion addresses the problem. It
also occurs to me that for Postgres at least, we have the PREPARE
statement, which addresses the optimisation and injection issues you
have raised. Technically [psql] already supports PREPARE except that
PREPARE uses the '$' character as its placeholder identifier, and '$1'
can't be passed around as a symbol in Pd. I think it might be
interesting to use the '?' notation currently under discussion as an
interface to PREPARE though.

Jamie

-- 
www.postlude.co.uk


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding (fwd)

[Mathieu Bouchard]

-- Forwarded message --
Date: Mon, 10 Dec 2007 11:52:25 -0500 (EST)
From: Mathieu Bouchard <[EMAIL PROTECTED]>
To: Mike McGonagle <[EMAIL PROTECTED]>
Subject: Re: [PD] [psql] object hand-holding

On Mon, 10 Dec 2007, Mike McGonagle wrote:


While I think I understand what you are getting at, I think that is
something we should leave to version 2 of this. Basically, what I am
understanding is that you want to be able to "compile" an SQL statement, and
then insert new data by making another call that only sends the data. Is
that right?


Yes. Imho that should be version 1. Else it reminds me of working in web 
programming and thinking up funny titles for items in the web app, such as:


  '; drop database web; select * from whatever where 'dummy'='

Which inserts nicely into pretty much any simple query statement of a dumb 
enough web app.


do you want any pd patches to be dumb enough?

 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Mathieu Bouchard]

On Mon, 10 Dec 2007, Mike McGonagle wrote:


Could someone please explain that IMPORTANCE of worrying about SQL
injection? Just how would it effect users of PD?


We don't know what pd users will do with [psql]. Do you?

 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] OT >>> more pd muzik >> segmentation fault !!!

[xm]

hi list !
 >>> more pd muzik >> drum n' drones

nvisible.taz >> features  >>> segmentation fault
 >>> programming and muzik noish~+daax!

enjoy :P


:: ..: ::: ::: :: :. ... . :: :: . : : :. : . . :  . ::

/*segmentation fault*/* *is a research xperimental audio-software 
project, based on the fusion of drones and percutive broken rythms, 
programmed in Pd-patches. /*sf*/ emerges from the work-in-progress in 
the 'nerd-core' underground of barcelona, in openlabs like 'hangar' or 
'csoa la fibra'. Spontanously we mixed the patches in two 
xperimental-jam-sessions first at [EMAIL PROTECTED] 
 (centre Santa monica), and after at 
Distorsion Festival (La Fibra) 


patching resources >> granular synthesis, asymetric sequencer, 
phasevocoder, physycalmodelling applied to AudioFX, Fibonacci sequencer, 
and lots of noise.

The 3 tracks that you can download at: 
http://pitchvolley.com/nvisible.taz/segmentationfault.html

are recorded and composed in live, letting flow the freequencies and 
feed'bugs',..all trakks are made under UbuntuStudio Gnu/linux, and 
licensed in cc.



kontakkt >> isnotoursegmentationfault_at_gmail_dot_com
http://pitchvolley.com/nvisible.taz/segmentationfault.html

.::: : : :: :  ::   :: : . . ..  : :: : : : :: :  ... ..




___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>   


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Frank Barknecht]

Hallo,
Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:

> Not quite as easy as abstractions - you still have to restart Pd.

Well, yes. But still the lua loader allows users to get the same
"power" as developers have without the need to learn and setup all the
stuff that's required to compile exernals. That's where the similarity
between lua and abstractions is. And as Lua is *designed* as an
embedded language, it can be shipped as a tiny binary without any
dependencies easily. lua.pd_linux statically built with Lua included
is 220 KB. Pd-extended is between 15 and 22 MB, zipped. What's easier
to manage?

But who am I telling this? ;)

Ciao
-- 
 Frank Barknecht _ __footils.org__

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Mathieu Bouchard]

On Mon, 10 Dec 2007, Jamie Bullock wrote:


The way you are suggesting always requires at least 2 objects per query:
an object to build the query and a message to send it.


I assumed that there would always be one variable part per query, so that 
there's always a float or symbol or list coming from somewhere to trigger 
the query. Some queries take no arguments but in my experience they are 
rather exceptional. So in the usual case it takes 1 object per query, and 
if the statement is completely non-variable, it takes a bang coming from 
somewhere, which could be counted as a "bang" messagebox or not, depending 
on how you count.


Using the [psql] way of doing things, provided that the queries have no 
variable atoms,


This almost *never* happens. As long as what you do in Pd is regular 
read-write activities involving tables that contain data that you only 
want to see a small part of at a time, you need variable atoms in almost 
any query:


  select person from attendance where chatroom=?
  select chatroom from attendance where person=?
  select * from users where user=?
  select * from chatrooms where chatroom=?

apps more likely to have invariable queries are apps that started small, 
stayed small, and will never be expanded.



True, this is a good argument for the [expr]-style SQL object. Although
there may be other ways to provide some protection against injection
like allowing the user to lock the number of statements in the query.


checking the number of statements is not enough: what about a value like: 
(including quotes)


  'or'1

put inside this statement:

  delete from users where username='$1'

this query will delete the complete table.

 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Mathieu Bouchard]

On Mon, 10 Dec 2007, Hans-Christoph Steiner wrote:

Too often "reducing effort" is equated with typing shortcuts and things along 
that line.  I think putting everything into the [psql] object box is version 
of this.  Things are a bigger concerns in the push to reduce effort are:

- reducing bugs!
- reducing time spent learning new objects
- reducing time spent remembering how to use objects
- making flexible programming easier rather than basic programming faster


add this:
- reducing risk of accidental SQL injection vulnerability
- reducing risk of intentional SQL injection vulnerability
- reducing to zero the effort required to protect against SQL injection
  vulnerability

And if SQL injection vulnerabilities are assumed to have to be addressed 
in the first place, then your interface is increasing likelihood of bugs, 
increasing time spent learning how to use objects _correctly_, increasing 
how much there's to remember about how to get a SQL query right, and 
making flexible programming harder (compared to a version that would work 
the way I say except support replacing a placeholder-based query by 
another placeholder-based query in case anyone ever needs this)


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Claude Heiland-Allen]

Frank Barknecht wrote:
> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
> 
>> On Dec 10, 2007, at 6:14 AM, Thomas Grill wrote:
>>
>>> Frank Barknecht schrieb:
  But as
 everyone knows that I don't really understand why a DB external  
 has to
 be a C/C++ external, I'll better be quiet now. ;)


>>> Right. Over and out
>> Basically, only C and Pd externals have proven easy to manage.  
> 
> lua is a C external (or rather a loader) and it's very easy to manage.
> Once the lua loader is built for your system (trivial on Linux and
> probably just as trivial on OS-X and MS-Windows, but I don't have
> access to these systems) a lua objectclasses is the equivalent to an
> abstraction, which especially means, that it's just as easily changed
> and edited by its users without every needing to recompile anything.

Not quite as easy as abstractions - you still have to restart Pd.

Howver, there is also a [luax] object, though, that loads the Lua code 
on each object creation rather than just once for all time, but you 
still have to recreate each object by hand if you change the script.

> Ciao


Claude
-- 
http://claudiusmaximus.goto10.org

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Hans-Christoph Steiner]

On Dec 10, 2007, at 4:21 AM, Jamie Bullock wrote:



On Sun, 2007-12-09 at 21:47 -0500, Mathieu Bouchard wrote:

On Sun, 9 Dec 2007, Jamie Bullock wrote:


Then I persuaded him that passing the queries as a list to the inlet
would be more flexible. It also greatly reduces the number of  
objects

required to send a query, if you have more than one query.


I don't understand the latter part. How does it work? I'm talking  
about
putting any number of queries together in a single object and  
passing the
arguments of those queries all together in a list. How can you  
reduce the

number of objects more than that?


The way you are suggesting always requires at least 2 objects per  
query:
an object to build the query and a message to send it. So if you  
have 5

different queries (I mean with different statements not just different
data), then you would need at least 10 objects. This would be the case
even if there was no variable data in the queries. Using the [psql]  
way
of doing things, provided that the queries have no variable atoms,  
only

6 objects would be required, one for the database connection, and 5
containing the queries, which when passed to the connection object  
also

trigger the sending.



Your way takes at least two objects
instead of one and it does not provide any protection against SQL
injection because it can't distinguish between a symbol passed as  
a SQL
argument and a symbol representing part of the statement syntax  
itself.


True, this is a good argument for the [expr]-style SQL object.  
Although

there may be other ways to provide some protection against injection
like allowing the user to lock the number of statements in the query.


For a place where you are expecting a number, you can protect against  
a SQL injection attack by merely putting a [float] before the message  
box with the SQL in it.  In other situations, I think that Perl has a  
pretty decent idea: a "SQL quote" function.  This could easily be a  
Pd object, [sqlquote], which would work with all of the SQL objects.  
This would probably be the easiest to implement.


SQL Placeholders seem like a good idea, and SQL already has a  
defined, documented, and  supported syntax for SQL placeholders.   
Ruby, Perl, Java, PHP and others use it, and I think we should use it  
too. Since we already have an inlet that is designed to accept only  
SQL.  There seems to be two defined as part of SQL, "?" for generic,  
and ":name" for named placeholders.


- the "?" could be supported by sending lists to the hot inlet. So if  
there were three "?" in the SQL statement, then you'd send a [5 Joe  
1239.2( to the hot inlet.


- the names ones could be supported as selectors to the hot inlet:

[insert into table (name,age) values (:name,:age) ( <--- cold inlet
[name Lila( <--- hot inlet
[age 12(<--- hot inlet

Then the SQL quoting would be handled internally to the Pd object.  I  
added examples of this to the interface sketch, it's attached.  This  
part could be safely implemented later, I think.




sql-interface.pd
Description: Binary data



This way, the object represents the database itself, the object's  
arguments can represent the connection to the database, then  
different queries are represented using messages sent to the database  
object.  That seems to mirror conceptually what's actually happening.


Lastly, I know that this is getting more complicated to implement,  
but I think it'll pay off in the end.  I'll happily help out with the  
implementation if either of you want me too.  Also, once this is  
ironed out, I'd like to port the Max/MSP [mysql] object to whatever  
interface we come up with.


.hc


 



Computer science is no more related to the computer than astronomy is  
related to the telescope.  -Edsger Dykstra



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Frank Barknecht]

Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

> On Dec 10, 2007, at 6:14 AM, Thomas Grill wrote:
> 
> > Frank Barknecht schrieb:
> >>  But as
> >> everyone knows that I don't really understand why a DB external  
> >> has to
> >> be a C/C++ external, I'll better be quiet now. ;)
> >>
> >>
> > Right. Over and out
> 
> Basically, only C and Pd externals have proven easy to manage.  

lua is a C external (or rather a loader) and it's very easy to manage.
Once the lua loader is built for your system (trivial on Linux and
probably just as trivial on OS-X and MS-Windows, but I don't have
access to these systems) a lua objectclasses is the equivalent to an
abstraction, which especially means, that it's just as easily changed
and edited by its users without every needing to recompile anything.

Ciao
-- 
 Frank Barknecht _ __footils.org__

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Inlet Proxy object example

[Mike McGonagle]

Hello everyone,
Over the weekend, I was "given" a huge lesson in both PD and humility...

Anyway, what this is is an example of how to create an inlet proxy object to
handle arbitrary list input on a cold right inlet. It is something that was
extracted from the 'x_list.c' source, and generalized to be just a raw
object. The example is not a useful object, but illustrates how the C source
framework is designed.

I posted the files to ( http://puredata.info/Members/mjmogo ).

Feedback is welcome and expected...

Mike


-- 
Peace may sound simple—one beautiful word— but it requires everything we
have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Mike McGonagle]

Hans, I still have yet to learn about the WIKI stuff, but I posted a Inlet
Proxy example on my page ( http://puredata.info/Members/mjmogo ). I don't
know if you want to just put a link, or move the file to the Proxy page you
created, either way works for me.
Thanks,

Mike


On Dec 10, 2007 10:05 AM, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote:

>
> On Dec 9, 2007, at 9:53 PM, Mathieu Bouchard wrote:
>
> > On Sun, 9 Dec 2007, Mike McGonagle wrote:
> >
> >> Well, this is not something that is within reach of many people.
> >> We need to understand not just PD's internals, but how flext uses
> >> them, and we also need to know how to integrate these things with
> >> the extended nightly builds. Not quite certain how many people
> >> know ALL of these things. Probably only a handful, and it would
> >> appear that none of them are interested in getting flext working.
> >
> > GridFlow also uses proxy inlets. There are simpler examples of
> > proxy inlets within pd itself. E.g. all [list] objects have it.
> >
> > Basically you need to create another object that will be the
> > "slave" of your main object, and then create an inlet that will use
> > that object. The second argument of inlet_new is for that: the
> > inlet appears on the first argument's box, but messages will be
> > sent to the second argument's object. In that case you pass 0,0 for
> > the other arguments (which are usually symbols, but here are null
> > pointers to mean "not applicable")
>
> I started a pdpedia page on the topic, please add anything useful:
>
> http://wiki.puredata.info/en/proxy_objects
>
> .hc
>
>
> 
> 
>
> I spent 33 years and four months in active military service and
> during that period I spent most of my time as a high class muscle man
> for Big Business, for Wall Street and the bankers.  - General
> Smedley Butler
>
>
>


-- 
Peace may sound simple—one beautiful word— but it requires everything we
have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Hans-Christoph Steiner]

On Dec 9, 2007, at 9:53 PM, Mathieu Bouchard wrote:

> On Sun, 9 Dec 2007, Mike McGonagle wrote:
>
>> Well, this is not something that is within reach of many people.  
>> We need to understand not just PD's internals, but how flext uses  
>> them, and we also need to know how to integrate these things with  
>> the extended nightly builds. Not quite certain how many people  
>> know ALL of these things. Probably only a handful, and it would  
>> appear that none of them are interested in getting flext working.
>
> GridFlow also uses proxy inlets. There are simpler examples of  
> proxy inlets within pd itself. E.g. all [list] objects have it.
>
> Basically you need to create another object that will be the  
> "slave" of your main object, and then create an inlet that will use  
> that object. The second argument of inlet_new is for that: the  
> inlet appears on the first argument's box, but messages will be  
> sent to the second argument's object. In that case you pass 0,0 for  
> the other arguments (which are usually symbols, but here are null  
> pointers to mean "not applicable")

I started a pdpedia page on the topic, please add anything useful:

http://wiki.puredata.info/en/proxy_objects

.hc


 


I spent 33 years and four months in active military service and  
during that period I spent most of my time as a high class muscle man  
for Big Business, for Wall Street and the bankers.  - General  
Smedley Butler



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Mike McGonagle]

On Dec 10, 2007 3:21 AM, Jamie Bullock <[EMAIL PROTECTED]> wrote:

>
> On Sun, 2007-12-09 at 21:47 -0500, Mathieu Bouchard wrote:
> > On Sun, 9 Dec 2007, Jamie Bullock wrote:
> >
> > > Then I persuaded him that passing the queries as a list to the inlet
> > > would be more flexible. It also greatly reduces the number of objects
> > > required to send a query, if you have more than one query.
> >
> > I don't understand the latter part. How does it work? I'm talking about
> > putting any number of queries together in a single object and passing
> the
> > arguments of those queries all together in a list. How can you reduce
> the
> > number of objects more than that?
>
> The way you are suggesting always requires at least 2 objects per query:
> an object to build the query and a message to send it. So if you have 5
> different queries (I mean with different statements not just different
> data), then you would need at least 10 objects. This would be the case
> even if there was no variable data in the queries. Using the [psql] way
> of doing things, provided that the queries have no variable atoms, only
> 6 objects would be required, one for the database connection, and 5
> containing the queries, which when passed to the connection object also
> trigger the sending.


Well, Jamie, at the same time, I think that Mathieu might be refering how
the output is handled from the 'sql' external. That is the part that would
make having just a single instance of a database object difficult at best to
work with. From some of the early tests that I have done, I have pretty much
always assumed that each instance would be outputing a different result set.
If you only used one database object, you would have to figure out how to
route all the result sets.


>
>
> > Your way takes at least two objects
> > instead of one and it does not provide any protection against SQL
> > injection because it can't distinguish between a symbol passed as a SQL
> > argument and a symbol representing part of the statement syntax itself.
>
> True, this is a good argument for the [expr]-style SQL object. Although
> there may be other ways to provide some protection against injection
> like allowing the user to lock the number of statements in the query.


Could someone please explain that IMPORTANCE of worrying about SQL
injection? Just how would it effect users of PD?

Mike


>
>
> Jamie
>
>
>
> --
> www.postlude.co.uk
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>



-- 
Peace may sound simple—one beautiful word— but it requires everything we
have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Hans-Christoph Steiner]

On Dec 10, 2007, at 6:47 AM, Thomas Grill wrote:

> Mike McGonagle schrieb:
>>
>>
>> On 12/9/07, *Thomas Grill* <[EMAIL PROTECTED] >  
>> wrote:
>>
>> Mike McGonagle schrieb:
>> I know and it has been on my todo list for a long time. The  
>> point is
>> that it hasn't made it to the top of this list since i don't  
>> need it.
>> On the other hand it doesn't seem so important in general that  
>> any
>> other
>> person has cared to do it although i consider it a trivial  
>> task and i
>> offered my support for any questions that might arise.
>>
>>
>> Well, this is not something that is within reach of many people. We
>> need to understand not just PD's internals, but how flext uses them,
>> and we also need to know how to integrate these things with the
>> extended nightly builds. Not quite certain how many people know  
>> ALL of
>> these things. Probably only a handful, and it would appear that none
>> of them are interested in getting flext working.
>>
> It's not like that. It's certainly not a precondition to understand  
> the
> inner workings of pd, flext or the operating system to compile an  
> external.
> Integrating flext or anything else into the pd-extended build system,
> needs knowledge of the pd-extended build system and not much more.  
> It's
> absolutely not necessary to understand flext to do this integration. I
> don't have sufficient knowledge of the pd-extended build system and  
> i'm
> not going to spend time on dealing with it, but whoever is  
> interested in
> the integration can dive into it, write the necessary make files (i
> could even provide skeletons for this) and stuff it into the build
> system in the usual free-style manner.

If flext had a autoconf build system, it would be trivial to add,  
just like Gem, PDP, PiDiP, zexy, etc..  The issue now is a custom  
build system that is difficult to script to work automatically cross- 
platform.  (or maybe it's not difficult, but it's custom so noone  
knows how).

Basically all it would take to add an autoconf system to Pd-extended  
is changing the paths here:

PDP_NAME=pdp
$(externals_src)/pdp/configure: $(externals_src)/pdp/configure.ac
cd $(externals_src)/pdp && autoconf

$(externals_src)/pdp/Makefile.config: $(externals_src)/pdp/ 
Makefile.config.in
cd $(externals_src)/pdp && ./configure PD_CPPFLAGS="-I$(pd_src)/src" \
--enable-quicktime

$(externals_src)/pdp/pdp.$(EXTENSION):  $(externals_src)/pdp/configure \
$(externals_src)/pdp/Makefile.config
$(MAKE) -C $(externals_src)/pdp PD_EXECUTABLE="$(pd_src)/bin/pd"

pdp: $(externals_src)/pdp/pdp.$(EXTENSION)

pdp_install: pdp
#   install -d $(objectsdir)/$(PDP_NAME)
#   $(scripts_src)/generate-libdir-metafile.sh $(objectsdir) $(PDP_NAME) \
#   --author "Tom Schouten" \
#   --description "Pure Data Packet" \
#   --license "GNU GPL"
install -p $(externals_src)/pdp/*.$(EXTENSION) $(objectsdir)
#   install -p $(externals_src)/pdp/abstractions/*.pd $(objectsdir)/$ 
(PDP_NAME)
install -p $(externals_src)/pdp/abstractions/*.pd $(objectsdir)
#   install -d $(helpdir)/$(PDP_NAME)
install -p $(externals_src)/pdp/doc/objects/*.* $(helpdir)
install -d $(manualsdir)/$(PDP_NAME)
install -p $(externals_src)/pdp/doc/reference.txt $(manualsdir)/$ 
(PDP_NAME)
install -p $(externals_src)/pdp/doc/introduction/*.* \
$(manualsdir)/$(PDP_NAME)
install -d $(examplesdir)/$(PDP_NAME)
install -p $(externals_src)/pdp/doc/examples/*.* \
$(examplesdir)/$(PDP_NAME)


.hc



>
>>
>> I also downloaded the latest version of flext, and will try again to
>> see if I can get this working. That being said, if we do go the route
>> of using flext, then we should decide now if we should continue
>> developing an SQL interface, or just use 'pool'.
>>
> I would be very interested what exactly isn't working with flext for
> you. I just sshd into linux, checked out flext, pool and pd from  
> cvs and
> compiled flext and pool without a single warning.
> I did exactly as described in the readme.txt files and it took about 2
> minutes.
> I have heard "it doesn't work" many many times, but it's completely
> non-constructive to say that without saying why or what.
>
> gr~~~
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list




 


All mankind is of one author, and is one volume; when one man dies,  
one chapter is not torn out of the book, but translated into a better  
language; and every chapter must be so translated -John Donne



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd

Re: [PD] [psql] object hand-holding

[Mike McGonagle]

On Dec 10, 2007 2:40 AM, IOhannes m zmoelnig <[EMAIL PROTECTED]> wrote:

> Thomas Grill wrote:
> > There must be other externals using proxy inlets, probably zexy or other
> > iem-based stuff.
>
> right: e.g. zexy's [mulitplex] (aka [mux]) uses proxy-inlets.
>
> there are 2 reasons why it is not in the externals-howto:
> #1 it would have complicated the howto needlessly
> #2 when i wrote the howto, i had no idea about proxy inlets and/or how
> to use them.


Yeah, I kind of figured that was the case.


>
>
>
> having said that, i think it is usually a bad idea to all right-hand
> inlets accept arbitrary messages for _most_ objects (not for all).
> a message with a (nonstandard) "selector" selects a method of the object
> to be called and makes this explicit. e.g. it tells the object to do
> something (and eventually provides auxiliary data, to complete this task).
> if you are just passing around data to be collected by the object, there
> is already a certain type of message to do so: "list".
> it is possible to create a right-hand "list" inlet using the methods
> described in the externals-howto (iirc :-))


Well, there are a couple of issues at hand. The first is making the text
look as much like SQL as possible. And the other is in dealing with commas.
Having to prepend each SQL statement with 'list', while not a big deal,
isn't really required. So why use it? This is why we need it to be an
"arbitrary" selector inlet.


>
>
> while i basically agree with matju, that a consistent use of the
> data-flow paradigm should not be made the holy grail (if we don't want
> to end up fighting green knights), i do think that we should bear
> data-flow (as opposed to control-flow) in mind and design objects
> accordingly.


As we are still in discussion about this, I just want to see if we can get
what Hans is suggesting implemented, and then we can see if it is more/less
cumbersome than what we have already.

Only way to find out is to do it...

Mike


-- 
Peace may sound simple—one beautiful word— but it requires everything we
have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] again, the pdcon in brazil issue

[PORRES]

So guys, I will get back to you after the 18th, when we`ll have a meeting here, 
then I will have some stuff to say... I am about to move to Sao Paulo and maybe 
get into the doctorate at the State University of sao Paulo, which is 
interested in sediating and supporting the event.

Any great questions or some expectations so far?

cheers

Alexandre Torres Porres

[EMAIL PROTECTED]

   
-
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Hans-Christoph Steiner]

On Dec 10, 2007, at 6:14 AM, Thomas Grill wrote:

> Frank Barknecht schrieb:
>>  But as
>> everyone knows that I don't really understand why a DB external  
>> has to
>> be a C/C++ external, I'll better be quiet now. ;)
>>
>>
> Right. Over and out

Basically, only C and Pd externals have proven easy to manage.  If  
you only care about your own machine, and people who like building  
things from source, that's one thing.  But most people want to make  
new things rather than spend time building software.

That's not to say that it is impossible to make the lua, python, etc.  
well supported.  It is just a matter of someone doing the work, and  
committing to maintain it.  So far, no one has.


.hc


 


   ¡El pueblo unido jamás será vencido!



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Hans-Christoph Steiner]

On Dec 9, 2007, at 9:41 PM, Mathieu Bouchard wrote:

> On Sat, 8 Dec 2007, Hans-Christoph Steiner wrote:
>
>> I'm not a big fan of [expr]'s syntax since it is custom syntax  
>> that is not used anywhere else in Pd.
>
> A precedent has to start somewhere :)
>
> I believe that the goal is to make an interface that is effortless  
> to use rather than try to be more dataflowish than the pope. The  
> goal is not to pass more messages and use more objects and  
> connections just to show off what's the concept of dataflow and how  
> deeply pd follows it. The goal is still to make patches work with  
> as little effort as possible.
>
> I also believe that there are plenty of pd classes that have at  
> least one element of syntax that is not used anywhere else in pd.  
> It also depends on how you look at pd: are two occurrences in two  
> very related classes, counting as one occurrence, or as two? and  
> why would it be counted that way?

Too often "reducing effort" is equated with typing shortcuts and  
things along that line.  I think putting everything into the [psql]  
object box is version of this.  Things are a bigger concerns in the  
push to reduce effort are:

- reducing bugs!
- reducing time spent learning new objects
- reducing time spent remembering how to use objects
- making flexible programming easier rather than basic programming  
faster

.hc


>
>> Instead, you could achieve the same result by using the interface  
>> I described, then embedded your SQL statements with [sql] into a  
>> subpatch or an abstraction.  This just about any regular Pd user  
>> knows how to do.
>
> But it's better to not have to do that.
>
>  _ _ __ ___ _  _ _ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada



 


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-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding (fwd)

[Hans-Christoph Steiner]

On Dec 9, 2007, at 8:27 PM, Mathieu Bouchard wrote:

>
> -- Forwarded message --
> Date: Sun, 9 Dec 2007 20:23:16 -0500 (EST)
> From: Mathieu Bouchard <[EMAIL PROTECTED]>
> To: Mike McGonagle <[EMAIL PROTECTED]>
> Subject: Re: [PD] [psql] object hand-holding
>
> On Sun, 9 Dec 2007, Mike McGonagle wrote:
>> On 12/7/07, Mathieu Bouchard <[EMAIL PROTECTED]> wrote:
>>> [sql select * from candies where flavour=? and colour=?]
>> I am actually considering going back to this idea, as I can't seem  
>> to figure
>> out why my current version of [sqlite] is crashing.
>
> Try valgrind... best development tool of the decade, imho.

Could you post some instructions on how to use valgrind to debug Pd  
related things on the dev docs wiki?  It would be very useful:

http://puredata.info/docs/developer

.hc


>> I wish there were some sort of tutorial on troubleshooting  
>> problems like
>> this, mostly because I don't really know where to start with  
>> something like
>> 'gdb'.
>
> Gdb is also useful, but often not, because it's too late: e.g. your  
> [psql] might be corrupting pd or something used by pd, and thus pd  
> might not be able to work properly anymore.
>
>> This is why I thought of this in the first place. You generally  
>> don't modify
>> the SQL, except to insert data.
>
> Yes. Now when it comes to modifying the command at runtime, i don't  
> know what to do, because commas and semicolons are not evaled by  
> objectboxes, whereas they are double-trouble in messageboxes. Yet I  
> wouldn't enjoy the long-winded "addcomma" everytime a comma is used  
> (most often INSERT but also SELECT that has a join). Currently  
> backslashes are not typable in messageboxes but they would solve  
> the problem in a less ugly way if they worked (as escape character).
>
> SQL injection is a big security issue, and it's hard to get it  
> figure out all holes. This is especially why one must use SQL  
> placeholders. The other main reason is so that one doesn't even  
> have to think about strings. The other other main reason is because  
> the DB can precompile a statement for multiple uses.
>
>  _ _ __ ___ _  _ _ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC  
> Canada___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



 


I have the audacity to believe that peoples everywhere can have three  
meals a day for their bodies, education and culture for their minds,  
and dignity, equality and freedom for their spirits.  - Martin  
Luther King, Jr.



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] RIP Stockhausen

[Andy Farnell]

Sad news, 

This is worth reading and it ties into recent discussions on this list.

http://www.music.princeton.edu/~ckk/smmt/scientific.commentary.2.html

Of course he will always be remembered as an avant garde composer,
but much of Stockhausens greatness is missed by artists who saw him as
a pseudo-scientist and scientists who dismissed him as an artist.
He was both at different times. A lack of rigor and precise voclabulary
hides his contribution to psychoacoustics, he basically provided
experimental support to Gabors theories, yet he is not mentioned once
in critcal textbooks like McAdams and Bigand.




On Mon, 10 Dec 2007 12:45:35 +
"eric labelle" <[EMAIL PROTECTED]> wrote:

> Thanks for posting this Chris...it is quite a loss.
> 
> 2007/12/10, Chris McCormick <[EMAIL PROTECTED]>:
> >
> > Hi,
> >
> > I haven't seen anyone post on the list about this, so I thought I'd
> > mention it.
> > <
> > http://www.nytimes.com/2007/12/08/arts/music/08stockhausen-1.html?_r=1&ref=obituaries&oref=slogin
> > >
> >
> > Best,
> >
> > Chris.
> >
> > ---
> > http://mccormick.cx
> >
> > ___
> > PD-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
> 
> 
> 
> -- 
> Eric Labelle
> [EMAIL PROTECTED]
> 
> Disques Dubearth - www.dubearth.com
> F_actorvisuals - www.f-actorvisuals.net
> King Tubby's Heritage Dub Foundation
> 


-- 
Use the source

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] RIP Stockhausen

[eric labelle]

Thanks for posting this Chris...it is quite a loss.

2007/12/10, Chris McCormick <[EMAIL PROTECTED]>:
>
> Hi,
>
> I haven't seen anyone post on the list about this, so I thought I'd
> mention it.
> <
> http://www.nytimes.com/2007/12/08/arts/music/08stockhausen-1.html?_r=1&ref=obituaries&oref=slogin
> >
>
> Best,
>
> Chris.
>
> ---
> http://mccormick.cx
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>



-- 
Eric Labelle
[EMAIL PROTECTED]

Disques Dubearth - www.dubearth.com
F_actorvisuals - www.f-actorvisuals.net
King Tubby's Heritage Dub Foundation
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Thomas Grill]

Mike McGonagle schrieb:
>
>
> On 12/9/07, *Thomas Grill* <[EMAIL PROTECTED] > 
> wrote:
>
> Mike McGonagle schrieb:
> I know and it has been on my todo list for a long time. The point is
> that it hasn't made it to the top of this list since i don't need it.
> On the other hand it doesn't seem so important in general that any
> other
> person has cared to do it although i consider it a trivial task and i
> offered my support for any questions that might arise.
>
>
> Well, this is not something that is within reach of many people. We 
> need to understand not just PD's internals, but how flext uses them, 
> and we also need to know how to integrate these things with the 
> extended nightly builds. Not quite certain how many people know ALL of 
> these things. Probably only a handful, and it would appear that none 
> of them are interested in getting flext working.
>  
It's not like that. It's certainly not a precondition to understand the 
inner workings of pd, flext or the operating system to compile an external.
Integrating flext or anything else into the pd-extended build system, 
needs knowledge of the pd-extended build system and not much more. It's 
absolutely not necessary to understand flext to do this integration. I 
don't have sufficient knowledge of the pd-extended build system and i'm 
not going to spend time on dealing with it, but whoever is interested in 
the integration can dive into it, write the necessary make files (i 
could even provide skeletons for this) and stuff it into the build 
system in the usual free-style manner.

>
> I also downloaded the latest version of flext, and will try again to 
> see if I can get this working. That being said, if we do go the route 
> of using flext, then we should decide now if we should continue 
> developing an SQL interface, or just use 'pool'.
>
I would be very interested what exactly isn't working with flext for 
you. I just sshd into linux, checked out flext, pool and pd from cvs and 
compiled flext and pool without a single warning.
I did exactly as described in the readme.txt files and it took about 2 
minutes.
I have heard "it doesn't work" many many times, but it's completely 
non-constructive to say that without saying why or what.

gr~~~


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] array indirection

[Jean-Yves GRATIUS]

Hi,

I have tried to change graph-on-parents settings by message for
displaying different arrays, it seems to work..

I did'nt test it with large tables.

(included patch : switchingGOPtables.pd).


Jean Yves Gratius 



Chuckk Hubbard a écrit :

On Dec 9, 2007 10:50 PM, Phil Stone <[EMAIL PROTECTED]>
wrote:
  
 
  Hi Chuck,


I think you're right; there's no way to avoid the copying.  It's good
to

dream, though.   :-) 

    
  
I have done some experimenting, and I think I'm on to something.  If
  
you create a graph from the put menu, then right-click and select
  
Open; and then Put an array on the opened subpatch, you can see the
  
red outline where you can decide what will be graphed-on the parent
  
graph.
  
  
It would not be too hard to send editmode and mouse movement messages
  
to that canvas to move arrays around inside it; and it probably would
  
actually be more efficient than copying.  But I also notice that the
  
graph subpatch has, in its options, an x and y margin, which moves the
  
red outline.  IF it's possible to change these values with messages,
  
it could be trivial to move that red outline to cover several
  
well-placed arrays, meaning that the graph would indeed switch arrays
  
like you want.
  
I started to look at the Pd code to see if I can find such a message
  
mentioned; if I find it I'll let you know.
  
  
-Chuckk
  
  
  
  
 
  Chuckk Hubbard wrote:

   
It would be possible, if not CPU-efficient,
to have them all hidden in
  
table objects, and simply use tabread and tabwrite to copy them to the
  
skeleton array when you want to switch.  You would only need one
  
tabread and tabwrite pair, just different ways to specify the target
  
of tabread.
  
I would envision binding the tab key to page through them.
  
  
But it is possible to put several arrays in one graph which makes me
  
wonder if there might even be a pure GUI way to do it.  Kind of makes
  
me want to take a look...
  
  
-Chuckk
  
  
On Dec 8, 2007 10:26 PM, Phil Stone <[EMAIL PROTECTED]>
wrote:
  
  
 
  This probably fits into the category of a
wish for PD; I think there's

no way to do it currently, but I'd love to be proven wrong!


I'd like to be able to change the data an array points to rather than

actually change the data in the array.  The scenario which me think of

this is, I'd like to have a display of a currently-selected waveform

(which could be one of many pre-allocated arrays).  It would be

wonderful to have a level of indirection where the display-array can be

given a new address [object reference?] to one of the various

pre-allocated arrays, after which it redraws itself.


I suppose this unleashes all the evils of pointers (multiple references

to memory, etc.), but it would a serious advantage, performance-wise,

for the scenario I'm envisioning.


I also think it would be very cool if arrays could act as buttons...but

that's a different subject.



Phil Stone

pkstonemusic.com



___

PD-list@iem.at
mailing list

UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



    
  
  
  
    
  
  
  
  








#N canvas 303 9 704 687 10;
#N canvas 0 524 610 502 subpatch 0;
#X obj 201 120 cnv 15 200 150 empty empty empty 20 12 0 14 -233017
-66577 0;
#X obj 200 321 cnv 15 200 150 empty empty empty 20 12 0 14 -233017
-66577 0;
#N canvas 0 0 450 300 graph4 0;
#X array table2 100 float 1;
#A 0 0 0 0 0.0714288 0.157143 0.171429 0.257144 0.314287 0.342858 0.42
0.457145 0.514288 0.557145 0.62 0.657145 0.73 0.714288 0.757146
0.757146 0.771431 0.785717 0.785717 0.785717 0.83 0.83 0.814289
0.814289 0.814289 0.814289 0.814289 0.814289 0.814289 0.814289 0.814289
0.83 0.757146 0.614288 0.514287 0.414287 0.378573 0.342858 0.257144
0.21 -0.471431 -0.52 -0.62 -0.62 -0.62 -0.62
-0.62 -0.62 -0.585717 -0.571431 -0.557145 -0.542859 -0.514288
-0.52 -0.485716 -0.47143 -0.450002 -0.428573 -0.414287 -0.42
-0.392859 -0.385716 -0.357144 -0.328573 -0.285715 -0.21 0.114286
0.142858 0.228572 0.242858 0.27143 0.31 0.314287 0.328573 0.328573
0.328573 0.328573 0.328573 0.328573 0.328573 0.328573 0.328573 0.31
0.257144 0.171429 0.142858 0.128572 0.114286 0.128572 0.171429 0.228572
0.242858 0.257144 0.257144 0 0 0;
#X coords 0 1 99 -1 200 140 1;
#X restore 200 330 graph;
#N canvas 0 0 450 300 graph3 0;
#X array table1 100 float 1;
#A 0 0 0 0 0 0 0 0 0 0.0142856 0.0571424 0.071428 0.114285 0.157142
0.164284 0.171427 0.214284 0.271426 0.28 0.35714 0.37 0.442854
0.471425 0.46 0.528567 0.557138 0.557138 0.528567 0

Re: [PD] [psql] object hand-holding

[Thomas Grill]

Frank Barknecht schrieb:
>  But as
> everyone knows that I don't really understand why a DB external has to
> be a C/C++ external, I'll better be quiet now. ;) 
>
>   
Right. Over and out

gr~~~


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Frank Barknecht]

Hallo,
Thomas Grill hat gesagt: // Thomas Grill wrote:

> it's unfortunate that you are not thrilled using flext.
> Since flext uses the PD api to get lists or other messages into 
> secondary inlets there's nothing to stop you from doing the same in 
> psql. The magic words are "proxy objects" which you might find in the 
> mailing list archive (or the flext source code, if you prefer that).
> Needless to say flext saves you from coding these things yourself in a 
> time consuming manner and makes other things really easy, once you got 
> it running. You could also compile pool then.

The Python and Lua objects also support arbitrary messages on their
inlets. Both languages have DB modules for just about every DB,
compilation of these externals only has to be done only once. But as
everyone knows that I don't really understand why a DB external has to
be a C/C++ external, I'll better be quiet now. ;) 

Ciao
-- 
 Frank Barknecht _ __footils.org__

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] general questions on externals

[Yvan Vander Sanden]

On Mon, 2007-12-10 at 09:27 +0100, IOhannes m zmoelnig wrote:
> altern wrote:
> > hi
> > 
> > The uni i am collaborating with has an engineer that did a image 
> > analisys tool on C couple of years ago. Now they want to port parts of 
> > it to PD creating an external. The engineer that does the job is 
> > checking the documentation about externals but he was getting some error.
> > 
> > He doesnt have internet at home, doesnt like it. And does not use email 
> > much, on top of this he does not speak english ... :( so this might end 
> > up like japanese whispers ...
> > 
> > As far as I understood he was trying to do a "hello world" example and 
> > was able to compile but the PD was not able to create the object despite 
> > of being placed into a folder within the PD path. He is using Visual 
> > Studio to compile. He was checking Flext as well. He was confused and he 
> > was asking which is the best way to go about creating externals under 
> > windows. I think he is using Visual Studio to compile.
> 
> the externals-howto (if he is referring to that) is pretty complete as 
> far as it goes to writing externals.
> it does say nothing about compiling externals though.

Last summmer, I wrote a small how-to about this, for people using Dev-C
++. Maybe that can help. It can be found on:

http://youngmusic.org/wiki/index.php/PD-linking-tutorial

There is also one about compiling a library of externals:

http://youngmusic.org/wiki/index.php/PD-library-tutorial

yvan vander sanden





___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Jamie Bullock]

On Sun, 2007-12-09 at 16:47 -0500, Hans-Christoph Steiner wrote:
> The "addcomma", "addsemi", "adddollar" messages are a workaround, for  
> sure, but yeah, I suppose a more pd-ish one.  I think that if SQL  
> gets submitted only on the right/cold inlet, then we would not need  
> those messages.  They might come in handy though, so they could be  
> added later.

I think we would still need 'addsemi' to act as a statement delimiter as
you showed in the subpatch of your example.

> "bang" for submit sounds good too.
> 
> As for clever hacks, I can't think of any with regexs too.  Plus from  
> my experience, clever hacks can often lead to really strange and  
> difficult bugs.  IMHO, we'd better off with something simple that  
> might be a bit harder to start on, but doesn't have odd conditions  
> that could trigger bugs.

I agree. I don't much like the idea of maintaining a list of SQL
statements for use in regex matches!

Jamie

-- 
www.postlude.co.uk


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[Jamie Bullock]

On Sun, 2007-12-09 at 21:47 -0500, Mathieu Bouchard wrote:
> On Sun, 9 Dec 2007, Jamie Bullock wrote:
> 
> > Then I persuaded him that passing the queries as a list to the inlet 
> > would be more flexible. It also greatly reduces the number of objects 
> > required to send a query, if you have more than one query.
> 
> I don't understand the latter part. How does it work? I'm talking about 
> putting any number of queries together in a single object and passing the 
> arguments of those queries all together in a list. How can you reduce the 
> number of objects more than that? 

The way you are suggesting always requires at least 2 objects per query:
an object to build the query and a message to send it. So if you have 5
different queries (I mean with different statements not just different
data), then you would need at least 10 objects. This would be the case
even if there was no variable data in the queries. Using the [psql] way
of doing things, provided that the queries have no variable atoms, only
6 objects would be required, one for the database connection, and 5
containing the queries, which when passed to the connection object also
trigger the sending.


> Your way takes at least two objects 
> instead of one and it does not provide any protection against SQL 
> injection because it can't distinguish between a symbol passed as a SQL 
> argument and a symbol representing part of the statement syntax itself. 

True, this is a good argument for the [expr]-style SQL object. Although
there may be other ways to provide some protection against injection
like allowing the user to lock the number of statements in the query. 

Jamie



-- 
www.postlude.co.uk


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] xml-rpc client

[Georg Holzmann]

Hallo!

> Thanks I looked at that but it wasn't clear to me how I could connect to
> an external server such as
> http://xmlrpc-c.sourceforge.net/api.sample.php with this. Do I need to
> run a python script along with the patch? Is there a help file some
> where?

Well, there is an help pach: look in /externals/iem/iemxmlrpc
  (I think not a help patch, but an example patch).
And you should be able to use that with any other language than python ...

LG
Georg

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [psql] object hand-holding

[IOhannes m zmoelnig]

Thomas Grill wrote:
> There must be other externals using proxy inlets, probably zexy or other 
> iem-based stuff.

right: e.g. zexy's [mulitplex] (aka [mux]) uses proxy-inlets.

there are 2 reasons why it is not in the externals-howto:
#1 it would have complicated the howto needlessly
#2 when i wrote the howto, i had no idea about proxy inlets and/or how 
to use them.


having said that, i think it is usually a bad idea to all right-hand 
inlets accept arbitrary messages for _most_ objects (not for all).
a message with a (nonstandard) "selector" selects a method of the object 
to be called and makes this explicit. e.g. it tells the object to do 
something (and eventually provides auxiliary data, to complete this task).
if you are just passing around data to be collected by the object, there 
is already a certain type of message to do so: "list".
it is possible to create a right-hand "list" inlet using the methods 
described in the externals-howto (iirc :-))


while i basically agree with matju, that a consistent use of the 
data-flow paradigm should not be made the holy grail (if we don't want 
to end up fighting green knights), i do think that we should bear 
data-flow (as opposed to control-flow) in mind and design objects 
accordingly.


mfg.adsf
IOhannes

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] general questions on externals

[IOhannes m zmoelnig]

altern wrote:
> hi
> 
> The uni i am collaborating with has an engineer that did a image 
> analisys tool on C couple of years ago. Now they want to port parts of 
> it to PD creating an external. The engineer that does the job is 
> checking the documentation about externals but he was getting some error.
> 
> He doesnt have internet at home, doesnt like it. And does not use email 
> much, on top of this he does not speak english ... :( so this might end 
> up like japanese whispers ...
> 
> As far as I understood he was trying to do a "hello world" example and 
> was able to compile but the PD was not able to create the object despite 
> of being placed into a folder within the PD path. He is using Visual 
> Studio to compile. He was checking Flext as well. He was confused and he 
> was asking which is the best way to go about creating externals under 
> windows. I think he is using Visual Studio to compile.

the externals-howto (if he is referring to that) is pretty complete as 
far as it goes to writing externals.
it does say nothing about compiling externals though.

most likely this is the problem your engineer is experiencing.

so here some tips:

- they should have a look at the makefiles for the externals that come 
with Pd (pd/extra/makefile), it has a relevant esection for building 
with M$VC (but only using commandline tools)

- alternatively, the examples of my externals-HOWTO are also checked 
into CVS (./doc/tutorials/externals-howto/), and there you will find 
Makefiles (still: using cmdline tools, also for M$VC)

- if they insist on building only from within the IDE (no cmdline 
tools), they could also have a look at the M$VC project for zexy. (this 
is shameless self-advertising i admit; but it is the simplest M$VC 
project i know well); just use zexy.dsw / zexy.dsp (or whatever is 
there) and upgrade to their version of M$VC (the IDE should handle this 
automatically); then build from this project (rename the probject; 
remove all files from the project; add your own files)



if they want to create the project on their own:
- an external is a .dll (something you have to tell M$VC pretty early 
when you create a new project)
- the external must link against pd.lib
- an external MUST export one certain function (it MAY export more; but 
this one is obligatory): "void _setup(void)"
use
- the external must reside in a file of its name::
   [myobj] (pd objectclass) -> myobj.dll (external-file) -> 
myobj_setup() (entry point)


mfgas.dr
IOhannes

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list