I have a couple of tasks remaining, but so far things are going
smoothly. I've had to review some of my earliest work on this branch,
and have found some success where I failed before. Thanks for the
review.
On Tue, Sep 24, 2013 at 10:22:15PM +0100, William S Fulton wrote:
>
> A couple of observations in perlrun.swg:
>
> +#define SWIG_POINTER_MG 0x4
> +#define SWIG_POINTER_WR 0x8
> +/* These Perl specific pointer conversion flags handle two alternate
> + * types of native pointer recovery, _MG handles wrapped variables and
> + * object attributes, and _WR handles destructors.
> + *
> + * TODO: document the shadow object memory layout.
> + */
>
> What do _MG and _WR stand for? Perhaps a longer name would be better
> or document them here.
I've renamed and clarified SWIG_POINTER_MG and removed the need
for SWIG_POINTER_WR. I also moved the value out to 0x4000 to give
swigrun.swg more room for additional flags in the future.
> -#define SWIG_SHADOW SWIG_OWNER << 1
> I was wondering if this would break current code and if there is a
> backwards compatible replacement? I don't think this was documented,
> however, a quick bit of googling showed up some use of it. Hopefully
> and preferably you can restore this macro with something that works
> as it used to, otherwise at the minimum, can you put something in
> the changes file as to how to code up a replacement.
I purged this early on when removing "$shadow" at the request of
a couple of you guys without really knowing what the feature did, but it
was easy to bring SWIG_SHADOW back.
> Could you also convert to perl and add the 'extend' and 'callback'
> examples? These are the standard examples showing off directors.
These are now in the branch.
> I see cwrap.c has new attribute handling for "arg:classref" and I'm
> trying to work out why this is necessary given that this additional
> 'self' parameter is also in the other director supported languages.
> It looks like these are equivalent to Python's 'PyObject *self' and
> Ruby's 'VALUE self', Java's 'jobject jself' etc. It seems that you
> are bypassing the 'use_director' in Swig_ConstructorToFunction.
This was to handle what I think is somewhat unique to Perl, an
implicit argument to static member functions and constructors. I was
able to retool things to avoid the cwrap.c patches.
> Also can the name be changed to 'SV self' or does 'SV proto' make a
> lot more sense in Perl?
This is a Perl idiom for the implicit first argument of class
methods before the callee knows whether the argument is a class
reference or an object instance. It would be misleading to name it
"self", though I can understand your confusion. I expect as support for
multiple inheritance evolves, the difference should become much clearer.
However, with removing the cwrap.c patches, the only mention of "proto"
is now in director classes.

On 24/09/13 20:40, Vladimir Kalinin wrote:
>> I think this is going to be the first time we merge github branches in
>> SWIG. I don't truly know what we should be doing. What I do know is that
>> if I was to merge most branches, it completely confuses me with all the
>> history of the development in the branch tangling the history of master.
>> So in many ways I'd prefer not to see the history of the development of
>> any of the branches, rather a single patch to apply to master with 'git
>> am'. It seems that many projects work this way. A rebase should result
>> in an easy to read branch history, so I'm all for a rebase too. I
>> believe the correct etiquette is to create a new branch with the rebase
>> as the current branch is already public.
>>
>> Anyway, if I merge or apply a patch, your branch needs to be in a clean
>> working state to for merging to current master. Ultimately I would like
>> a Github pull request. I will then either 'git merge' it or 'git am' it
>> when the Travis tests all pass. Could you wait until 2.0.11 is released
>> before doing this though?
>>
>
> I merged the current swig master to my branch, so that now it can be
> easily merged upstream. Since you are going to ignore the branch
> history (--squash), doing rebase makes no sense (rebase would only be
> necessary to get a cleaner version of the branch history).
> I also posted a pull request on github.
Some first impressions of the patch:
- Documentation needed.
- As this is a major c++ feature, one fairly simple example in
Examples/<lang>/nested is needed, maybe showing off two nested classes deep.
- More runtime tests needed, the nested class runtime tests can be
easily duplicated from Java to C#.
- Nested class within the java/c# proxy class is not indented correctly.
- cwrap.c:1178 directorname assignment is pointless.
- In nested_class.i, the following effectively removes the test from
SWIG parsing, was that the intention?
-#ifdef SWIG
+#if defined(__GNUC__) || defined(_MSC_VER)
I'll take a deeper look next, but it basically looks like it does what
it should which I think is quite exciting.
Do you have any plans to extend this to other languages atm? One of the
things I want to get to grips with next is what happens with the
languages that havn't yet implemented support for nested classes... this
behaviour needs documenting too.
William

