SF bug #1297 #7

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
Contributor

ptomulik commented Jan 6, 2013

Fix proposition for SourceForge bug #1297.

Contains test cases (currently under Examples/python/).

Original issue report: https://sourceforge.net/p/swig/bugs/1297/
Related discussion: https://sourceforge.net/mailarchive/message.php?msg_id=30309054

I'll send test results in separate comment.

The patched file is Source/Modules/python.cxx.
Changes are also made to Examples/python/check.list

William, I'm sorry but I couldn't figure-out how to move test cases to test-suite directory.
The test cases are currently under Exapmles/python/. These are:

import_package/from_init1
import_package/from_init2
import_package/from_init3
import_package/relativeimport1
import_package/relativeimport2
import_package/same_modnames1
import_package/same_modnames2

There are also appropriate entries in Examples/python/check.list.

@ptomulik ptomulik commented on an outdated diff Jan 6, 2013

Source/Modules/python.cxx
- Node *options = Getattr(mod, "options");
- String *pkg = options ? Getattr(options, "package") : 0;
- if (pkg) {
- Printf(importname, "%s.", pkg);
- }
- Printf(importname, "%s.", modname);
- }
- Append(importname, Getattr(n, "sym:name"));
- Setattr(n, "python:proxy", importname);
+ String *modname = Getattr(mod, "name");
+ Node *options = Getattr(mod, "options");
+ String *pkg = options ? Getattr(options, "package") : 0;
+ String *sym = Getattr(n, "sym:name");
+ String *importname = newImportName(package, mainmodule, pkg, modname, sym);
+ Setattr(n, "python:proxy", importname);
+ Delete(importname);
@ptomulik

ptomulik Jan 6, 2013

Contributor

Delete(importname) was absent here previously (memory leak?).

@ptomulik ptomulik commented on an outdated diff Jan 6, 2013

Source/Modules/python.cxx
@@ -839,10 +1021,6 @@ class PYTHON:public Language {
Printv(f_shadow, "else:\n", NULL);
Printf(f_shadow, tab4 "import %s\n", module);
- /* Delete the version_info symbol since we don't use it elsewhere in the
- * module. */
- Printv(f_shadow, "del version_info\n", NULL);
@ptomulik

ptomulik Jan 6, 2013

Contributor

newImportDirective() generates code that relies on version_info.

Owner

wsfulton commented Jan 17, 2013

ptomulik, are you planning on moving this into the test-suite infrastructure any time soon? If so, I'd rather wait before using this patch and doing it myself.

Contributor

ptomulik commented Jan 17, 2013

Hi,

It may be hard now, as I have really busy days.
I would rather address this later as separate pull
request (this may take me month or so to find
some spare time, so ..).

With best regards!

Pawel Tomulik

Owner

wsfulton commented Mar 8, 2013

No problem about the test-suite. I had a look and it is just too different to add in nicely, so we can just keep the examples you provided or maybe just some of them.

Weren't relative imports introduced in 2.6, so shouldn't this be (2,6,0):

if version_info >= (3,0,0):
    from . import foo
else:
    import foo

The main problem with the patch is it breaks SWIG when used with -builtin. I didn't try any other of the options, such as -O, but these will need checking.

Re the implementation, I don't think it needs much changed as you think it might in the SF bug. Just a couple of boring things: I think you can you change char * usage to String * in most places, except for pfx (which ought to be called prefix) in newImportDirective - you can use Strncmp instead of strncmp and Len instead of strlen
Your variables begin with '
' eg _pkg, that is not a convention we use and pointer types should be 'String ' not 'String'

Why do newImportDirective and newImportName have 'new' as a prefix?

When you provide a new patch, could you rebase your patch too, so we don't get useless history such as .pyc commits? Thanks.

Owner

wsfulton commented Apr 14, 2013

@ptomulik Are you able to address the comments, in particular the -builtin breakages ?

Contributor

ptomulik commented Apr 14, 2013

Hi,
sorry for being silent so long, having lot of work since December 2012 and still can't find some spare time,

W dniu 08.03.2013 21:39, William S Fulton pisze:

No problem about the test-suite. I had a look and it is just too different to add in nicely, so we can just keep the examples you provided or maybe just some of them.

Weren't relative imports introduced in 2.6, so shouldn't this be (2,6,0):
if version_info >= (3,0,0):
from . import foo
else:
import foo

It seems like you're right with relative imports, they're available since 2.6 and (3,0,0) may be changed to (2,6).
At least if my understanding of http://www.python.org/dev/peps/pep-0328/ is correct (looks like I haven't studied it thoroughly previously). The 'import' syntax in all subversions of python 2.x is interpreted in "old way", i.e it is not known from the import directive whether foo.bar means absolute or relative name for a module. Seems like enabling true relative imports in 2.6 and further is better option.

The main problem with the patch is it breaks SWIG when used with -builtin. I didn't try any other of the options, such as -O, but these will need checking.

I haven't tested all possible configurations, just the test that were available at that time. Is it clear what is the cause of failures with -builtin? Any test case?

Re the implementation, I don't think it needs much changed as you think it might in the SF bug. Just a couple of boring things: I think you can you change char * usage to String * in most places, except for pfx (which ought to be called prefix) in newImportDirective - you can use Strncmp instead of strncmp and Len instead of strlen
Your variables begin with '
' eg _pkg, that is not a convention we use and pointer types should be 'String ' not 'String'

Ok, will try.

Why do newImportDirective and newImportName have 'new' as a prefix?

It was to denote that the functions allocate new string.

When you provide a new patch, could you rebase your patch too, so we don't get useless history such as .pyc commits? Thanks.

Will try, just have problems to find some spare time for it.

Pawel Tomulik

Owner

wsfulton commented Apr 18, 2013

-builtin uses quite a few different code paths in python.cxx and I think you've simply overlooked some areas in the implementation. Unfortunately there are a huge number of permutations to test, but this is an important feature that must work. You can turn on this feature when running the test-suite or examples by setting additional options in the SWIG_FEATURES env variable. Run the test-suite like this and you'll see how it breaks SWIG:

env SWIG_FEATURES=-builtin make check-python-test-suite

I'm just about ready for the swig-2.0.10 release and would like to have this fixed in the new version if at all possible.

Owner

wsfulton commented May 23, 2013

Just bumping this patch. It won't make swig-2.0.10 in its current state as outlined. Will it be attended to?

Contributor

ptomulik commented May 27, 2013

Hi,

I'm going to get around to work on this patch today. Will notify about progress/problems.

Regards!

@ptomulik ptomulik added a commit to ptomulik/swig that referenced this pull request May 27, 2013

@ptomulik ptomulik added test cases for SF bug #1297/GH issue #7 4fc8240
Contributor

ptomulik commented May 28, 2013

William,

please take a look at the updated pull request, (commit ptomulik/swig@c7e0f60). Here are some comments:

  1. I've followed your guidelines regarding variable (and function) naming and usage of String instead of char*. The patch is revamped. The commit history is reduced to two commits (first tests, then patch).

  2. Switching between explicit (new)/implicit (old) relative import syntax is done at the module generation time. It seems to be the only way. The runtime switch I've used previously was a mistake. It was a syntax error on python <= 2.4 (the source is ill-formed, because older python parser doesn't recognize the explicit relative imports):

    if sys.version_info >= (2,6,0):
       from . import foo
    else:
       import foo
  3. The flag -py3 decides whether implicit or explicit imports are used in the generated python files. This should be fine, as the implicit relative imports should work for all python 2 versions, also for >= 2.6. For python 3, the user actually needs to rebuild its modules with -py3 flag (?), because they must be linked against correct python libraries.

  4. It's hard for me to identify other points in code, which should be adjusted for the patch to be 'complete'. Any advice? I've spent some time searching through the code, but couldn't see anything sensible (the code is little bit messy and undocumented).

  5. I've run python-test-suite with -builtin for my branch SFbug1297 and for master. The results are pretty same (there are failures, but they're identical for both versions).

Owner

wsfulton commented May 29, 2013

I think this is fine. Ideally the relative imports would be generated for 2.6 and later, but given the difficulties, let's leave it as you have it working for 3.0 and later with the -py3 option.

There are a few code style deviations, but I can fix them when I merge. The only thing I would really like before merging is to combine all 5 examples into one bigger example. These examples are really regression tests not really very friendly for users (which the examples should be). Given we can't get these tests into the test-suite, I would rather just have one example encompassing all the cases you are covering. Perhaps just put them all in subdirectories under the enlarged single example called import_packages.
The examples should print out a little something like "Finished importing package xyz"
Examples can't be run from the subdirectories, eg:

