Thursday, 2015-02-19

drobillafalktx: The feature structs do it00:04
drobillaThat bool parameter seems like the best way, though I dislike the prototype not being exactly the C one less a handle00:05
drobillaI think I might go with the Derived thing00:06
drobillaIt means the entire wrapper can be tidily wrapped in a class, much of it private00:07
drobillaSurely inheriting from Plugin<MyPlug> or Lib<MyLib> isn't *that* weird00:07
drobillaIt's a mixin, but it's not a huge list of them with fancy delegation and template metaprogramming and all that.  Relatively straightforward, and all you have to do or understand is to inherit like that00:08
falktxyeah, I'm going with that route too, but the static parts need to be better handled00:09
drobillaHm, I think the C entry point can just be "return new ..." this way00:12
falktxwith a try/catch please00:13
drobilla?00:13
drobillaI guess.........00:13
falktxwhat happens if a C host tries to load a plugin that throws during instantiate?00:14
drobillaI would ideally like to avoid exceptions entirely.  Maybe more embedded folks even want to compile without00:14
drobillaBad things? :)00:14
drobillaI'll look into it00:14
drobillaconst violations oh my00:21
*** gianMOD has quit IRC00:24
drobillaooh, the names clash00:27
drobillahrm00:27
falktxdrobilla: btw, LV2_SYMBOL_EXPORT is missing from lv2_lib_descriptor00:37
drobillafalktx: Yeah, just noticed that.00:39
drobillaI can't help but think that with <Derived> in there, mixin methods can happen00:45
drobillaI guess we'll see how interfaces work out without00:45
falktxI'm not really sure how interfaces can work00:46
falktxit needs to be static00:47
falktxhow can it be extended like that?00:47
falktxwe need some global pointer00:48
drobillaHm, that trick doesn't work for Plugin.  You need a Descriptor *without* instantiating the class.00:49
drobillafalktx: MyPlug() : MyExt<MyPlug>(this)00:50
drobillaMyExt::whatever() { plug->whatever(); }00:50
drobillaHm, I guess it could cast self to Derived, too, if it's inherited.  downcast though00:51
falktxextension_data is a static function, created before the plugin is initialized00:51
drobillayep.00:51
drobillahm.00:52
drobillaThat part's weird.00:52
drobillaSame problem I just hit, essentially.00:52
falktxI'm not seeing how one can add new stuff to it externally00:52
drobillaThe descriptor is a descriptor of the class, but C++ classes are not first class.00:52
falktxwell, for me I have "static const LV2_Descriptor* createDescriptor(const char* uri)"00:52
falktxthat gets called somewhere in lv2_lib_descriptor for all plugins00:53
falktxof course, a reverse "destroyDescriptor" is needed in this case00:54
Haskellfant  (setq helm-command-prefix-key "C-c h")00:54
Haskellfantups sry00:54
falktxbut anyway, lv2-extension-data, can't see how one will add stuff externally00:54
drobillaI have all that working, but need to think how extension_data works00:54
drobillaIt's a static method, so...00:54
drobillaThis kind of ruins 99% of the point of <Derived> but lemme see00:55
drobillaMaybe messing up user code so the header (who cares) is cleaner is wrong thinking00:55
drobillaMyPlug::descriptor(uri); is nice though00:56
drobillafalktx: For magic extension_data it seems either mixins, or a vector/whatever of extensions to loop through is necessary01:01
falktxyeah01:02
drobillaI think that might be the end of that valiant effort to not use extension mixins....01:03
drobillaThis could maybe be pushed into some class specifically for handling this that the extensions register with01:04
drobillafalktx: Pushed a version with a lib wrapper, and fully class isolated wrapping stuff01:08
falktxif (!t) delete t; ??01:13
falktxyou're deleting a null pointer01:13
falktxalso c++ "new" never fails, unless using -fno-exceptions afaik01:14
falktxLV2_Lib_Descriptor::cleanup looks wrong too01:16
falktxlv2_lib_descriptor returns "new AmpppLib", which is lv2::Lib01:17
falktxhmm wait, reinterpret_cast<Derived*> is confusing me a bit01:18
falktxis it Derived from plugin or lib?01:18
falktxdrobilla: having those functions marked virtual would be nice01:19
falktxdrobilla: it means devs can use 'override' and detect possible function argument mistakes01:20
falktxwithout override mistakes will go by unnoticed01:20
falktx(I think...)01:20
drobillafalktx: Yeah, that's where the if (!t->valid()) thing should go.01:22
drobillafalktx: Overhead free wrapper.  Period.01:22
drobillaThere are a few contraints that sticking to will make this thing actually get done and not become a rabbit hole and source of potential fuck-up.  That's one of them.01:23
drobillaThere is already too much function call overhead in the current state of things thanks to connect_port(), adding even more is the opposite of what I want to do.01:24
drobillaIf you override it incorrectly you'll get a compile time error because the static wrappers call them with specific arguments01:25
falktxbut some float/int conversion might still happen01:25
drobillaPossibly.01:26
falktxanyway, doesn't look bad yet :)01:27
drobillaThere are a few things you have to go without without a whole 100% RTTI virtual thing01:27
drobillaC'est la vie, this is pretty much a canonical domain where "hey let's be Java!" isn't appropriate.  It's nice enough.01:27
drobillaIt would be nice if C++ had pure non-virtual methods01:28
drobillaI find it a bit amusing how blatantly amppp.cpp shows off the horrors of connect_port :)01:31
drobillarun(), then 6 times as much boilerplate crap for setting buffers in a plugin that would be pure/stateless otherwise01:31
drobillaOkay, so, extension_data(), hmm01:34
*** gianMOD has joined #lv201:35
drobillaMixins really are The way to do this sort of thing01:36
*** gianMOD has quit IRC01:40
drobillaI'm starting to think maybe I don't care01:41
drobillaUser code is what matters01:41
drobillaThe nasty thing is that means two classes per extension mixin, the one you inherit from (to take the required parameter), then the interface nested inside that01:43
drobillaunless ": public Mixins<Worker, false, URIMap, true>" is somehow possible01:46
drobillaOnly alternative to template hackery I can think of is class ExtHandler { ... }01:53
drobillathen require any plugin with extra data to have one as a member, then extension classes take that as a param01:54
drobillaMyPlug() : Worker(_exts, features), URIMap(_exts, features) {}01:54
drobillathen void* extension_data(const char* uri) { return _exts.lookup(uri); }01:54
drobillaFlat inheritance tree, at the cost of having to deal with that manually, if through an object that makes it almost free01:55
drobilla(overhead doesn't matter in this case, it can just be std::map or whatever)01:55
* drobilla idly wonders if we can do all this without using bloody inheritance whatsoever02:22
drobillaHm, actually, the object thing could be a bit cleaner, if you have to *inherit* from ExtensionManager, then Plugin::extension_data could static_cast to that and call it on itself, so user code wouldn't need to write an extension_data02:23
falktxlater02:33
*** falktx has quit IRC02:33
*** zth_studiocomp has quit IRC02:42
*** zth_studiocomp has joined #lv202:42
*** zth_studiocomp has quit IRC03:03
*** zth_studiocomp has joined #lv203:03
*** NickSB2 has quit IRC03:40
*** greenkobold has quit IRC04:32
*** o0o0o has joined #lv204:51
*** edogawa has joined #lv207:56
*** sigma6 has joined #lv208:15
*** ricardocrudo has joined #lv209:22
*** gianMOD has joined #lv209:23
*** NickSB2 has joined #lv209:36
drobillabgola: I implemented RT-safe server side presets09:45
drobillabgola: It's a little strange, not sure it's 100% correct, but seems to work and shouldn't cause dropouts/zombies at least09:45
drobillabgola: The GUI loads them this way now as well09:45
drobillabgola: No query interface yet, but if you know the URI you can set them09:46
*** ddom has joined #lv209:51
*** gianMOD has quit IRC10:00
*** falktx has joined #lv210:32
*** gianMOD has joined #lv211:01
*** gianMOD has quit IRC11:05
*** EntropySink has joined #lv211:15
*** ricardocrudo has quit IRC12:00
*** gianMOD has joined #lv212:02
*** EntropySink has quit IRC12:05
*** EntropySink has joined #lv212:05
*** gianMOD has quit IRC12:06
*** ricardocrudo has joined #lv212:13
*** edogawa_ has joined #lv212:13
*** edogawa has quit IRC12:16
*** ricardocrudo has quit IRC12:30
* falktx wonders if zyn-lv2 can work on osx12:41
falktxhmm starting fltk freezes carla12:45
*** gianMOD has joined #lv213:02
*** gianMOD has quit IRC13:08
*** ricardocrudo has joined #lv213:15
*** gianMOD has joined #lv213:30
*** ricardocrudo_ has joined #lv213:42
*** ricardocrudo has quit IRC13:44
*** HarryHaaren has joined #lv214:15
*** NickSB2 has quit IRC14:29
* HarryHaaren notes interesting email on LV2-dev, been thinking about it, makes sense. Will reply there when I have a coherent response14:56
*** HarryHaaren has quit IRC14:58
*** gianMOD has quit IRC15:29
*** gabrbedd has quit IRC15:34
*** gabrbedd has joined #lv215:36
*** gabrbedd has quit IRC15:44
*** gabrbedd has joined #lv215:44
*** gianMOD has joined #lv215:51
*** EntropySink has quit IRC16:30
*** EntropySink has joined #lv216:30
*** edogawa_ has quit IRC16:32
*** gianMOD has quit IRC16:39
*** gianMOD has joined #lv216:40
*** gianMOD has quit IRC17:49
*** ddom has quit IRC17:50
*** ricardocrudo_ has quit IRC17:56
*** o0o0o has quit IRC17:56
*** gianMOD has joined #lv218:31
*** gianMOD has quit IRC18:35
*** falktx has quit IRC19:16
*** LAbot has joined #lv221:41
*** edogawa has joined #lv222:04
*** gianMOD has quit IRC22:27
*** gianMOD has joined #lv222:31
*** ricardocrudo_ has quit IRC22:31
*** gianMOD has quit IRC23:05
* drobilla realizes sord_validate doesn't check class restrictions at all, just properties23:19
drobillaI wonder what I'll find if I implement that...23:19

Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!