Re: [vos-d] Fun with the generator
Also spracht Peter Amstutz (Tue, 18 Mar 2008 11:09:24 -0400): > On Mon, Mar 17, 2008 at 07:33:24PM +, Lalo Martins wrote: >> Well. I spun off the web MVC stuff into a new library (hypervos). >> That opened a pandora box of generator fun :-) > > Yea, as you've probably figured out by now, writing good C++ is hard, > but automatically generating good C++ is even harder. :-D >> 2: The #define guards use only the file name. If you have headers with >> the same name in different libraries (eg MVC.hh)... you get my point I >> think. I manually changed them to eg #define _hypervos_MVC_hh_, might >> make the change in the generator later. > > Oops. Yes, the generator should be smarter than that. See my comment > below about directory organization for headers. Fixed in my branch (assuming we agree _hypervos_MVC_hh_ is good enough). >> 3: Much worse happens if you have namespaces with the same name :-) the >> generated code has things like MVC::View all over, which of course >> generate "ambiguous namespace reference" errors galore. > > This is a bit of a pathalogical case, although hopefully now you see the > reason for the site_xxx namespace. > > The brute force solution would be to have the generator go ahead and > qualify everything with the excessively long site_xxx namespace, which I > was trying to avoid purely for the sake of readability. Ah no, you're taking it a step further. I'm referring to VOS Namespace objects, not C++ namespaces in general. See, you already solved this problem ;-) since we encourage each library to ship one Library object, named the same as the library, and then a number of Namespace objects inside it. Splitting a (VOS) Library in different (C++) libraries and/or directories would, yes, be a problem, but we'll cross that bridge when there is even water on the river ;-) What I'm talking about is... - Site 0011223344556677889900aabbccddee - Library vos - Namespace MVC - Site 6879706572766f73203474656877696e - Library hypervos - Namespace MVC See? So that could be handled in C++ (and it's how I solved it by manually editing the files, but that means I can't atm run the generator on mod_vos or my other project) by qualifying it with vos::MVC:: or hypervos::MVC:: >> 4: This is unrelated to the hypervos move, I noticed it earlier. If my >> class "Foo" extends "vos::core::Bar", then Foo.hh will have #include >> "Bar.hh" >> which of course won't work so well... should be :-) > > Since I was originally focused on getting the libvos core to work, I > didn't give too much thought to how the C++ headers should be explictly > organized into directories. Again, the brute force solution would be to > have the headers mimic the namespace up to and including the site, which > would be horribly verbose but would eliminate most of the ambigious > cases. Again, you're forgetting we already have the handy Library object, which I'd like to encourage developers to keep unique-ish. So would do it (and, bonus of bonuses, already works with our current layout!), and it's what I made the generator do, in my branch. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Fun with the generator
On Mon, Mar 17, 2008 at 07:33:24PM +, Lalo Martins wrote: > Well. I spun off the web MVC stuff into a new library (hypervos). That > opened a pandora box of generator fun :-) Yea, as you've probably figured out by now, writing good C++ is hard, but automatically generating good C++ is even harder. > Also, I'm not saying these need to be fixed urgently; just that we need > to know about them for the future. I'm not surprised by any of these limitations you ran in to, I've been planning on fixing them when it became a real problem. > 1: mod_vos.xod (and my other projects) extend a lot of classes from the > new library. But since the generator doesn't know about those, it > reports broken links and generally doesn't know what to do. > > The answer to this may be in my plugin loader; I might try my hand at > solving it later this week. At the moment, external libraries can successfully import from the main VOS namespace because it is available in the generator by virtue of being compiled into libvos. However, it should be able to import from other libraries in general. A stopgap solution would be to add an option to the to generator pre-load additional XOD files. Eventually we should have a general set of strategies for searching for site replicas (local repositories, going on line, possibly extracting them from executables) so finding and importing an interface library will be no different from accessing and replicating any other vobject site (be it a 3d world, hypervos, etc). I do like the idea of using the plugin loader to ask a binary library what its interface is. > 2: The #define guards use only the file name. If you have headers with > the same name in different libraries (eg MVC.hh)... you get my point I > think. I manually changed them to eg #define _hypervos_MVC_hh_, might > make the change in the generator later. Oops. Yes, the generator should be smarter than that. See my comment below about directory organization for headers. > 3: Much worse happens if you have namespaces with the same name :-) the > generated code has things like MVC::View all over, which of course > generate "ambiguous namespace reference" errors galore. This is a bit of a pathalogical case, although hopefully now you see the reason for the site_xxx namespace. The brute force solution would be to have the generator go ahead and qualify everything with the excessively long site_xxx namespace, which I was trying to avoid purely for the sake of readability. > 4: This is unrelated to the hypervos move, I noticed it earlier. If my > class "Foo" extends "vos::core::Bar", then Foo.hh will have > #include "Bar.hh" > which of course won't work so well... should be :-) Since I was originally focused on getting the libvos core to work, I didn't give too much thought to how the C++ headers should be explictly organized into directories. Again, the brute force solution would be to have the headers mimic the namespace up to and including the site, which would be horribly verbose but would eliminate most of the ambigious cases. > 5: Just to put in a positive note and because I like the number 5 better > than 4, I'll say I found great joy in recent s5 work; in particular > Vobject::clone() saved me hours of toil! That's good to hear :-) I slipped that one in as part of the template stuff I did (which you should take a look at, by the way.) -- [ Peter Amstutz ][ [EMAIL PROTECTED] [EMAIL PROTECTED] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ] signature.asc Description: Digital signature ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Fun with the generator
Also spracht Lalo Martins (Mon, 17 Mar 2008 19:33:24 +): > 1: mod_vos.xod (and my other projects) extend a lot of classes from the > new library. But since the generator doesn't know about those, it > reports broken links and generally doesn't know what to do. > > The answer to this may be in my plugin loader; I might try my hand at > solving it later this week. > > 2: The #define guards use only the file name. If you have headers with > the same name in different libraries (eg MVC.hh)... you get my point I > think. I manually changed them to eg #define _hypervos_MVC_hh_, might > make the change in the generator later. > > 3: Much worse happens if you have namespaces with the same name :-) the > generated code has things like MVC::View all over, which of course > generate "ambiguous namespace reference" errors galore. > > 4: This is unrelated to the hypervos move, I noticed it earlier. If my > class "Foo" extends "vos::core::Bar", then Foo.hh will have #include > "Bar.hh" > which of course won't work so well... should be :-) > > 5: Just to put in a positive note and because I like the number 5 better > than 4, I'll say I found great joy in recent s5 work; in particular > Vobject::clone() saved me hours of toil! Fixed 2 and 4 today, may tackle 1 or 3 tomorrow. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Fun with the generator
Well. I spun off the web MVC stuff into a new library (hypervos). That opened a pandora box of generator fun :-) I'm a bit exhausted, so I'll go over them briefly; if you need more detail, ask, and I'll elaborate tomorrow. Or check out my branch and play around yourself. Also, I'm not saying these need to be fixed urgently; just that we need to know about them for the future. 1: mod_vos.xod (and my other projects) extend a lot of classes from the new library. But since the generator doesn't know about those, it reports broken links and generally doesn't know what to do. The answer to this may be in my plugin loader; I might try my hand at solving it later this week. 2: The #define guards use only the file name. If you have headers with the same name in different libraries (eg MVC.hh)... you get my point I think. I manually changed them to eg #define _hypervos_MVC_hh_, might make the change in the generator later. 3: Much worse happens if you have namespaces with the same name :-) the generated code has things like MVC::View all over, which of course generate "ambiguous namespace reference" errors galore. 4: This is unrelated to the hypervos move, I noticed it earlier. If my class "Foo" extends "vos::core::Bar", then Foo.hh will have #include "Bar.hh" which of course won't work so well... should be :-) 5: Just to put in a positive note and because I like the number 5 better than 4, I'll say I found great joy in recent s5 work; in particular Vobject::clone() saved me hours of toil! best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
