1. RE: Invaid argument type in dll.e
- Posted by Brian Broker <bkb at cnw.com> Oct 06, 2003
- 398 views
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
- Posted by Andy Serpa <ac at onehorseshy.com> Oct 07, 2003
- 410 views
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
- Posted by Elliott Sales de Andrade <quantum_analyst at hotmail.com> Oct 07, 2003
- 380 views
>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
- Posted by Chris Burch <chrisburch at uku.co.uk> Oct 07, 2003
- 409 views
--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--