I've put tclpd in externals/ since a few days.
even if the example I provided it is usable, perhaps it misses much features.
I still miss some ideas for libpd.tcl (a nifty library for wrapping the pd api)
I would like to throw it in here, hoping some dev/tcl coder is interested in trying it, hacking it, giving feedback
(beware: alpha release!)
I think I skipped this message because of the [ANN] in the message, I thought it had to do with the neural network stuff..
Anyway, this sounds awesome! I think this is the best approach for a nice API for writing GUI objects. Have you seen [widget] at all?
.hc
On Sep 21, 2007, at 6:05 PM, federico wrote:
I've put tclpd in externals/ since a few days.
even if the example I provided it is usable, perhaps it misses much features.
I still miss some ideas for libpd.tcl (a nifty library for wrapping the pd api)
I would like to throw it in here, hoping some dev/tcl coder is interested in trying it, hacking it, giving feedback
(beware: alpha release!)
-- Federico Ferri
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
All information should be free. - the hacker ethic
Ok, now I am going thru your readme, here are some first thoughts.
- About the symbol/float stuff, I think Pd is intended to always reduce atoms to their elemental type based on their content. Therefore, {symbol 123} shouldn't really exist. For the most part in Pd, it doesn't. Therefore, I think it would be better to just use normal Tcl lists, at least for now. Plus, I think Pd's type handling is partially modeled after Tcl's.
- what I'd really like to see is the GUI API in Tcl. I starting writing down ideas here: http://puredata.org/dev/GUIs feel free to edit, add, etc.
I'd like to help make native tcl gui objects a reality, but I don't know swig or C++. I can help in other ways, like adding it to Pd- extended (surprise, surprise).
.hc
On Sep 21, 2007, at 6:05 PM, federico wrote:
I've put tclpd in externals/ since a few days.
even if the example I provided it is usable, perhaps it misses much features.
I still miss some ideas for libpd.tcl (a nifty library for wrapping the pd api)
I would like to throw it in here, hoping some dev/tcl coder is interested in trying it, hacking it, giving feedback
(beware: alpha release!)
-- Federico Ferri
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
All information should be free. - the hacker ethic
On Tue, 23 Oct 2007, Hans-Christoph Steiner wrote:
- About the symbol/float stuff, I think Pd is intended to always reduce
atoms to their elemental type based on their content. Therefore, {symbol 123} shouldn't really exist.
If I make symbol 123456789 it's because it's intended to stay 123456789. I don't want tclpd to bastardise it by assuming that i'm ok with an approximation of the number that it could be representing if my intent was really to represent a quantity instead of just having a string of characters.
Federico and I came to the conclusion that we came to because pretty much anything else sucked in some way. We don't care that Pd seems perfectly ok with blowing up the saving of symbols that look like numbers, and we don't care that you don't want support for pointers.
I don't think that you and I and all of us have to stick with mere original intents.
The main alternative I would have had to that, is to represent Pd symbols in Tcl as the Pd parser would accept them. This means that a float would be backslashed. But I had ruled that out because then there would be no way to represent a pointer, unless some extra syntax is designed, plus other reasons.
Therefore, I think it would be better to just use normal Tcl lists, at least for now.
If you do it "at least for now", you're stuck with it forever or so.
Plus, I think Pd's type handling is partially modeled after Tcl's.
I don't know how you can argue that, but there's a large enough chunk of difference, that you could ignore the similarities. If Pd's type system was roughly like Tcl's, then users would never have to think about types in [pack], [unpack], [t], and such, for example.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
I am not saying that I like the current symbol system. I am saying that I don't think it is appropriate to change the behavior in only certain places. That just leads to more confusion and bugs.
For now, I think it would be a good idea to have the Tcl API match Pd as close as possible. Pointer support would be interesting but I don't think you need to do it that way.
It is like it is now, so we can test it as it is.
.hc
On Oct 24, 2007, at 6:16 AM, Mathieu Bouchard wrote:
On Tue, 23 Oct 2007, Hans-Christoph Steiner wrote:
- About the symbol/float stuff, I think Pd is intended to always
reduce atoms to their elemental type based on their content. Therefore, {symbol 123} shouldn't really exist.
If I make symbol 123456789 it's because it's intended to stay 123456789. I don't want tclpd to bastardise it by assuming that i'm ok with an approximation of the number that it could be representing if my intent was really to represent a quantity instead of just having a string of characters.
Federico and I came to the conclusion that we came to because pretty much anything else sucked in some way. We don't care that Pd seems perfectly ok with blowing up the saving of symbols that look like numbers, and we don't care that you don't want support for pointers.
I don't think that you and I and all of us have to stick with mere original intents.
The main alternative I would have had to that, is to represent Pd symbols in Tcl as the Pd parser would accept them. This means that a float would be backslashed. But I had ruled that out because then there would be no way to represent a pointer, unless some extra syntax is designed, plus other reasons.
Therefore, I think it would be better to just use normal Tcl lists, at least for now.
If you do it "at least for now", you're stuck with it forever or so.
Plus, I think Pd's type handling is partially modeled after Tcl's.
I don't know how you can argue that, but there's a large enough chunk of difference, that you could ignore the similarities. If Pd's type system was roughly like Tcl's, then users would never have to think about types in [pack], [unpack], [t], and such, for example.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
------------------------------------------------------------------------ ----
¡El pueblo unido jamás será vencido!
On Wed, 24 Oct 2007, Hans-Christoph Steiner wrote:
I am not saying that I like the current symbol system. I am saying that I don't think it is appropriate to change the behavior in only certain places. That just leads to more confusion and bugs.
Therefore, you want us to change the behaviour so that it becomes inconsistent with how C-based externals behave, so that it fits more your interpretation of Miller's intent than what Miller actually designed as an external API.
So, you are the one who is trying to change the symbol system or the atom system.
For now, I think it would be a good idea to have the Tcl API match Pd as close as possible.
Therefore, Federico did the right thing, and you just contradicted yourself?
Pd has two different policies in practice: by its mishandling of float-looking symbols, it seems somewhat typeless, but that's only when writing to a file or socket. At the t_atom level, within Pd patches and messages, Pd is very strict on types. Externals use the t_atom level only. So far, Tcl has received things using the other policy, because it's across a socket, but server-side Tcl shouldn't be like that.
When considering only the t_atom level, Tcl and Pd are not much alike. Where they have most in common is the use of dollar for substitution, semicolon for message separation, space-delimiters for atom separation, and an overall preference for simple syntax designed in several layers. That's why I've been mentioning a special Tcl/Pd affinity in the past.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
federico -
Hans-Christoph Steiner -
Mathieu Bouchard