gmane.comp.programming.swig.devel

[ swig-Bugs-2149523 ] wrong line numbers in errormessages

SourceForge.net — 2008-10-07T06:45:09

Bugs item #2149523, was opened at 2008-10-06 06:36 Message generated for change (Comment added) made by jwatte You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2149523&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: preprocessor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Omni Bee (omnibee) Assigned to: Nobody/Anonymous (nobody) Summary: wrong line numbers in error messages Initial Comment: Swig incorrectly reports line numbers in error messages. For example, it reports: offnums.hpp(30): Error: Syntax error in input(1). but the input file has only 25 lines. I used the following command file: swig -c++ -python offnums.hpp (no idea if it matters or not) ---------------------------------------------------------------------- Comment By: Jon Watte (jwatte) Date: 2008-10-06 23:45 Message: I'm trying to track down a problem as well, and am having a problem I think might be similar, as changing the lines where a syntax error is reported does random things to the error. It would be great if the offending line could be printed as well, for manual cross reference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2149523&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2149523 ] wrong line numbers in errormessages

SourceForge.net — 2008-10-06T13:36:52

Bugs item #2149523, was opened at 2008-10-06 15:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2149523&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: preprocessor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Omni Bee (omnibee) Assigned to: Nobody/Anonymous (nobody) Summary: wrong line numbers in error messages Initial Comment: Swig incorrectly reports line numbers in error messages. For example, it reports: offnums.hpp(30): Error: Syntax error in input(1). but the input file has only 25 lines. I used the following command file: swig -c++ -python offnums.hpp (no idea if it matters or not) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2149523&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: SWIG 1.3.36 , Perl 5.8.8 C++ enumeration problem

Frank Chang — 2008-10-01T20:19:22

------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2130351 ] [python] %immutable directivecreates a 2nd variable ?

SourceForge.net — 2008-10-01T01:38:49

Bugs item #2130351, was opened at 2008-09-26 16:16 Message generated for change (Settings changed) made by olly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2130351&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: David Michel (dav_m) Assigned to: Nobody/Anonymous (nobody) Initial Comment: Normally, when using an interface file for python like this: //example.i %module example %{ int a; %} int a; the variable a is available in python via the command: example.cvar.a and has by default read and write access. When using the the %immutable directive such as: //example.i %module example %{ int a; %} %immutable int a; SWIG actually creates a example.cvar.a which is effectively read-only (that's what it's suppose to do) but also create a another, separate variable example.a which has read-write permissions (not good at all !): 0.0 0.0 Traceback (most recent call last): File "", line 1, in AttributeError: Variable a is read-only. 3 ---------------------------------------------------------------------- Comment By: David Michel (dav_m) Date: 2008-09-29 11:14 Message: Yes, I agree. The same is true for anything in the module (e.g. we are allowed to do example.func = 'foo'). But then the question is: why is there 2 things created, 'example.cvar.a' *and* 'example.a' ? Without the %immutable command, there is only one variable created, 'example.cvar.a' . What is 'example.a' created for ? I ony found it by mistake as I typed too quickly and forgot the 'cvar'...and it confused me as to why it exits in the first place ---------------------------------------------------------------------- Comment By: William Fulton (wsfulton) Date: 2008-09-27 11:09 Message: %pythonnondynamic can be used to prevent this happening for proxy classes. I don't know of a feature for global variables though. ---------------------------------------------------------------------- Comment By: Josh Cherry (jlcherry) Date: 2008-09-26 16:45 Message: I would say this is a feature rather than a bug. You don't actually have write access to the C++ variable. After setting example.a to 3, if you check example.cvar.a you should see that it is still 0.0. Setting example.a merely makes the python name point somewhere else (note that you can set it to anything, not just a number). It's unfortunate that this is possible, but the same is true for anything in the module (if you had a function named func, you could do example.func = 'foo'). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2130351&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2137679 ] http://swig.org site is down

SourceForge.net — 2008-09-30T19:14:34