On 24/09/13 20:40, Vladimir Kalinin wrote:
>> I think this is going to be the first time we merge github branches in
>> SWIG. I don't truly know what we should be doing. What I do know is that
>> if I was to merge most branches, it completely confuses me with all the
>> history of the development in the branch tangling the history of master.
>> So in many ways I'd prefer not to see the history of the development of
>> any of the branches, rather a single patch to apply to master with 'git
>> am'. It seems that many projects work this way. A rebase should result
>> in an easy to read branch history, so I'm all for a rebase too. I
>> believe the correct etiquette is to create a new branch with the rebase
>> as the current branch is already public.
>>
>> Anyway, if I merge or apply a patch, your branch needs to be in a clean
>> working state to for merging to current master. Ultimately I would like
>> a Github pull request. I will then either 'git merge' it or 'git am' it
>> when the Travis tests all pass. Could you wait until 2.0.11 is released
>> before doing this though?
>>
>
> I merged the current swig master to my branch, so that now it can be
> easily merged upstream. Since you are going to ignore the branch
> history (--squash), doing rebase makes no sense (rebase would only be
> necessary to get a cleaner version of the branch history).
> I also posted a pull request on github.
>
Thanks, I'll look at this next, finally, and I apologise for not getting
around to it sooner. I see there are test-suite failures from the Travis
build, are you looking at those?
William

On Tue, Sep 24, 2013 at 10:22:15PM +0100, William S Fulton wrote:
> On 19/09/13 20:32, Robert Stone wrote:
> >On Thu, Sep 19, 2013 at 08:20:28AM +0100, William S Fulton wrote:
> >>I'm looking for branches to merge onto master now. Robert, it looks
> >>like the talby-perl5-improvements branch might be ready? Can you
> >>confirm, if so, I'll start thinking about merging it in.
> >>
> >
> > I've completed the major documentation updates I mentioned last
> >time. However, there are two more things I have planned. The first is
> >to move and clean up the documentation from Lib/perl5/GUTS into the
> >Doc/Manual/Perl5.html file. The second is to write an update for
> >CHANGES.current.
> >
> > I can notify you when I've done those two things, but you can
> >proceed without them if you like. I should have them soon.
>
> I committed a couple of minor tweaks on the branch and there are
> some further small improvements to do before the merge.
>
> A couple of observations in perlrun.swg:
>
> +#define SWIG_POINTER_MG 0x4
> +#define SWIG_POINTER_WR 0x8
> +/* These Perl specific pointer conversion flags handle two alternate
> + * types of native pointer recovery, _MG handles wrapped variables and
> + * object attributes, and _WR handles destructors.
> + *
> + * TODO: document the shadow object memory layout.
> + */
>
> What do _MG and _WR stand for? Perhaps a longer name would be better
> or document them here.
>
> -#define SWIG_SHADOW SWIG_OWNER << 1
> I was wondering if this would break current code and if there is a
> backwards compatible replacement? I don't think this was documented,
> however, a quick bit of googling showed up some use of it. Hopefully
> and preferably you can restore this macro with something that works
> as it used to, otherwise at the minimum, can you put something in
> the changes file as to how to code up a replacement.
>
> director_ignore.i shows a problem as there are warnings on ignored methods.
>
> The _wrap.h file for directors is missing. The contents seemed to
> have ended up in the _wrap.cxx file.
>
> Could you also convert to perl and add the 'extend' and 'callback'
> examples? These are the standard examples showing off directors.
>
> A few more lines of documentation in the director section
> introducing what they do would be nice. I don't think anyone reading
> it will fully realise the power of directors and that the feature
> enables cross language polymorphism and callbacks. The Python
> chapter on the subject is probably worth cribbing.
>
> I see cwrap.c has new attribute handling for "arg:classref" and I'm
> trying to work out why this is necessary given that this additional
> 'self' parameter is also in the other director supported languages.
> It looks like these are equivalent to Python's 'PyObject *self' and
> Ruby's 'VALUE self', Java's 'jobject jself' etc. It seems that you
> are bypassing the 'use_director' in Swig_ConstructorToFunction.
>
> Also can the name be changed to 'SV self' or does 'SV proto' make a
> lot more sense in Perl?
I'll start on these updates this evening. Thanks for looking
over this work!
-Robert

Working on your own Github fork is the way to go. I have deleted the
joelandersson-matlab branch. I hope you can contact them and track down
their latest code and use it as a base/reference.
William
On 24/09/13 09:30, Joel Andersson wrote:
> Hello!
>
> Late answer to this post since I don't follow this list regularly. From
> what gathered, Josef worked on this during his master's thesis together
> with a fellow student.
>
> Both their theses can be found online:
> http://is.muni.cz/th/256594/fi_m/thesis.pdf
> http://is.muni.cz/th/256412/fi_m/thesis_pacula.pdf
>
> I haven't heard about any work on this since.
>
> I have some spare time now and I plan to give SWIG-Matlab another shot.
> Since you are now on github, I'll probably do this in a fork and won't
> use the "joelandersson-matlab" branch, which has essentially no work in
> it (feel free to delete it). I'll send another mail to the list when
> I've started coding, probably around November.
>
> Greetings!
> Joel
>
>
>
>
> 2013/3/5 William S Fulton <wsf@...
> <mailto:wsf@...>>
>
> On 01/03/13 23:22, Kris Thielemans wrote:
> > Hi
> >
> > Does anyone know the status of the work by Josef Pacula on
> getting swig to
> > work to generate wrappers for matlab? There was quite an active
> discussion
> > in 2012, but there doesn't seem to have been a reaction on the
> last email
> > from Josef requesting some feedback
> >
> (http://article.gmane.org/gmane.comp.programming.swig.devel/21759/match=matl
> > ab)
> >
> > The code in github doesn't seem to have changed for 8 months,
> except in a
> > "pure" branch by "JohnRil", see
> > https://github.com/twiho/Matlab-in-SWIG/tree/pure
> >
> > I haven't tried any of this out (yet).
> >
> I don't know any more. Did you contact Joseph to see what he had to say?
> Please post to the list if you find out more.
>
> William
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Swig-devel mailing list
> Swig-devel@...
> <mailto:Swig-devel@...>
> https://lists.sourceforge.net/lists/listinfo/swig-devel
>
>
>
>
> --
> Joel Andersson, PhD Student
> Electrical Engineering Department (ESAT-SCD), Room 05.11,
> K.U.Leuven, Kasteelpark Arenberg 10 - bus 2446, 3001 Heverlee, Belgium
> Phone: +32-16-321819
> Mobile: +32-486-672874 (Belgium) / +34-63-4408800 (Spain) /
> +46-707-360512 (Sweden)
>
> Private address: Weidestraat 5, 3000 Leuven, Belgium

