<br><br>2008/11/8, Alan Grimes <<a href="mailto:agrimes@speakeasy.net">agrimes@speakeasy.net</a>>:<br>>> Enumerating case is only possible if the component act like a Finit<br>>> State Automaton. That may not be the case for every component.<br>
>> Embedding language in javascript fashion is (I think) a bad use of<br>>> XML.Remember this: "You know you made a poor use of XML when you need<br>>> some additionnal parsing".<br>><br>> bah!<br>
> That doesn't apply because in our use case, what we are trying to<br>> encode, as data are programs, which necessarily need to be interpreted,<br>> no shame in that.<br>><br>> It is absolutely necessary that the user be able to design components.<br>
> So compiled C++ is out of the question.<br><br>A subcircuit like the user could design is nothing else than a set of components and wires. It is a simple component, so XML is just fine.<br><br>NB : I don't know much about analogue electronic. I'm more into digital electronic.<br>
<br>> B. Being able to easily create derived components. IE, specifying that<br>> "this component is just like that component but here are some specific<br>> specifications". That way we'd have a model for a darlington pair<br>
> transistor, then when the user finds a datasheet, he can quickly write a<br>>  specific part specification based on the generic library model.<br><br>That means components may have parameters.<br>I don't see an elegant way for the component to get the parameters and use them.<br>
<br>I'm not sure inheritance concept could be applied here. Because we don't have "userland feature" to share between ancestor and decendant.<br><br>But right, some component may be specialized.<br><br>><br>
> Multiple inheritance is also important, On-Semi, for example, makes a<br>> power transistor teamed with a thermal diode. So therefore, we'd have to<br>> inherit both the transistor model and the thermal diode model and then<br>
> assign them to a heatsink domain which may then be combined with a<br>> larger heatsink domain in the circuit, to get an accurate model of the<br>> part.<br><br>I'm really not sure you want multiple inheritance.<br>
Saying that "a fan is an engine and blades" is wrong. Take blades, take an engine, you don't get a fan.<br><br>I think the relationship is more like "use a" (composition) than "is a" (inheritance).<br>
<br>Since there is no feature to share between ancestor and decendant, the simple inheritance could be seen as "use a" relationship.<br><br><br>>> I'm not against the use of XML, but I think that only simple components<br>
>> should be written in XML. Others may be written in C/C++, compiled as<br>>> .so and loaded at launch time (or later...).<br>><br>> Linux absolutly, positively, categorically, does not (and will not<br>
> ever), in any way, support that type of dynamically linked libraries. I<br>> have no idea what gave you the impression that it did.<br><br>It DOES. And as far as I know, it always did.<br>Just man dlopen.<br><br>><br>
> It is conceivably possible that there are kernel calls which may make it<br>> possible BUT THEY ARE NOT DOCUMENTED, ANYWHERE!!!!, There may even be<br>> linkers which support that, but once again they are not documented<br>
> anywhere, and there might be user libraries that let you do it but they<br>> are either so obscure I've never heard of them or so arcane that I'd<br>> never attempt to use them. I have spent so much time and effort in utter<br>
> frustration that I've had it. I want to design my own OS that loading<br>> plugins is it's primary and essential function, however, in attempting<br>> to develop such an OS, I've not only received no support (which is<br>
> expected), I've also been actively thwarted by people who have later<br>> confessed that they didn't like me so they actively worked to frustrate<br>> my efforts by banning me from chat rooms and mailing lists. I'm sorry,<br>
> this is a red-hot sore hot-button issue for me.<br><br>Even if Linux hadn't dlopen function, there is ne need to use obscure syscall to implement it.<br>dlopen is a userland function that you could write yourself using 3 syscalls : open, mmap and close.<br>
The most arcane may be... mmap I think.<br>If you dislike mmap, just use malloc and load the .so into memory yourself. (But don't forget to use mprotect to allow execution).<br><br>dlsym just does some basic ELF-format parsing to find the address of an "object" by its name (by looking up the symtab).<br>
<br><br>dlopen is not an arcane function from an arcane library. It's part of the gnu libc and is conforming to POSIX (like the man says).<br><br><br><br>Celelibi<br>