1. RE: Invaid argument type in dll.e
Hi Chris,
The bottom line is, the C routine definitions should never have been
declared with NULL's or 0's. The definition's need to be fixed... This
shouldn't be too difficult but perhaps a bit time consuming. Or you
could wrap define_c_func/proc to check for NULL parameters but then you
still need to replace occurrences of define_c_func/proc to whatever your
wrapper name is.
Personally, I'd just fix the definitions and maybe re-release the fixed
code to the archives.
-- Brian
Chris Burch wrote:
> Hi
>
> I have a headache.
>
> After purchasing eu2.4, I find that a lot of the downloaded programs are
>
> broken, particularly directe and exotica.
>
> The problem lies in dll.e, particularly :-
>
> global function define_c_func(object lib, object routine_name, sequence
> arg_sizes, atom return_type)
> -- define a C function (or machine code routine)
>
> return machine_func(M_DEFINE_C, {lib, routine_name, arg_sizes,
> return_type})
> end function
>
> returns invalid argument type. (usually line 53) This didn't happen in
> eu2.3.
>
> The reason (gathered from previous postings) - and correct me if I'm
> wrong,
> is that some programs pass NULL, and not {}, which is now interpreted in
> eu2.4
> differently.
>
> Having traced thru (in exotica) various files, eg emain.ew,
> ewin32_api.ew,
> and replace various NULLs with {} the errors are changing places, so
> it's
> beginning to work.
>
> However, other solutions could be
>
> 1. Rewrite the eu sorce code to accomodate these different types passed
> to
> the interpreter - so that the error is not returned.
>
> 2. Check the type passed to the define_c_func, and change it to the
> correct
> type in situ so that the error is not returned.
>
> 2 is where my headache started. I've tried various things, checking to
> see if
> what's passed is an object or a sequence, but I am floundering a little,
> and
> any pointers would be greatly appreciated. Also, due to floundering, I'm
> a
> little sparse on detail - sorry.
>
> At the moment, in order to experiment with with direct x, I'm having to
> use
> eu2.3, which is inconvenient more than anything.
>
> Chris
>
2. RE: Invaid argument type in dll.e
Just a note:
There are a number of wrappers for external .dll libraries (zlib,
sqlite, etc.) in the archives that should (now) be using cdecl
declarations instead of stdcall (add "+" before the function name in the
declaration). They happen to work with the interpreter because of a
quirk in Watcom, but will crash if translated to C.
So when making a wrapper, check to see what the proper calling
convention is...
Brian Broker wrote:
>
>
> Hi Chris,
>
> The bottom line is, the C routine definitions should never have been
> declared with NULL's or 0's. The definition's need to be fixed... This
> shouldn't be too difficult but perhaps a bit time consuming. Or you
> could wrap define_c_func/proc to check for NULL parameters but then you
> still need to replace occurrences of define_c_func/proc to whatever your
>
> wrapper name is.
>
> Personally, I'd just fix the definitions and maybe re-release the fixed
> code to the archives.
>
> -- Brian
>
> Chris Burch wrote:
> > Hi
> >
> > I have a headache.
> >
> > After purchasing eu2.4, I find that a lot of the downloaded programs are
> >
> >
> > broken, particularly directe and exotica.
> >
> > The problem lies in dll.e, particularly :-
> >
> > global function define_c_func(object lib, object routine_name, sequence
> > arg_sizes, atom return_type)
> > -- define a C function (or machine code routine)
> >
> > return machine_func(M_DEFINE_C, {lib, routine_name, arg_sizes,
> > return_type})
> > end function
> >
> > returns invalid argument type. (usually line 53) This didn't happen in
> > eu2.3.
> >
> > The reason (gathered from previous postings) - and correct me if I'm
> > wrong,
> > is that some programs pass NULL, and not {}, which is now interpreted in
> >
> > eu2.4
> > differently.
> >
> > Having traced thru (in exotica) various files, eg emain.ew,
> > ewin32_api.ew,
> > and replace various NULLs with {} the errors are changing places, so
> > it's
> > beginning to work.
> >
> > However, other solutions could be
> >
> > 1. Rewrite the eu sorce code to accomodate these different types passed
> > to
> > the interpreter - so that the error is not returned.
> >
> > 2. Check the type passed to the define_c_func, and change it to the
> > correct
> > type in situ so that the error is not returned.
> >
> > 2 is where my headache started. I've tried various things, checking to
> > see if
> > what's passed is an object or a sequence, but I am floundering a little,
> >
> > and
> > any pointers would be greatly appreciated. Also, due to floundering, I'm
> >
> > a
> > little sparse on detail - sorry.
> >
> > At the moment, in order to experiment with with direct x, I'm having to
> > use
> > eu2.3, which is inconvenient more than anything.
> >
> > Chris
> >
>
3. RE: Invaid argument type in dll.e
>From: Andy Serpa <ac at onehorseshy.com>
>Subject: RE: Invaid argument type in dll.e
>
>
>Just a note:
>
>There are a number of wrappers for external .dll libraries (zlib,
ZLib does. It's only required for one function, gzprintf, because it takes
a variable number of arguments.
>sqlite, etc.) in the archives that should (now) be using cdecl
>declarations instead of stdcall (add "+" before the function name in the
>declaration). They happen to work with the interpreter because of a
>quirk in Watcom, but will crash if translated to C.
>
>So when making a wrapper, check to see what the proper calling
>convention is...
>
>
>Brian Broker wrote:
> >
> >
> > Hi Chris,
> >
> > The bottom line is, the C routine definitions should never have been
> > declared with NULL's or 0's. The definition's need to be fixed... This
> > shouldn't be too difficult but perhaps a bit time consuming. Or you
> > could wrap define_c_func/proc to check for NULL parameters but then you
> > still need to replace occurrences of define_c_func/proc to whatever your
> >
> > wrapper name is.
> >
> > Personally, I'd just fix the definitions and maybe re-release the fixed
> > code to the archives.
> >
> > -- Brian
> >
> > Chris Burch wrote:
> > > Hi
> > >
> > > I have a headache.
> > >
> > > After purchasing eu2.4, I find that a lot of the downloaded programs
>are
> > >
> > >
> > > broken, particularly directe and exotica.
> > >
> > > The problem lies in dll.e, particularly :-
> > >
> > > global function define_c_func(object lib, object routine_name,
>sequence
> > > arg_sizes, atom return_type)
> > > -- define a C function (or machine code routine)
> > >
> > > return machine_func(M_DEFINE_C, {lib, routine_name, arg_sizes,
> > > return_type})
> > > end function
> > >
> > > returns invalid argument type. (usually line 53) This didn't happen in
> > > eu2.3.
> > >
> > > The reason (gathered from previous postings) - and correct me if I'm
> > > wrong,
> > > is that some programs pass NULL, and not {}, which is now interpreted
>in
> > >
> > > eu2.4
> > > differently.
> > >
> > > Having traced thru (in exotica) various files, eg emain.ew,
> > > ewin32_api.ew,
> > > and replace various NULLs with {} the errors are changing places, so
> > > it's
> > > beginning to work.
> > >
> > > However, other solutions could be
> > >
> > > 1. Rewrite the eu sorce code to accomodate these different types
>passed
> > > to
> > > the interpreter - so that the error is not returned.
> > >
> > > 2. Check the type passed to the define_c_func, and change it to the
> > > correct
> > > type in situ so that the error is not returned.
> > >
> > > 2 is where my headache started. I've tried various things, checking to
> > > see if
> > > what's passed is an object or a sequence, but I am floundering a
>little,
> > >
> > > and
> > > any pointers would be greatly appreciated. Also, due to floundering,
>I'm
> > >
> > > a
> > > little sparse on detail - sorry.
> > >
> > > At the moment, in order to experiment with with direct x, I'm having
>to
> > > use
> > > eu2.3, which is inconvenient more than anything.
> > >
> > > Chris
> > >
> >
4. RE: Invaid argument type in dll.e
--part1_16e.24a1c2e8.2cb49c14_boundary
Hi
Thanks Brian and Andy
Am now going to trawl thru all the stuff that doesn't work - will post it
back to the site, but may be a while - perhaps when eu++ pro 15.56 comes out! A
'good learning experience' though.
Chris
--part1_16e.24a1c2e8.2cb49c14_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
<HTML><FONT FACE=3Darial,helvetica><FONT SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=
=3D"Arial" LANG=3D"0">Hi<BR>
<BR>
Thanks Brian and Andy<BR>
<BR>
Am now going to trawl thru all the stuff that doesn't work - will post it ba=
ck to the site, but may be a while - perhaps when eu++ pro 15.56 comes out!=20=
A 'good learning experience' though.<BR>
<BR>
Chris<BR>
--part1_16e.24a1c2e8.2cb49c14_boundary--
