headers
SourceForge.net | 1 Jul 2008 22:29
Picon
Favicon

[ swig-Patches-2008229 ] For python, use a relative import for the C-extension

Patches item #2008229, was opened at 2008-07-01 20:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2008229&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: Richard Boulton (richardb)
Assigned to: Nobody/Anonymous (nobody)
Summary: For python, use a relative import for the C-extension

Initial Comment:
Currently, when shadow classing is enabled in python, the generated python module imports the compiled
C-extension by doing "import module".  In python versions up-to and including 2.5, this generally works
fine, because python will do relative imports by default (ie, look in the same directory as the module
performing the import, as well as on sys.path).

However, in 2.6, implicit relative imports will raise a warning, and in 2.7 onwards they will be invalid. 
Therefore, the generated code will only work if the compiled C-extension is present on sys.path.  It will
therefore no longer be valid to place an extension inside a parent module and include it from elsewhere in
that module - modules will need to be installed globally.

In python 2.5 onwards, (but not in python 2.4 or earlier), explicit relative imports can be performed by
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 1 Jul 2008 23:26
Picon
Favicon

[ swig-Patches-2008229 ] For python, use a relative import for the C-extension

Patches item #2008229, was opened at 2008-07-01 22:29
Message generated for change (Comment added) made by amauryf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2008229&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: Richard Boulton (richardb)
Assigned to: Nobody/Anonymous (nobody)
Summary: For python, use a relative import for the C-extension

Initial Comment:
Currently, when shadow classing is enabled in python, the generated python module imports the compiled
C-extension by doing "import module".  In python versions up-to and including 2.5, this generally works
fine, because python will do relative imports by default (ie, look in the same directory as the module
performing the import, as well as on sys.path).

However, in 2.6, implicit relative imports will raise a warning, and in 2.7 onwards they will be invalid. 
Therefore, the generated code will only work if the compiled C-extension is present on sys.path.  It will
therefore no longer be valid to place an extension inside a parent module and include it from elsewhere in
that module - modules will need to be installed globally.

In python 2.5 onwards, (but not in python 2.4 or earlier), explicit relative imports can be performed by
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 2 Jul 2008 05:23
Picon
Favicon

[ swig-Patches-2008229 ] For python, use a relative import for the C-extension

Patches item #2008229, was opened at 2008-07-01 21:29
Message generated for change (Comment added) made by olly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2008229&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: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Richard Boulton (richardb)
Assigned to: Nobody/Anonymous (nobody)
Summary: For python, use a relative import for the C-extension

Initial Comment:
Currently, when shadow classing is enabled in python, the generated python module imports the compiled
C-extension by doing "import module".  In python versions up-to and including 2.5, this generally works
fine, because python will do relative imports by default (ie, look in the same directory as the module
performing the import, as well as on sys.path).

However, in 2.6, implicit relative imports will raise a warning, and in 2.7 onwards they will be invalid. 
Therefore, the generated code will only work if the compiled C-extension is present on sys.path.  It will
therefore no longer be valid to place an extension inside a parent module and include it from elsewhere in
that module - modules will need to be installed globally.

In python 2.5 onwards, (but not in python 2.4 or earlier), explicit relative imports can be performed by
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefano Moratto | 2 Jul 2008 08:40
Picon

DELPHI (Object Pascal) Module

Dear SWIG's community,

                      I've developed a functional delphi module that
implements all the swig functions except for director.
The module compiles all the examples that can be found in the CSharp
example's folder and I tested some testsuits (cpp_basic, bloody_hell,
enums ).

I would like this effort will be included in the standard SWIG because
     * I think the DELPHI community needs this tools;
     * I'm a developer in the GDAL project and I done a GDAL's
version for delphi using SWIG but I can not include it in the standard
GDAL distros
     while the Delphi module is not included in SWIG.

How can I produce a patch to be sent to you? I developed starting from
swigwin-1.35 sources.

Best Regards,
Stefano Moratto

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
Permalink | Reply | 22 comments |
headers
Richard Boulton | 2 Jul 2008 11:13
Gravatar

Python 3 branch merge

Haoyu has now got his python 3 branch to a point where it can generate
code which works well with python 3.0, to the extent that a fairly
complex library (xapian) can be imported and used from python3.

He still has several further parts of his project to work on, but I
thought this would be a good time to think about how to go about merging
his code into trunk.

There are some parts of the code which are probably uncontroversial for
merging: for example, converting exception raising code from "raise
FooError, e" to "raise FooError(e)" (since there are already instances
of the latter construct in the generated code, so there are no
compatibility issues).

However, other bits will need discussion - for example, there's a lot of
conditional compilation in the new code, which could do with being
tidied up.

One question I was wondering about: should we try and use some system
for doing online code reviews - there's an application at
http://codereview.appspot.com/ which allows any project to register, and
is being used for python development, and quite a few other projects, so
might be worth a look.  There's also a rather nice application called
"review board" (http://www.review-board.org/) which might be better -
this one is from the VMWare people, and seems very flash - but we'd need
to find somewhere to install it, and it doesn't sound like a trivial
install.

The hope is that such a system would enable us to keep track of which
parts of the code have been reviewed and approved.  But perhaps just
(Continue reading)

Permalink | Reply | 10 comments |
headers
William S Fulton | 3 Jul 2008 00:09
Picon
Favicon
Gravatar

Re: DELPHI (Object Pascal) Module

Stefano Moratto wrote:
> Dear SWIG's community,
> 
>                       I've developed a functional delphi module that
> implements all the swig functions except for director.
> The module compiles all the examples that can be found in the CSharp
> example's folder and I tested some testsuits (cpp_basic, bloody_hell,
> enums ).
> 
> I would like this effort will be included in the standard SWIG because
>      * I think the DELPHI community needs this tools;
>      * I'm a developer in the GDAL project and I done a GDAL's
> version for delphi using SWIG but I can not include it in the standard
> GDAL distros
>      while the Delphi module is not included in SWIG.
> 
> How can I produce a patch to be sent to you? I developed starting from
> swigwin-1.35 sources.
> 

