Re: function pointers in structures and Java

Thanks for the info, it was very helpful.

In our case, the typemap didn't work, I suspect because the original 
headers/C files are in K&R, it doesn't find Object *object in the parameter 
list of the .c file.

However, I was able to make the following work, which is the same as our C 
syntax usage, so that works just fine:

TYPEDEF(struct _TY, TY)
struct _TY {
#ifdef SWIG
     PROTOTYPE(Boolean, foo, (TY *ty, int bar));
#else
     PROTOTYPE(Boolean, (*foo), (TY *ty, int bar));
#endif
     unsigned long buckets;
};

/* I'll end up making a PROTOTYPEF which will handle the SWIG differences 
and simplify end user usage */

I didn't realize that that was the only issue I was up against...the (*foo) 
as opposed to just the foo.

In this case, the usage in the .java file became:

         _TY t1 = TY.new__TY(50);
         _TY t2 = TY.new__TY(100);

Re: typemaps unsigned long *

We are using the typemaps.i from Java to handle some conversions for us...

For example, one of our methods is:

getInt32(..., unsigned long *value);

We've replaced value with OUTPUT, and %include typemaps.i

This allows us presumably to use a long[] in the java code.

Here is an excerpt of code [ modified by adding the fprintf ].

the fprintf prints out the values I would expect, but the java code does not...

         }
         arg4 = &temp4;
     }
     result = (Boolean)(arg1)->getInt32(arg2,arg3,arg4);

     jresult = (jlong)result;
     {
         (*jenv)->SetLongArrayRegion(jenv, jarg4, 0, 1, (jlong *)&temp4);
         fprintf(stderr, "temp4 = %d, arg4 = %d\n", temp4, *arg4);
     }
     {
         if (arg3) (*jenv)->ReleaseStringUTFChars(jenv, jarg3, arg3);
     }
     return jresult;
}

Re: typemaps unsigned long *

I can see a problem here which interestingly enough doesn't manifest itself 
here, but does on your machine. A jlong is a 64 bit number and an unsigned long 
is usually a 32 bit number, the cast for temp4 is dodgy. Let me know if this 
fixes the problem and I'll repair the typemaps for the forthcoming release:

%include "typemaps.i"
%typemap(argout) unsigned long *OUTPUT
{
jlong jvalue = temp$argnum;
//JCALL4(SetLongArrayRegion, jenv, $input, 0, 1, (jlong *)&temp$argnum);
JCALL4(SetLongArrayRegion, jenv, $input, 0, 1, &jvalue);
}

Suggestion: you an use %apply instead of changing value to OUTPUT.