$ cd Examples/python/import_from_init1
$ make

If you are surprised, it is because SWIG and SWIG_LIB are set in the top level makefile using 'chk-set-env'. Probably each subdirectory makefile should set TOP with an extra relative path.

Contributor

ptomulik commented May 30, 2013

William, please forgive me this quite long essay (conclusions are at the end). :) I decided to gather the problems we faced here (mainly for future reference).

I've looked again at the PEP328 and also performed some simple experiments. There are two python features, that are of concern when thinking about imports and compatibility with different python versions.

  1. The first feature is called the new absolute import behavior. When this behavior is enabled in python, the notion
# module "pkg1.mod1", file "<root>/pkg1/mod1.py"
import pkg2.mod2

is unambiguous and it imports module, whose absolute name is pkg2.mod2 (file <root>/pkg2/mod2.py). Otherwise (the new absolute import behavior disabled) this code may import pkg1.pkg2.mod2 (file <root>/pkg1/pkg2/mod2.py) or pkg2.mod2 (file <root>/pkg2/mod2.py) depending on what is found on disk – it is not known in advance (from the source code) whether an absolute or relative import is in effect.

  1. The second feature is what I call the explicit syntax for relative imports, that is the following notion
# module "pkg1.mod1", file "<root>/pkg1/mod1.py"
from .. import mod0 # file <root>/mod0.py
from . import mod1a # file <root>/pkg1/mod1a.py
from .pkg2 import mod2 # file <root>/pkg1/pkg2/mod2.py

The new behavior 1. is default for python3 and is disabled in python2. It may be enabled in python >= 2.5 by

from __future__ import absolute_import

at the beginning of a module. However, the feature absolute_import is unavailable on python2.4.

The explicit syntax for relative imports 2. is implemented in python >= 2.5 but not in python 2.4.

Now, it looks like we have the following options to import module, which is within current package or its subpackage:

  1. Forget about python 2.4 and stick to one of the conventions:

    a) enable the new absolute import behavior in every generated file (when py3=0) and always use the notion import pkg1.pkg2.mod2 in generated *.py files,
    b) don't care whether the new behavior is in effect and use the explicit syntax for relative imports.

  2. Support python 2.4 – do not enable the new absolute import behavior – and:

    a) use the notion import pkg1.pkg2.mod2 in generated files (absolute import in py3 and ambiguous one in py2 with the intent to import module via absolute name), or
    b) use notion import pkg2.mod2 when py3=0 (with the intent to import module via relative name) and the explicit syntax for relative imports when py3=1.

Ad. 1.a) from pythonic point of view, the absolute imports seem to be most reliable, because the imports are unambiguous, and there is no possibility for module name clashes in local map of imported modules (i.e. mod.py and pkg1/mod.py imported in pkg1/foo.py are always distinguishable; in case of relative imports only the content of one module is available, even when explicit syntax is used). The absolute imports, however, may cause problems when one tries to import things from package-initialization files __init__.py. Some people use it, it may be also a small step towards nspace feature (I don't know).

Ad 1.b) this introduces potential problem with aliasing, but it mitigates problem with importing modules in __init__.py files. This still breaks python 2.4.

Ad 2.a) This is actually what is currently in swig.

Ad 2.b) This is what is proposed in this changeset. For modules, that are outside of current package, the absolute import is used (ambiguous import with the intent to be absolute for py3=0).

Conclusions

  1. I strive away from breaking python 2.4
  2. I prefer relative imports, because of the imports in __init__.py
  3. Maybe it could be good to provide additional command-line options to enable enforcement of the new absolute import behavior and/or the explicit syntax for relative imports (which breaks python 2.4 but only on demand)?

Regarding Examples - I'll make necessary corrections as proposed.

Contributor

ptomulik commented May 31, 2013

Hi,

I've refactored the tests, but the Makefiles use realpath function now, and this may generate portability problems (it's available on GNU Make 3.81 and may have some problems on Win32).
I'll try to work on it a little.

ptomulik closed this May 31, 2013

ptomulik reopened this May 31, 2013

Contributor

ptomulik commented Jun 5, 2013

I've updated this changeset. Now we have:

  • absolute imports by default (as it was originally),
  • -relimport option to switch from absolute to relative imports,
  • -absimport option to put from __future__ import absolute_import at the beginning of *.py,
  • -importininit option - "enable it if you wish to do imports in __init__.py" - relevant only for py3=1,

