headers
William S Fulton | 2 Jul 2009 00:06
Picon
Favicon
Gravatar

Re: fifth week report

Matevž Jekovec wrote:
> Hi William, David and others.
> 
> This week I continued doing research on the new C++0x features and 
> implemented some of them:
> 
>  * Introduced new symbol CXXFLAGS to configure.in and Examples/Makefile?
<http://www.dabeaz.com/cgi-bin/wiki.pl?action=change1&id=Cpp0xSupportForSwig/Makefile>.in. R11321
>   * Use CXXFLAGS instead of CFLAGS when compiling C++ test cases
>   * Added "-std=c++0x" flag to GCC compiler
>  * Added support for constexpr. R11322
>   * Added keyword "constexpr" and terminal CONSTEXPR to Swig parser.
>   * Added testcase cpp0x_constexpr.i
>  * Added support for explicit conversion operators. R11323
>   * Added testcase cpp0x_explicit_conversion_operator.i
>  * Added support for raw string literals and fixed support for wide strings. R11327
>   * Added support for unicode strings starting with u", u8" and U".
>   * Fixed support for wide strings starting with L".
>   * Added testcase cpp0x_raw_string_literals.i.
> 
> The support for custom string delimiters is still missing - something 
> I'm planning to do today or tomorrow. In the following week, I plan to 
> do research on the concepts, axioms, variadic templates and look into 
> the templating code in Swig. I hope to implement some less demanding 
> features (static_assert).
> 

Hi Matevž

This is coming along nicely... good to see the testcases going in at the
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 2 Jul 2009 04:23
Picon
Favicon

[ swig-Bugs-2813836 ] python/std_map.i fails to lock correctly

Bugs item #2813836, was opened at 2009-06-29 18:51
Message generated for change (Comment added) made by tbble
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2813836&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: python
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Paul Hampson (tbble)
Assigned to: Olly Betts (olly)
Summary: python/std_map.i fails to lock correctly

Initial Comment:
python/std_map.i does not have correct locking. In several functions, it takes the lock only for a
PyErr_SetString and fails to protect a PyList_New or PyDict_New and related calls later on. In struct
traits_asptr<std::map<K,T> >::asptr, no lock is taken at all.

I've attached a patch (against 1.3.38, but SVN indicates that this is the most recent version of this file)
against Lib/python/std_map.i

----------------------------------------------------------------------

>Comment By: Paul Hampson (tbble)
Date: 2009-07-02 12:23
(Continue reading)

Permalink | Reply | 0 comments |
headers
William S Fulton | 2 Jul 2009 08:41
Picon
Favicon
Gravatar

Re: Reimplementing ocaml module.

Guillaume Yziquel wrote:
>> William S Fulton a écrit :
>>
>>> If you want to create a runtime-less module from scratch, I suggest 
>>> you base
>>> it on C#  as that is probably the most featureful statically typed 
>>> language
>>> module. Take csharp.cxx and start hacking that to fit ocaml. I suggest
>>> getting the basic examples and test-suite test cases working before 
>>> working
>>> on a big project (freeling).
>>>
>>> William
> 
> I've been starting to rewrite the module according to chapter 35 of the 
> documentation. Rather scarce for now. Code is available at:
> 
> http://yziquel.homelinux.org/trac/browser/ocaml/swig-ocaml/ocaml-module
> 
> However, I now have the following error, when compiling swig with this 
> module:
> 
>> ../Source/DOH/doh.h: In member function ‘virtual int OCAML::top(Node*)’:
>> ../Source/DOH/doh.h:303: error: too few arguments to function ‘DOH* 
>> DohNewFile(DOH*, const char*, DOH*)’
>> Modules/ocaml.cxx:59: error: at this point in file
> 
> This refers to the following line of code:
> 
>>     59        f_runtime = NewFile(outfile, "w");
(Continue reading)

Permalink | Reply | 1 comment |
headers
William S Fulton | 2 Jul 2009 20:31
Picon
Favicon
Gravatar

Re: swig unusable with octave-3.2.x

