Thank you for the input.
MEX files are C/C++ source files, that are able to be compiled and
executed from Matlab. The interface requires that every function to be
wrapped is saved in a single MEX file (=C or C++ source file). Each of
those files contains entry point function "void mexFunction(...)" and
should be named by the name that will be called from matlab. So for
example getStupidNumber.cpp.
#include "mex.h"
void mexFunction (int nlhs, mxArray *plhs[], int nrhs, const
mxArray *prhs[])//this is always the same no matter the name of the
wrapped function or file
{
mxArray *v = mxCreateDoubleMatrix (1, 1, mxREAL);
double *data = mxGetPr (v);
*data = 1.23456789;
plhs[0] = v;
}
nlhs, nrhs = number of left/right hand arguments
plhs, prhs = array of the arguments
And that is it. If you wanted to have anything else, eg wrap another
function or so, you would have to create a new source file for it.
I've solved that by moving the creation of the output file into the
function wrapper.
I need to support functions that operate on templated classes (pass
such classes as arguments). These classes basically represent
pictures.
I have not yet comprehended the typemaps and the documentation to
creating new module is very brief. But I think I can do the job.
On 29 March 2010 22:16, Donny Viszneki <donny.viszneki@...> wrote:
> Some tips for your post:
>
> Could you describe a little more the Matlab <-> C/C++ interface? Those
> unfamiliar with Matlab are not very helped by "Matlab MEX files" and
> it's confusing what the significance or challenge is with regards to
> "need to have every wrapped function in a single file."
>
> What features of C/C++ do you intend to support? Those who don't know
> Matlab will not have any idea what Matlab is capable of representing
> in its own terms.
>
> My personal advice on which module to derive from: Don't derive from
> any! It takes longer to get started, but if you begin from scratch,
> then you really have a very clear idea of how your SWIG module works.
>
> On Sun, Mar 28, 2010 at 4:26 AM, Josef Pacula <josef.pacula@...> wrote:
>> Hello everybody,
>> I am very new to mailing lists so tell me of any customs or anything if needed.
>> I am working on a very simple Matlab module for SWIG as my bachelors thesis.
>> I am currently wondering how to solve Matlab MEX files need to have
>> every wrapped function in a single file.
>> Does any other supported language have similar API? Do you have any
>> hints how to approach this?
>> Or do you have any opinion on which module would be best to take derive from?
>> Sincerely,
>> Josef Pacula
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Swig-devel mailing list
>> Swig-devel@...
>> https://lists.sourceforge.net/lists/listinfo/swig-devel
>>
>
>
>
> --
> http://codebad.com/
>

Hello
I am unable to bind the C, Function pointers and callback to access in Lua.
Requirtement: I am trying to bind C [SDL] lib function pointers in Lua with
swig tool.
typedef int (*SDL_EventFilter)(const SDL_Event *event);
void SDL_SetEventFilter(SDL_EventFilter filter);
Now I want that SDL_SetEventFilter() will take the Lua fuction as a
parameter and Set it as callback of type SDL_EventFilter.
Can anybody help me to do this??
--
Thanks & Regards
Amit Jain
+91-9999311609

Hello everybody,
I am very new to mailing lists so tell me of any customs or anything if needed.
I am working on a very simple Matlab module for SWIG as my bachelors thesis.
I am currently wondering how to solve Matlab MEX files need to have
every wrapped function in a single file.
Does any other supported language have similar API? Do you have any
hints how to approach this?
Or do you have any opinion on which module would be best to take derive from?
Sincerely,
Josef Pacula

Bugs item #2975715, was opened at 2010-03-24 02:40
Message generated for change (Tracker Item Submitted) made by
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2975715&group_id=1645
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fnordly ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Building in separate directory fails all checks
Initial Comment:
I like to...
tar xf swig-1.3.40.tar.bz2
mkdir swig-1.3.40-build
cd swig-1.3.40-build
time { ../swig-1.3.40/configure &&
make -k &&
make -k install &&
make -k check
} >>../swig-1.3.40-1 2>>../swig-1.3.40-2 &
tail -f ../swig-1.3.40-{1,2}
Though the build and install process seemed to go well, all checks failed as files were not found as they were looked for in the build directory rather than in the source directory. The first attempt took just under 18 minutes. I have chosen to rebuild in the source directory and run the checks without reinstalling. It is still testing an hour later. I only have Perl5, Python, Python3, TCL and gcj. Now, I see that ld cannot find -lcygperl5_10.dll and that I am going to have to reconfigure, remake, reinstall, recheck all after figuring out how to link to libperl. (Do I use libperl.dll.a or libperl.a or what? Do I use -lperl or -lperl.dll or what?) Oh well, figuring it out is all part of the fun. Tomorrow, I will be able to rebug you guys with more innocuous timings and the solution to my Perl linkage problems. Thanks for everything, though. I hope that I am not causing any problems. I don't see these two bugs listed, but I didn't really look yet, either. I will look again before posting again.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2975715&group_id=1645

Bugs item #2973305, was opened at 2010-03-19 16:24
Message generated for change (Tracker Item Submitted) made by
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2973305&group_id=1645
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: parsing
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Marcelo Matus (marcelomatus)
Summary: General parsing bug with non numeric expressions
Initial Comment:
The example submitted to the swig-user list:
void useSomeFunc( int i=GetTestClass().someFunc() );
Response from William:
This seems to be a general parsing bug. Non numeric expressions containing . or -> are not parsable. Please log as a bug. Workaround is to simplify the expression, eg:
int GetTestClassSomeFunc() {
return GetTestClass().someFunc();
}
void useSomeFunc( int i=GetTestClassSomeFunc() );
or persuade someone or yourself to fix the bug. The fix to this is going to be somewhere around exprcompound in parser.y. Please add this info to the bug report.
William
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2973305&group_id=1645