for default path (absolute imports) the fixed issues are covered by import_packages/same_modnamesN tests.

Owner

wsfulton commented Jun 6, 2013

I am convinced that we need this support, but only when different invocations of SWIG generate different modules which need combining in one package. I don't think this is a widely used pattern though. I would like the default to work with older (pre 2.5) versions of Python and you have provided this with your latest changes.

It seems to me that absolute paths are the safest default for Python 2 mainly because Python <2.5 can't support relative imports. Relative imports are probably the best default for Python 3, however, having said that, I don't like this inconsistency between Python 2 and 3 generated code, but in the bigger picture is probably better.

Overall, we need to keep this simple and flexible and I think there are too many proposed command line options.

I suggest keeping -relimport and -norelimport as you have implemented, but please change names to -relativeimport -norelativeimport. Default will be to use -norelativeimport and the default when using -py3 should be -relativeimport. I don't really understand why there is a need for -importininit/-noimportininit, could you please explain - can we not just incorporate this into the above options?

Instead of command line options for generating or not generating the 'from future import absolute_import', let's add a generic code generation feature to add any code at the beginning of the proxy file. This can be done by way of a new %insert("pythonbegin")/%pythonbegin and work like %insert("python")/%pythoncode except the code gets generated at the beginning of the file, similar to %insert("begin")/%begin --- code will be generated just after the banner.

Clearly this of course will need documenting by itself as well how to use it along with the new import documentation. A separate patch for this would be preferable.

A summary of this info on relative imports is needed in the docs for users and should clearly state what is generated with and without -py3 and give short concise examples and reasons for using these options.

Finally, can you check the effects of the new command line options when using -noproxyimport for any incompatibilities (which may need fixing or perhaps just documenting)?

I'm glad you brought up %nspace earlier on. I think your patch is closely related to how this would be implemented and I think you would be very well qualified to implement %nspace, should you be interested. I did the implementations in Java/C# and I don't think it will be that hard to actually implement. The hardest part is to design it to correctly map onto the Python equivalent to C++ namespaces, which given your knowledge of Python packages and modules, you look qualified to do. If you are interested, a separate patch would be most welcome.

Contributor

ptomulik commented Jun 21, 2013

Dear William,

It appears that I'll not be able to work on this changeset for next few weeks, sorry. I won't be a progress blocker for swig so I suggest someone could eventually take over this topic. Nevertheless, I have few comments below.

I am convinced that we need this support, but only when different invocations of SWIG generate different modules which need combining in one package. I don't think this is a widely used pattern though. I would like the default to work with older (pre 2.5) versions of Python and you have provided this with your latest changes.

Just to remark (I forgot about it earlier): when you have a "big module", you may split it into few smaller interfaces, then build these modules in parallel (make -j, scons -j and so on) and combine them again into single python package later for user's convenience.

It seems to me that absolute paths are the safest default for Python 2 mainly because Python <2.5 can't support relative imports. Relative imports are probably the best default for Python 3, however, having said that, I don't like this inconsistency between Python 2 and 3 generated code, but in the bigger picture is probably better.

Overall, we need to keep this simple and flexible and I think there are too many proposed command line options.

I suggest keeping -relimport and -norelimport as you have implemented, but please change names to -relativeimport -norelativeimport. Default will be to use -norelativeimport and the default when using -py3 should be -relativeimport. I don't really understand why there is a need for -importininit/-noimportininit, could you please explain - can we not just incorporate this into the above options?

Ok, I agree, but I suggest not to default to relative imports in py3 - let's it be still absolute. After all I've realized, that this "import from __init__.py" is not sufficient nor good reason for defaulting to relative imports. New defaults may really surprise swig users. Absolute imports are less ambiguous. For %nspace implementation we should find another way. Sorry for changing my approach, but I'm in process of continuous learning. :)

Instead of command line options for generating or not generating the 'from future import absolute_import', let's add a generic code generation feature to add any code at the beginning of the proxy file. This can be done by way of a new %insert("pythonbegin")/%pythonbegin and work like %insert("python")/%pythoncode except the code gets generated at the beginning of the file, similar to %insert("begin")/%begin --- code will be generated just after the banner.

That's ok.

