SourceForge.net | 2 Aug 20:57 2003
Picon
Picon

[ swig-Bugs-782052 ] Problems with configure.in

Bugs item #782052, was opened at 2003-08-02 13:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=782052&group_id=1645

Category: chicken
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Lenz (wuzzeb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems with configure.in

Initial Comment:
In ./configure --help it says to pass the option
--with-chickensharedlib=path.  
Problem is, the first argument to the AC_ARG_WITH macro
is chicklis so the correct argument is
--with-chicklis=path.

All the Chicken AC_ARG_WITH macros should be fixed so
that the first argument (the actual --with argument
configure looks for) and the text in the --help are the
same.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=782052&group_id=1645
(Continue reading)

William S Fulton | 3 Aug 23:51 2003
Picon

Re: SWIG-Modula3

Henning Thielemann wrote:
> I would like to have a SWIG producing Modula 3 interfaces. How can I write
> such an extension? E.g. I could start on java.cxx since in the list of
> SWIG supported languages Java seems to be closest to Modula3.
>  Unfortunately most C/C++ programmers don't make use of 'const int'
> (Modula: CONST) or 'enum' (Modula: {}) etc. 
Note that enums are wrapped with integers in all the SWIG language modules. I'm 
hoping to make some changes soon so that it is easy for the target language to 
use the equivalent of the language's enum type instead of an integer. An integer 
would still be used as the wrapper C/C++ wrapper type.

> but relying on the
> preprocessor's '#define' (no counterpart in Modula). The SET type (bit
> vector as used for flag sets) of Modula has no equivalent in C, it is
> often implemented as integer in form of a preprocessor symbol or 'int'. 
> Pointer arguments may sometimes be converted to call by reference
> arguments (VAR or READONLY in Modula3) or to ARRAYs.  I'm afraid the
> interface files "*.i"  have to be modified to hold all this additional
> information, right?
It looks like it to me. You may want to look at the C# typemaps.i file and the 
typemaps in there for passing by reference. C# has the capability to decide 
whether something is passed by reference or value - if the type has a "ref" 
prefix it is passed by reference. You'll probably define your own type typemaps 
like the onew used by Java and C#:

C# type typemap    Java equivalent
---------------    ---------------
ctype              jni              - C type used in C code
imtype             jtype            - Java or C# intermediary type
cstype             jstype           - Java or C# proxy code type
(Continue reading)

William S Fulton | 4 Aug 00:05 2003
Picon

Re: Language support request

Have you seen the link to a SWIG Javascript version on this page?
http://www.swig.org/compat.html#SupportedLanguages

Any volunteers to update and maintain the module will ensure it gets distributed 
with the latest SWIG releases.

William

Fahrezal Effendi wrote:
> I need SWIG to support Mozzila's JavaScript
> (SpiderMokey).
> http://www.mozzila.org/js/spidermonkey/
> 
> Thanks.
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
> _______________________________________________
> Swig-dev mailing list  -  Swig-dev <at> cs.uchicago.edu
> http://mailman.cs.uchicago.edu/mailman/listinfo/swig-dev
> 

William Fulton | 5 Aug 00:32 2003

[Swig-CVS] commit SWIG/Lib/perl5 perlrun.swg

Attachment: application/octet-stream, 423 bytes
Scott Finneran | 7 Aug 05:53 2003

Patch for Redhat 9

Hello all,

Attached is a small patch to allow swig generated code to compile under 
Redhat Linux 9. Used to work fine under 7.3 but with the upgrade to gcc 
& glibc the code compiles with errors. Shouldn't cause problems for 
other OSs as far as I can tell.

Cheers,