Donny Viszneki wrote:
> On Mon, Mar 15, 2010 at 4:01 PM, William S Fulton
> <wsf@...> wrote:
> > Are you following the svn commits? If so you'd have noticed some limited
> > support for non-flattened namespaces via the nspace feature. So
> currently
> > only enums, classes, unions and structs can exist in a namespace. Of
> notable
> > absence are variables and functions declared in a namespace.
>
> No, not recently, but now I'll be sure to check it out
>
> > In your target language, you can always get the current namespace
> via a call
> > to Language::getNSpace(). The namespace returned is a language specific
> > namespace and currently for C# and Java (only supported languages),
> it uses
> > "." as the namespace/package separator. I suspect many languages
> will just
> > use the ".", but when one comes along that does not, we can easily
> make this
> > configurable for the core code.
>
> I find observations about the "." to be superficial and slightly
> irrelevant. Usability is important, so those things must be
> considered, however when I think about how my SWIG module should work,
> I mostly think about it in terms of the primitives that must work with
> for my target language/platform. In Javascript, the "dot operator" is
> the "property of" operator, and the value of an expression like
> "foo.bar" is a value that can be assigned (unless an exception is
> thrown) to any other variable, so I think much more of the object that
> is represented than "foo.bar" than I do of the expression "foo.bar."
>
> In practice, though, I doubt C++ statements like "namespace foo = bar"
> are *ever* used in the kind of code that is going to be fed to SWIG,
> so perhaps this should be a lower priority for me. I went after
> namespaces very early on for two reasons. First, because "modules" are
> an idea being developed for the Javascript community by the CommonJS
> group, and those are a lot like namespaces. Secondly because what Java
> and C++ call a static member function are also a very common
> programming idiom in Javascript, and I knew these had to be
> implemented in the same way that namespaces would be.
>
> > On a more strategic level, I suggest you forget about flattening the
> > namespaces until you can support all of SWIG's other features. One
> of SWIG's
> > strengths are the number of languages it supports and a degree of
> > consistency amongst the wrappers. I'm not likely to accept any namespace
> > changes that don't build on the nspace feature, so please
> demonstrate this
> > working plus all the other SWIG features before modifying the nspace
> > support. Walking before running is strongly advised!
>
> I apologize if I was unclear, I do not want to flatten namespaces.
>
> > Donny Viszneki wrote:
> >> Because I am attempting to support unflattened namespaces, it would be
> >> really helpful if cdecl Node instances would have an attribute
> >> referencing their namespace. Perhaps for the most correct behavior,
> >> SWIG would later have to instantiate and process more Node instances
> >> representing the different aliases which result from statements like:
> >>
> >> namespace foo {
> >> void bar(void);
> >> }
> >> namespace baz = foo;
> >>
> > Why are you concerned with this. All the namespaces are handled
> within the
> > core code. Is there some symbol table problem we should know about?
>
> I'm not really sure what kind of symbol table problem could have lead
> me in this direction. For clarity as I mentioned above, it is probably
> a very uncommon practice to feed SWIG code like "namespace foo = bar".
>
> >> For this we'd need a cdecl Node for foo::bar(), and then some other
> >> node perhaps a "cdecl-alias" that linked back to the "primordial node"
> >> representing the right cdecl. In this case perhaps you'd get a
> >> primordial "bar()" cdecl for with a new "namespace" attribute
> >> describing the "foo" namespace, and then later a "bar()" cdecl-alias
> >> with a "primordial" attribute referencing the original "bar()" cdecl
> >> node, but with a new "namespace" attribute referencing a node
> >> describing the baz namespace.
> >>
> >> For something like "namespace baz = foo" the quickest solution might
> >> be a "namespace-alias" Node, but the cdecl-alias/primordial technique
> >> in the above paragraph also covers declarations like "namespace baz {
> >> using foo::bar; }"
> >>
> > I think the wrappers should always use a fully qualified type in the
> target
> > language and each wrapped type can only exist in one namespace.
> Given that,
> > why do you need to be concerned with namespace aliases? Surely it is
> just
> > something for the parser to deal with? I believe it does this all okay.
>
> I'm not sure what a "fully qualified type" would be in my target
> language, Javascript.
I was hoping you'd be able to answer that! Given:
%feature("nspace");
namespace A {
struct S {};
}
namespace B {
struct S {};
}
In Java the fully qualified names are A.S and B.S and an instance of
each is constructed like:
A.S a = new A.S();
B.S b = new B.S();
How would you do the equivalent in with your Javascript proxy classes?
That should answer the question on fully qualified types.
> Did you mean that I should be satisfied with the
> namespace getters and setters? For me, a getter or a setter means
> bypassing Spidermonkey's built-in mechanisms for accomplishing what
> basically amounts to "getNamespaceFoo(){return namespaceFoo}"
>
> Why I would be concerned with namespace aliases is to achieve
> referential identity between two members of namespaces that are
> aliased to the same namespace. For instance for the following C++
> code:
>
> namespace Foo {
> int add(int a, int b);
> }
> namespace Bar = Foo;
>
> The Javascript expression "Foo.add == Foo.bar" should be true.
>
No! This particular concept of having namespace aliases just has never
been considered before because SWIG flattens the namespaces. However,
given that the nspace feature is working and it only support classes,
structs, unions, enums and does not support variables and functions like
add above, consider a case which works, wrapping a class:
namespace Foo {
struct S {
void subtract(int a, int b);
};
}
namespace Bar = Foo;
void thing(Bar::S s) {}
Just Foo.S.subtract() is available in the target language, there is no
Bar.S.subtract(). The namespace aliases are handled in the SWIG type
system correctly, but they are effectively ignored, and you have to pass
Foo.S to thing(). This is no different to SWIG's treatment of typedef.
If there are a million typedefs to Foo::S, only one proxy class S is
available in the target language. The same is and should remain so for
namespace aliases, after all, they are just mega typedefs. I really
don't see a need to change this behaviour. Referential identity would
not be an issue because there is just one type for S in the target language.
> >> One SWIG behavior I think I don't like is that I notice namespaces are
> >> generating getters and setters right now. My plan for wrapping
> >> namespaces in my module does not include injecting intermediate
> >> getters for each statement like "mymodule.namespace.func(1,2,3)" nor
> >> to allow statements like "mymodule.namespace1 = mymodule.namespace2".
> >> Statements like "mymodule.namespace = whatever" would either be
> >> disallowed or would simply be handled by the Javascript interpreter by
> >> (for "mymodule.namespace = whatever")
> > Again, you really don't want to be getting into this nightmare
> generating
> > this kind of code. Just generate the fully qualified types.
>
> Sorry for being unclear, I want to write *less* code, and allow the
> Javascript interpreter to provide consistent and predictable semantics
> to the Javascript programmer. I don't want or need getters or setters
> for namespaces
What do you mean by this? You can't write a 'getter' (as in a function)
to get a namespace in C++.
> , as namespaces will be represented in my target
> platform as Javascript Objects, which are a lot like Hash tables with
> special hooks, and once I have instantiated them, attached properties
> to them, and then attached them as properties of other objects to they
> can be reached by the programmer, I want to be done with them. No more
> SWIG wrapper code need intervene once it is all set up at module
> initialization time.
In order to fully support namespaces by mapping them to Objects, you
will need to add function and variables support to the nspace feature.
Unfortunately this also means you need to ensure this works for the
languages that support it at the moment ... Java and C#. Really, I would
leave this to a later stage once you have got all the basics working in
a flattened namespace. The majority of SWIG users are content with
flattened namespaces and I suspect the same for Javascript users.
William

t-legiaw wrote:
> I am trying to pass an array of strings from c# to the underling c++ library.
>
> string[] -> *char[]
>
> This works fine in java using an approach like this:
>
> %include "various.i"
> %apply char **STRING_ARRAY { const char *cfgFiles[] };
>
> But I cannot figure out to do that for C#.
>
> Can someone help regarding this?
>
I'm don't think we have any support for this. If you write the pinvoke
code by hand and post it here, I can help you put it into typemaps so
that you can easily use the marshalling whenever SWIG parses const char *[].
William

Bugs item #2971885, was opened at 2010-03-17 12:26
Message generated for change (Tracker Item Submitted) made by wolff3
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2971885&group_id=1645
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: lua
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: sebastian (wolff3)
Assigned to: Mark Gossage (mgossage)
Summary: Lua: C++ typename check fails for equally named classes
Initial Comment:
Suggest you have two SWIG modules, "A" and "B". Also suggest you use
different namespaces in both modules with equally named classes, say:
library A:
namespace A
{
class classname
{
//! constructor
classname(const std::string & ident);
...
};
}
and library B:
namespace B
{
class classname
{
//! constructor
classname(const int & id);
...
};
}
Then both libraries will be wrapped by SWIG into 2 different modules
and linked together. In Lua, you expect to be able to call:
a = A.classname("hello") -- call constructor of A::classname
b = B.classname( 3 ) -- call constructor of B::classname
SWIG actually merges equally class names from different namespaces into
one. That is, if the load_module routine of module A was called before
B, then it expects the syntax of A::classname, if B.classname( ... ) is
called.
I am using latest SWIG 1.3.40
Best regards
Sebastian
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2971885&group_id=1645