Igor wrote:
> Hello,
> 
> Can't get octave example compiled with recently released octave-3.2.0. Here is 
> the output:
> -----------------------------------------------------------------------------------------------------
> user <at> garik:/usr/doc/swig-1.3.38/Examples/octave/simple$ swig -octave -c++ -o 
> ~/example.cpp example.i                                   
> user <at> garik:/usr/doc/swig-1.3.38/Examples/octave/simple$ cd
> user <at> garik:~$ g++ -shared -I/usr/include/octave-3.2.0 -o example.oct 
> example.cpp
> example.cpp: In member function 'void octave_swig_type::install_global()':
> example.cpp:1197: error: 'curr_sym_tab' was not declared in this scope
> example.cpp:1197: error: 'link_to_global_variable' was not declared in this 
> scope
> example.cpp:1204: error: 'symbol_record' was not declared in this scope
> example.cpp:1204: error: 'sr' was not declared in this scope
> example.cpp:1204: error: 'global_sym_tab' was not declared in this scope
> example.cpp: In function 'void SWIG_Octave_SetModule(void*, 
> swig_module_info*)':
> example.cpp:2110: error: 'curr_sym_tab' was not declared in this scope
> example.cpp:2110: error: 'link_to_global_variable' was not declared in this 
> scope
> example.cpp: In function 'octave_value_list Fexample(const octave_value_list&, 
> int)':
> example.cpp:2600: error: 'curr_sym_tab' was not declared in this scope
> example.cpp:2600: error: 'link_to_global_variable' was not declared in this 
> scope
> -----------------------------------------------------------------------------------------------------
>
(Continue reading)

Permalink | Reply | 14 comments |
headers
Xavier Delacour | 2 Jul 2009 21:10
Picon

Re: swig unusable with octave-3.2.x

On Thu, Jul 2, 2009 at 11:31 AM, William S
Fulton<wsf <at> fultondesigns.co.uk> wrote:
> Igor wrote:
>>
>> Hello,
>>
>> Can't get octave example compiled with recently released octave-3.2.0.
>> Here is the output:
>>
>> -----------------------------------------------------------------------------------------------------
>> user <at> garik:/usr/doc/swig-1.3.38/Examples/octave/simple$ swig -octave -c++
>> -o ~/example.cpp example.i
>> user <at> garik:/usr/doc/swig-1.3.38/Examples/octave/simple$ cd
>> user <at> garik:~$ g++ -shared -I/usr/include/octave-3.2.0 -o example.oct
>> example.cpp
>> example.cpp: In member function 'void octave_swig_type::install_global()':
>> example.cpp:1197: error: 'curr_sym_tab' was not declared in this scope
>> example.cpp:1197: error: 'link_to_global_variable' was not declared in
>> this scope
>> example.cpp:1204: error: 'symbol_record' was not declared in this scope
>> example.cpp:1204: error: 'sr' was not declared in this scope
>> example.cpp:1204: error: 'global_sym_tab' was not declared in this scope
>> example.cpp: In function 'void SWIG_Octave_SetModule(void*,
>> swig_module_info*)':
>> example.cpp:2110: error: 'curr_sym_tab' was not declared in this scope
>> example.cpp:2110: error: 'link_to_global_variable' was not declared in
>> this scope
>> example.cpp: In function 'octave_value_list Fexample(const
>> octave_value_list&, int)':
>> example.cpp:2600: error: 'curr_sym_tab' was not declared in this scope
(Continue reading)

Permalink | Reply | 13 comments |
headers
Guillaume Yziquel | 3 Jul 2009 00:58
Picon
Favicon

typemaps in functionWrapper.

William S Fulton a écrit :
>
>> What is the syntax and semantics of the NewFile function?
>
> This documentation is out of date. The source is always up to date and 
> there are always lots of examples in this area as we have about 20 
> different modules implementing this standard code. I've updated the docs 
> for the next release.
> 
> William

Thank you for updating the docs. Sorry for asking naïve questions, but 
getting in the C / C++ code of swig isn't exactly funny...

OK. I indeed had it working by looking at one of the 20 examples. I 
understood how one is suppose to redefine the "methods" of the Language 
class to get things working. I'm now looking at the functionWrapper 
method in more details. I'm having trouble understanding the following 
piece of code from the C# functionWrapper method:

> /* Attach the non-standard typemaps to the parameter list. */
>     Swig_typemap_attach_parms("ctype", l, f);
>     Swig_typemap_attach_parms("imtype", l, f);

How does Swig_typemap_attach_parms work?

I saw the description

