Re: [PD-dev] from t_symbol to t_class
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-13 18:50, Jonathan Wilkes wrote: but adding/revising code inside class_new would retain 100% binary compatibility, whereas adding members to public structures is a 100% guarantee to break binary compatibiliy. And if I just put the struct inside m_class.c but not in m_pd.h is that enough to keep it from being exposed? yes, that shouldn't be a problem. i was mainly concerned about your plans to extend the existing t_symbol (but i might have misunderstood your suggestion). Another questions-- inside class_new when I add a class/symbol pair to the list (I suppose by calling a function to add an entry to the list), I need to walk the current list to see if that symbol has already been added and overwrite the old class pointer with the new one, right? And if so, won't this searching add to the patch load time? yes. obviously, all code that you add will eventually take some ime to execute. however, i wouldn't worry too much about that before it becomes obvious that it takes too long...Pd already handles quite a number of linked lists that are searched linearily. e.g. calling class_new() already checks, whether the new class is already in the long list of objectclasses registered with pd_objectmaker, and this is not the reason why it takes long to load large patches. otoh, it would of course be nice to abstract these hashtable-like structures away, in something like std::map; this would make it easy to switch to a different algorithm (eg. binary trees) once we find that a linear search is the bottleneck. fgasmdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlD0Bz0ACgkQkX2Xpv6ydvT0ggCg0h1nqbsPzsuKTUhxa+yd4Khk 9G4An1nt6vfPlQj3lMLf4+M0j9PJbk5F =J5Ry -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] from t_symbol to t_class
On 01/12/2013 11:56 PM, Jonathan Wilkes wrote: a t_class *s_class? Would that affect performance? it would break binary compatibility. there's no good reason to add hash-like lookups to t_symbol (your only reason is convenience). and avoiding code duplication. i think that breaking binary compatibility is more important than code duplication, but ... Then searching for an existing class would be easy-- just do a gensym and check if its s_class exists. but checking whether a class exists, is as simple as calling zgetfn on pd_objectmaker. i think this is _quite_ easy. Well yes. I meant searching for a class and _returning_ a class pointer. ...which only means that the current interface (using zgetfn with pd_objectmaker) is inadequate to your problem. So without adding/revising code inside class_new, is creating an instance the only way to get access to the class attributes? unfortunately yes. but adding/revising code inside class_new would retain 100% binary compatibility, whereas adding members to public structures is a 100% guarantee to break binary compatibiliy. i think it is one of Pd's greater weaknesses, that so many data structures are exposed (rather than opaque). if we had more accessor-functions, there would be less need to worry about binary compatibiliy. fgamsdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] from t_symbol to t_class
- Original Message - From: IOhannes zmölnig zmoel...@iem.at To: pd-dev@iem.at Cc: Sent: Sunday, January 13, 2013 5:57 AM Subject: Re: [PD-dev] from t_symbol to t_class On 01/12/2013 11:56 PM, Jonathan Wilkes wrote: a t_class *s_class? Would that affect performance? it would break binary compatibility. there's no good reason to add hash-like lookups to t_symbol (your only reason is convenience). and avoiding code duplication. i think that breaking binary compatibility is more important than code duplication, but ... Nevertheless its important to avoid code duplication, for obvious reasons. Then searching for an existing class would be easy-- just do a gensym and check if its s_class exists. but checking whether a class exists, is as simple as calling zgetfn on pd_objectmaker. i think this is _quite_ easy. Well yes. I meant searching for a class and _returning_ a class pointer. ...which only means that the current interface (using zgetfn with pd_objectmaker) is inadequate to your problem. Yes. So without adding/revising code inside class_new, is creating an instance the only way to get access to the class attributes? unfortunately yes. but adding/revising code inside class_new would retain 100% binary compatibility, whereas adding members to public structures is a 100% guarantee to break binary compatibiliy. And if I just put the struct inside m_class.c but not in m_pd.h is that enough to keep it from being exposed? Another questions-- inside class_new when I add a class/symbol pair to the list (I suppose by calling a function to add an entry to the list), I need to walk the current list to see if that symbol has already been added and overwrite the old class pointer with the new one, right? And if so, won't this searching add to the patch load time? -Jonathan i think it is one of Pd's greater weaknesses, that so many data structures are exposed (rather than opaque). if we had more accessor-functions, there would be less need to worry about binary compatibiliy. fgamsdr IOhannes ___ 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] from t_symbol to t_class
On 01/12/2013 12:04 AM, Jonathan Wilkes wrote: In C would I just make a struct with fields of t_symbol, t_class, and a pointer to link to the next one? Yeah, a linked list would work fine, probably not as efficient as the c++ hash structure (but lots easier to maintain). One nit-to-pick: Use a t_class pointer, which is a t_pd. Hm... since the code to add new classes to the list will probably end up looking exactly like the code to add symbols to the symbol table, what if I just bloat the _symbol struct by adding a t_class *s_class? Would that affect performance? it would break binary compatibility. there's no good reason to add hash-like lookups to t_symbol (your only reason is convenience). true, there's an s_thing there, but that's mainly for performance reasons (looking up symbol-class mappings is usually outside a performance critical path)(and having s_thing in t_symbol is very ugly) Then searching for an existing class would be easy-- just do a gensym and check if its s_class exists. but checking whether a class exists, is as simple as calling zgetfn on pd_objectmaker. i think this is _quite_ easy. fgmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] from t_symbol to t_class
- Original Message - From: IOhannes zmölnig zmoel...@iem.at To: pd-dev@iem.at Cc: Sent: Saturday, January 12, 2013 9:27 AM Subject: Re: [PD-dev] from t_symbol to t_class On 01/12/2013 12:04 AM, Jonathan Wilkes wrote: In C would I just make a struct with fields of t_symbol, t_class, and a pointer to link to the next one? Yeah, a linked list would work fine, probably not as efficient as the c++ hash structure (but lots easier to maintain). One nit-to-pick: Use a t_class pointer, which is a t_pd. Hm... since the code to add new classes to the list will probably end up looking exactly like the code to add symbols to the symbol table, what if I just bloat the _symbol struct by adding a t_class *s_class? Would that affect performance? it would break binary compatibility. there's no good reason to add hash-like lookups to t_symbol (your only reason is convenience). and avoiding code duplication. true, there's an s_thing there, but that's mainly for performance reasons (looking up symbol-class mappings is usually outside a performance critical path)(and having s_thing in t_symbol is very ugly) Then searching for an existing class would be easy-- just do a gensym and check if its s_class exists. but checking whether a class exists, is as simple as calling zgetfn on pd_objectmaker. i think this is _quite_ easy. Well yes. I meant searching for a class and _returning_ a class pointer. So without adding/revising code inside class_new, is creating an instance the only way to get access to the class attributes? -Jonathan fgmasdr IOhannes ___ 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] from t_symbol to t_class
From: Charles Henry czhe...@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Sent: Friday, January 4, 2013 6:17 PM Subject: Re: [PD-dev] from t_symbol to t_class [..] In C would I just make a struct with fields of t_symbol, t_class, and a pointer to link to the next one? Yeah, a linked list would work fine, probably not as efficient as the c++ hash structure (but lots easier to maintain). One nit-to-pick: Use a t_class pointer, which is a t_pd. Hm... since the code to add new classes to the list will probably end up looking exactly like the code to add symbols to the symbol table, what if I just bloat the _symbol struct by adding a t_class *s_class? Would that affect performance? Then searching for an existing class would be easy-- just do a gensym and check if its s_class exists. -Jonathan Chuck ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] from t_symbol to t_class
On 01/04/2013 07:19 AM, Miller Puckette wrote: I think you're safe calling vmess() to pass no arguments to clip_new (for example) - the worst that can happen is the return value (the global newest is zero. If not it's a proper Pd object you can use zgetfn() on to test it for messages. Main problem I see with this is that some classes like select and list are actually several classes that share a name (and which one gets created depends on the arguments sent to vmess()) also, what happens if the object in question accesses some hardware ressource? e.g. [pix_video] will try to grab an available video-source, potentially locking a hardware device. in theory this should not be aproblem, as the object will hopefully be freed by [classinfo] asap, but in practice it might have all kinds of side-effects, starting from short lockups of Pd to launching rockets. gmfad IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] from t_symbol to t_class
- Original Message - From: IOhannes zmölnig zmoel...@iem.at To: pd-dev@iem.at Cc: Sent: Friday, January 4, 2013 4:43 AM Subject: Re: [PD-dev] from t_symbol to t_class On 01/04/2013 07:19 AM, Miller Puckette wrote: I think you're safe calling vmess() to pass no arguments to clip_new (for example) - the worst that can happen is the return value (the global newest is zero. If not it's a proper Pd object you can use zgetfn() on to test it for messages. Main problem I see with this is that some classes like select and list are actually several classes that share a name (and which one gets created depends on the arguments sent to vmess()) also, what happens if the object in question accesses some hardware ressource? e.g. [pix_video] will try to grab an available video-source, potentially locking a hardware device. in theory this should not be aproblem, as the object will hopefully be freed by [classinfo] asap, but in practice it might have all kinds of side-effects, starting from short lockups of Pd to launching rockets. I'd prefer to just inspect the class without creating a new instance but I can't figure out how. Are all t_gobj linked together in one big list? -Jonathan gmfad IOhannes ___ 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] from t_symbol to t_class
On Fri, Jan 4, 2013 at 11:36 AM, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: IOhannes zmölnig zmoel...@iem.at To: pd-dev@iem.at Cc: Sent: Friday, January 4, 2013 4:43 AM Subject: Re: [PD-dev] from t_symbol to t_class On 01/04/2013 07:19 AM, Miller Puckette wrote: I think you're safe calling vmess() to pass no arguments to clip_new (for example) - the worst that can happen is the return value (the global newest is zero. If not it's a proper Pd object you can use zgetfn() on to test it for messages. Main problem I see with this is that some classes like select and list are actually several classes that share a name (and which one gets created depends on the arguments sent to vmess()) also, what happens if the object in question accesses some hardware ressource? e.g. [pix_video] will try to grab an available video-source, potentially locking a hardware device. in theory this should not be aproblem, as the object will hopefully be freed by [classinfo] asap, but in practice it might have all kinds of side-effects, starting from short lockups of Pd to launching rockets. I'd prefer to just inspect the class without creating a new instance but I can't figure out how. Are all t_gobj linked together in one big list? -Jonathan I think the t_gobj are in a list per canvas--see the canvas_dodsp method in g_canvas.c to see how it's done. Classes in Pd exist without having an instance of the class. Once the setup method is called (which for externals will require you to create an instance), the class data structure is created and loaded with all its methods. However, I don't know how to get a pointer to the class, when all you know is the symbol. Within a class, the methods are stored in an array c_methods. See the class definition in m_imp.h. You can dump out all the symbols that have methods by looping over the array from 0 to (c_nmethod-1) and accessing the method's me_name. Chuck ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] from t_symbol to t_class
Sure - canvas_finderror() is an example of how to go through every object in the whole Pd process. cheers M On Fri, Jan 04, 2013 at 09:36:42AM -0800, Jonathan Wilkes wrote: I'd prefer to just inspect the class without creating a new instance but I can't figure out how. Are all t_gobj linked together in one big list? -Jonathan gmfad IOhannes ___ 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] from t_symbol to t_class
I think you're safe calling vmess() to pass no arguments to clip_new (for example) - the worst that can happen is the return value (the global newest is zero. If not it's a proper Pd object you can use zgetfn() on to test it for messages. Main problem I see with this is that some classes like select and list are actually several classes that share a name (and which one gets created depends on the arguments sent to vmess()) cheers Miller On Thu, Jan 03, 2013 at 09:16:27PM -0800, Jonathan Wilkes wrote: Hi list, Since matju couldn't find a way to do this without patching Pd I doubt it's possible, but I want to ask anyway: [symbol clip( | [classinfo] -- spits out a list of methods, or other class attributes, etc. I can check if clip exists using zgetfn I can get a function pointer to clip_new using zgetfn I assume I can assign t_object *instance using my function pointer to clip_new that I got from zgetfn, but since I short circuited the normal way of creating the object I have no way of knowing what kind of args to send it, so it seems like I'm likely to crash. Is there really no way to inspect class foo given symbol foo and proof from zgetfn that foo exists? -Jonathan ___ 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