Patches item #2967392, was opened at 2010-03-10 15:02
Message generated for change (Comment added) made by marko314
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2967392&group_id=1645
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: MarkoK (marko314)
Assigned to: Robert Stone (talby)
Summary: perl - invalid code if C++ method has default parameters
Initial Comment:
If method of a C++ class has parameters with default values, and is not overloaded, the code generated for Perl crashes, because it tries to assign value to contents of a NULL pointer. The patch is attached. I've applied the same solution as used in the equivalent python file (if statement added).
----------------------------------------------------------------------
>Comment By: MarkoK (marko314)
Date: 2010-03-16 08:44
Message:
There is another important change in my copy of SWIG 1.3.40 I forgot to
mention - I've copied
boost_shared_ptr.i from your branch. It seems to work with the exception
of
this problem.
One of my 'broken' methods is:
void addFunction(const std::string &functionName,
bool isIncludeFunctionLines = false);
The generated code:
XS(_wrap_CProfilerController_addFunction) {
dXSARGS;
{
unsigned long _index = 0;
SWIG_TypeRank _rank = 0;
if (items == 2) {
SWIG_TypeRank _ranki = 0;
SWIG_TypeRank _rankm = 0;
SWIG_TypeRank _pi = 1;
int _v = 0;
{
int res = SWIG_ConvertPtr(ST(0), 0,
SWIGTYPE_p_std__tr1__shared_ptrT_isys__CProfilerController_t, 0);
_v = SWIG_CheckState(res);
}
The problem is in the second parameter of SWIG_ConvertPtr(), which is 0
and
breaks in the code I've patched.
Marko
----------------------------------------------------------------------
Comment By: Robert Stone (talby)
Date: 2010-03-13 19:19
Message:
Thanks for the report! There's clearly something wrong in this area of the
code if you were able to get an attempt to dereference a NULL pointer, but
I'm having trouble reproducing the issue. I'd like to build a testcase so
I can be certain this problem won't re-emerge.
I tried something like:
class Thing {
public:
int method(Thing *p = 0) {
return p ? 1 : 0;
}
};
but can't seem find a way to make the generated code crash with this.
----------------------------------------------------------------------
Comment By: MarkoK (marko314)
Date: 2010-03-10 15:06
Message:
Forgot to mention - the patch was made against the current trunk, svn. rev.
11934
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2967392&group_id=1645

On Mon, Mar 15, 2010 at 4:01 PM, William S Fulton
<wsf@...> wrote:
> Are you following the svn commits? If so you'd have noticed some limited
> support for non-flattened namespaces via the nspace feature. So currently
> only enums, classes, unions and structs can exist in a namespace. Of notable
> absence are variables and functions declared in a namespace.
No, not recently, but now I'll be sure to check it out
> In your target language, you can always get the current namespace via a call
> to Language::getNSpace(). The namespace returned is a language specific
> namespace and currently for C# and Java (only supported languages), it uses
> "." as the namespace/package separator. I suspect many languages will just
> use the ".", but when one comes along that does not, we can easily make this
> configurable for the core code.
I find observations about the "." to be superficial and slightly
irrelevant. Usability is important, so those things must be
considered, however when I think about how my SWIG module should work,
I mostly think about it in terms of the primitives that must work with
for my target language/platform. In Javascript, the "dot operator" is
the "property of" operator, and the value of an expression like
"foo.bar" is a value that can be assigned (unless an exception is
thrown) to any other variable, so I think much more of the object that
is represented than "foo.bar" than I do of the expression "foo.bar."
In practice, though, I doubt C++ statements like "namespace foo = bar"
are *ever* used in the kind of code that is going to be fed to SWIG,
so perhaps this should be a lower priority for me. I went after
namespaces very early on for two reasons. First, because "modules" are
an idea being developed for the Javascript community by the CommonJS
group, and those are a lot like namespaces. Secondly because what Java
and C++ call a static member function are also a very common
programming idiom in Javascript, and I knew these had to be
implemented in the same way that namespaces would be.
> On a more strategic level, I suggest you forget about flattening the
> namespaces until you can support all of SWIG's other features. One of SWIG's
> strengths are the number of languages it supports and a degree of
> consistency amongst the wrappers. I'm not likely to accept any namespace
> changes that don't build on the nspace feature, so please demonstrate this
> working plus all the other SWIG features before modifying the nspace
> support. Walking before running is strongly advised!
I apologize if I was unclear, I do not want to flatten namespaces.
> Donny Viszneki wrote:
>> Because I am attempting to support unflattened namespaces, it would be
>> really helpful if cdecl Node instances would have an attribute
>> referencing their namespace. Perhaps for the most correct behavior,
>> SWIG would later have to instantiate and process more Node instances
>> representing the different aliases which result from statements like:
>>
>> namespace foo {
>> void bar(void);
>> }
>> namespace baz = foo;
>>
> Why are you concerned with this. All the namespaces are handled within the
> core code. Is there some symbol table problem we should know about?
I'm not really sure what kind of symbol table problem could have lead
me in this direction. For clarity as I mentioned above, it is probably
a very uncommon practice to feed SWIG code like "namespace foo = bar".
>> For this we'd need a cdecl Node for foo::bar(), and then some other
>> node perhaps a "cdecl-alias" that linked back to the "primordial node"
>> representing the right cdecl. In this case perhaps you'd get a
>> primordial "bar()" cdecl for with a new "namespace" attribute
>> describing the "foo" namespace, and then later a "bar()" cdecl-alias
>> with a "primordial" attribute referencing the original "bar()" cdecl
>> node, but with a new "namespace" attribute referencing a node
>> describing the baz namespace.
>>
>> For something like "namespace baz = foo" the quickest solution might
>> be a "namespace-alias" Node, but the cdecl-alias/primordial technique
>> in the above paragraph also covers declarations like "namespace baz {
>> using foo::bar; }"
>>
> I think the wrappers should always use a fully qualified type in the target
> language and each wrapped type can only exist in one namespace. Given that,
> why do you need to be concerned with namespace aliases? Surely it is just
> something for the parser to deal with? I believe it does this all okay.
I'm not sure what a "fully qualified type" would be in my target
language, Javascript. Did you mean that I should be satisfied with the
namespace getters and setters? For me, a getter or a setter means
bypassing Spidermonkey's built-in mechanisms for accomplishing what
basically amounts to "getNamespaceFoo(){return namespaceFoo}"
Why I would be concerned with namespace aliases is to achieve
referential identity between two members of namespaces that are
aliased to the same namespace. For instance for the following C++
code:
namespace Foo {
int add(int a, int b);
}
namespace Bar = Foo;
The Javascript expression "Foo.add == Foo.bar" should be true.
>> One SWIG behavior I think I don't like is that I notice namespaces are
>> generating getters and setters right now. My plan for wrapping
>> namespaces in my module does not include injecting intermediate
>> getters for each statement like "mymodule.namespace.func(1,2,3)" nor
>> to allow statements like "mymodule.namespace1 = mymodule.namespace2".
>> Statements like "mymodule.namespace = whatever" would either be
>> disallowed or would simply be handled by the Javascript interpreter by
>> (for "mymodule.namespace = whatever")
>
> Again, you really don't want to be getting into this nightmare generating
> this kind of code. Just generate the fully qualified types.
Sorry for being unclear, I want to write *less* code, and allow the
Javascript interpreter to provide consistent and predictable semantics
to the Javascript programmer. I don't want or need getters or setters
for namespaces, as namespaces will be represented in my target
platform as Javascript Objects, which are a lot like Hash tables with
special hooks, and once I have instantiated them, attached properties
to them, and then attached them as properties of other objects to they
can be reached by the programmer, I want to be done with them. No more
SWIG wrapper code need intervene once it is all set up at module
initialization time.
Thanks again for all of your feedback, and keeping me up to date on
the latest SWIG changes upstream!
--
http://codebad.com/

Donny
Are you following the svn commits? If so you'd have noticed some limited
support for non-flattened namespaces via the nspace feature. So
currently only enums, classes, unions and structs can exist in a
namespace. Of notable absence are variables and functions declared in a
namespace.
In your target language, you can always get the current namespace via a
call to Language::getNSpace(). The namespace returned is a language
specific namespace and currently for C# and Java (only supported
languages), it uses "." as the namespace/package separator. I suspect
many languages will just use the ".", but when one comes along that does
not, we can easily make this configurable for the core code.
On a more strategic level, I suggest you forget about flattening the
namespaces until you can support all of SWIG's other features. One of
SWIG's strengths are the number of languages it supports and a degree of
consistency amongst the wrappers. I'm not likely to accept any namespace
changes that don't build on the nspace feature, so please demonstrate
this working plus all the other SWIG features before modifying the
nspace support. Walking before running is strongly advised!
More comments inline.
Donny Viszneki wrote:
> Ah parentNode()! That's exactly what I was looking for.
>
> Next order of business:
>
> Because I am attempting to support unflattened namespaces, it would be
> really helpful if cdecl Node instances would have an attribute
> referencing their namespace. Perhaps for the most correct behavior,
> SWIG would later have to instantiate and process more Node instances
> representing the different aliases which result from statements like:
>
> namespace foo {
> void bar(void);
> }
> namespace baz = foo;
>
Why are you concerned with this. All the namespaces are handled within
the core code. Is there some symbol table problem we should know about?
> For this we'd need a cdecl Node for foo::bar(), and then some other
> node perhaps a "cdecl-alias" that linked back to the "primordial node"
> representing the right cdecl. In this case perhaps you'd get a
> primordial "bar()" cdecl for with a new "namespace" attribute
> describing the "foo" namespace, and then later a "bar()" cdecl-alias
> with a "primordial" attribute referencing the original "bar()" cdecl
> node, but with a new "namespace" attribute referencing a node
> describing the baz namespace.
>
> For something like "namespace baz = foo" the quickest solution might
> be a "namespace-alias" Node, but the cdecl-alias/primordial technique
> in the above paragraph also covers declarations like "namespace baz {
> using foo::bar; }"
>
I think the wrappers should always use a fully qualified type in the
target language and each wrapped type can only exist in one namespace.
Given that, why do you need to be concerned with namespace aliases?
Surely it is just something for the parser to deal with? I believe it
does this all okay.
> One SWIG behavior I think I don't like is that I notice namespaces are
> generating getters and setters right now. My plan for wrapping
> namespaces in my module does not include injecting intermediate
> getters for each statement like "mymodule.namespace.func(1,2,3)" nor
> to allow statements like "mymodule.namespace1 = mymodule.namespace2".
> Statements like "mymodule.namespace = whatever" would either be
> disallowed or would simply be handled by the Javascript interpreter by
> (for "mymodule.namespace = whatever")
Again, you really don't want to be getting into this nightmare
generating this kind of code. Just generate the fully qualified types.
> setting the "namespace" property
> of the object referenced by "mymodule" to be a reference to the
> Javascript object "whatever" (or whatever other value "whatever" might
> be including numbers, strings, or functions.) The Javascript
> interpreter is already well suited to this task, as namespaces and the
> place where static class member functions live are simply going to be
> Javascript objects or Javascript functions, both of which can have
> arbitrary properties assigned to them. In fact my way of wrapping both
> namespace members as well as static class members is going to be
> identical, and so certainly be invoke the same wrappering code.
>
> Thanks again for taking the time to read my emails
>
William
> On Sun, Mar 7, 2010 at 12:33 PM, William S Fulton
> <wsf@...> wrote:
>> Donny Viszneki wrote:
>>> Hi all.
>>>
>>> So I've noticed a common programming pattern in other SWIG modules.
>>> Here's some pseudo-code:
>>>
>>> class MyLanguage : public Language {
>>> bool specialMode;
>>> int processSomeNode(Node* n){
>>> if (doWeNeedSpecialMode(n))
>>> specialMode = true;
>>> Language::processSomeNode(n);
>>> specialMode = false;
>>> }
>>> };
>>>
>>> In English, what this pattern attempts to accomplish is to pass down a
>>> notional attribute to nodes nested in some node that contains the
>>> clues for special processing.
>>>
>>> The pattern I expected to be available to me is that some attributes
>>> could simply be inherited from the nodes that contained them. The
>>> obvious case for an attribute that should be inherited by a node's
>>> children is what its parents are, but I can imagine others.
>>>
>>> My use case:
>>>
>>> In Javascript as in many other scripting languages, "Objects" (or
>>> hashes, or tables; whatever you want to call them) are the single
>>> unified organizational paradigm for the language. OOP classes in
>>> Javascript are more or less (a bit less, actually) accomplished using
>>> Objects. Javascript's analog to a C++ namespace is an Object.
>>> Functions in Javascript can have properties (attributes) associated on
>>> them *just* like Objects, and so Javascript's analog to static class
>>> methods are (more or less) Objects.
>>>
>>> Perhaps I'm saying "Objects" too much, when what I really mean is that
>>> everything fits into a very natural hierarchical organization. Here is
>>> some early code from my SWIG module to further demonstrate what I
>>> mean, in pseudo-code form for clarity (to avoid confusion, you should
>>> know that "node" here is a "ModuleTree" element, not a SWIG Node, but
>>> they're conceptually similar):
>>>
>>> RegisterModuleTree(ModuleTree *node, JSObject *parent) {
>>> do {
>>> switch (node->type)
>>> {
>>> case TYPE_PRIMITIVE:
>>> RegisterPrimitive(node, parent);
>>> break;
>>> case TYPE_NAMESPACE
>>> JSObject *newNamespaceObject = RegisterNewObject(node, parent);
>>> if (node->hasChildren)
>>> RegisterModuleTree(node->firstChild, newNamespaceObject);
>>> break;
>>> /* other types... */
>>> }
>>> } while (NULL != (node = node->nextSibling));
>>> }
>>>
>>> So you can see in my wrapper code produced by SWIG, the initialization
>>> code walks through a hierarchical tree and begins defining variables
>>> and entry points for the interpreter. Emitting code to define a tree
>>> structure unsurprisingly necessitates building that tree structure (or
>>> something similar to it) in my SWIG module. I thought this would be
>>> straightforward, but I couldn't find any inheritance mechanisms, or a
>>> "parent" link for SWIG Nodes that I could use to walk up a Node tree
>>> and infer what attributes my Node should be inheriting.
>>>
>> I think this is easily solved via a call to parentNode(n). Be aware that the
>> parent node is not always of the same type, for example when a method is
>> wrapped using %extend, it is different to when a normal class method is
>> wrapped. You can view this with the swig -debug-top n option or by adding
>> Swig_print_node(n) into the code somewhere.
>>
>>> The need for SWIG Node attribute inheritance is so that I can avoid an
>>> annoying "push and pop" pattern of programming that is used in many
>>> other SWIG modules (no insult to any SWIG module programmers! you guys
>>> are great!:)
>>>
>>> So I thought I would just be able to do something like this:
>>>
>>> Setattr(n, "mytree:bookmark", treeParent);
>>>
>>> If I had a way of achieving inheritance, then in namespaceWrapper() or
>>> classWrapper() or any other wrapper that will require my module to
>>> define more Javascript properties as children of the Javascript Object
>>> (or constructor function, in the case of classes) this simple code
>>> would then allow me to do this:
>>>
>>> // Push myNewTreeNode into the first child position
>>> // of our tree parent
>>> treeParent = Getattr(n, "mytree:bookmark");
>>> nextSibling = Getattr(treeParent, "mytree:firstChild");
>>> Setattr(treeParent, "mytree:firstChild", myNewTreeNode);
>>> Setattr(myNewTreeNode, "mytree:nextSibling", nextSibling);
>>>
>>> The output of this tree structure might look something like this:
>>>
>>> TopLevel
>>> - Namespace1
>>> -- ChildOfNamespace1
>>> -- ChildOfNamespace2
>>> - Class1
>>> -- constructorFunctionForClass1
>>> -- staticMemberVariableForClass1
>>> -- staticMemberFunctionForClass1
>>> -- Class1_2 // <-- a class that is also a member of Class 1
>>> etc. etc.
>>>
>>> Some of this is easy to do differently than I'm doing, but some of it
>>> is impossible without this sort of programming.
>>>
>>> ANY advice that can be provided would be extremely appreciated, but
>>> I'm really hoping someone will say "Oh yes, here is the mechanism for
>>> SWIG Node attribute inheritance..."
>>>
>>> Thanks in advance :)
>>>
>> Hopefully my answer above helps??
>>
>> William
>>
>
>