On 20/09/13 19:30, William S Fulton wrote:
> On 19/09/13 08:50, Simon Marchetto wrote:
>
>>
>> All identifiers must be 24 chars max long. Again, in Scilab 5.x. Scilab
>> has a very long history....
>
> Probably SWIG should then warn when an identifier is too long then so as
> to be helpful to users because otherwise the wrapped methods cannot be
> used.
>
> Note that some warnings are turned off by default and are turned on when
> using -Wextra. The Scilab identifier length warning could possibly be
> turned off by default??
>
This seems like a serious limitation that Scilab users should be warned
about by default as the code being wrapped is not usable. Doesn't it
make more sense to have this warning on by default?
William

On 19/09/13 20:32, Robert Stone wrote:
> On Thu, Sep 19, 2013 at 08:20:28AM +0100, William S Fulton wrote:
>> I'm looking for branches to merge onto master now. Robert, it looks
>> like the talby-perl5-improvements branch might be ready? Can you
>> confirm, if so, I'll start thinking about merging it in.
>>
>
> I've completed the major documentation updates I mentioned last
> time. However, there are two more things I have planned. The first is
> to move and clean up the documentation from Lib/perl5/GUTS into the
> Doc/Manual/Perl5.html file. The second is to write an update for
> CHANGES.current.
>
> I can notify you when I've done those two things, but you can
> proceed without them if you like. I should have them soon.
I committed a couple of minor tweaks on the branch and there are some
further small improvements to do before the merge.
A couple of observations in perlrun.swg:
+#define SWIG_POINTER_MG 0x4
+#define SWIG_POINTER_WR 0x8
+/* These Perl specific pointer conversion flags handle two alternate
+ * types of native pointer recovery, _MG handles wrapped variables and
+ * object attributes, and _WR handles destructors.
+ *
+ * TODO: document the shadow object memory layout.
+ */
What do _MG and _WR stand for? Perhaps a longer name would be better or
document them here.
-#define SWIG_SHADOW SWIG_OWNER << 1
I was wondering if this would break current code and if there is a
backwards compatible replacement? I don't think this was documented,
however, a quick bit of googling showed up some use of it. Hopefully and
preferably you can restore this macro with something that works as it
used to, otherwise at the minimum, can you put something in the changes
file as to how to code up a replacement.
director_ignore.i shows a problem as there are warnings on ignored methods.
The _wrap.h file for directors is missing. The contents seemed to have
ended up in the _wrap.cxx file.
Could you also convert to perl and add the 'extend' and 'callback'
examples? These are the standard examples showing off directors.
A few more lines of documentation in the director section introducing
what they do would be nice. I don't think anyone reading it will fully
realise the power of directors and that the feature enables cross
language polymorphism and callbacks. The Python chapter on the subject
is probably worth cribbing.
I see cwrap.c has new attribute handling for "arg:classref" and I'm
trying to work out why this is necessary given that this additional
'self' parameter is also in the other director supported languages. It
looks like these are equivalent to Python's 'PyObject *self' and Ruby's
'VALUE self', Java's 'jobject jself' etc. It seems that you are
bypassing the 'use_director' in Swig_ConstructorToFunction.
Also can the name be changed to 'SV self' or does 'SV proto' make a lot
more sense in Perl?
William

> I think this is going to be the first time we merge github branches in
> SWIG. I don't truly know what we should be doing. What I do know is that
> if I was to merge most branches, it completely confuses me with all the
> history of the development in the branch tangling the history of master.
> So in many ways I'd prefer not to see the history of the development of
> any of the branches, rather a single patch to apply to master with 'git
> am'. It seems that many projects work this way. A rebase should result
> in an easy to read branch history, so I'm all for a rebase too. I
> believe the correct etiquette is to create a new branch with the rebase
> as the current branch is already public.
>
> Anyway, if I merge or apply a patch, your branch needs to be in a clean
> working state to for merging to current master. Ultimately I would like
> a Github pull request. I will then either 'git merge' it or 'git am' it
> when the Travis tests all pass. Could you wait until 2.0.11 is released
> before doing this though?
>
I merged the current swig master to my branch, so that now it can be
easily merged upstream. Since you are going to ignore the branch
history (--squash), doing rebase makes no sense (rebase would only be
necessary to get a cleaner version of the branch history).
I also posted a pull request on github.

Hello!
Late answer to this post since I don't follow this list regularly. From
what gathered, Josef worked on this during his master's thesis together
with a fellow student.
Both their theses can be found online:
http://is.muni.cz/th/256594/fi_m/thesis.pdfhttp://is.muni.cz/th/256412/fi_m/thesis_pacula.pdf
I haven't heard about any work on this since.
I have some spare time now and I plan to give SWIG-Matlab another shot.
Since you are now on github, I'll probably do this in a fork and won't use
the "joelandersson-matlab" branch, which has essentially no work in it
(feel free to delete it). I'll send another mail to the list when I've
started coding, probably around November.
Greetings!
Joel
2013/3/5 William S Fulton <wsf@...>
> On 01/03/13 23:22, Kris Thielemans wrote:
> > Hi
> >
> > Does anyone know the status of the work by Josef Pacula on getting swig
> to
> > work to generate wrappers for matlab? There was quite an active
> discussion
> > in 2012, but there doesn't seem to have been a reaction on the last
> email
> > from Josef requesting some feedback
> > (
> http://article.gmane.org/gmane.comp.programming.swig.devel/21759/match=matl
> > ab)
> >
> > The code in github doesn't seem to have changed for 8 months, except in a
> > "pure" branch by "JohnRil", see
> > https://github.com/twiho/Matlab-in-SWIG/tree/pure
> >
> > I haven't tried any of this out (yet).
> >
> I don't know any more. Did you contact Joseph to see what he had to say?
> Please post to the list if you find out more.
>
> William
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Swig-devel mailing list
> Swig-devel@...
> https://lists.sourceforge.net/lists/listinfo/swig-devel
>
--
Joel Andersson, PhD Student
Electrical Engineering Department (ESAT-SCD), Room 05.11,
K.U.Leuven, Kasteelpark Arenberg 10 - bus 2446, 3001 Heverlee, Belgium
Phone: +32-16-321819
Mobile: +32-486-672874 (Belgium) / +34-63-4408800 (Spain) / +46-707-360512
(Sweden)
Private address: Weidestraat 5, 3000 Leuven, Belgium

Hi William,
Thanks, I am behind on things. (I had to get out a release so I had to
go with my disabled approach.) I'll try to test this soon.
One thought about using the target language infinity: I don't know if
its guaranteed that it will equal the C99 infinity and what happens in
that case.
Thanks,
Eric
On 9/11/13, William S Fulton <wsf@...> wrote:
> On 09/09/13 22:41, William S Fulton wrote:
>> On 09/09/13 19:39, Vadim Zeitlin wrote:
>>> On Mon, 09 Sep 2013 19:28:07 +0100 William S Fulton
>>> <wsf@...> wrote:
>>>
>>> WSF> > I do not know what range of compilers you support. Semi-recent
>>> WSF> > versions of gcc and clang should have no problems with isinf. I
>>> think
>>> WSF> > Intel is okay too but have not verified.
>>> WSF> >
>>> WSF> Some preprocessor macros will be needed to provide as wide a
>>> support as
>>> WSF> possible. There must be some code out there that gives portable
>>> isinf()
>>> WSF> for pre C99 standard. If anyone knows of a good source, let me
>>> know.
>>>
>>> See
>>>
>>> https://github.com/wxWidgets/wxWidgets/blob/master/include/wx/math.h#L56
>>>
>>> for the definition which should work with just about everything (just
>>> pretend that it was already updated to use C++11 isinf() if
>>> available...).
>>>
>> Thanks, that is nearly what we want, isinf() isn't quite the opposite of
>> isfinite() though. We want to accept isnan() so combining isfinite() and
>> isnan() might work.
>>
> I've committed a fix so that infinity is now accepted for type float.
> The implementation does require a C99 isfinite() to be available,
> otherwise we can't reliably check for infinity and then we fall back to
> the previous incorrect behaviour. I did also attempt to use an
> equivalent to isfinite() on a very limited set of platforms: Windows and
> Solaris, based on the wxWidgets version. See commit
> a91cd0bc5c1550bfa2c922c7434323c30ca1fb87 -
> https://github.com/swig/swig/commit/a91cd0bc5c1550bfa2c922c7434323c30ca1fb87
>
> Eric, can you check this all works for you.
>
> William
>
>
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