Bugs item #2137679, was opened at 2008-09-30 07:18 Message generated for change (Comment added) made by techtonik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2137679&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: anatoly techtonik (techtonik) Assigned to: Nobody/Anonymous (nobody) Summary: http://swig.org site is down Initial Comment: http://swig.org is inaccessible, because DNS record is invalid. Pinging vhost.sourceforge.net [216.34.181.97] with 32 bytes of data: Reply from 216.34.181.97: bytes=32 time=215ms TTL=239 Reply from 216.34.181.97: bytes=32 time=157ms TTL=239 Reply from 216.34.181.97: bytes=32 time=247ms TTL=239 Reply from 216.34.181.97: bytes=32 time=304ms TTL=239 Ping statistics for 216.34.181.97: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 157ms, Maximum = 304ms, Average = 230ms Pinging swig.org [216.136.171.204] with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 216.136.171.204: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms ---------------------------------------------------------------------- Date: 2008-09-30 19:14 Message: There are two pings in listing above. Can you post your results here? ---------------------------------------------------------------------- Comment By: William Fulton (wsfulton) Date: 2008-09-30 07:38 Message: Works for me. Anyone else having problems? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2137679&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2137679 ] http://swig.org site is down

SourceForge.net — 2008-09-30T07:38:18

How to use Swig 1.3.36 and perl 5.8.8 C++ enumeration? Abridged version of earlier message

Frank Chang — 2008-09-29T13:03:00

Re: Python 3.0 support branch merged

Haoyu Bai — 2008-09-28T09:57:36

On Tue, Sep 16, 2008 at 4:57 AM, William S Fulton fultondesigns.co.uk> wrote: Sorry for AFK a few days. :p That's a better design, so I've merged the pybuffer test case and benchmark into a single test case. Should I just rename the PySwigObject_richcompare, which I was introduced in. Or replace all the occurrence of PySwig to SwigPy? Google code search indicates a number of code have used these API, as shown here: http://www.google.com/codesearch?lr=&q=PySwig.*+file%3A\.i%24 Change the name would broken all of them. Also it is a bit odd if PySwigObject_richcompare uses a naming convention different to others.

Re: no mention of 1.3.36 on www.swig.org

William S Fulton — 2008-09-27T12:23:24

Yes you are right. I've started to use a news feed for news, but I haven't quite found the time to move it onto the front page yet. I have backported all the news into it. It is the regular sourceforge project news feed and you can see it here: http://sourceforge.net/news/?group_id=1645. I'll try and get it moved onto the front page soon, there is a test news page here: http://www.swig.org/news.php. William ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2143727 ] interface %import doesn't takepackage names into account

SourceForge.net — 2008-10-03T06:15:05

Bugs item #2143727, was opened at 2008-10-02 23:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2143727&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: Serge Monkewitz (smonkewitz) Assigned to: Nobody/Anonymous (nobody) Summary: interface %import doesn't take package names into account Initial Comment: The python documentation (http://www.swig.org/Doc1.3/Python.html#Python_nn72) on python packages for modules states: "Using the package option of the %module directive allows you to specify what Python package that the module will be living in when installed. This is useful when the .i file is %imported by another .i file. By default SWIG will assume that the importer is able to find the importee with just the module name, but if they live in separate Python packages then that won't work. However if the importee specifies what its package is with the %module option then the Python code generated for the importer will use that package name when importing the other module and also in base class declarations, etc. if the package name is different than its own." This doesn't seem to be true in practice. As a test case, consider the following interface files: first.i ---- %module(package="a") first %inline %{ class base { public: int foo(void) { return 1; } }; %} second.i ------- %module(package="b") second %import first.i %inline %{ class derived : public base { public: int bar(void) { return 2; } }; %} The python code generated by swig 1.3.36 for second.i contains import first rather than import a.first In case it's useful, I've attached a patch relative to swig 1.3.36 which fixes this issue for me. Caveat: I'm very far from being an expert on swig internals, and have not done extensive testing of this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2143727&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2137679 ] http://swig.org site is down

SourceForge.net — 2008-10-01T20:18:19

Bugs item #2137679, was opened at 2008-09-30 07:18 Message generated for change (Comment added) made by wsfulton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2137679&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: anatoly techtonik (techtonik) Assigned to: David M. Beazley (beazley) Summary: http://swig.org site is down Initial Comment: http://swig.org is inaccessible, because DNS record is invalid. Pinging vhost.sourceforge.net [216.34.181.97] with 32 bytes of data: Reply from 216.34.181.97: bytes=32 time=215ms TTL=239 Reply from 216.34.181.97: bytes=32 time=157ms TTL=239 Reply from 216.34.181.97: bytes=32 time=247ms TTL=239 Reply from 216.34.181.97: bytes=32 time=304ms TTL=239 Ping statistics for 216.34.181.97: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 157ms, Maximum = 304ms, Average = 230ms Pinging swig.org [216.136.171.204] with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 216.136.171.204: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms ---------------------------------------------------------------------- Date: 2008-10-01 20:18 Message: Yup I misread the bug report. The dns record for swig.org points to somewhere invalid (216.136.171.204), whereas www.swig.org correctly points to vhost.sourceforge.net. Online tools such as http://www.dyndns.com/support/tools/dnsquery.html show this. I'll try and ping David to sort it out. ---------------------------------------------------------------------- Comment By: Olly Betts (olly) Date: 2008-10-01 01:37 Message: wsfulton: Are you sure? http://swig.org/ has been broken for me for a while, but I keep failing to raise the issue. Perhaps you typed in swig.org and your browser added the "www." for you or something? Assigning to Dave, since he owns swig.org and so presumably controls the DNS for it. The DNS entry to swig.org needs to look the same as that for www.swig.org. ---------------------------------------------------------------------- Comment By: anatoly techtonik (techtonik) Date: 2008-09-30 19:14 Message: There are two pings in listing above. Can you post your results here? ---------------------------------------------------------------------- Comment By: William Fulton (wsfulton) Date: 2008-09-30 07:38 Message: Works for me. Anyone else having problems? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2137679&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2095124 ] [php5] Function returning objectalways returns new object

SourceForge.net — 2008-10-01T12:25:08

Bugs item #2095124, was opened at 2008-09-05 15:39 Message generated for change (Comment added) made by olly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2095124&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: php Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barry Cohen (barrycohen) Assigned to: Olly Betts (olly) Summary: [php5] Function returning object always returns new object Initial Comment: I've been working with SWIG for Python, Perl and PHP5 and have found the following to be a problem on PHP5 only. Using SWIG 1.3.36. Wrap the following C++ for php5: == example.h == class Foo { public: Foo() { i = 303; } int get_i() { return i; } Foo &update_i(Foo &f) { f.i *= 2; return f; } private: int i; }; == example.i == %module example %{ #include "example.h" %} %include "example.h" The produced example.php then contains this update function: class Foo { -- snip -- function update_i($f) { $r=Foo_update_i($this->_cPtr,$f); return is_resource($r) ? new Foo($r) : $r; } } As far as I can tell, the whole is_resource() thing is used because the function is returning an object. The problem is that $r is always a resource, so you always get a new Foo() back. Consequently, this PHP: $b = new Foo(); print $b->get_i() . "\n"; $b = $b->update_i($b); print $b->get_i() . "\n"; produces 303 303 rather than 303 606 as you would hope. This may seem like a bit of a contrived example, but the same thing happens if you create a C++ vector of structs, e.g. == example.h == struct foo { int bar; }; == example.i == %module example %rename(is_empty) empty; %include "std_vector.i" %{ #include "example.h" %} %template(v_foo) std::vector; %include "example.h" Again, the get() function in the v_foo class in example.php contains the is_resource() thing. This leads to the following PHP error: $v = new v_Foo(); $foo = new foo(); $foo->bar = 123; $v->push($foo); print $v->size() . "\n"; print $v->get(0)->bar . "\n"; This prints: 1 0 rather than 1 123 as you would expect, because a new foo() is returned from v_foo->get(). The biggest problem for me at the moment is that I can't think of a sensible workaround without modifying the way the initial C++ works. Thanks ---------------------------------------------------------------------- Date: 2008-10-01 13:25 Message: OK, so the issue seems to be that SWIG doesn't wrap an implicit copy ctor unless you use %copyctor or -copyctor equivalent. But the PHP backend isn't aware of this. ---------------------------------------------------------------------- Comment By: Olly Betts (olly) Date: 2008-09-18 07:09 Message: Creating the new PHP-side Foo object is OK as it's the wrapped C++ object which matters (at least while we don't support directors for PHP). Your example works if you explicitly define the copy constructor in example.h: Foo(const Foo&o) : i(o.i) {} Now I just need to figure out why... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2095124&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2021700 ] Variable replacement ingenerated code

