1. how to write a wrapper?
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?
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
-
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
-
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
-
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
-
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?
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?
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?
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
-
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?
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?
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?
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