I am trying to pass an array of strings from c# to the underling c++ library.
string[] -> *char[]
This works fine in java using an approach like this:
%include "various.i"
%apply char **STRING_ARRAY { const char *cfgFiles[] };
But I cannot figure out to do that for C#.
Can someone help regarding this?

Patches item #2967392, was opened at 2010-03-10 14:02
Message generated for change (Comment added) made by talby
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2967392&group_id=1645
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: MarkoK (marko314)
>Assigned to: Robert Stone (talby)
Summary: perl - invalid code if C++ method has default parameters
Initial Comment:
If method of a C++ class has parameters with default values, and is not overloaded, the code generated for Perl crashes, because it tries to assign value to contents of a NULL pointer. The patch is attached. I've applied the same solution as used in the equivalent python file (if statement added).
----------------------------------------------------------------------
>Comment By: Robert Stone (talby)
Date: 2010-03-13 18:19
Message:
Thanks for the report! There's clearly something wrong in this area of the
code if you were able to get an attempt to dereference a NULL pointer, but
I'm having trouble reproducing the issue. I'd like to build a testcase so
I can be certain this problem won't re-emerge.
I tried something like:
class Thing {
public:
int method(Thing *p = 0) {
return p ? 1 : 0;
}
};
but can't seem find a way to make the generated code crash with this.
----------------------------------------------------------------------
Comment By: MarkoK (marko314)
Date: 2010-03-10 14:06
Message:
Forgot to mention - the patch was made against the current trunk, svn. rev.
11934
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2967392&group_id=1645