Clearly this of course will need documenting by itself as well how to use it along with the new import documentation. A separate patch for this would be preferable.

A summary of this info on relative imports is needed in the docs for users and should clearly state what is generated with and without -py3 and give short concise examples and reasons for using these options.

Finally, can you check the effects of the new command line options when using -noproxyimport for any incompatibilities (which may need fixing or perhaps just documenting)?

I'm glad you brought up %nspace earlier on. I think your patch is closely related to how this would be implemented and I think you would be very well qualified to implement %nspace, should you be interested. I did the implementations in Java/C# and I don't think it will be that hard to actually implement. The hardest part is to design it to correctly map onto the Python equivalent to C++ namespaces, which given your knowledge of Python packages and modules, you look qualified to do. If you are interested, a separate patch would be most welcome.

Thank you, I'll try to get back to these topics when having more spare time.

Concluding, I'd be glad if someone could continue this work if necessary. I'll try to remove these unnecessary CLI options today, but I'm not able to implement this %insert("pythonbegin")/%pythonbegin feature. If you think it could be sufficient, maybe we just stop at this point and pull the changes leaving %pythonbegin and %nspace for separate tickets?

ptomulik closed this Jun 21, 2013

ptomulik reopened this Jun 21, 2013

Contributor

ptomulik commented Jun 21, 2013

sorry, again hit wrong button :)

Contributor

ptomulik commented Jun 21, 2013

Ok, this is what I was able to do for now. I think, it's good point to pull this changeset in (with some additional lifting as you said few posts earlier). Anyhow, I must leave it as is for the moment and think it shouldn't wait here longer.

Owner

wsfulton commented Jul 5, 2013

Okay, keeping the default to be absolute imports for python 2 and python 3 is fine with me. The -norelateiveimport command line option is then redundant and should be removed from the patch.

I've implemented the %pythonbegin directive in d0af4f5. The only other remaining thing to be done before I will merge this into master is to put in some decent documentation giving examples (including use of %pythonbegin %{from future import absolute_import%} and motivation for this feature and when to use it.

%nspace can be done in a separate patch and it would be much appreciated if you tackled this when you have some spare time.

Owner

wsfulton commented Oct 15, 2013

@ptomulik Just the docs are required to complete. Are you going to do this? The longer this gets left, the harder it is to merge.

Contributor

ptomulik commented Nov 20, 2013

Yes, I'm set on having this finished :). Sorry for being absent so long, lot of duties last time. Also, AFAIR I've put what I thought is necessary to Python.html, and new python options are documented as well. Is there something missing?

Contributor

ptomulik commented Nov 21, 2013

William,

I've rebased this branch against master and squashed all commits into one. I have also skimmed through this thread, and recalled what should be put in docs. I would rather create a separate pull request for this instead of expanding this large enough commit. Could you suggest the right place in user manual to put the docs explaining the generation of import directives and the usage of new flags?

I have ran tests with -noproxyimports (you suggested me previously to check interactions between this option and the new options introduced here). It looks like there are no surprising interactions. Import directives are not generated in all cases and all examples that use %import and symbols from other modules fail for the same reason (python NameError).

Owner

wsfulton commented Nov 23, 2013

Hi. I'm happy to hear you are looking at this again, although I've mostly forgotten what the issues were now as it was so long ago!

I seem to recall long discussion as to why and when one would use the relative imports. All the motivation for this, such as problems encountered if not using it, and examples need to be put in the documentation. The new command line options need to be documented too. You have quite a bit of info in the examples and code, the best bits need collating for user level documentation. It needs to go somewhere in Python.html... How about a new section after "Python packages", just before "Python 3 Support".

By all means add the docs to another pull request, but I need the docs before committing anything to master.

One small thing, I see a TODO in the patch in python.cxx, I'm not sure why that comment is in there?

@ptomulik ptomulik added a commit to ptomulik/swig that referenced this pull request Nov 26, 2013