On 19/09/13 08:50, Simon Marchetto wrote:
>
> All identifiers must be 24 chars max long. Again, in Scilab 5.x. Scilab
> has a very long history....
Probably SWIG should then warn when an identifier is too long then so as
to be helpful to users because otherwise the wrapped methods cannot be used.
Note that some warnings are turned off by default and are turned on when
using -Wextra. The Scilab identifier length warning could possibly be
turned off by default??
William

On 19/09/13 19:47, Beinan Li wrote:
> Hi SWIG-devel
>
> It's my first time posting here.
> Just would like to let you know I found an issue regarding C# a year ago
> but was too busy to submit a patch. Now the ticket and patch is
> available here:
>
> https://sourceforge.net/p/swig/patches/344/
>
Thanks, I've commented it with what I think is a better approach.
William

On Thu, Sep 19, 2013 at 08:20:28AM +0100, William S Fulton wrote:
> I'm looking for branches to merge onto master now. Robert, it looks
> like the talby-perl5-improvements branch might be ready? Can you
> confirm, if so, I'll start thinking about merging it in.
>
I've completed the major documentation updates I mentioned last
time. However, there are two more things I have planned. The first is
to move and clean up the documentation from Lib/perl5/GUTS into the
Doc/Manual/Perl5.html file. The second is to write an update for
CHANGES.current.
I can notify you when I've done those two things, but you can
proceed without them if you like. I should have them soon.
-Robert

Hi SWIG-devel
It's my first time posting here.
Just would like to let you know I found an issue regarding C# a year ago
but was too busy to submit a patch. Now the ticket and patch is available
here:
https://sourceforge.net/p/swig/patches/344/
Apologies if my messages make no sense to you. English is not my first
language.
Cheers,
Beinan