> /* -----------------------------------------------------------------------------
>  * Swig_typemap_attach_parms()
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 3 Jul 2009 08:09
Picon
Favicon

[ swig-Bugs-2808470 ] SWIG_croak_null not mapped properly

Bugs item #2808470, was opened at 2009-06-18 16:37
Message generated for change (Comment added) made by olly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2808470&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: perl
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sandor Skolnik (seskolnik)
Assigned to: Nobody/Anonymous (nobody)
Summary: SWIG_croak_null not mapped properly

Initial Comment:
For Perl version 10 (i.e. PERL_VERSION equal to 10) the compiler (g++) complains about
#  define SWIG_croak_null() croak(Nullch)

To fix it, I modified /usr/share/swig1.3/perl5/perlrun.swg
and replaced the line with
#  define SWIG_croak_null() croak("Croak at line %d\n", __LINE__)

This resolves the warning, and as far as I have tested resolves the issue.

----------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Olly Betts | 3 Jul 2009 13:52
Favicon
Gravatar

Re: swig unusable with octave-3.2.x

On 2009-07-02, Xavier Delacour <xavier.delacour <at> gmail.com> wrote:
> Very likely this will require some configure magic or a switch to
> toggle between octave <3.2 and >=3.2. Suggestions on what method is
> preferred would be welcome.

The code SWIG generates shouldn't depend on the version of octave (if any)
which happened to be installed when SWIG was built.  That would mean you'd
need to install SWIG twice if you wanted to be able to generate wrappers
for both octave < 3.2 and >= 3.2.  It's also very unhelpful when SWIG is
built as a binary package.

There are a couple of approaches which are usually used:

(a) Generate wrappers which can work with either < 3.2 or >= 3.2 using
conditional compilation in the generated C/C++ wrapper code.  This works
less well if you need different code in generated code which is in the
octave language (assuming SWIG generates any octave code - I'm not
familiar with that backend at all I'm afraid).  For example, Python has
various tests like "#if PY_VERSION_HEX < 0x02030000", Perl and Ruby both
have "#ifdef" checks for macros added in newer versions of the respective
APIs with fallback versions.

(b) Add a command line option to SWIG's octave backend (e.g. something
like "-octaveversion=3.2") - for example, Python has -py3 to turn on some
extra features which require Python 3 and -modern which requires Python
2.3; PHP used to have -php4 and -php5 before we dropped PHP4 support;
guile has -gh and -scm.

Cheers,
    Olly
(Continue reading)

Permalink | Reply | 12 comments |
headers
SourceForge.net | 3 Jul 2009 16:26
Picon
Favicon

[ swig-Bugs-2810380 ] Possible problem with stubs

Bugs item #2810380, was opened at 2009-06-22 17:37
Message generated for change (Settings changed) made by olly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2810380&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: tcl
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Christian Gollwitzer (auriocus)
Assigned to: Olly Betts (olly)
Summary: Possible problem with stubs

Initial Comment:
The initialization code for Tcl stubs currently looks like the following:

#ifdef USE_TCL_STUBS
  if (Tcl_InitStubs(interp, (char*)"8.1", 0) == NULL) {
    return TCL_ERROR;
  }
#endif  

The hard-coded versionstring  "8.1"  should be replaced by the macro TCL_VERSION - this requests the stubs
interface for the version against which the extension is compiled. Also, to simplify Tk extensions, the
init code could include a corresponding Tk_InitStubs call. (this got me crazy when I tried to port a
(Continue reading)

Permalink | Reply | 6 comments |
headers
William S Fulton | 3 Jul 2009 19:08
Picon
Favicon
Gravatar

Re: swig unusable with octave-3.2.x

Olly Betts wrote:
> On 2009-07-02, Xavier Delacour <xavier.delacour <at> gmail.com> wrote:
>> Very likely this will require some configure magic or a switch to
>> toggle between octave <3.2 and >=3.2. Suggestions on what method is
>> preferred would be welcome.
> 
> The code SWIG generates shouldn't depend on the version of octave (if any)
> which happened to be installed when SWIG was built.  That would mean you'd
> need to install SWIG twice if you wanted to be able to generate wrappers
> for both octave < 3.2 and >= 3.2.  It's also very unhelpful when SWIG is
> built as a binary package.
> 
> There are a couple of approaches which are usually used:
> 
> (a) Generate wrappers which can work with either < 3.2 or >= 3.2 using
> conditional compilation in the generated C/C++ wrapper code.  This works
> less well if you need different code in generated code which is in the
> octave language (assuming SWIG generates any octave code - I'm not
> familiar with that backend at all I'm afraid).  For example, Python has
> various tests like "#if PY_VERSION_HEX < 0x02030000", Perl and Ruby both
> have "#ifdef" checks for macros added in newer versions of the respective
> APIs with fallback versions.
> 
> (b) Add a command line option to SWIG's octave backend (e.g. something
> like "-octaveversion=3.2") - for example, Python has -py3 to turn on some
> extra features which require Python 3 and -modern which requires Python
> 2.3; PHP used to have -php4 and -php5 before we dropped PHP4 support;
> guile has -gh and -scm.
> 
Agreed the code being generated should never depend on anything that
(Continue reading)

Permalink | Reply | 0 comments |

Gmane