More follow-up:
Are const static class members supported? These two declarations are
giving me a syntax error during SWIG processing:
class Foo {
const static int Bar = 666;
};
and:
class Foo {
const static int Bar;
};
const int Foo::Bar = 666;
I think ideally the semantics for static class members are the same
for namespace members.
On Thu, Mar 11, 2010 at 5:21 AM, Donny Viszneki
<donny.viszneki@...> wrote:
> Ah parentNode()! That's exactly what I was looking for.
>
> Next order of business:
>
> Because I am attempting to support unflattened namespaces, it would be
> really helpful if cdecl Node instances would have an attribute
> referencing their namespace. Perhaps for the most correct behavior,
> SWIG would later have to instantiate and process more Node instances
> representing the different aliases which result from statements like:
>
> namespace foo {
> void bar(void);
> }
> namespace baz = foo;
>
> For this we'd need a cdecl Node for foo::bar(), and then some other
> node perhaps a "cdecl-alias" that linked back to the "primordial node"
> representing the right cdecl. In this case perhaps you'd get a
> primordial "bar()" cdecl for with a new "namespace" attribute
> describing the "foo" namespace, and then later a "bar()" cdecl-alias
> with a "primordial" attribute referencing the original "bar()" cdecl
> node, but with a new "namespace" attribute referencing a node
> describing the baz namespace.
>
> For something like "namespace baz = foo" the quickest solution might
> be a "namespace-alias" Node, but the cdecl-alias/primordial technique
> in the above paragraph also covers declarations like "namespace baz {
> using foo::bar; }"
>
> One SWIG behavior I think I don't like is that I notice namespaces are
> generating getters and setters right now. My plan for wrapping
> namespaces in my module does not include injecting intermediate
> getters for each statement like "mymodule.namespace.func(1,2,3)" nor
> to allow statements like "mymodule.namespace1 = mymodule.namespace2".
> Statements like "mymodule.namespace = whatever" would either be
> disallowed or would simply be handled by the Javascript interpreter by
> (for "mymodule.namespace = whatever") setting the "namespace" property
> of the object referenced by "mymodule" to be a reference to the
> Javascript object "whatever" (or whatever other value "whatever" might
> be including numbers, strings, or functions.) The Javascript
> interpreter is already well suited to this task, as namespaces and the
> place where static class member functions live are simply going to be
> Javascript objects or Javascript functions, both of which can have
> arbitrary properties assigned to them. In fact my way of wrapping both
> namespace members as well as static class members is going to be
> identical, and so certainly be invoke the same wrappering code.
>
> Thanks again for taking the time to read my emails
>
> On Sun, Mar 7, 2010 at 12:33 PM, William S Fulton
> <wsf@...> wrote:
>> Donny Viszneki wrote:
>>>
>>> Hi all.
>>>
>>> So I've noticed a common programming pattern in other SWIG modules.
>>> Here's some pseudo-code:
>>>
>>> class MyLanguage : public Language {
>>> bool specialMode;
>>> int processSomeNode(Node* n){
>>> if (doWeNeedSpecialMode(n))
>>> specialMode = true;
>>> Language::processSomeNode(n);
>>> specialMode = false;
>>> }
>>> };
>>>
>>> In English, what this pattern attempts to accomplish is to pass down a
>>> notional attribute to nodes nested in some node that contains the
>>> clues for special processing.
>>>
>>> The pattern I expected to be available to me is that some attributes
>>> could simply be inherited from the nodes that contained them. The
>>> obvious case for an attribute that should be inherited by a node's
>>> children is what its parents are, but I can imagine others.
>>>
>>> My use case:
>>>
>>> In Javascript as in many other scripting languages, "Objects" (or
>>> hashes, or tables; whatever you want to call them) are the single
>>> unified organizational paradigm for the language. OOP classes in
>>> Javascript are more or less (a bit less, actually) accomplished using
>>> Objects. Javascript's analog to a C++ namespace is an Object.
>>> Functions in Javascript can have properties (attributes) associated on
>>> them *just* like Objects, and so Javascript's analog to static class
>>> methods are (more or less) Objects.
>>>
>>> Perhaps I'm saying "Objects" too much, when what I really mean is that
>>> everything fits into a very natural hierarchical organization. Here is
>>> some early code from my SWIG module to further demonstrate what I
>>> mean, in pseudo-code form for clarity (to avoid confusion, you should
>>> know that "node" here is a "ModuleTree" element, not a SWIG Node, but
>>> they're conceptually similar):
>>>
>>> RegisterModuleTree(ModuleTree *node, JSObject *parent) {
>>> do {
>>> switch (node->type)
>>> {
>>> case TYPE_PRIMITIVE:
>>> RegisterPrimitive(node, parent);
>>> break;
>>> case TYPE_NAMESPACE
>>> JSObject *newNamespaceObject = RegisterNewObject(node, parent);
>>> if (node->hasChildren)
>>> RegisterModuleTree(node->firstChild, newNamespaceObject);
>>> break;
>>> /* other types... */
>>> }
>>> } while (NULL != (node = node->nextSibling));
>>> }
>>>
>>> So you can see in my wrapper code produced by SWIG, the initialization
>>> code walks through a hierarchical tree and begins defining variables
>>> and entry points for the interpreter. Emitting code to define a tree
>>> structure unsurprisingly necessitates building that tree structure (or
>>> something similar to it) in my SWIG module. I thought this would be
>>> straightforward, but I couldn't find any inheritance mechanisms, or a
>>> "parent" link for SWIG Nodes that I could use to walk up a Node tree
>>> and infer what attributes my Node should be inheriting.
>>>
>> I think this is easily solved via a call to parentNode(n). Be aware that the
>> parent node is not always of the same type, for example when a method is
>> wrapped using %extend, it is different to when a normal class method is
>> wrapped. You can view this with the swig -debug-top n option or by adding
>> Swig_print_node(n) into the code somewhere.
>>
>>> The need for SWIG Node attribute inheritance is so that I can avoid an
>>> annoying "push and pop" pattern of programming that is used in many
>>> other SWIG modules (no insult to any SWIG module programmers! you guys
>>> are great!:)
>>>
>>> So I thought I would just be able to do something like this:
>>>
>>> Setattr(n, "mytree:bookmark", treeParent);
>>>
>>> If I had a way of achieving inheritance, then in namespaceWrapper() or
>>> classWrapper() or any other wrapper that will require my module to
>>> define more Javascript properties as children of the Javascript Object
>>> (or constructor function, in the case of classes) this simple code
>>> would then allow me to do this:
>>>
>>> // Push myNewTreeNode into the first child position
>>> // of our tree parent
>>> treeParent = Getattr(n, "mytree:bookmark");
>>> nextSibling = Getattr(treeParent, "mytree:firstChild");
>>> Setattr(treeParent, "mytree:firstChild", myNewTreeNode);
>>> Setattr(myNewTreeNode, "mytree:nextSibling", nextSibling);
>>>
>>> The output of this tree structure might look something like this:
>>>
>>> TopLevel
>>> - Namespace1
>>> -- ChildOfNamespace1
>>> -- ChildOfNamespace2
>>> - Class1
>>> -- constructorFunctionForClass1
>>> -- staticMemberVariableForClass1
>>> -- staticMemberFunctionForClass1
>>> -- Class1_2 // <-- a class that is also a member of Class 1
>>> etc. etc.
>>>
>>> Some of this is easy to do differently than I'm doing, but some of it
>>> is impossible without this sort of programming.
>>>
>>> ANY advice that can be provided would be extremely appreciated, but
>>> I'm really hoping someone will say "Oh yes, here is the mechanism for
>>> SWIG Node attribute inheritance..."
>>>
>>> Thanks in advance :)
>>>
>> Hopefully my answer above helps??
>>
>> William
>>
>
>
> --
> http://codebad.com/
>
--
http://codebad.com/