Stefano

I think the best way to submit a patch is to send it to SF. Some people 
send patches inline in an email, but usually the lines get broken up, 
then the patch program can't patch properly. The patch will probably 
apply cleanly to svn head even if you send the patch diff'd to 1.3.35. A 
unix/cygwin line ending diff will be preferable. Please send any initial 
documentation you have to the list too.

We're always interested in new modules and Pascal would be a good one to
(Continue reading)

Permalink | Reply | 17 comments |
headers
William S Fulton | 3 Jul 2008 00:34
Picon
Favicon
Gravatar

Re: Python 3 branch merge

Richard Boulton wrote:
> Haoyu has now got his python 3 branch to a point where it can generate
> code which works well with python 3.0, to the extent that a fairly
> complex library (xapian) can be imported and used from python3.
> 
> He still has several further parts of his project to work on, but I
> thought this would be a good time to think about how to go about merging
> his code into trunk.
> 
Great, this might be a first for GSoC! Releasing the student's code into 
trunk is sometimes not even done after the GSoC project has completed, 
never mind midway through.

> There are some parts of the code which are probably uncontroversial for
> merging: for example, converting exception raising code from "raise
> FooError, e" to "raise FooError(e)" (since there are already instances
> of the latter construct in the generated code, so there are no
> compatibility issues).
> 
> However, other bits will need discussion - for example, there's a lot of
> conditional compilation in the new code, which could do with being
> tidied up.
> 
> One question I was wondering about: should we try and use some system
> for doing online code reviews - there's an application at
> http://codereview.appspot.com/ which allows any project to register, and
> is being used for python development, and quite a few other projects, so
> might be worth a look.  There's also a rather nice application called
> "review board" (http://www.review-board.org/) which might be better -
> this one is from the VMWare people, and seems very flash - but we'd need
(Continue reading)

Permalink | Reply | 9 comments |
headers
Stefano Moratto | 3 Jul 2008 10:11
Picon

Re: DELPHI (Object Pascal) Module

William,
              I developed the module using both Visual Studio (2005)
C++ and mingw so I have working windows and unix like compile
environments. I followed all the requirements in
http://www.swig.org/Doc1.3/Extending.html#Extending_prerequisites.

I checked the diff command and it is available in my mingw environment
so I will proceed with the building of the diff package. I will assure
to have unix style LF in the code.

Today I'm going to modify the makefiles in order to compile with FPC.
Maybe it will be sufficient to
./configure --with-delphi-compiler=fpc or something similar.

I ran the test suites only on few cases (two c++ and two c) but I
would like to put the module online in order to find some help to
finish the test suites.

Yesterday I tried to send the docs to the list but it is to large >
40k and the list doesn't accept .zip files.

BTW my SF account is smoratto

Stefano

On Thu, Jul 3, 2008 at 12:09 AM, William S Fulton
<wsf <at> fultondesigns.co.uk> wrote:
> Stefano Moratto wrote:
>>
>> Dear SWIG's community,
(Continue reading)

Permalink | Reply | 16 comments |
headers
Lucena, Ivan | 3 Jul 2008 15:27

Re: DELPHI (Object Pascal) Module

Stefano,

I can help with Free Pascal on Linux if you want.

Best regards,

Ivan

Stefano Moratto wrote:
> William,
>               I developed the module using both Visual Studio (2005)
> C++ and mingw so I have working windows and unix like compile
> environments. I followed all the requirements in
> http://www.swig.org/Doc1.3/Extending.html#Extending_prerequisites.
> 
> I checked the diff command and it is available in my mingw environment
> so I will proceed with the building of the diff package. I will assure
> to have unix style LF in the code.
> 
> Today I'm going to modify the makefiles in order to compile with FPC.
> Maybe it will be sufficient to
> ./configure --with-delphi-compiler=fpc or something similar.
> 
> I ran the test suites only on few cases (two c++ and two c) but I
> would like to put the module online in order to find some help to
> finish the test suites.
> 
> Yesterday I tried to send the docs to the list but it is to large >
> 40k and the list doesn't accept .zip files.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stefano Moratto | 3 Jul 2008 17:02
Picon

Re: DELPHI (Object Pascal) Module

Ivan,
        thank your for your help.

I'm just modifying the makefiles for fpc.

Using fpc and -Sd (delphi mode) allows me to compile the examples fine.
Unfortunately fpc accepts only one source file at a time on the
command line so I have to play with Makefile.in order to compile all
the files.
All the example programs are composed by 2 files: example.pas
(generated from example.i) and runme.dpr (the test program).

>From Examples/Makefile.in - : this has been added for delphi support

##################################################################
#####                      DELPHI                          ######
##################################################################

# Extra DELPHI specific dynamic linking options
DELPHI_DLNK  =  -mno-cygwin -mthreads -Wl,--add-stdcall-alias
DELPHI_LIBPREFIX =
DELPHICOMPILER =  <at> DELPHICOMPILER <at> 
DELPHICFLAGS = -mno-cygwin -mthreads
DELPHISO = .dll
DELPHIFLAGS =  <at> DELPHIFLAGS <at> 
# ----------------------------------------------------------------
# Build a DELPHI dynamically loadable module (C)
# ----------------------------------------------------------------

delphi: $(SRCS)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane