[Ktechlab-devel] simulator

[Celelibi]

2008/11/8, Alan Grimes <agrimes at speakeasy.net>:
>> Enumerating case is only possible if the component act like a Finit
>> State Automaton. That may not be the case for every component.
>> Embedding language in javascript fashion is (I think) a bad use of
>> XML.Remember this: "You know you made a poor use of XML when you need
>> some additionnal parsing".
>
> bah!
> That doesn't apply because in our use case, what we are trying to
> encode, as data are programs, which necessarily need to be interpreted,
> no shame in that.
>
> It is absolutely necessary that the user be able to design components.
> So compiled C++ is out of the question.

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.

NB : I don't know much about analogue electronic. I'm more into digital
electronic.

> B. Being able to easily create derived components. IE, specifying that
> "this component is just like that component but here are some specific
> specifications". That way we'd have a model for a darlington pair
> transistor, then when the user finds a datasheet, he can quickly write a
>  specific part specification based on the generic library model.

That means components may have parameters.
I don't see an elegant way for the component to get the parameters and use
them.

I'm not sure inheritance concept could be applied here. Because we don't
have "userland feature" to share between ancestor and decendant.

But right, some component may be specialized.

>
> Multiple inheritance is also important, On-Semi, for example, makes a
> power transistor teamed with a thermal diode. So therefore, we'd have to
> inherit both the transistor model and the thermal diode model and then
> assign them to a heatsink domain which may then be combined with a
> larger heatsink domain in the circuit, to get an accurate model of the
> part.

I'm really not sure you want multiple inheritance.
Saying that "a fan is an engine and blades" is wrong. Take blades, take an
engine, you don't get a fan.

I think the relationship is more like "use a" (composition) than "is a"
(inheritance).

Since there is no feature to share between ancestor and decendant, the
simple inheritance could be seen as "use a" relationship.


>> I'm not against the use of XML, but I think that only simple components
>> should be written in XML. Others may be written in C/C++, compiled as
>> .so and loaded at launch time (or later...).
>
> Linux absolutly, positively, categorically, does not (and will not
> ever), in any way, support that type of dynamically linked libraries. I
> have no idea what gave you the impression that it did.

It DOES. And as far as I know, it always did.
Just man dlopen.

>
> It is conceivably possible that there are kernel calls which may make it
> possible BUT THEY ARE NOT DOCUMENTED, ANYWHERE!!!!, There may even be
> linkers which support that, but once again they are not documented
> anywhere, and there might be user libraries that let you do it but they
> are either so obscure I've never heard of them or so arcane that I'd
> never attempt to use them. I have spent so much time and effort in utter
> frustration that I've had it. I want to design my own OS that loading
> plugins is it's primary and essential function, however, in attempting
> to develop such an OS, I've not only received no support (which is
> expected), I've also been actively thwarted by people who have later
> confessed that they didn't like me so they actively worked to frustrate
> my efforts by banning me from chat rooms and mailing lists. I'm sorry,
> this is a red-hot sore hot-button issue for me.

Even if Linux hadn't dlopen function, there is ne need to use obscure
syscall to implement it.
dlopen is a userland function that you could write yourself using 3 syscalls
: open, mmap and close.
The most arcane may be... mmap I think.
If you dislike mmap, just use malloc and load the .so into memory yourself.
(But don't forget to use mprotect to allow execution).

dlsym just does some basic ELF-format parsing to find the address of an
"object" by its name (by looking up the symtab).


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).



Celelibi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20081109/a1c63485/attachment.html>