Ah parentNode()! That's exactly what I was looking for.
Next order of business:
Because I am attempting to support unflattened namespaces, it would be
really helpful if cdecl Node instances would have an attribute
referencing their namespace. Perhaps for the most correct behavior,
SWIG would later have to instantiate and process more Node instances
representing the different aliases which result from statements like:
namespace foo {
void bar(void);
}
namespace baz = foo;
For this we'd need a cdecl Node for foo::bar(), and then some other
node perhaps a "cdecl-alias" that linked back to the "primordial node"
representing the right cdecl. In this case perhaps you'd get a
primordial "bar()" cdecl for with a new "namespace" attribute
describing the "foo" namespace, and then later a "bar()" cdecl-alias
with a "primordial" attribute referencing the original "bar()" cdecl
node, but with a new "namespace" attribute referencing a node
describing the baz namespace.
For something like "namespace baz = foo" the quickest solution might
be a "namespace-alias" Node, but the cdecl-alias/primordial technique
in the above paragraph also covers declarations like "namespace baz {
using foo::bar; }"
One SWIG behavior I think I don't like is that I notice namespaces are
generating getters and setters right now. My plan for wrapping
namespaces in my module does not include injecting intermediate
getters for each statement like "mymodule.namespace.func(1,2,3)" nor
to allow statements like "mymodule.namespace1 = mymodule.namespace2".
Statements like "mymodule.namespace = whatever" would either be
disallowed or would simply be handled by the Javascript interpreter by
(for "mymodule.namespace = whatever") setting the "namespace" property
of the object referenced by "mymodule" to be a reference to the
Javascript object "whatever" (or whatever other value "whatever" might
be including numbers, strings, or functions.) The Javascript
interpreter is already well suited to this task, as namespaces and the
place where static class member functions live are simply going to be
Javascript objects or Javascript functions, both of which can have
arbitrary properties assigned to them. In fact my way of wrapping both
namespace members as well as static class members is going to be
identical, and so certainly be invoke the same wrappering code.
Thanks again for taking the time to read my emails
On Sun, Mar 7, 2010 at 12:33 PM, William S Fulton
<wsf@...> wrote:
> Donny Viszneki wrote:
>>
>> Hi all.
>>
>> So I've noticed a common programming pattern in other SWIG modules.
>> Here's some pseudo-code:
>>
>> class MyLanguage : public Language {
>> bool specialMode;
>> int processSomeNode(Node* n){
>> if (doWeNeedSpecialMode(n))
>> specialMode = true;
>> Language::processSomeNode(n);
>> specialMode = false;
>> }
>> };
>>
>> In English, what this pattern attempts to accomplish is to pass down a
>> notional attribute to nodes nested in some node that contains the
>> clues for special processing.
>>
>> The pattern I expected to be available to me is that some attributes
>> could simply be inherited from the nodes that contained them. The
>> obvious case for an attribute that should be inherited by a node's
>> children is what its parents are, but I can imagine others.
>>
>> My use case:
>>
>> In Javascript as in many other scripting languages, "Objects" (or
>> hashes, or tables; whatever you want to call them) are the single
>> unified organizational paradigm for the language. OOP classes in
>> Javascript are more or less (a bit less, actually) accomplished using
>> Objects. Javascript's analog to a C++ namespace is an Object.
>> Functions in Javascript can have properties (attributes) associated on
>> them *just* like Objects, and so Javascript's analog to static class
>> methods are (more or less) Objects.
>>
>> Perhaps I'm saying "Objects" too much, when what I really mean is that
>> everything fits into a very natural hierarchical organization. Here is
>> some early code from my SWIG module to further demonstrate what I
>> mean, in pseudo-code form for clarity (to avoid confusion, you should
>> know that "node" here is a "ModuleTree" element, not a SWIG Node, but
>> they're conceptually similar):
>>
>> RegisterModuleTree(ModuleTree *node, JSObject *parent) {
>> do {
>> switch (node->type)
>> {
>> case TYPE_PRIMITIVE:
>> RegisterPrimitive(node, parent);
>> break;
>> case TYPE_NAMESPACE
>> JSObject *newNamespaceObject = RegisterNewObject(node, parent);
>> if (node->hasChildren)
>> RegisterModuleTree(node->firstChild, newNamespaceObject);
>> break;
>> /* other types... */
>> }
>> } while (NULL != (node = node->nextSibling));
>> }
>>
>> So you can see in my wrapper code produced by SWIG, the initialization
>> code walks through a hierarchical tree and begins defining variables
>> and entry points for the interpreter. Emitting code to define a tree
>> structure unsurprisingly necessitates building that tree structure (or
>> something similar to it) in my SWIG module. I thought this would be
>> straightforward, but I couldn't find any inheritance mechanisms, or a
>> "parent" link for SWIG Nodes that I could use to walk up a Node tree
>> and infer what attributes my Node should be inheriting.
>>
> I think this is easily solved via a call to parentNode(n). Be aware that the
> parent node is not always of the same type, for example when a method is
> wrapped using %extend, it is different to when a normal class method is
> wrapped. You can view this with the swig -debug-top n option or by adding
> Swig_print_node(n) into the code somewhere.
>
>> The need for SWIG Node attribute inheritance is so that I can avoid an
>> annoying "push and pop" pattern of programming that is used in many
>> other SWIG modules (no insult to any SWIG module programmers! you guys
>> are great!:)
>>
>> So I thought I would just be able to do something like this:
>>
>> Setattr(n, "mytree:bookmark", treeParent);
>>
>> If I had a way of achieving inheritance, then in namespaceWrapper() or
>> classWrapper() or any other wrapper that will require my module to
>> define more Javascript properties as children of the Javascript Object
>> (or constructor function, in the case of classes) this simple code
>> would then allow me to do this:
>>
>> // Push myNewTreeNode into the first child position
>> // of our tree parent
>> treeParent = Getattr(n, "mytree:bookmark");
>> nextSibling = Getattr(treeParent, "mytree:firstChild");
>> Setattr(treeParent, "mytree:firstChild", myNewTreeNode);
>> Setattr(myNewTreeNode, "mytree:nextSibling", nextSibling);
>>
>> The output of this tree structure might look something like this:
>>
>> TopLevel
>> - Namespace1
>> -- ChildOfNamespace1
>> -- ChildOfNamespace2
>> - Class1
>> -- constructorFunctionForClass1
>> -- staticMemberVariableForClass1
>> -- staticMemberFunctionForClass1
>> -- Class1_2 // <-- a class that is also a member of Class 1
>> etc. etc.
>>
>> Some of this is easy to do differently than I'm doing, but some of it
>> is impossible without this sort of programming.
>>
>> ANY advice that can be provided would be extremely appreciated, but
>> I'm really hoping someone will say "Oh yes, here is the mechanism for
>> SWIG Node attribute inheritance..."
>>
>> Thanks in advance :)
>>
> Hopefully my answer above helps??
>
> William
>
--
http://codebad.com/

