[Texmacs-dev] Re: Compiling TexMacs on OSX

[Henri Lesourd]

Abdelrazak Younes wrote:

> Henri Lesourd wrote:
>
> > The default version of TeXmacs doesn't depends
> > on any Qt lib: we don't want to force a dependency
> > on that.
>
>
> Well, that was my original "concentrate on one frontend" advice if you 
> remember.

As far as I understand, "concentrate on one frontend" is not
the same as "avoid being forced to depend on one underlying
technology of the frontend", but...


> Anyway, if you cannot bear QtXml dependency, you can choose a number 
> of other cross-platform xml library (eg. libxml), which was my point. 
> Of course if you prefer to do it all yourself, that's your choice too.
If you need a standard XML parser, then probably you will use
a lib at some point for this purpose. Otherwise, for saving/loading
your own XML, scratching your own itch is OK, I would say.

Depends on the API of the lib, in fact.


> > Mangling method names, or how exactly the dispatch is performed
> > is hidden inside the compiler, it's blackbox, you cannot change
> > it, and you cannot gain any reliable (i.e.: platform-independent)
> > knowledge about that.
> >
> > Thus you don't enjoy control on these important things.
>
>
> OK, I think this means that I, personally, won't enjoy (in the literal 
> sense) control on these things because, well, I don't think there is 
> much gain in controlling these things, how important they can be.

When there is no control on important things, it usually
goes together with strong limitations in what you can do
in the related areas...


> If I want to do kernel programming, I'll go program a kernel module :-)
The problem is not doing kernel programming: it is that
if you want to be able to recompile and dynamically reload
chunks of code, you must use a well-defined set of techniques,
which are currently not compatible with the current state
of the C++ standard, nor with the current state of linker
technologies.


In the past, there used to be an OS which was able to
store genuine C++ classes in an object file: OS/2.

In the current less sophisticated, C-based OS we currently
use, you can only implement this functionality by means
of unhealthy hacks. Thus finally, the only clean way left
is working at the C level.


Thus there is, on the one hand, a limitation of C++ (which,
as I showed in a previous post, stems from the shortsightedness
of the C++ designers), along with a limitation of the
current operating systems.

This being said, you can very well say that you are not
interested in such more advanced possibilities. But its
very difficult to deny they could exist, and that there
are lots of uses of such technologies, especially in
the domain of implementing more dynamic and more user
hackeable environments.