SourceForge.net — 2008-10-01T01:56:07

Bugs item #2021700, was opened at 2008-07-18 18:56 Message generated for change (Settings changed) made by olly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2021700&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. Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Haoyu Bai (bhy) Assigned to: Nobody/Anonymous (nobody) Summary: Variable replacement in generated code Initial Comment: The following .i file generates code which just simply can't be compiled: %module varnamebug %include %cstring_input_binary(char *buf, int len); %inline %{ void testname(char *buf, int len) {} %} Because these generated code: arg1 = (char *) buf; arg2 = (int) size1 - 1; where 'buf' should be replaced as 'buf1' but it havn't. I think this is because the 'buf' also a parameter name. So it won't be replaced by SWIG. This occured in these backend: Python, Perl, Ruby, TCL Not occured in: Java, C#, Lua havn't try others. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2021700&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2034216 ] [ruby] generated tracking codeerrors with Ruby 1.8.7 / 1.9

SourceForge.net — 2008-10-01T01:54:45

Bugs item #2034216, was opened at 2008-07-31 19:37 Message generated for change (Settings changed) made by olly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2034216&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: ruby Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex (bro_ken_toy) Assigned to: Gonzalo Garramuno (gga73) Initial Comment: SWIG's generated tracking code is not compatible with the latest ruby versions : 1.8.7 and 1.9 Specifically, during ruby's garbage collection phase, the function SWIG_RubyRemoveTracking may be called, which in turn calls SWIG_RubyPtrToReference. This converts a void* (ptr to the C++ object) to a ruby numeric corresponding to the pointer address, which is then used as a ruby hash key. The pointer address may convert into a Ruby BigNum, which is a new object allocation. As of Ruby 1.8.7 / Ruby 1.9 object allocation during GC phase is a bug and will crash out with an error message. For the time being we (wxRuby) have worked round this be re-implementing the tracking code using a HashMap class from wxWidgets, but this isn't a general solution. This problem will affect any SWIG/Ruby project that uses the tracking code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2034216&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2080497 ] [python] type checking inpystdcommon.swg

SourceForge.net — 2008-10-01T01:53:22

Bugs item #2080497, was opened at 2008-08-28 14:12 Message generated for change (Settings changed) made by olly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2080497&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: Romain Boman (r_boman) Assigned to: Nobody/Anonymous (nobody) Initial Comment: I have just found a problem concerning type checking when using a std::vector as input argument. Here is a small module containing 2 new classes A and B %module castswig %{ #include %} %include "std_vector.i" %inline { class A { public: A() { std::cout << "A constructor\n"; } }; } %template() std::vector; %inline { class B { public: B(const std::vector &listA) { std::cout << "B constructor\n"; } }; } And my python file showing the bug: from castswig import * a1=A() a2=A() b1 = B( [a1,a2] ) # <= OK b2 = B( [1,2] ) # <= should fail The problem is the last statement does not fail athough the input list contains integers instead of A objects! I think the bug is located in "Lib/python/pystdcommon.swg" (line 49) template struct traits_asptr { static int asptr(PyObject *obj, Type **val) { Type *p; int res = (SWIG_ConvertPtr(obj, (void**)&p, type_info(), 0) == SWIG_OK) ? SWIG_OLDOBJ : 0; if (SWIG_IsOK(res)) { if (val) *val = p; } return res; } }; The "res" variable is always 0(SWIG_OLDOBJ=0) after the call of SWIG_ConvertPtr. That's why "SWIG_IsOK(res)" is always true and the cast is always done. I have replaced this line by: int res = SWIG_ConvertPtr(obj, (void**)&p, type_info(), 0); and it seems to work. An exception is thrown as expected and "b2 = B([1,2])" fails as it should. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2080497&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2137679 ] http://swig.org site is down