Scott
diff -Naur SWIG.orig/Lib/perl5/perlmain.i SWIG/Lib/perl5/perlmain.i
--- SWIG.orig/Lib/perl5/perlmain.i	2003-08-07 10:00:18.000000000 +1000
+++ SWIG/Lib/perl5/perlmain.i	2003-08-07 10:04:15.000000000 +1000
 <at>  <at>  -24,7 +24,7  <at>  <at> 

 %{

-static void xs_init _((void));
+static void xs_init _((pTHX));
 static PerlInterpreter *my_perl;

 int perl_eval(char *string) {
 <at>  <at>  -64,7 +64,7  <at>  <at> 
 /* EXTERN_C void boot_DynaLoader _((CV* cv)); */

 static void
-xs_init()
+xs_init(pTHX)
 {
 /*  dXSUB_SYS; */
     char *file = __FILE__;
Scott Finneran | 7 Aug 06:03 2003

Re: Patch for Redhat 9

Oops,

Should have mentioned that this only effects code generated for Perl.

Scott

Scott Finneran wrote:
> Hello all,
> 
> Attached is a small patch to allow swig generated code to compile under 
> Redhat Linux 9. Used to work fine under 7.3 but with the upgrade to gcc 
> & glibc the code compiles with errors. Shouldn't cause problems for 
> other OSs as far as I can tell.
> 
> Cheers,
> 
> Scott
> 
> 
> ------------------------------------------------------------------------
> 
> diff -Naur SWIG.orig/Lib/perl5/perlmain.i SWIG/Lib/perl5/perlmain.i
> --- SWIG.orig/Lib/perl5/perlmain.i	2003-08-07 10:00:18.000000000 +1000
> +++ SWIG/Lib/perl5/perlmain.i	2003-08-07 10:04:15.000000000 +1000
>  <at>  <at>  -24,7 +24,7  <at>  <at> 
>  
>  %{
>  
> -static void xs_init _((void));
> +static void xs_init _((pTHX));
>  static PerlInterpreter *my_perl;
>  
>  int perl_eval(char *string) {
>  <at>  <at>  -64,7 +64,7  <at>  <at> 
>  /* EXTERN_C void boot_DynaLoader _((CV* cv)); */
>  
>  static void
> -xs_init()
> +xs_init(pTHX)
>  {
>  /*  dXSUB_SYS; */
>      char *file = __FILE__;

William Fulton | 7 Aug 10:31 2003

[Swig-CVS] commit SWIG/Lib/python pyrun.swg

Attachment: application/octet-stream, 179 bytes
SourceForge.net | 4 Aug 14:07 2003
Picon
Picon

[ swig-Bugs-782778 ] simple nested namespace lookup failing

Bugs item #782778, was opened at 2003-08-04 14:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=782778&group_id=1645

Category: code generation (general)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Duret-Lutz (adl)
Assigned to: David M. Beazley (beazley)
Summary: simple nested namespace lookup failing

Initial Comment:
I'm wrapping a large C++ project using nested namespaces
using SWIG 1.3.19.  I know SWIG will flatten namespaces
and this is *not* a problem to me.  However in some cases
SWIG fails to lookup the right type and this is more 
annoying.

I've come up to the following simple test case.  It
defines a type foo::bar::x, and latter use it as bar::x 
from the namespace foo.  Unfortunately, SWIG
creates two types (foo__bar__x and bar__x) instead
of only one (foo__bar__x).

~/tmp % cat foo.i
%module foo

%inline %{

namespace foo
{
  namespace bar
  {
     struct x
     {
     };
  }

  int doit(const bar::x&);
}

~/tmp % swig -c++ -python foo.i
~/tmp % grep 'define  SWIG' foo.cxx
#define  SWIGTYPE_p_foo__bar__x swig_types[0] 
#define  SWIGTYPE_p_bar__x swig_types[1] 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=782778&group_id=1645

SourceForge.net | 3 Aug 22:41 2003
Picon
Picon

[ swig-Bugs-782468 ] Chicken Runtime code broken w.r.t. type information

Bugs item #782468, was opened at 2003-08-03 15:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=782468&group_id=1645

Category: chicken
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Lenz (wuzzeb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Chicken Runtime code broken w.r.t. type information

Initial Comment:
This was originally reported here
http://mailman.cs.uchicago.edu/pipermail/swig-dev/2003-May/010959.html

I was looking at the runtime library and how you handle
pointers, and it is broken.  It will break on multiple
inheritance and on multiple modules all using the same
type library.  see section 8.8 in the Typemaps chapter
of the swig documentiation.  The example involving
FooBar there will not work. See attached file "multi.i"
  The following code looks like
; This is the CHICKEN interpreter.
; Version 1, Build 10 - linux-unix-gnu-x86
; (c)2000-2003 Felix L. Winkelmann
>>> (define obj (multi:new-Joo))
>>> (multi:Foo-a-set obj 3)
>>> (multi:Bar-b-set obj 5)
>>> (multi:Foo-a-get obj)
5
>>> (exit)

Prints out the value 5 since (multi:Bar-b-set )
actually sets Foo::a.

How common.swg works is a little tricky. 
swig_type_info is actually used for two purposes.  To
get a better idea of how it works, I suggest you read
my page at http://www.cs.wisc.edu/~lenz/swig.html. 
That is not exactly how the common.swg works in CVS but
it is close... same general idea.

The problem is in swig_convert_ptr... the correct
algorithm for swig_convert_ptr is something like this...

// returns 1 on type error
int SWIG_ConvertPtr(language data, void **result,
swig_type_info *type) {
swig_type_info *cast;
swig_type_info *from;
check if language data is correct type;
from = swig_extract_type_info(language data);
if (type) {
  cast = SWIG_TypeCheck(from->name, type);
  //cast = SWIG_TypeCheckStruct(from, type); faster
lookup avaliable in my patch to common.swg
  if (cast) {
    *result = SWIG_TypeCast(cast, (void *)
swig_extract_data_ptr(language data));
    return 0;
  } else {
    return 1;
  }
} else {
  *result = (void *) swig_extract_data_ptr(language data);
  return 0;
}
return 1;
}

You are missing the SWIG_TypeCheck() function call.

See the current common.swg uses swig_type_info for 2
purposes.  First off, every type gets what I will call
a master swig_type_info structure.  These are stored in
the swig_type_list linked list AND in the swig_types
array.  Then, every swig_type_info stores another
linked list of swig_type_info structures which store
casting data.

Currently in chicken, each tagged pointer stores a
record containing a pointer to a master swig_type_info
structure. Then in swig_convert_ptr() you extract that
type and pass that type to SWIG_TypeCast. This is
wrong!  What you need to do is first resolve any
differences between the expected type (passed as a
paramter) and the type coming from the tagged pointer.
 There isn't currently even any type checking.  Say for
example that I pass the wrong type to a function.  Say
a function expects a Bar * but I pass it a Foo *.  The
swig_type_info structure passed into the
swig_convert_ptr() function will be the one for Bar *.
 The swig_type_info structure coming from the tagged
pointer will point to a Foo *.  Currently, the chicken
module will not do any conversions or checks... What
needs to happen (and what happens in SWIG_TypeCheck())
is the type of the incoming tagged pointer and the
expected type need to be compared.  If Foo is derived
from Bar OR Foo is typedefed to Bar then even tho
 the types don't match, the conversion is still valid.
 Otherwise, an error should be reported.

Lastly, why don't you use the tagged pointer like so
(code in swig_new_pointer_obj)?
C_word *p = *a, *p0 = p;
*(p++) = C_TAGGED_POINTER_TAG;
*((void **)(p++) = ptr;
*((void **)(p++) = (void *) type;
*a = p;
return (C_word)p0;

or even something like (don't know if it will work...)
*(p++) = C_TAGGED_POINTER_TAG;
*((void **)(p++) = ptr;
C_mutate((C_word *)(p++), C_mpointer(p++, type));

Then in swig_convert_ptr you can have code like
swig_type_info *from;
*ptr = (void *) C_pointer_address(obj);
from = (swig_type_info *) C_block_item(obj, 3);

This way you get rid of all that code at the bottom of
chicken.swg in %insert(chicken). You don't need to
create a record and have all that code creating records
and setting them into the clientdata part of the
swig_type_info... just store the swig_type_info pointer
directly in the tagged pointer.  The only thing you
lose is the ability to print out the pointer.... but
the in the Mzscheme module we just ignore that... in
Mzscheme, if you try and display a swig pointer, it
just prints "#swig" doesn't even print the type.

Looking in library.scm in the chicken source, it seems
that a tagged pointer will recursivly call out on the
tag... and then the tag (since in the first case we
just stored a pointer) would generate a "unpritable
non-immediate object encountered" (unless the pointer
happend to have a correct tag... bad stuff...)

If you want printing, the best way might be to not use
tagged pointers at all.  The problem with tagged
pointers is that the tag is the same for every pointer,
so in say the ##sys#print function in library.scm we
can't install a custom callback function to print it
out.  Guile and Mzscheme solve this problem by having a
function which returns an unused tag.  Then all the
swig heap objects have a their own unique tag, and
callback functions for displaying can be registered
with guile.  But in chicken, since anyone can use the
tagged pointer tag, we can't install a specific
callback for only swig tagged pointers, hence the need
for records.

One way might be to create a record containing the
pointer to the object and a pointer to the
swig_type_info strucuture.  This effectivly is the same
as creating our own tag for use only by swig heap
objects.  Something like
(define-record swig obj type)
(define-record-printer (swig tag out)
  (fprintf out "#<c++ ~S>(~A)" 
    ((foreign-lambda c-string "swig_type_name"
c-pointer) (swig-type tag)
    (swig-obj tag)))

char *swig_type_name(void *type) {
  return ((swig_type_info *)type->name);
}

and then in swig_new_pointer_obj the equlivelent of
(make-swig ptr type).

Finally, why do you have all that code in
SWIG_POINTER_AS_STRING?   That code never gets used. 
Also those functions for swig_pack_data and
swig_unpack_data?  Never used that I can see.  I see
there are functions like that in the python code, but I
think you can force everyone to use a tagged pointer
and just get rid of all that code.

Attached is a new chickenrun.swg (this is not tested...
I haven't even tried to compile it).  It is just to
give you an idea about how the chickenrun.swg could
look.  Note: I changed the name of the runtime
functions to some standard names.

Onother suggestion is to use the function names like I
have defined them and then in chicken.swg add something
like

%include(runtime) %{
#define SWIG_ConvertPtr(s, result, type) \
        SWIG_Chicken_ConvertPtr(s, result, type)
#define SWIG_MustGetPtr(s, result, type, argnum) \
        SWIG_Chicken_MustGetPtr(s, result, type, argnum)
#define SWIG_NewPointerObj(obj, type, own) do { \
        C_word *known_space = C_alloc(3); \
        SWIG_Chicken_NewPointerObj(obj, &known_space,
type, own); \
        } until(1)
%}

That way the interface for the 3 functions can be the
same as the other language modules.  Also notice the
removal of SWIG_ALLOCSZ_POINTER().  Also, if you use
this, some typemaps will need to be converted to use
SWIG_MustGetPtr().  The reason SWIG_ConvertPtr() does
not issue an error or throw an exception and just
returns the result is so that function overloading can
work.  Take a look at how the guile module does
function overloading... it calls SWIG_ConvertPtr to
test if the input param is the right type, and if so
calls that overloaded method.  If SWIG_ConvertPtr
fails, it moves to testing the next overloaded
function.  So for that we don't want SWIG_ConvertPtr to
die and give an error.  So typemaps in typemaps.i
should use SWIG_MustGetPtr().

John

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=782468&group_id=1645

SourceForge.net | 6 Aug 17:11 2003
Picon
Picon

[ swig-Bugs-784226 ] Confusion template instanciation

Bugs item #784226, was opened at 2003-08-06 15:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=784226&group_id=1645

Category: code generation (general)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guillaume Brocker (gbrocker)
Assigned to: David M. Beazley (beazley)
Summary: Confusion template instanciation

Initial Comment:
I'm using SWIG 1.3.19 under windows.

I wanted to instanciate the std::vector with a pointer
to a class of my own as type. I used %template like this :

%template MeshVector std::vector<Mesh*>;

But the pointer seems to be confusing for swig, since
the generated code cannot be compiled. After having a
quick look, it appears that the template type place
holder is not replaced by the template type parameter
all the time.

When the template parameter is my class instead of a
pointer to my class, then swig handles the
instanciation well.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=784226&group_id=1645


Gmane