1. how to write a wrapper?
- Posted by Jules <jdavy at dsl.pip?x.co?> Aug 02, 2007
- 503 views
most of the Euphoria "heavyweights" (as opposed to the "lightweights", like me) devote much of their time and effort into wrapping libraries to extend Eu's functionality. I understand the basic mechanics of this: There are actually 3 steps to go through. 1/ Your wrapper must open a shared file (.dll on Windows, .so on Linux/BSD) using open_dll() (be sure to include machine.e). This function will return some atom I'll call entry_point. 2/ For each routine you need to wrap, define a constant representing that routine using defie_c_func (or _proc): constant the_func=define_c_func(entry_point,func_name,arg_type_list,return_type) You can also access public variables using define_c_var(). 3/ Then, in any program using the routines, including your own wrapper, you use c_func() or c_proc() to call the routine, using the identifiers defined in stage 2 as routine ids. And that should be all, unless you have to fiddle with calling convention. If the doc for your dll talks about cdecl, then there is a specific syntax to use in define_c_func. (thanks to CChris for this post). I'd like to have a go at writing a simple wrapper but am unsure where to start. I assume I don't need much knowledge of C, but surely I need some? and if so, what, particularly? I don't (hopefully) need spoon-feeding, but if someone could point me in the right direction, that would be great. I'm sure there are many other Eu coders who would like to see a tutorial on this subject. I'd be happy to write one myself, once I've learned the basics.
2. Re: how to write a wrapper?
- Posted by Andy <videogamefreak101 at hot?ai?.com> Aug 02, 2007
- 489 views
You should only be fine with a reference to c. Just go over some documentation of C and you should be fine.
3. Re: how to write a wrapper?
- Posted by Jules <jdavy at d?l.pip?x.com> Aug 02, 2007
- 490 views
- Last edited Aug 03, 2007
Andy wrote: > > You should only be fine with a reference to c. Just go over some documentation > of C and you should be fine oh dear, I've been (politely) RTFM'ed. probably better if I post something specific. I'll get as far as I can and when stuck I'll return. Thanks anyway.
4. Re: how to write a wrapper?
- Posted by CChris <christian.cuvier at agri?ulture.gouv.?r> Aug 02, 2007
- 494 views
- Last edited Aug 03, 2007
Jules wrote: > > Andy wrote: > > > > You should only be fine with a reference to c. Just go over some > > documentation > > of C and you should be fine > > oh dear, I've been (politely) RTFM'ed. > > probably better if I post something specific. I'll get as far as I can and > when > stuck I'll return. > > Thanks anyway. You need three things actually: 1/ A fair idea of what the dll/so you wrap has inside. You'll get this knowledge from the documentation of the shared file, which may or may not be suitably organised. In some cases, feedback from users, if available, may help. 2/ A fair idea of what the ysers of your wrapper would like to do with it, and which sort of pivture of what the hared lib handles they have. The most important, because you are the one who is going to translate the shared lib's ressources into stuff users may have interest in and can grok. No C so far. 3/ The knowledge, from the documentation of the shared file, of the prototypes of the routines/vars you are going to use from the lib. You have to know what is a char, signed or not, a wchar, a tchar, an int and perhaps all sorts of fancy things. Pointers are well handled by the C_POINTER data type in the define_c_*() definition sequence, so the issue isn't as big as one would think. That's the only place some basic knowledge of C is needed. Unless you need to understand the source of the lib, if available. That's another matter. Also, remember that things are straightforward for shared libs coded in C, but not quite if they were output by a C++ compiler. I think the doc of fptr.e by M. Lewis contains useful information; I never tried it myself. Looking at the wxEuphoria wrappers is probably even more educational. CChris
5. Re: how to write a wrapper?
- Posted by Matt Lewis <matthewwalkerlewis at gmail?co?> Aug 02, 2007
- 485 views
- Last edited Aug 03, 2007
CChris wrote: > > Also, remember that things are straightforward for shared libs coded in C, but > not quite if they were output by a C++ compiler. I think the doc of fptr.e by > M. Lewis contains useful information; I never tried it myself. Looking at the > wxEuphoria wrappers is probably even more educational. > Heh. Yeah, if you look at the current version, the lesson to be learned is that you should write a C++ wrapper around C++ code and expose a C interface. Matt
6. Re: how to write a wrapper?
- Posted by Jules <jdavy at dsl.?ipex?com> Aug 02, 2007
- 483 views
- Last edited Aug 03, 2007
CChris wrote: > > Jules wrote: > > > > Andy wrote: > > > > > > You should only be fine with a reference to c. Just go over some > > > documentation > > > of C and you should be fine > > > > oh dear, I've been (politely) RTFM'ed. > > > > probably better if I post something specific. I'll get as far as I can and > > when > > stuck I'll return. > > > > Thanks anyway. > > You need three things actually: > > 1/ A fair idea of what the dll/so you wrap has inside. You'll get this > knowledge > from the documentation of the shared file, which may or may not be suitably > organised. In some cases, feedback from users, if available, may help. > > 2/ A fair idea of what the ysers of your wrapper would like to do with it, and > which sort of pivture of what the hared lib handles they have. The most > important, > because you are the one who is going to translate the shared lib's ressources > into stuff users may have interest in and can grok. > > No C so far. I suppose if the dll is well documented then it may be ok. > > 3/ The knowledge, from the documentation of the shared file, of the prototypes > of the routines/vars you are going to use from the lib. You have to know what > is a char, signed or not, a wchar, a tchar, an int and perhaps all sorts of > fancy things. Pointers are well handled by the C_POINTER data type in the > define_c_*() > definition sequence, so the issue isn't as big as one would think. That's the > only place some basic knowledge of C is needed. > > Unless you need to understand the source of the lib, if available. That's > another > matter. > > Also, remember that things are straightforward for shared libs coded in C, but > not quite if they were output by a C++ compiler. I think the doc of fptr.e by > M. Lewis contains useful information; I never tried it myself. Looking at the > wxEuphoria wrappers is probably even more educational. So it looks as though I'll need to at least understand C data types. I've been looking in the archives and came across SWIG/Euphoria, which is supposed to generate wrapper code. I haven't had a close look at it yet, but it seems as though it may ease the burden.
7. Re: how to write a wrapper?
- Posted by Craig Welch <euphoriah at cwelch.o?g> Aug 03, 2007
- 502 views
Jules wrote: > I've been > looking in the archives and came across SWIG/Euphoria, which is supposed to > generate wrapper code. I haven't had a close look at it yet, but it seems as > though it may ease the burden. It will ease the *typing* burden, but it won't help you at all conceptually. -- Craig
8. Re: how to write a wrapper?
- Posted by johnw <mail at j-webst?r.co?uk> Aug 03, 2007
- 518 views
Jules wrote: > > most of the Euphoria "heavyweights" (as opposed to the "lightweights", like > me) devote much of their time and effort into wrapping libraries to extend > Eu's > functionality. I understand the basic mechanics of this: > > There are actually 3 steps to go through. > > 1/ Your wrapper must open a shared file (.dll on Windows, .so on Linux/BSD) > > using open_dll() (be sure to include machine.e). This function will return > some atom I'll call entry_point. > > 2/ For each routine you need to wrap, define a constant representing that > routine using defie_c_func (or _proc): > > constant > the_func=define_c_func(entry_point,func_name,arg_type_list,return_type) > > You can also access public variables using define_c_var(). > > 3/ Then, in any program using the routines, including your own wrapper, > you use c_func() or c_proc() to call the routine, using the identifiers > defined in stage 2 as routine ids. > > And that should be all, unless you have to fiddle with calling convention. > If the doc for your dll talks about cdecl, then there is a specific syntax > to use in define_c_func. > > (thanks to CChris for this post). I'd like to have a go at writing a simple > wrapper but am unsure where to start. I assume I don't need much knowledge of > C, but surely I need some? and if so, what, particularly? I don't (hopefully) > need spoon-feeding, but if someone could point me in the right direction, that > would be great. I'm sure there are many other Eu coders who would like to see > a tutorial on this subject. I'd be happy to write one myself, once I've > learned > the basics. I am in the same boat, a couple of years ago I bought a Velleman usb interface board and it came with a DLL, I managed to hack a wrapper by looking at code writen by others and used it as a template, I was really pleased when it worked and suprised that I had managed to do it, the DLL was well documented and only had a few functions. if I were good at writing wrappers I could use dll's written by far better programmers than me,(just about everyone) and perhaps give me access to code written for specialised tasks.
9. Re: how to write a wrapper?
- Posted by CChris <christian.cuvier at ag?icultur?.gouv.fr> Aug 03, 2007
- 481 views
CChris wrote: > > Jules wrote: > > > > Andy wrote: > > > > > > You should only be fine with a reference to c. Just go over some > > > documentation > > > of C and you should be fine > > > > oh dear, I've been (politely) RTFM'ed. > > > > probably better if I post something specific. I'll get as far as I can and > > when > > stuck I'll return. > > > > Thanks anyway. > > You need three things actually: > > 1/ A fair idea of what the dll/so you wrap has inside. You'll get this > knowledge > from the documentation of the shared file, which may or may not be suitably > organised. In some cases, feedback from users, if available, may help. > > 2/ A fair idea of what the ysers of your wrapper would like to do with it, and > which sort of pivture of what the hared lib handles they have. The most > important, > because you are the one who is going to translate the shared lib's ressources > into stuff users may have interest in and can grok. > > No C so far. > > 3/ The knowledge, from the documentation of the shared file, of the prototypes > of the routines/vars you are going to use from the lib. You have to know what > is a char, signed or not, a wchar, a tchar, an int and perhaps all sorts of > fancy things. Pointers are well handled by the C_POINTER data type in the > define_c_*() > definition sequence, so the issue isn't as big as one would think. That's the > only place some basic knowledge of C is needed. > > Unless you need to understand the source of the lib, if available. That's > another > matter. > > Also, remember that things are straightforward for shared libs coded in C, but > not quite if they were output by a C++ compiler. I think the doc of fptr.e by > M. Lewis contains useful information; I never tried it myself. Looking at the > wxEuphoria wrappers is probably even more educational. > > CChris A couple things I forgot mentioning: 3'/ The documentation for define_c_func() states that <quote> Parameter types which use 4 bytes or less are all passed the same way, so it is not necessary to be exact when choosing a 4-byte parameter type. However the distinction between signed and unsigned may be important when you specify the return type of a function. </quote> As a result, you can get along with only 4 data type declaration: C_FLOAT (32 bit fp numbers, nothing else), C_DOUBLE (64 bit fp numbers, nothing else), C_LONG (anything else signed), C_POINTER (anything else unsigned). Using more precise datatypes helps memorising or making sense of the prototypes, but doesn't really matter. As you can see, you even don't have much to know about C data types - just grab the difference between fp and non fp, 32 and 64 bit fp, signed and unsigned data. 4/I have found very useful to document things as you create them. This technique allows to detct inconsistencies, redundancy and areas still to cover. Perhaps that's just me, but I'm mentioning it just in case. This strategy initially slows down development, but considerably shortend later stages. It also applies for any development, not only wrappers. CChris
10. Re: how to write a wrapper?
- Posted by don cole <doncole at pac?e?l.net> Aug 04, 2007
- 458 views
- Last edited Aug 05, 2007
CChris wrote: > > CChris wrote: > > > > Jules wrote: > > > > > > Andy wrote: > > > > > > > > You should only be fine with a reference to c. Just go over some > > > > documentation > > > > of C and you should be fine > > > > > > oh dear, I've been (politely) RTFM'ed. > > > > > > probably better if I post something specific. I'll get as far as I can and > > > when > > > stuck I'll return. > > > > > > Thanks anyway. > > > > You need three things actually: > > > > 1/ A fair idea of what the dll/so you wrap has inside. You'll get this > > knowledge > > from the documentation of the shared file, which may or may not be suitably > > organised. In some cases, feedback from users, if available, may help. > > > > 2/ A fair idea of what the ysers of your wrapper would like to do with it, > > and > > which sort of pivture of what the hared lib handles they have. The most > > important, > > because you are the one who is going to translate the shared lib's > > ressources > > into stuff users may have interest in and can grok. > > > > No C so far. > > > > 3/ The knowledge, from the documentation of the shared file, of the > > prototypes > > of the routines/vars you are going to use from the lib. You have to know > > what > > is a char, signed or not, a wchar, a tchar, an int and perhaps all sorts of > > fancy things. Pointers are well handled by the C_POINTER data type in the > > define_c_*() > > definition sequence, so the issue isn't as big as one would think. That's > > the > > only place some basic knowledge of C is needed. > > > > Unless you need to understand the source of the lib, if available. That's > > another > > matter. > > > > Also, remember that things are straightforward for shared libs coded in C, > > but > > not quite if they were output by a C++ compiler. I think the doc of fptr.e > > by > > M. Lewis contains useful information; I never tried it myself. Looking at > > the > > wxEuphoria wrappers is probably even more educational. > > > > CChris > > A couple things I forgot mentioning: > 3'/ The documentation for define_c_func() states that > <quote> > Parameter types which use 4 bytes or less are all passed the same way, so it > is not necessary to be exact when choosing a 4-byte parameter type. However > the distinction between signed and unsigned may be important when you specify > the return type of a function. > </quote> > As a result, you can get along with only 4 data type declaration: C_FLOAT (32 > bit fp numbers, nothing else), C_DOUBLE (64 bit fp numbers, nothing else), > C_LONG > (anything else signed), C_POINTER (anything else unsigned). Using more precise > datatypes helps memorising or making sense of the prototypes, but doesn't > really > matter. As you can see, you even don't have much to know about C data types > - just grab the difference between fp and non fp, 32 and 64 bit fp, signed and > unsigned data. > > 4/I have found very useful to document things as you create them. This > technique > allows to detct inconsistencies, redundancy and areas still to cover. Perhaps > that's just me, but I'm mentioning it just in case. This strategy initially > slows down development, but considerably shortend later stages. It also > applies > for any development, not only wrappers. > > CChris What does fp stand for? Floating Point? I whole heartedly agree with and now document the symplest of my programs. Because as someone else pointed out, You may write some thing like: function ar43(sequence b1, sequence b2) return getdec(b1)+64 * getdec(b2)/144 end function You may understand this at the time of the writing. But go back to it six months from now and say "What the **** is this?" Don Cole
11. Re: how to write a wrapper?
- Posted by CChris <christian.cuvier at agriculture?gouv.fr> Aug 05, 2007
- 479 views
don cole wrote: > > CChris wrote: > > > > CChris wrote: > > > > > > Jules wrote: > > > > > > > > Andy wrote: > > > > > > > > > > You should only be fine with a reference to c. Just go over some > > > > > documentation > > > > > of C and you should be fine > > > > > > > > oh dear, I've been (politely) RTFM'ed. > > > > > > > > probably better if I post something specific. I'll get as far as I can > > > > and > when</font></i> > > > > stuck I'll return. > > > > > > > > Thanks anyway. > > > > > > You need three things actually: > > > > > > 1/ A fair idea of what the dll/so you wrap has inside. You'll get this > > > knowledge > > > from the documentation of the shared file, which may or may not be > > > suitably > > > organised. In some cases, feedback from users, if available, may help. > > > > > > 2/ A fair idea of what the ysers of your wrapper would like to do with it, > > > and > > > which sort of pivture of what the hared lib handles they have. The most > > > important, > > > because you are the one who is going to translate the shared lib's > > > ressources > > > into stuff users may have interest in and can grok. > > > > > > No C so far. > > > > > > 3/ The knowledge, from the documentation of the shared file, of the > > > prototypes > > > of the routines/vars you are going to use from the lib. You have to know > > > what > > > is a char, signed or not, a wchar, a tchar, an int and perhaps all sorts > > > of > > > fancy things. Pointers are well handled by the C_POINTER data type in the > > > define_c_*() > > > definition sequence, so the issue isn't as big as one would think. That's > > > the > > > only place some basic knowledge of C is needed. > > > > > > Unless you need to understand the source of the lib, if available. That's > > > another > > > matter. > > > > > > Also, remember that things are straightforward for shared libs coded in C, > > > but > > > not quite if they were output by a C++ compiler. I think the doc of fptr.e > > > by > > > M. Lewis contains useful information; I never tried it myself. Looking at > > > the > > > wxEuphoria wrappers is probably even more educational. > > > > > > CChris > > > > A couple things I forgot mentioning: > > 3'/ The documentation for define_c_func() states that > > <quote> > > Parameter types which use 4 bytes or less are all passed the same way, so it > > is not necessary to be exact when choosing a 4-byte parameter type. However > > the distinction between signed and unsigned may be important when you > > specify > > the return type of a function. > > </quote> > > As a result, you can get along with only 4 data type declaration: C_FLOAT > > (32 > > bit fp numbers, nothing else), C_DOUBLE (64 bit fp numbers, nothing else), > > C_LONG > > (anything else signed), C_POINTER (anything else unsigned). Using more > > precise > > datatypes helps memorising or making sense of the prototypes, but doesn't > > really > > matter. As you can see, you even don't have much to know about C data types > > - just grab the difference between fp and non fp, 32 and 64 bit fp, signed > > and > > unsigned data. > > > > 4/I have found very useful to document things as you create them. This > > technique > > allows to detct inconsistencies, redundancy and areas still to cover. > > Perhaps > > that's just me, but I'm mentioning it just in case. This strategy initially > > slows down development, but considerably shortend later stages. It also > > applies > > for any development, not only wrappers. > > > > CChris > > What does fp stand for? Floating Point? > Yes, C knows about 2 sorts of floating points as defined in IEEE754, and Euphoria knows them too (see atom_to_float32() and atom_to_float64()). I don't know if the bug with Watcom compilers mentioned in the entry for define_c_func() was fixed - didn't check. The doc may have been written for v10.6. CChris > I whole heartedly agree with and now document the symplest of my programs. > Because as someone else pointed out, You may write some thing like: > > function ar43(sequence b1, sequence b2) > return getdec(b1)+64 * getdec(b2)/144 > end function > > You may understand this at the time of the writing. > But go back to it six months from now and say "What the **** is this?" > > Don Cole
12. Re: how to write a wrapper?
- Posted by Jason Gade <jaygade at ?a?oo.com> Aug 05, 2007
- 454 views
CChris wrote: > > I don't know if the bug with Watcom compilers mentioned in the entry for > define_c_func() > was fixed - didn't check. The doc may have been written for v10.6. > > CChris Which bug? Can you give a link please? -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
13. Re: how to write a wrapper?
- Posted by CChris <christian.cuvier at agric?lture.g?uv.fr> Aug 05, 2007
- 496 views
Jason Gade wrote: > > CChris wrote: > > > > I don't know if the bug with Watcom compilers mentioned in the entry for > > define_c_func() > > was fixed - didn't check. The doc may have been written for v10.6. > > > > CChris > > Which bug? Can you give a link please? > > > -- > "Any programming problem can be solved by adding a level of indirection." > --anonymous > "Any performance problem can be solved by removing a level of indirection." > --M. Haertel > "Premature optimization is the root of all evil in programming." > --C.A.R. Hoare > j. From the doc entry for define_c_func(): If you use exw to call a cdecl C routine that returns a floating-point value, it might not work. This is because the Watcom C compiler (used to build exw) has a non-standard way of handling cdecl floating-point return values. Not exactly a compiler bug, but it may introduce some in your code. CChris