Re: [PD-dev] removing string types from pd-extended release
On Sat, 28 Jun 2008, Mathieu Bouchard wrote: I edited it quite a bit. Split it in 5 parts total: the normal types, the messagebox-only types, the pseudo-types, the user-defined normal types, and the user-defined pseudo-types. By pseudo-type I mean something not used in t_atom::a_type. I added the GF/DD types as well. In addition to reserving A_ATOM (12), A_LIST (13), A_GRID (14), I just added A_GRIDOUT (15). So far, I already use A_LIST and I'm starting to use A_GRIDOUT right away as a replacement for my bogus use of A_POINTER. The others are for future use. There is a slight possibility of a merge of A_GRID and A_GRIDOUT together eventually, and there's a much bigger possibility of adding extra types for some OpenCV things and such. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing string types from pd-extended release
On Fri, 9 May 2008, IOhannes m zmölnig wrote: Stephen Sinclair wrote: also, i'd just like to add, that i think the 666 atomID should be reserved for 'evil' data. It could be useful in the future for optimized implementations of evil processing routines. you are right; sorry for the confusion with A_BLOB/A_STRING... time to start a wiki http://puredata.info/docs/developer/AtomTypes I edited it quite a bit. Split it in 5 parts total: the normal types, the messagebox-only types, the pseudo-types, the user-defined normal types, and the user-defined pseudo-types. By pseudo-type I mean something not used in t_atom::a_type. I added the GF/DD types as well. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing string types from pd-extended release
On May 9, 2008, at 5:27 PM, IOhannes m zmölnig wrote: Stephen Sinclair wrote: also, i'd just like to add, that i think the 666 atomID should be reserved for 'evil' data. It could be useful in the future for optimized implementations of evil processing routines. you are right; sorry for the confusion with A_BLOB/A_STRING... time to start a wiki http://puredata.info/docs/developer/AtomTypes Seems like it would be most useful as a header (.h) file. Perhaps we could just make that page be C header format, with inline comments. .hc mfgasr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing string types from pd-extended release
Martin Peach wrote:
I've attached the reasoning behind my string patch, probably there is a
lot wrong with it.
But I can't see how to do this kind of thing otherwise without modifying
Pd.
i only proposed to just removed all the selector stuff (string) and
use plain atoms (within lists/messages) instead.
i don't see _any_ reason why we would need to have a stringmethod pd
knows about.
instead use:
snip
#define STRING_ATOMID=666
static void myobj_string(t_myobj*x, t_symbol*s, int argc, t_atom*argv) {
if (argc STRING_ATOMID==argv-a_type) {
// hold on, this is a string!
...
} else {
pd_error(x, expected string);
}
}
void myobj_setup(void) {
...
class_addmethod(myobj_class, (t_method)myobj_string, gensym(string),
A_GIMME, 0);
}
/snip
et voila! no need to patch Pd at all.
in a second step, Pd should handle atoms outside its known world properly.
my initial idea was to introduce a way to register new types with Pd, so
pd would know about a new a_type number during runtime and would be
able to do handle it more intelligently (e.g. calling a certain
atom_getstring() method when [post]ing; rejecting atom-types that it
doesn't know about;...)
miller was rather reluctant about this, as it probably adds too much
hazzle for too little benefit.
therefore we basically agreed (at lac2008) that we would just use
additional a_type-numbers and that's basically it!
fgmadsr
IOhannes
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing string types from pd-extended release
IOhannes m zmölnig wrote: #define STRING_ATOMID=666 and while we are at it: i hereby want to claim the atomID 75 for FTMobjects [1]. please do not use this atomID, if you are not wrapping FTMobjects within such atom. mfasdr IOhannes [1] http://ftm.sf.net/ http://ftm.ircam.fr ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing string types from pd-extended release
IOhannes m zmölnig wrote: IOhannes m zmölnig wrote: #define STRING_ATOMID=666 and while we are at it: i hereby want to claim the atomID 75 for FTMobjects [1]. please do not use this atomID, if you are not wrapping FTMobjects within such atom. additionally, i want to claim atomID 77 for FTMstrings (which are part of ftm, but since i have never used them before, i plainly forgot about them; i also cannot answer any questions on how they actually work and whether they might be compatible with mrpeach's strings) mfgasdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing string types from pd-extended release
On Fri, May 9, 2008 at 3:13 AM, IOhannes m zmölnig [EMAIL PROTECTED] wrote: IOhannes m zmölnig wrote: IOhannes m zmölnig wrote: #define STRING_ATOMID=666 and while we are at it: i hereby want to claim the atomID 75 for FTMobjects [1]. please do not use this atomID, if you are not wrapping FTMobjects within such atom. additionally, i want to claim atomID 77 for FTMstrings (which are part of ftm, but since i have never used them before, i plainly forgot about them; i also cannot answer any questions on how they actually work and whether they might be compatible with mrpeach's strings) also, i'd just like to add, that i think the 666 atomID should be reserved for 'evil' data. It could be useful in the future for optimized implementations of evil processing routines. thanks, Steve ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing string types from pd-extended release
Stephen Sinclair wrote: also, i'd just like to add, that i think the 666 atomID should be reserved for 'evil' data. It could be useful in the future for optimized implementations of evil processing routines. you are right; sorry for the confusion with A_BLOB/A_STRING... time to start a wiki http://puredata.info/docs/developer/AtomTypes mfgasr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing string types from pd-extended release
On Fri, May 9, 2008 at 11:27 AM, IOhannes m zmölnig [EMAIL PROTECTED] wrote: Stephen Sinclair wrote: also, i'd just like to add, that i think the 666 atomID should be reserved for 'evil' data. It could be useful in the future for optimized implementations of evil processing routines. you are right; sorry for the confusion with A_BLOB/A_STRING... time to start a wiki http://puredata.info/docs/developer/AtomTypes very nice, thanks. :) hopefully it will be useful. (for evil purposes of course.) steve ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing string types from pd-extended release
Could someone point me to IOhannes' technique? If it makes sense I'll give it a go during the next week. Martin From: Hans-Christoph Steiner [EMAIL PROTECTED] To: pd-dev List pd-dev@iem.at Subject: [PD-dev] removing string types from pd-extended release Date: Thu, 8 May 2008 20:44:09 +0200 Hey, We talked about this in the recent past. Could someone who knows the details remove the declarations of the string type from branches/pd- extended/0.40? Or shall I just remove the whole patch? I want to include string support, but using the technique that IOhannes laid out, which should be possible without patching Pd (AFAIK). .hc Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing string types from pd-extended release
I don't know the details, but I believe it was just choosing an unused number to represent the type. Then also not using a keyword. Ultimately, there could be something like /etc/services where we can register these numbers. Or maybe they could just be included in the Pd headers. http://lists.puredata.info/pipermail/pd-dev/2008-04/011257.html .hc On May 8, 2008, at 10:33 PM, Martin Peach wrote: Could someone point me to IOhannes' technique? If it makes sense I'll give it a go during the next week. Martin From: Hans-Christoph Steiner [EMAIL PROTECTED] To: pd-dev List pd-dev@iem.at Subject: [PD-dev] removing string types from pd-extended release Date: Thu, 8 May 2008 20:44:09 +0200 Hey, We talked about this in the recent past. Could someone who knows the details remove the declarations of the string type from branches/pd- extended/0.40? Or shall I just remove the whole patch? I want to include string support, but using the technique that IOhannes laid out, which should be possible without patching Pd (AFAIK). .hc - --- Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev All information should be free. - the hacker ethic ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing string types from pd-extended release
I've attached the reasoning behind my string patch, probably there is a
lot wrong with it.
But I can't see how to do this kind of thing otherwise without modifying Pd.
Martin
Hans-Christoph Steiner wrote:
I don't know the details, but I believe it was just choosing an
unused number to represent the type. Then also not using a keyword.
Ultimately, there could be something like /etc/services where we can
register these numbers. Or maybe they could just be included in the
Pd headers.
http://lists.puredata.info/pipermail/pd-dev/2008-04/011257.html
.hc
On May 8, 2008, at 10:33 PM, Martin Peach wrote:
Could someone point me to IOhannes' technique? If it makes sense
I'll give it a go during the next week.
Martin
From: Hans-Christoph Steiner [EMAIL PROTECTED]
To: pd-dev List pd-dev@iem.at
Subject: [PD-dev] removing string types from pd-extended release
Date: Thu, 8 May 2008 20:44:09 +0200
Hey,
We talked about this in the recent past. Could someone who knows the
details remove the declarations of the string type from branches/pd-
extended/0.40? Or shall I just remove the whole patch? I want to
include string support, but using the technique that IOhannes laid
out, which should be possible without patching Pd (AFAIK).
.hc
-
---
Using ReBirth is like trying to play an 808 with a long stick.-
David Zicarelli
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
All information should be free. - the hacker ethic
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
I think it would be most efficient to have a string type be a length followed
by that many unsigned chars,
similar to a Pascal string but with the length being something like a 32-bit
integer.
It would not be added to pd's symbol list. The atom whose type was string would
have
to contain a pointer to the first byte of the string, and a length. Multibyte
characters would just
be counted as multiple characters when calculating the length, so the length
would be the number of bytes
in the string, not the number of characters.
It looks too easy to me...In m_pd.h, add:
A_STRING
to t_atomtype at line 139 of m_pd.h.
Add
t_string * w_string;
to t_word at line 122 of m_pd.h.
Add the typedef:
typedef struct _string /* pointer to a string */
{
unsigned long s_length; /* length of string in bytes */
unsigned char *s_data; /* pointer to 1st byte of string */
} t_string;
at line 106 of m_pd.h
...so a string atom would have a_type = A_STRING and a_w = a_w.w_string, which
points to a t_string containing
the length and a pointer to the string.
This we did first and now we are compiling pd on linux to see if it breaks
anything...not so far.
If pd is otherwise able to handle atom types it doesn't know about (?), all the
string manipulation objects could
be built as externals.
As I see it the atom types are defined in m_pd.h and registered in m_class.c,
which would need to have functions added
to it to handle string, like adding:
t_symbol s_string ={string, 0, 0};
to the list of t_symbols around line 555, and changing:
static t_symbol *symlist[] = { s_pointer, s_float, s_symbol, s_bang,
s_list, s_anything, s_signal, s__N, s__X, s_x, s_y, s_};
to:
static t_symbol *symlist[] = { s_pointer, s_float, s_symbol, s_bang,
s_list, s_anything, s_signal, s__N, s__X, s_x, s_y, s_, s_string};
...and pd_typedmess needs a handler for string messages around line 658:
if (s == s_string)
{
if (argc == 1) (*c-c_stringmethod)(x, argv-a_w.w_string);
else goto badarg;
return;
}
...and a handler for messages with string arguments with other names, just
befor case A_SYMBOL, line 728:
case A_STRING:/* MP 20070106 string type */
post(pd_typedmess A_STRING);
if (!argc) goto badarg;
if (argv-a_type == A_STRING)
{
post(argv-a_type == A_STRING, argc = %d, narg= %d, argc,
narg);
*ap = (t_int)(argv-a_w.w_string);
mp = 1;
}
argc--;
argv++;
narg++;
ap++;
break;
Still in m_class.c, around line 344 we add:
void class_addstring(t_class *c, t_method fn)
{
c-c_stringmethod = (t_stringmethod)fn;
}
This is used to register a string handler with pd so that incoming strings will
be sent to fn.
We added:
else if (sel == s_string) /* MP 20070106 string type */
{
post(class_addmethod: %p, fn);
if (argtype != A_STRING || va_arg(ap, t_atomtype)) goto phooey;
class_addstring(c, fn);
}
around line 300 of m_class.c in case someone calls