Le 18/09/2013 01:06, William S Fulton a écrit :
> These makefile changes still need doing.
>
> Here is a list of the remaining issues I can see. This concludes my
> review for the moment. I just want to look at the typemaps in more
> detail next, then probably we can think about merging into master once
> the issues mentioned including the ones below are addressed.
>
> - The banner is missing in builder.sce. You'll need to code something
> up like JAVA::emitBanner().
>
> - typedef int SciObject; => All C/C++ symbols introduced by SWIG in
> the wrapper code should have Swig or SWIG as a prefix. Sci as a prefix
> ought to be reserved for symbols in the Scilab headers.
> There are a few of these, such as SciSequence_InputIterator should be
> SwigSciSequence_InputIterator, SciSwigIterator_T should be
> SwigSciIterator_T. Use 'grep -i sciswig' to find them or look at the
> symbols in a compiled shared object. Also there are other global
> variables such as fname and outputPosition which should be prefixed.
>
> - This include:
> #include "stack-c.h"
> It would be better to keep all the scilab #includes together, so I
> would move this further up the file.
>
> - extern "C" should be within the __cplusplus macro:
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> - Should fname in all the wrappers, such as:
> int _wrap_Square_perimeter(char *fname, unsigned long fname_len) {
> not be const char *, or is that the correct convention?
>
> - Does Scilab support multiple threads? The use of globals such as
> fname and outputPosition is not thread safe. The goal of SWIG is to
> not remove thread safety if it already exists in the library being
> wrapped.
>
> - /* functionReturnTypemap */ comment in generated code should be
> removed.
>
> - Test-suite...
> constructor_copy.i => I've restored some lost code in this testcase
> (additional constructors) and committed it. If it breaks anything in
> scilab, the language module itself will need fixing.
> ignore_template_constructor.i => Scilab should work with this test.
> Let's see what breaks.
> Examples/test-suite/scilab/aggregate_runme.sci => we can change the
> name of 'move' to something else in the .i file (let's do when the
> merge to master is complete).
>
> - What the situation about identifiers being too long, what are the
> restrictions? Can you document details in Scilab.html?
>
> - There is some usage of mprintf for errors in the test-suite
> (swigtest.start). Errors should print to stderr - can this be done?
>
> William
>
Hello William,
Agree with all this.
About:
- Should fname in all the wrappers, such as:
int _wrap_Square_perimeter(char *fname, unsigned long fname_len) {
not be const char *, or is that the correct convention?
Scilab convention is char *....
- Does Scilab support multiple threads?
No Scilab is not threadsafe, in any case, in 5.x.
- What the situation about identifiers being too long
All identifiers must be 24 chars max long. Again, in Scilab 5.x. Scilab
has a very long history....
About documentation, I will complete it soon.
Simon Marchetto

On 14/09/13 13:19, Vadim Zeitlin wrote:
> On Thu, 12 Sep 2013 18:33:38 +0100 William S Fulton <wsf@...> wrote:
>
> WSF> I'm afraid nothing has happened. We need a fairly generic feature where
> WSF> code snippets can be added to what is already there rather than
> WSF> replacing it. The pragma was going to be deprecated as it is a bit
> WSF> quirky, but I'm afraid no decent replacement was ever put in place.
>
> What exactly is wrong with the #pragma though? This is perhaps not the
> most elegant way of solving the problem but a pretty common one and I don't
> think they can be removed anyhow because they must certainly be used by the
> existing SWIG users (and deprecating them without ever removing them really
> doesn't solve anything).
>
> I'd keep the pragmas and just make them work as expected, either by
> default or, at least, if explicitly requested. I.e. I propose to either
>
> 1. Concatenate all the pragma values together.
>
> or, if you think there is a risk of breaking any existing code with this,
>
> 2. Add "append" argument so that you could do something like
>
> %pragma(java, append) jniclassimports="..."
>
> or perhaps a more readable
>
> %pragma(java) jniclassimports+="..."
>
> (2) would be uglier and require changing the grammar but safer. IMHO (1)
> isn't really dangerous though, as I wrote, I struggle to think about any
> situation where you'd want to intentionally override the contents added by
> a previous pragma. And if this is really necessary, then perhaps the
> expected behaviour should still be the default and we should handle
>
> %pragma(java) jniclassimports=""
>
> as an explicit request to clear the contents of this pragma (because what
> else could this do?).
>
>
> What do you think?
Those could work. I don't really like changing behaviour and I am not
keen on the pragmas. How about we deprecate most of these particular
pragmas with a warning if they are used. Then provide replacements which
use %insert which concatenate the values together, eg:
%insert("jniclassimports") {
import java.io.*;
}
and enhance with a macro, so that the following is effectively the same:
%jniclassimports %{
import java.io.*;
%}
This will have the advantage of solving the other problem you mentioned
recently and allow the use of the preprocessor as pragmas do not have
this ability. Then the following will be the equivalent to the above:
#define JAVA_IO java.io
%jniclassimports {
import JAVA_IO;
}
We lose out on using "" syntax though, so
%jniclassimports "import java.io;"
wouldn't work. Perhaps that could be a general enhancement added to %insert.
William

On 17/09/13 21:16, William S Fulton wrote:
> On 17/09/13 20:52, Marvin Greenberg wrote:
>> As an aside, ./Lib/swigwarn.swg should probably be added to the clean
>> target
> Yup agreed. I'll add that in.
I take that back! These are cleaned in the maintainer-clean target as
they are maintainer built files. See the makefile for more info on the
main clean targets: clean, distclean, maintainer-clean... they follow
standard conventions.
William

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details