%apply unsigned long*OUTPUT {unsigned long *value};
int getInt32(..., unsigned long *value) {

William

Brian Hawley wrote:

> 
> We are using the typemaps.i from Java to handle some conversions for us...
> 
> For example, one of our methods is:
> 
> getInt32(..., unsigned long *value);
> 

Re: function pointers in structures and Java

There is no global scope in Java, so new__TY doesn't make sense unless it is a 
method in the current or base class scope. You could try %rename for renaming 
_TY to TY, but I don't know if it will work as you already have a typedef to TY.

William

Brian Hawley wrote:

> 
> Thanks for the info, it was very helpful.
> 
> In our case, the typemap didn't work, I suspect because the original 
> headers/C files are in K&R, it doesn't find Object *object in the 
> parameter list of the .c file.
> 
> However, I was able to make the following work, which is the same as our 
> C syntax usage, so that works just fine:
> 
> TYPEDEF(struct _TY, TY)
> struct _TY {
> #ifdef SWIG
>     PROTOTYPE(Boolean, foo, (TY *ty, int bar));
> #else
>     PROTOTYPE(Boolean, (*foo), (TY *ty, int bar));
> #endif
>     unsigned long buckets;
> };
> 
> /* I'll end up making a PROTOTYPEF which will handle the SWIG 
> differences and simplify end user usage */

Re: typemaps unsigned long *

That fixed it.

At 10:02 AM 12/2/2003 +0000, William S Fulton wrote:

>I can see a problem here which interestingly enough doesn't manifest 
>itself here, but does on your machine. A jlong is a 64 bit number and an 
>unsigned long is usually a 32 bit number, the cast for temp4 is dodgy. Let 
>me know if this fixes the problem and I'll repair the typemaps for the 
>forthcoming release:
>
>%include "typemaps.i"
>%typemap(argout) unsigned long *OUTPUT
>{
>jlong jvalue = temp$argnum;
>//JCALL4(SetLongArrayRegion, jenv, $input, 0, 1, (jlong *)&temp$argnum);
>JCALL4(SetLongArrayRegion, jenv, $input, 0, 1, &jvalue);
>}
>
>Suggestion: you an use %apply instead of changing value to OUTPUT.
>
>%apply unsigned long*OUTPUT {unsigned long *value};
>int getInt32(..., unsigned long *value) {
>
>William
>
>Brian Hawley wrote:
>
>>We are using the typemaps.i from Java to handle some conversions for us...
>>For example, one of our methods is:

SWIG-1.3.20 Release Candidate 1

Well, we're in the final stages of putting the next SWIG release 
together.   I'm still working on fixing a few bugs here and there, but 
I'm going to start putting some release candidates online.   Since we 
haven't made a release in awhile, it would be great if some people 
could try out the candidates and let us know if there are any 
problems---especially if you encountered problems with 1.3.19.  Also, a 
lot of the support for OS X has been reworked.  So, if you're using a 
Mac, you may want to give it a try.

The first release candidate can be found here:

      http://www.signal6.com/swig-1.3.20.tar.gz

Enjoy!

Cheers,
Dave

_______________________________________________
Swig maillist  -  Swig <at> cs.uchicago.edu
http://mailman.cs.uchicago.edu/mailman/listinfo/swig

Re: SWIG-1.3.20 Release Candidate 1

>>>>> " " == David Beazley <beazley <at> signal6.com> writes:

     > Well, we're in the final stages of putting the next SWIG
     > release together.  I'm still working on fixing a few bugs here
     > and there, but I'm going to start putting some release
     > candidates online.  Since we haven't made a release in awhile,
     > it would be great if some people could try out the candidates
     > and let us know if there are any problems---especially if you
     > encountered problems with 1.3.19.  Also, a lot of the support
     > for OS X has been reworked.  So, if you're using a Mac, you may
     > want to give it a try.

     > The first release candidate can be found here:

     >       http://www.signal6.com/swig-1.3.20.tar.gz

  I'm getting this error building on a redhat 9 system:

 gcc -DHAVE_CONFIG_H -I. -I. -I../Source/Include -I/usr/include/php -I/usr/include/php/Zend
-I/usr/include/php/main -I/usr/include/php/TSRM -g -O2 -Wall -MT libswigphp4_la-libphp4.lo -MD
-MP -MF .deps/libswigphp4_la-libphp4.Tpo -c libphp4.c  -fPIC -DPIC -o .libs/libswigphp4_la-libphp4.o
libphp4.c: In function `SWIG_ZTS_ConvertPtr':
libphp4.c:498: warning: dereferencing type-punned pointer will break strict-aliasing rules
libphp4.c:489: warning: unused variable `val'
libphp4.c:547:20: config.h: No such file or directory
libphp4.c: At top level:
libphp4.c:322: warning: `SWIG_landfill' defined but not used
make[1]: *** [libswigphp4_la-libphp4.lo] Error 1

  I was getting this same error about a week ago in swigs I was

various.i and char **

I have a function:

Boolean getString(char *id, char **value_p);

The purpose of getString is to allocate some memory, and put the string 
associated with id into the allocated space, and set the argument to that 
allocated memory location.

i.e.

char *value_p;

getString("abc", &value_p);  /* in C code */

I want to be able to use this function from within the Java code.

 From reviewing the documentation, it appears that "various.i" in Java has 
a typemap -- char**STRING_OUT, so, I modified my function declaration as such:

Boolean getString(char *id, char **STRING_OUT);

However, when I compile the code which contains the function, I get the 
following error.  The Object references are because the function is 
actually a member of the struct _Object structure.

/home/engr/tmp/bnh-engr/libraries/1.6/generic-i386-linux22/object//_Object.java:
57: getCPtr(SWIGTYPE_p_p_char) in SWIGTYPE_p_p_char cannot be applied to 
(java.l
ang.String[])

Code generation for Vector of unsigned long / short / int

Re: Code generation for Vector of unsigned long / short / int

On Dec 2, 2003, at 7:15 PM, Nair, Sanjay S wrote:

> Hi,
>
>             I noticed some problem with the SWIG code generation for  
> unsigned long / int / short vectors. I found this old discussion on  
> web
>
> http://mailman.cs.uchicago.edu/pipermail/swig-dev/2002-September/ 
> 008504.html, which talks about the similar problem I’m having.
>
>  

I'm not aware of any problems with this.  What version of SWIG is this?

-- Dave

_______________________________________________
Swig maillist  -  Swig <at> cs.uchicago.edu
http://mailman.cs.uchicago.edu/mailman/listinfo/swig