Saturday, November 11, 2006
Progress in the Wrappers Collection
The Eiffel Wrapper Libraries Collection is a project to provide SmartEiffel bindings to several commonly used Free libraries. Since its announcement in March, it has come a long way. GTK+ bindings (which includes GDK, Glib, Gobject and Pango) are quite usable now and planning a beta release soon. Also included are libglade bindings, so you can now develop GUI Eiffel applications with a RAD builder.
There is a lot of work in progress into the database APIs too.
And a recent newcomer to the collection is a wrapper to the ffmpeg library, also at a usable level (want to do real time video playback in Eiffel? now you can!).
Of course, anyone interested in contributing more libraries (or time to help with the existing one) is welcome.
There is a lot of work in progress into the database APIs too.
And a recent newcomer to the collection is a wrapper to the ffmpeg library, also at a usable level (want to do real time video playback in Eiffel? now you can!).
Of course, anyone interested in contributing more libraries (or time to help with the existing one) is welcome.
posted by Daniel F Moisset @ 13:35 
Comments:
<< Home
Thanks for the update! Are any of these wrappers defining classes to match classifiers in their libraries, or are they all just flat bindings?
berend, I am curious about how does EWG guess about how to manage memory handling of C structures automatically... there is some information about pointer ownership which is only in the documentation (that is, in the lucky times when documentation is clear about it instead of forcing us to dig into the library code). Any insight about it should be useful for our work, I thought that part of what we were doing had to be done manually.
joe: what do you mean by "match classifiers"? If you mean wrapping each kind of structure with a different Eiffel class instead of just having a bunch of "externals", we are doing it the nice way.
It would be better if it was using the supported and standardized C/C++ inline mechanism. You could achieve a better portability among Eiffel compilers.
emmanuel: we are using externals, but just adding some higher-level wrapping about it (better types, genericity, assertions).
The issue is I've seen some external using the plug-in mechanism which is not standard, and when wrapping structure, it uses the old syntax which ECMA decided to abandon in favor of the new inline mechanism.
Jose, the inline mechanism enables you to write block of C code in Eiffel without having to write a C external module.
Jose, the inline mechanism enables you to write block of C code in Eiffel without having to write a C external module.
Thank you emmanuel.
The fact is that I had missed the point that ECMA had standardized the use of "C inline" construct.
In parenthesis, do you know how to deal with structures? for exemple the function stat.
Anyway, even if I share your doubt about portability of plugins, the wrapper collection is currently intended to be specific to SmartEiffel. Any comment Paolo?
The fact is that I had missed the point that ECMA had standardized the use of "C inline" construct.
In parenthesis, do you know how to deal with structures? for exemple the function stat.
Anyway, even if I share your doubt about portability of plugins, the wrapper collection is currently intended to be specific to SmartEiffel. Any comment Paolo?
Hi Jose, wrapping a C structure access in Eiffel using the C inline mechanism is exactly the same as in C.
That is to say:
struct RECT {
int x, y, width, height;
}
get_x (p: POINTER): INTEGER is
external
"C inline use <whatever_defining_RECT.h>"
alias
"return (EIF_INTEGER) ((struct RECT *) $p)->x;"
end
That is to say:
struct RECT {
int x, y, width, height;
}
get_x (p: POINTER): INTEGER is
external
"C inline use <whatever_defining_RECT.h>"
alias
"return (EIF_INTEGER) ((struct RECT *) $p)->x;"
end
I'm grouping all the answer all you deserve for your interest in those wrappres.
* Joe (12 nov) those wrappers are fully oo. Currently they are not "complete" wrappers. Agent enabled and inheritance-based callbacks, GList, GSList are generic (for the wrappers) and heirs of the proper COLLECTION, multiple inheritance is used in place of interfaces.
* Dear Berend, EWG does not wrap macros. We do. EWG - as Daniel wrote - does not address many cases in memory handling as we are trying to do: it provides only shared/unshared wrappers. EWG's GTK wrappers are far behind those currently provided by EWLC. Since I have tried to help Andreas for a while to write those wrappers I can say it. The reasons why I stopped helping Andreas is that it is painfully difficoult - at least for me - to support multiple compiler when I use just the GNU compiler and the other one more used were still proprietary. Many things weren't just possible with the time I could spend on such a project, i.e.: writing generic wrappers for things like GList. So I has to choose either to trying to continue to use EWG without finishing anything or trying to concentrate on the compiler I use, on "free as in freedom" software. I chose the second.
* As a side note, writing the low-level wrappers, is not as time consuming as you think. I spend most of the time (~80%) writing the high-level OO classes. Infact I've a small set of Emacs's query-replace-regexp that greatly hasten writing such externals classes.
* Emmanuel, we do use inline mechanism when necessary. Since I'm quite a lazy person I tend to write:
get_x (p: POINTER): INTEGER is
external "C struct RECT get x use < rect.h>"
end
I know it is SmartEiffel-specific. Our project's target is first to create a fairly complete, usable and extensive set of library wrappers for the GNU compiler. Then, and only then we would consider supporting other "Free as in freedom" compilers (namely ISE) IF we will have enough resources; when I started ISE were still proprietary; there are issues about ISE's "freedom" that I hope to discuss before Christmas (i.e. GPLed libraries).
Post a Comment
* Joe (12 nov) those wrappers are fully oo. Currently they are not "complete" wrappers. Agent enabled and inheritance-based callbacks, GList, GSList are generic (for the wrappers) and heirs of the proper COLLECTION, multiple inheritance is used in place of interfaces.
* Dear Berend, EWG does not wrap macros. We do. EWG - as Daniel wrote - does not address many cases in memory handling as we are trying to do: it provides only shared/unshared wrappers. EWG's GTK wrappers are far behind those currently provided by EWLC. Since I have tried to help Andreas for a while to write those wrappers I can say it. The reasons why I stopped helping Andreas is that it is painfully difficoult - at least for me - to support multiple compiler when I use just the GNU compiler and the other one more used were still proprietary. Many things weren't just possible with the time I could spend on such a project, i.e.: writing generic wrappers for things like GList. So I has to choose either to trying to continue to use EWG without finishing anything or trying to concentrate on the compiler I use, on "free as in freedom" software. I chose the second.
* As a side note, writing the low-level wrappers, is not as time consuming as you think. I spend most of the time (~80%) writing the high-level OO classes. Infact I've a small set of Emacs's query-replace-regexp that greatly hasten writing such externals classes.
* Emmanuel, we do use inline mechanism when necessary. Since I'm quite a lazy person I tend to write:
get_x (p: POINTER): INTEGER is
external "C struct RECT get x use < rect.h>"
end
I know it is SmartEiffel-specific. Our project's target is first to create a fairly complete, usable and extensive set of library wrappers for the GNU compiler. Then, and only then we would consider supporting other "Free as in freedom" compilers (namely ISE) IF we will have enough resources; when I started ISE were still proprietary; there are issues about ISE's "freedom" that I hope to discuss before Christmas (i.e. GPLed libraries).
<< Home