@ptomulik ptomulik Docs for SFbug1297 patch (PR #7) fc64bc3
Contributor

ptomulik commented Nov 26, 2013

Ok, I did some additional cleanups to python.cxx and reverted Doc/Manual/Python.html to its original form here. Also added two tests for pure relative imports. Docs are provided in PR #111.

In this final form we have these things (in short):

  • convention to use absolute module names in *.i interface files (mentioned in user manual),
  • absolute import syntax used by default in the generated proxy files,
  • relative imports may be enabled by -relativeimport flag (may be necessary for backward compatibility, e.g.,).

It appears, that there is no need for previously proposed -importinit flag. The imports from __init__.py work with just (properly implemented) -relativeimport. The -importinit flag is removed from the current commit.

@ptomulik ptomulik added a commit to ptomulik/swig that referenced this pull request Nov 26, 2013

@ptomulik ptomulik Docs for SFbug1297 patch (PR #7) 5cb10da

@ptomulik ptomulik added a commit to ptomulik/swig that referenced this pull request Nov 26, 2013

@ptomulik ptomulik Docs for SFbug1297 patch (PR #7) 38af180

@ptomulik ptomulik added a commit to ptomulik/swig that referenced this pull request Nov 26, 2013

@ptomulik ptomulik Docs for SFbug1297 patch (PR #7) e5e6635

@ptomulik ptomulik added a commit to ptomulik/swig that referenced this pull request Nov 26, 2013

@ptomulik ptomulik Docs for SFbug1297 patch (PR #7) 5ba65ec

@ptomulik ptomulik added a commit to ptomulik/swig that referenced this pull request Nov 26, 2013

@ptomulik ptomulik Docs for SFbug1297 patch (PR #7) 626619a

@ptomulik ptomulik added a commit to ptomulik/swig that referenced this pull request Nov 26, 2013

@ptomulik ptomulik Docs for SFbug1297 patch (PR #7) c869055
Contributor

ptomulik commented Nov 28, 2013

Can we have this merged?

@ptomulik ptomulik added a commit to ptomulik/swig that referenced this pull request Dec 12, 2013

@ptomulik ptomulik Docs for SFbug1297 patch (PR #7) ad0725e
@ptomulik ptomulik Fixed SF bug #1297
This changeset resolves several issues related to python imports.
For example, it's possible now to import modules having same module
names, but belonging to different packages.

From the user's viewpoint, this patch gives a little bit more control on
import directives generated by swig. The user may choose to use relative
or absolute imports (docs are provided in separate PR).

Some details:
  - we (still) generate import directives in form 'import a.b.c' which
    corresponds to absolute imports in python3 and (the only available)
    ambiguous one in python2.
  - added -relativeimport option to use explicit relative import syntax
    (python3),

Tests are under Examples/python, these are in fact regression tests but
with the current swig testing framework it seems to be impossible to put
appropriate tests under test-suite.
f0a5ec4

@ptomulik ptomulik added a commit to ptomulik/swig that referenced this pull request Dec 23, 2013

@ptomulik ptomulik Docs for SFbug1297 patch (PR #7) 9e9c18c

wsfulton closed this in 5562dee Dec 24, 2013

@wsfulton wsfulton added a commit that referenced this pull request Dec 24, 2013

@ptomulik @wsfulton ptomulik + wsfulton Documentation for improved python import option
Docs for SFbug1297 patch (PR #7)

closes #111
f53bd5a

@ptomulik ptomulik added a commit to ptomulik/swig that referenced this pull request Dec 24, 2013

@ptomulik ptomulik added example with %pythonbegin
This was requested in PR #7 but overlooked. Contains an example where
one does: from __future__ import absolute_import using %pythonbegin
directive.
690eac3

@wsfulton wsfulton added a commit that referenced this pull request Feb 21, 2014

@ptomulik @wsfulton ptomulik + wsfulton added example with %pythonbegin
This was requested in PR #7 but overlooked. Contains an example where
one does: from __future__ import absolute_import using %pythonbegin
directive.
0ed98c0

@jgillis jgillis pushed a commit to jgillis/swig that referenced this pull request Jul 14, 2015

@jaeandersson jaeandersson [MATLAB] #7 Redirecting std::cout and std::cerr to mexPrintf 16ea068

@jgillis jgillis pushed a commit to jgillis/swig that referenced this pull request Jul 14, 2015

@jaeandersson jaeandersson [MATLAB] #7 No redirect of std::cout and std::cerr by default 2763d49

@jgillis jgillis pushed a commit to jgillis/swig that referenced this pull request Jul 14, 2015

@jaeandersson jaeandersson [MATLAB] #7 Fix as suggested by @traversaro @nunoguedelha cf4ccf9

ptomulik deleted the ptomulik:SFbug1297 branch Oct 16, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment