[ 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

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

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
> 

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

Mon Aug  4 17:32:02 CDT 2003
Files: %{sVv}
Update of /cvsroot/SWIG/Lib/perl5
In directory schlitz:/tmp/cvs-serv24872

Modified Files:
	perlrun.swg 
Log Message:
Reduced number of occurrences of annoying warning to 1, as reported by Gerald Williams using perl-5.8.0
and GCC3 onwards on Cygwin:

In function `int SWIG_ConvertPtr(SV*, void**,  swig_type_info*, int)':
warning: cast to pointer from integer of different size

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)

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));

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

Thu Aug  7 03:31:10 CDT 2003
Files: %{sVv}
Update of /cvsroot/SWIG/Lib/python
In directory schlitz:/tmp/cvs-serv4873

Modified Files:
	pyrun.swg 
Log Message:
Minor warning fix

[ 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

[ 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)

[ 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