SourceForge.net — 2008-10-01T01:37:40

Bugs item #2137679, was opened at 2008-09-30 08:18 Message generated for change (Comment added) made by olly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2137679&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: anatoly techtonik (techtonik) Summary: http://swig.org site is down Initial Comment: http://swig.org is inaccessible, because DNS record is invalid. Pinging vhost.sourceforge.net [216.34.181.97] with 32 bytes of data: Reply from 216.34.181.97: bytes=32 time=215ms TTL=239 Reply from 216.34.181.97: bytes=32 time=157ms TTL=239 Reply from 216.34.181.97: bytes=32 time=247ms TTL=239 Reply from 216.34.181.97: bytes=32 time=304ms TTL=239 Ping statistics for 216.34.181.97: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 157ms, Maximum = 304ms, Average = 230ms Pinging swig.org [216.136.171.204] with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 216.136.171.204: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms ---------------------------------------------------------------------- Date: 2008-10-01 02:37 Message: wsfulton: Are you sure? http://swig.org/ has been broken for me for a while, but I keep failing to raise the issue. Perhaps you typed in swig.org and your browser added the "www." for you or something? Assigning to Dave, since he owns swig.org and so presumably controls the DNS for it. The DNS entry to swig.org needs to look the same as that for www.swig.org. ---------------------------------------------------------------------- Comment By: anatoly techtonik (techtonik) Date: 2008-09-30 20:14 Message: There are two pings in listing above. Can you post your results here? ---------------------------------------------------------------------- Comment By: William Fulton (wsfulton) Date: 2008-09-30 08:38 Message: Works for me. Anyone else having problems? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2137679&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2137679 ] http://swig.org site is down

SourceForge.net — 2008-09-30T07:18:17

Bugs item #2137679, was opened at 2008-09-30 07:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2137679&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: anatoly techtonik (techtonik) Assigned to: Nobody/Anonymous (nobody) Summary: http://swig.org site is down Initial Comment: http://swig.org is inaccessible, because DNS record is invalid. Pinging vhost.sourceforge.net [216.34.181.97] with 32 bytes of data: Reply from 216.34.181.97: bytes=32 time=215ms TTL=239 Reply from 216.34.181.97: bytes=32 time=157ms TTL=239 Reply from 216.34.181.97: bytes=32 time=247ms TTL=239 Reply from 216.34.181.97: bytes=32 time=304ms TTL=239 Ping statistics for 216.34.181.97: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 157ms, Maximum = 304ms, Average = 230ms Pinging swig.org [216.136.171.204] with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 216.136.171.204: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2137679&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Python 3.0 support branch merged

William S Fulton — 2008-09-29T20:41:24

They all need changing so I suggest we do it now rather than keep adding incorrect names. Even if these names are used externally, I think they should be changed so that by default they use SwigPy rather than PySwig. As you change them, make a list of the names and add some backwards compatibility mode for anyone who wants it, eg: /* Symbols which are deprecated and renamed to conform to recommended Python naming conventions */ #if defined(SWIG_DEPRECATED_PYSWIG_API) # define PySwigObject SwigPyObject ... etc ... #endif Then anyone who still wants the old API can simply define SWIG_DEPRECATED_PYSWIG_API. William ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Some problems with function hiding (C# new)

Jan Jezabek — 2008-09-29T20:52:07

Thanks for looking at this. The purpose of the attribute is to mark a method which has the same name as a method in one of its ancestors (excluding the case when the method in the child overrides or hides the method in the parent). This is analogous to overloading - but it is not detected at the symbol table level. Your example obviously shows a bug, I will have a look at it. The decision is based on sym:name so that the user can rename the method as a workaround for targets without support for overloading. I'll take care of the underscore :). Jan Jezabek ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Python 3.0 support branch merged

William S Fulton — 2008-09-29T20:41:58

Would it make sense to annotate with all the available options using some sort of separation character like '|' ? Then you would have: def foo(name : "| const char *", number : "| int | float"): noting that if there is nothing before the first '|' the parameter is then optional. William ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: SWIG 1.3.36 , Perl 5.8.8 C++ enumeration problem

Frank Chang — 2008-09-29T15:41:39