Bugs item #2958164, was opened at 2010-02-24 11:45
Message generated for change (Comment added) made by mutandiz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2958164&group_id=1645
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: allegrocl
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Timothy Anderson (taa01776)
Assigned to: Mikel Bancroft (mutandiz)
Summary: allegrocl output with C++ namespace can't find IDENTITY
Initial Comment:
When generating allegrocl functions (in allegrocl.cxx emit_defun), it occasionally needs to refer to the CL symbol IDENTITY (in Replaceall(ldestructor, ldestructor, "identity").
However, if the data type being referenced is in a C++ namespace, the CL package system :uses are not set up to find #'identity.
A fix is to change the literal string "identity" to "cl::identity"; almost all the other symbols that show up in an output Lisp file are already qualified in this way.
----------------------------------------------------------------------
>Comment By: Mikel Bancroft (mutandiz)
Date: 2010-03-10 11:39
Message:
Committed revision 11935. Thanks for the report.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2958164&group_id=1645

Patches item #2967392, was opened at 2010-03-10 15:02
Message generated for change (Comment added) made by marko314
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2967392&group_id=1645
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: MarkoK (marko314)
Assigned to: Nobody/Anonymous (nobody)
Summary: perl - invalid code if C++ method has default parameters
Initial Comment:
If method of a C++ class has parameters with default values, and is not overloaded, the code generated for Perl crashes, because it tries to assign value to contents of a NULL pointer. The patch is attached. I've applied the same solution as used in the equivalent python file (if statement added).
----------------------------------------------------------------------
>Comment By: MarkoK (marko314)
Date: 2010-03-10 15:06
Message:
Forgot to mention - the patch was made against the current trunk, svn. rev.
11934
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2967392&group_id=1645

Patches item #2967392, was opened at 2010-03-10 15:02
Message generated for change (Tracker Item Submitted) made by marko314
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2967392&group_id=1645
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: MarkoK (marko314)
Assigned to: Nobody/Anonymous (nobody)
Summary: perl - invalid code if C++ method has default parameters
Initial Comment:
If method of a C++ class has parameters with default values, and is not overloaded, the code generated for Perl crashes, because it tries to assign value to contents of a NULL pointer. The patch is attached. I've applied the same solution as used in the equivalent python file (if statement added).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2967392&group_id=1645

Bugs item #2965875, was opened at 2010-03-08 22:04
Message generated for change (Comment added) made by ebf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2965875&group_id=1645
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: java
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Eric Friedman (ebf)
Assigned to: William Fulton (wsfulton)
Summary: Problems with long/jlong and int64_t on 64-bit platforms
Initial Comment:
Hi,
I am using SWIG 1.3.39 and GCC 4.4.1 (Ubuntu 4.4.1-4ubuntu9) on Ubuntu 9.10 (Linux efriedma-ux 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux).
Normally on 64-bit Linux, int64_t is defined to be a `long int`. However, in SWIG (at least for Java), it is defined incorrectly, as seen in the following simple interface file:
// foo.i
%module foo
%{
#include <boost/static_assert.hpp>
#include <boost/type_traits/is_same.hpp>
BOOST_STATIC_ASSERT(( boost::is_same<int64_t, jlong>::value ));
%}
This may be compiled as follows:
$ swig -c++ -java foo.i
$ g++ foo_wrap.cxx
foo_wrap.cxx:216: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILURE<false>'
The error means the Boost static assertion has failed, which indicates that `int64_t` and `jlong` are not the same type. (The result is the same even if I include the SWIG import <stdint.i>.)
However, the following C++ program, which has the same check compiles without a problem:
#include <boost/static_assert.hpp>
#include <boost/type_traits/is_same.hpp>
int main()
{
BOOST_STATIC_ASSERT(( boost::is_same<int64_t, jlong>::value ));
return 0;
}
Trying to track this down, it seems as though the problem is due to the following lines in the SWIG-generated source file (foo_wrap.cxx):
/* Fix for jlong on 64-bit x86 Solaris */
#if defined(__x86_64)
# ifdef _LP64
# undef _LP64
# endif
#endif
Doing this causes the JNI headers to make the `jlong` type as a typedef for `long long int`. I don't understand why this is being done, as it's different from `int64_t`.
Thanks,
Eric
P.S. Looking at the Subversion history for this change, I came across the following:
http://swig.svn.sourceforge.net/viewvc/swig?view=rev&revision=6891
The commit message (from marcelomatus) is "fix warning(error?) with jlong + x86_64". Does that give any clue as to why this introduced? Are there other problems with SWIG on 64-bit platforms? (The uncertainty in the commit message is a bit unnerving.)
----------------------------------------------------------------------
>Comment By: Eric Friedman (ebf)
Date: 2010-03-10 00:57
Message:
Also, there is a further problem for 64-bit platforms (though seemingly
unrelated):
swigarch.i seems to be broken unless SWIGWORDSIZE64 is manually defined
(e.g., using -DSWIGWORDSIZE64). I see this has been reported elsewhere
(http://old.nabble.com/-BUG--stdint.i-gets-int64_t-wrong-on-64bit-archs-td20695275.html)
as well.
Unlike the issue with the core typemaps, this issue can at least be worked
around in a straightforward way with the -D option. But to fix it correctly
though seems to require changing the actual SWIG code generator (i.e., to
automatically define a preprocessor symbol like __x86_64 or __WORDSIZE
while processing interface files).
----------------------------------------------------------------------
Comment By: Eric Friedman (ebf)
Date: 2010-03-10 00:56
Message:
Looking further into this issue, I've come to the conclusion it's not just
`int64_t` that's being defined incorrectly on 64-bit platforms but also
`long` is being incorrectly typemapped. Specifically, it seems that at
least the Java support in SWIG assumes a 32-bit target.
In particular, a C `long` is always mapped to a Java `int` (`jint`).
However, on 64-bit platforms, a `long` is 64-bits and should be treated as
a Java `long` (`jlong`). The same issue applies also for `unsigned long`.
I think what should be happening is that typemaps for `long` should not be
defined at all. Instead, depending on the platform, either the typemaps for
`int` (on a 32-bit platform) or for `long long` (on a 64-bit platform)
should be copied (using %apply) to handle `long`. I've modified my
java/java.swg accordingly (and removed the _LP64 business in
java/javahead.swg) and it seems to solve the problem. I'll see if I can
post a patch in the next few days.
----------------------------------------------------------------------
Comment By: Eric Friedman (ebf)
Date: 2010-03-08 22:05
Message:
Also forgot to mention: I also checked with the latest version of SWIG
(1.3.40), and it seems that this issue is still present there as well.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2965875&group_id=1645

Bugs item #2965875, was opened at 2010-03-08 22:04
Message generated for change (Comment added) made by ebf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2965875&group_id=1645
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: java
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Eric Friedman (ebf)
Assigned to: William Fulton (wsfulton)
>Summary: Problems with long/jlong and int64_t on 64-bit platforms
Initial Comment:
Hi,
I am using SWIG 1.3.39 and GCC 4.4.1 (Ubuntu 4.4.1-4ubuntu9) on Ubuntu 9.10 (Linux efriedma-ux 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux).
Normally on 64-bit Linux, int64_t is defined to be a `long int`. However, in SWIG (at least for Java), it is defined incorrectly, as seen in the following simple interface file:
// foo.i
%module foo
%{
#include <boost/static_assert.hpp>
#include <boost/type_traits/is_same.hpp>
BOOST_STATIC_ASSERT(( boost::is_same<int64_t, jlong>::value ));
%}
This may be compiled as follows:
$ swig -c++ -java foo.i
$ g++ foo_wrap.cxx
foo_wrap.cxx:216: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILURE<false>'
The error means the Boost static assertion has failed, which indicates that `int64_t` and `jlong` are not the same type. (The result is the same even if I include the SWIG import <stdint.i>.)
However, the following C++ program, which has the same check compiles without a problem:
#include <boost/static_assert.hpp>
#include <boost/type_traits/is_same.hpp>
int main()
{
BOOST_STATIC_ASSERT(( boost::is_same<int64_t, jlong>::value ));
return 0;
}
Trying to track this down, it seems as though the problem is due to the following lines in the SWIG-generated source file (foo_wrap.cxx):
/* Fix for jlong on 64-bit x86 Solaris */
#if defined(__x86_64)
# ifdef _LP64
# undef _LP64
# endif
#endif
Doing this causes the JNI headers to make the `jlong` type as a typedef for `long long int`. I don't understand why this is being done, as it's different from `int64_t`.
Thanks,
Eric
P.S. Looking at the Subversion history for this change, I came across the following:
http://swig.svn.sourceforge.net/viewvc/swig?view=rev&revision=6891
The commit message (from marcelomatus) is "fix warning(error?) with jlong + x86_64". Does that give any clue as to why this introduced? Are there other problems with SWIG on 64-bit platforms? (The uncertainty in the commit message is a bit unnerving.)
----------------------------------------------------------------------
>Comment By: Eric Friedman (ebf)
Date: 2010-03-10 00:56
Message:
Looking further into this issue, I've come to the conclusion it's not just
`int64_t` that's being defined incorrectly on 64-bit platforms but also
`long` is being incorrectly typemapped. Specifically, it seems that at
least the Java support in SWIG assumes a 32-bit target.
In particular, a C `long` is always mapped to a Java `int` (`jint`).
However, on 64-bit platforms, a `long` is 64-bits and should be treated as
a Java `long` (`jlong`). The same issue applies also for `unsigned long`.
I think what should be happening is that typemaps for `long` should not be
defined at all. Instead, depending on the platform, either the typemaps for
`int` (on a 32-bit platform) or for `long long` (on a 64-bit platform)
should be copied (using %apply) to handle `long`. I've modified my
java/java.swg accordingly (and removed the _LP64 business in
java/javahead.swg) and it seems to solve the problem. I'll see if I can
post a patch in the next few days.
----------------------------------------------------------------------
Comment By: Eric Friedman (ebf)
Date: 2010-03-08 22:05
Message:
Also forgot to mention: I also checked with the latest version of SWIG
(1.3.40), and it seems that this issue is still present there as well.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2965875&group_id=1645

Bugs item #2965875, was opened at 2010-03-08 22:04
Message generated for change (Comment added) made by ebf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2965875&group_id=1645
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: java
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Eric Friedman (ebf)
Assigned to: William Fulton (wsfulton)
Summary: int64_t defined incorrectly
Initial Comment:
Hi,
I am using SWIG 1.3.39 and GCC 4.4.1 (Ubuntu 4.4.1-4ubuntu9) on Ubuntu 9.10 (Linux efriedma-ux 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux).
Normally on 64-bit Linux, int64_t is defined to be a `long int`. However, in SWIG (at least for Java), it is defined incorrectly, as seen in the following simple interface file:
// foo.i
%module foo
%{
#include <boost/static_assert.hpp>
#include <boost/type_traits/is_same.hpp>
BOOST_STATIC_ASSERT(( boost::is_same<int64_t, jlong>::value ));
%}
This may be compiled as follows:
$ swig -c++ -java foo.i
$ g++ foo_wrap.cxx
foo_wrap.cxx:216: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILURE<false>'
The error means the Boost static assertion has failed, which indicates that `int64_t` and `jlong` are not the same type. (The result is the same even if I include the SWIG import <stdint.i>.)
However, the following C++ program, which has the same check compiles without a problem:
#include <boost/static_assert.hpp>
#include <boost/type_traits/is_same.hpp>
int main()
{
BOOST_STATIC_ASSERT(( boost::is_same<int64_t, jlong>::value ));
return 0;
}
Trying to track this down, it seems as though the problem is due to the following lines in the SWIG-generated source file (foo_wrap.cxx):
/* Fix for jlong on 64-bit x86 Solaris */
#if defined(__x86_64)
# ifdef _LP64
# undef _LP64
# endif
#endif
Doing this causes the JNI headers to make the `jlong` type as a typedef for `long long int`. I don't understand why this is being done, as it's different from `int64_t`.
Thanks,
Eric
P.S. Looking at the Subversion history for this change, I came across the following:
http://swig.svn.sourceforge.net/viewvc/swig?view=rev&revision=6891
The commit message (from marcelomatus) is "fix warning(error?) with jlong + x86_64". Does that give any clue as to why this introduced? Are there other problems with SWIG on 64-bit platforms? (The uncertainty in the commit message is a bit unnerving.)
----------------------------------------------------------------------
>Comment By: Eric Friedman (ebf)
Date: 2010-03-08 22:05
Message:
Also forgot to mention: I also checked with the latest version of SWIG
(1.3.40), and it seems that this issue is still present there as well.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2965875&group_id=1645

Bugs item #2965875, was opened at 2010-03-08 22:04
Message generated for change (Tracker Item Submitted) made by ebf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2965875&group_id=1645
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: java
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Eric Friedman (ebf)
Assigned to: William Fulton (wsfulton)
Summary: int64_t defined incorrectly
Initial Comment:
Hi,
I am using SWIG 1.3.39 and GCC 4.4.1 (Ubuntu 4.4.1-4ubuntu9) on Ubuntu 9.10 (Linux efriedma-ux 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux).
Normally on 64-bit Linux, int64_t is defined to be a `long int`. However, in SWIG (at least for Java), it is defined incorrectly, as seen in the following simple interface file:
// foo.i
%module foo
%{
#include <boost/static_assert.hpp>
#include <boost/type_traits/is_same.hpp>
BOOST_STATIC_ASSERT(( boost::is_same<int64_t, jlong>::value ));
%}
This may be compiled as follows:
$ swig -c++ -java foo.i
$ g++ foo_wrap.cxx
foo_wrap.cxx:216: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILURE<false>'
The error means the Boost static assertion has failed, which indicates that `int64_t` and `jlong` are not the same type. (The result is the same even if I include the SWIG import <stdint.i>.)
However, the following C++ program, which has the same check compiles without a problem:
#include <boost/static_assert.hpp>
#include <boost/type_traits/is_same.hpp>
int main()
{
BOOST_STATIC_ASSERT(( boost::is_same<int64_t, jlong>::value ));
return 0;
}
Trying to track this down, it seems as though the problem is due to the following lines in the SWIG-generated source file (foo_wrap.cxx):
/* Fix for jlong on 64-bit x86 Solaris */
#if defined(__x86_64)
# ifdef _LP64
# undef _LP64
# endif
#endif
Doing this causes the JNI headers to make the `jlong` type as a typedef for `long long int`. I don't understand why this is being done, as it's different from `int64_t`.
Thanks,
Eric
P.S. Looking at the Subversion history for this change, I came across the following:
http://swig.svn.sourceforge.net/viewvc/swig?view=rev&revision=6891
The commit message (from marcelomatus) is "fix warning(error?) with jlong + x86_64". Does that give any clue as to why this introduced? Are there other problems with SWIG on 64-bit platforms? (The uncertainty in the commit message is a bit unnerving.)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2965875&group_id=1645