On 20/01/2013, at 10:36 PM, john skaller wrote:
>
> On 20/01/2013, at 6:37 PM, Michael Maul wrote:
>
>> Why is it gone?
>
> Lack of resources to maintain it.
Just so you understand: for it to work, it has to parse ALL of your header
files. The WHOLE system (after pre-processing).
There's no other way with rubbish like C. All the system headers have
to be parsed. The pre-processor inserts #line directives so we know
where definitions come from.
Unfortunately, many header files depend on flags, and some depend
on previously included header files .. so the contents of a #include
section of a file isn't invariant.
So an annotation file is needed to control the scanning process to
tell it how to fix the stupidity of the C language and pre-processor.
Naturally that annotation file is not only platform dependent,
its different on every individual build, and it changes on every
upgrade of anything.
A fully automatic scan with annotations takes a long time,
and it fails every time, so you just keep adjusting the annotations
to get around the last problem. For example skipping C++
header file some moron thought was cool to end in .h instead of .hpp.
You also have to tell it where all the files come from and that has to
be fed to the pre-processor, and it has to agree with the settings
use by your actual compiler.
When you have everything you have a major problem resolving type
names. You cannot just lift every type name into felix, some are aliases.
And you also cannot use the names they're aliases FOR either!
For example you must not use "int" when the alias says "machine_word"
because it would be wrong on x86_64.
So for every typename you have to decide what to do with it:
make a binding, make a typedef, or just get rid of it.
Then you have to generate function interfaces with a canonical
set of these type names: sometimes you want the core name,
but sometimes you want an alias: it depends on whether the target
library changes the alias with the platform or not. An alias like
machine_word will change types. An alias like SDL_int64 will not.
Then, some of the types have to be made into cstructs so that
we can access the components. Its hard to know whether a type
should be abstract or not.
Every issue that flxcc faces and you have to annotate like this
is an example of why C is the most appalling awful crappy rubbish
language in existence: it simply cannot distinguish abstractions,
discrete types, non-portable types, portable types, etc.
It's really hard to even tell what to do with enums. Is it a bitmask?
Is it an enumeration? If its an enumeration is it sequential?
Can the enums be added or are the discrete?
Then you get to functions, and is that really a void*?
How do you represent a C function pointer in Felix?
Flxcc can actually detect when a function is a callback registration
function or an actual callback in 90% of cases. I had to add
a special callback feature to Felix to get around the fact that
synthesised function type names cannot be guessed at by
the Felix client programmer. Callbacks get wrapped so
you can supply a Felix closure instead of a C function
and a void *client data.
What do you do with an incomplete scan, where you have a type
you know nothing about?
So the end result of this process: you get a binding for say GSL.
It isn't right, it doesn' compile, but you can edit it, and eventually
it will compile under Felix. You can even test 2 or 3 functions to
make sure you can link and run a bit of it.
After that you need a GSL guru to maintain the binding,
and in particular, make tests for everything, and, adjust the way
types are handled and functions are wrapped, so its more
"Felix like". For example GSL is like many C science libraries,
it has functions for every combination of float, double, long double,
complex, double complex, int, long .. ALL of which could be done
in Felix with a single polymorphic function.
At which point you begin to wonder why bother binding to a library
when it is probably easier to write a new one from scratch.
Libraries that use macros are a nightmare because the pre-procesor
eliminates them. So you have to parse the C source file *without*
pre-processing as well.
In the old Felix, I actually wrote Python scripts (in Interscript)
to do some of this for specific libraries. This turned out to be
easier because you can add as many library specific hacks
and kludges to the Python script, and for the next library
you copy the script and edit it.
It's all very tricky! SDL binding (which was generated by flxcc first
then painfully hand edited) broke because I changed the Felix
integer model so all integer types are distinct. It used to be that
int64, intptr, etc were aliases exactly as they were in C.
But that doesn't work, because the aliases in Felix do not
"change" automatically with the target (except for maybe
the core ones like size_t). And of course types named by
macros cannot change if say SIZE_T resolves to "int"
on a 32 bit machine, the resulting binding to "int" will
be wrong on a 64 bit machine.
The only interfaces that can really be handled properly are ones
like Posix where the Standard make things fairly clear after
you get used to how it operates: we all know a file descriptor
is an abstraction NOT an int.
There is an automatically generated interface to ALL posix functions
in Felix, see
misc/posix.txt
misc/posix_out.txt
misc/www_schweikhardt_net_identifiers.html
Of course, the generated Felix doesn't compile because only the functions
are bound, not the types. Still, you can use "cut and paste" to try to build
a proper complete interface.
Sorry about the rant, just so you'd get some idea what "lack of resources"
means :)
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
