Thomas, don't get me wrong, I am quite certain that you have written a very useful product. My only trouble is that I have never been able to get anything to compile that is using it. Over the weekend, I tried to compile Plain Vanilla PD, and that was a pain in the ass, too, and when I was done, it didn't work.
One of the things that I have heard mention is that it would be nice to have flext as part of the Extended build. That would be a good thing, as we could take advantage of all the externals that use flext, without having to compile them ourselves. Also, it is not part of the Plain Vanilla PD, so that makes it suspect to forcing the user to integrate it themselves.
Could you point out where in the source for flext that allows the inclusion of lists to a 'cold' inlet, and that allows the use of arbitrary selectors?
Thanks,
Mike
On 12/9/07, Thomas Grill
<gr@grrrr.org> wrote:Hi Mike,
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.
gr~~~
Mike McGonagle schrieb:
> Ok, so I spent the weekend just trying to figure out if what Hans
> described is POSSIBLE at all... And NO, it is not possible in Plain
> Vanilla PD. You can't create a second inlet that will take arbitrary
> selectors. According to the ' pd-external-HOWTO.pdf' (by IOhannes),
> page 32;
>
> "It is not possible to addmethods for more than one select to a right
> inlet. Particularly it is not possible to add a universal method for
> arbitrary selectors to a right inlet."
>
> And this is exactly what Hans is proposing. The 'cold' inlet would
> need to recognize arbitrary selectors. I don't know if it is possible
> to create a second inlet that takes a list, as there is no function
> call to add a list inlet.
>
> The only way that I know to do that is to use Flext, and quite
> frankly, this is one of the things that I wanted to avoid in the first
> place. If we are forced to use Flext, then why not just get 'pool'
> running and be done with this mess...
>
> Also, I don't think the idea of having other "hot" messages, like [use
> <database>( should be made into their own selectors, as ALL SQL should
> be processed in the same way, and no special cases should be created.
> I think it would be difficult for a user to know what SQL goes where,
> there may only be a few of them, but it still makes special cases out
> of those bits of SQL. The only selectors the external should recognize
> are ones that are for controlling the external itself.
>
> So, if anyone has any ideas, I think I am just going to continue with
> what I have, you can use it if you want, but quite frankly, this is
> very frustrating when a suggestion like this comes from one of the
> lead developers, and it turns out not to be possible. I am not really
> thrilled about using Flext, as it is not part of the Extended build,
> and it is not part of Vanilla-PD (also, I have never been able to get
> anything to compile on my machine with Flext, not so say I put forth a
> huge effort, as I like things to be as simple as possible). I didn't
> want to force a user to have to download and install any additional
> packages (which include not just PD, but an extra database).
>
> Or am I just freaking out over nothing.
>
>
> Mike
>
>
> On 12/9/07, *Hans-Christoph Steiner* <
hans@eds.org
> <mailto:hans@eds.org>> 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.
>
> "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.
>
> .hc
>
>
> On Dec 9, 2007, at 9:26 AM, Jamie Bullock wrote:
>
> >
> > Hi Hans,
> >
> > I like this idea of a hot and cold inlet, and I can see where
> you are
> > going with making the database access objects more pd-like. I also
> > agree
> > that the sql/sqlend delimiters are a rather inelegant workaround for
> > Pd's lack of a string type. What you suggest shouldn't be too
> hard to
> > implement either.
> >
> > I have a few specific comments (see below).
> >
> > On Fri, 2007-12-07 at 21:37 -0500, Hans-Christoph Steiner wrote:
> >> That is done by sending the [submit( message to the hot
> inlet. Or do
> >> you mean having multiple SQL calls separated by
> semi-colons? If you
> >> wanted to add semicolons, there would have to be a special
> message, I
> >> think we could just reuse the "addsemi", "addcomma", "adddollar"
> >> messages from message boxes.
> >
> > This feels like another workaround, but I suppose it's more
> > idiomatic pd
> > than 'sqlend'.
>
>
>
> >> As far as I know, the semi-colon at the end of the statement in
> SQL
> >> triggers the execution of that statement, so I can't see an
> advantage
> >> to having multiple, semi-colon terminated statements in a single
> >> message box. Does it change how the SQL is executed if they are
> >> submitted at the same time?
> >
> > No.
> >
> >>>
> >>> The other thing I think that would have to be is forcing all input
> >>> SQL to go into the second inlet. Allowing some things to go
> into the
> >>> hot inlet, while others are required to go into the second outlet
> >>> would make it difficult to use because you would have to remember
> >>> which type of statement can go where...
> >>
> >>
> >> Any SQL statement would be allowed on the cold inlet. Because
> of the
> >> limitations of Pd (no escape mechanism), and the fact that commas
> >> already have a meaning in Pd messages, the hot inlet would not be
> >> able
> >> to handle commas (unless someone comes up with something quite
> >> clever).
> >
> > I think we should either come up with something quite clever (using
> > regex springs to mind), or not allow queries to be submitted to the
> > hot
> > inlet at all. Having a hot inlet that doesn't quite handle
> queries in
> > the same way as the cold inlet is just confusing.
> >
> > Another suggestion: perhaps it would be even more idiomatic to use
> > "bang" instead of "submit" as the 'quert send' message?
> >
> > Jamie
> >
> > --
> > www.postlude.co.uk <http://www.postlude.co.uk
>
>
>
>
> ------------------------------------------------------------------------
>
> ----
>
> 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
>
>
>
>
>
> --
> 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
>
--
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