Re: [Cython] Cpyx for automatic Module creation and inlining of Cython code...
'+cStrip,'-o',pydName])
elif sys.platform=='darwin': cmd='
'.join(['gcc',gccOptions,'-fno-strict-aliasing','-Wno-long-double','-
no-cpp-precomp','-mno-fused-madd','-fno-common',
'-dynamic','-
DNDEBUG','-g','-O3','-bundle','-undefined dynamic_lookup','-
I'+pythonInclude,
'-
I'+pythonInclude+'/python2.5','-I'+arrayObjectDir,'-L'+pythonLibs,'-
L/usr/local/lib','-L'+cPath,'-Wl,-R'+cPath,
'-
l'+cStrip,pyx2cName,'-o',soName])
elif sys.platform=='linux2': cmd='
'.join(['gcc',gccOptions,'-fPIC','-shared',pyx2cName,'-
I'+pythonInclude,'-L'+pythonLibs,'-L'+cPath,'-Wl,-R'+cPath,'-
lpython2.5','-l'+cStrip,'-o',soName])
else: print 'Platform ' +
sys.platform + ' not supported yet'
if printCmds:
print '\n', cmd
os.system(cmd)
os.chdir(cwd)
#Shamelessly steal the idea used by scipy.weave.inline but for Pyrex/
Cython instead...
# In order to be able to import *, have to use exec in the calling
module...
def
PyrexInline
(code
,cleanUp
=
False
,useDistutils=False,useCython=False,gccOptions='',printCmds=True):
'''PyrexInline returns a string that is an import statement to
the temporary cython module'''+ \
'''Use this like: exec(PyrexInline(rsomecode,options))'''
testCode=r
cdef extern from stdio.h:
ctypedef struct FILE
FILE * stdout
int printf(char *format,...)
int fflush( FILE *stream )
def PyrexPrint(mystring):
printf(mystring)
fflush(stdout)
PyrexPrint('HelloWorld!')
tmpPath=os.path.expanduser('~/.Cpyx_tmp')
if not os.path.isdir(tmpPath):
os.mkdir(tmpPath)
if tmpPath not in sys.path:
sys.path.append(tmpPath)
if cleanUp:
CleanTmp()
# Ensure you always get a new module!
# This means there is no reason to reload
# Also means memory gets majorly eaten up!
# Can't have everything!
moduleName='Pyrex'+str(random.randint(0,1e18))
file=os.path.join(tmpPath,moduleName+'.pyx')
fid=open(file,'w')
fid.write(code)
fid.close()
Cpyx
(file
,useDistutils
=
useDistutils
,useCython=useCython,gccOptions=gccOptions,printCmds=printCmds)
#cmd=import +moduleName+ as LoadPyrexInline
cmd=from +moduleName+ import *
if printCmds:
print cmd
return cmd
# Create a dummy function that defaults to using Cython instead for
clarity...
def
CythonInline
(code
,cleanUp
=
False,useDistutils=False,useCython=True,gccOptions='',printCmds=True):
return
PyrexInline
(code
,cleanUp
=
cleanUp
,useDistutils
=
useDistutils
,useCython=useCython,gccOptions=gccOptions,printCmds=printCmds)
def CleanTmp():
tmpPath=os.path.expanduser('~/.Cpyx_tmp')
for i in glob.glob(os.path.join(tmpPath,'*')):
os.remove(i)
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] except values: could we relax to non-constant expressions?
On Mon, Dec 14, 2009 at 7:20 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Lisandro Dalcin wrote: Well, at least in Cython, an enum is not compatible with all scalar types, just with integral types. That won't matter if you tell Pyrex that the opaque type is an int. I have to insist: I have VERY good reasons to not tell Cython/Pyrex that the opaque type is an int. Instead, I REALLY need to tell that they are pointers, and not just a typedef to void*, but to DIFFERENT, INCOMPATIBLE, fake structures. Why am I being so pedantic about this? Because if I tell Cython/Pyrex that various MPI opaque types are 'int', and the underlying MPI implementation also uses 'int' for defining (using typedef's ) the various different handle types, then I do not have ANY guard against mistakes (I mean, like passing a actual int instead of MPI_Comm in some call). Greg, please tell me, what could go wrong with accepting external definition for except clauses? I cannot imagine any potential issue, but your resistance to my use case makes my think that you have some concerns about my request... -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
[Cython] remove old cruft
Cython contains some code to C-compilelink generated C sources. This likely comes from Pyrex. I would like to remove all that (we already have pyximport, and there are better ways to implement .pyx - .so|.pyd): This change is going to require: 1) Fix Cython/Compiler/Main.py in a few places 2) rm -r Cython/Mac 3) rm -r Cython/Unix 4) adjust setup.py for changes in (2) y (3) -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] running Cython from a zip file
On Thu, Dec 17, 2009 at 8:24 PM, Robert Bradshaw rober...@math.washington.edu wrote: Really, that's hardly any savings at all. Maybe at one point this was really expensive? In any case, I think it might make more sense to generate the pickle at install time (with a possible error), and silently ignore failed re-creating attempts otherwise. Well, I was tempted to propose exactly that, but I had a bit of fear of having strong opposition :-) ... -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] remove old cruft
On Thu, Dec 17, 2009 at 8:35 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Dec 17, 2009, at 7:29 AM, Stefan Behnel wrote: Lisandro Dalcín, 17.12.2009 16:16: Cython contains some code to C-compilelink generated C sources. This likely comes from Pyrex. I would like to remove all that (we already have pyximport, and there are better ways to implement .pyx - .so|.pyd): This change is going to require: 1) Fix Cython/Compiler/Main.py in a few places 2) rm -r Cython/Mac 3) rm -r Cython/Unix 4) adjust setup.py for changes in (2) y (3) +1, make that rm -fr. +1 from me too. http://hg.cython.org/cython-devel/rev/adcb695965d7 -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] [PATCH] Fix usage of elif on undefined values
On Thu, Dec 17, 2009 at 8:38 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Dec 17, 2009, at 2:40 PM, Lisandro Dalcín wrote: On Thu, Dec 17, 2009 at 12:25 PM, Julien Danjou jul...@danjou.info wrote: This kills a compilation warning. Signed-off-by: Julien Danjou jul...@danjou.info --- Cython/Compiler/Nodes.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Cython/Compiler/Nodes.py b/Cython/Compiler/Nodes.py index e6b0048..dfe94d6 100644 --- a/Cython/Compiler/Nodes.py +++ b/Cython/Compiler/Nodes.py @@ -4822,7 +4822,7 @@ utility_function_predeclarations = \ #ifdef __GNUC__ #define INLINE __inline__ -#elif _WIN32 +#elif defined(_WIN32) #define INLINE __inline #else #define INLINE -- 1.6.5.4 Mmm... What about the fix below? IIUC, __inline is a builtin keyword for MSVC, but not for every other C compiler running on Windows... Better safe than sorry... $ hg diff Cython/Compiler/Nodes.py diff -r d76177fc0796 Cython/Compiler/Nodes.py --- a/Cython/Compiler/Nodes.py Thu Dec 17 09:32:44 2009 +0100 +++ b/Cython/Compiler/Nodes.py Thu Dec 17 19:38:15 2009 -0300 @@ -4820,9 +4820,9 @@ utility_function_predeclarations = \ -#ifdef __GNUC__ +#if defined(__GNUC__) #define INLINE __inline__ -#elif _WIN32 +#elif defined(_MSC_VER) #define INLINE __inline #else #define INLINE Good point, please push. Are there any other compilers that we should single out? We heavily use the assumption that inlined functions actually get inlined for optimization purposes. Intel? PathScale? PGI? Borland? (Open) Watcom? I can do it for Intel and PathScale ... -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] [PATCH] Fix usage of elif on undefined values
On Thu, Dec 17, 2009 at 9:25 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Dec 17, 2009, at 4:08 PM, Lisandro Dalcín wrote: Good point, please push. Are there any other compilers that we should single out? We heavily use the assumption that inlined functions actually get inlined for optimization purposes. Intel? PathScale? PGI? Borland? (Open) Watcom? I can do it for Intel and PathScale ... Never heard of PathScale, but if you think there's a good chance of people compiling Cython code with it than it shouldn't hurt. Well, I build mpi4py on SiCortex machines (MIPS arch) with PathScale :-) Also, inline is part of the C99 standard, maybe we could check for that generically too. Of course. BTW, we should protect all these definitions of INLINE inside an outer #ifndef INLINE ... #endif. That way, in the face of a compiler Cython is not aware of, we can pass -DINLINE=something and make it work. What do you think? Yes, we should. This is a preliminary fix: http://hg.cython.org/cython-devel/rev/9918bc676467 -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] running Cython from a zip file
On Fri, Dec 18, 2009 at 4:10 AM, Stefan Behnel stefan...@behnel.de wrote: Note that zip files don't support binaries, though. So a Cython version running from a zip file will be substantially slower than one that is properly installed with a compiled parser. And there is an additional gotcha: using the PXD's in Cython/Includes... -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] running Cython from a zip file
On Fri, Dec 18, 2009 at 4:26 PM, Lisandro Dalcín dalc...@gmail.com wrote: On Fri, Dec 18, 2009 at 4:10 AM, Stefan Behnel stefan...@behnel.de wrote: Note that zip files don't support binaries, though. So a Cython version running from a zip file will be substantially slower than one that is properly installed with a compiled parser. And there is an additional gotcha: using the PXD's in Cython/Includes... BTW, we could support this in the future (using the annoying setuptool mechanism ;-) ) http://peak.telecommunity.com/DevCenter/PkgResources#resource-extraction PS: Every body hates setuptools, but no one (before Tarek) contributed any solution to all the issues setuptools tried to address... Setuptool's .so|.dll extraction could be unintuitive or seem ugly behaviour, but if you do not like it, do not use it. No one forces you to create or use compiled ext modules inside a zip file :-) ... -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] bint to bool conversion
On Fri, Dec 18, 2009 at 8:07 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Dec 18, 2009, at 2:41 PM, mark florisson wrote: Hello, Currently, bint Cython types get converted to int Python objects when accessed in Python code as attributes of an object, and I think it would be more consistent and logical to have it return actual bool objects (for instance if you return a bint from a function or method it gets converted to a bool). I agree, that's a bug. So instead of storing a bint as an int, it could be stored as a char, and the T_BOOL macro name could be used in the PyMemberDef to have it automatically converted to True/False. I have included a patch that does this, but this obviously causes overflows for code that assigns values that don't fit in a char. I'm not sure if that's an issue, if it is, could we perhaps generate get/set methods that return a bool object when accessed from python code? For consistency, at least as things are now, we should store it as an int. However, we could generate custom get/set methods as we do with attributes that are typed as builtin or extension types. Or use custom get/set for everything... IIRC, we discussed about this in the past. -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
[Cython] In Py=2.6, kwargs can be general mappings
While testing type inference in mpi4py, I noticed that code like the
one below is failing in the last line. It seems that in Py=2.6,
Python makes a coercion on kw and builds an actual dict instance
before calling.
class Foo:
def view(self, **kw):
print (kw)
for k in kw.keys():
print (k)
Foo().view(a=0, b=1, c=2)
class MyDict(object):
def __getitem__(self, k):
assert k == 'a'
return 7
def keys(self):
return ['a']
Foo().view(**MyDict()) # -- Here is the issue
Running on Py=2.6, the code above gives:
{'a': 0, 'c': 2, 'b': 1}
a
c
b
{'a': 7}
a
so that makes me think that at some point Python is building a tmp
dict out of MyDict instance.
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] In Py=2.6, kwargs can be general mappings
On Tue, Dec 22, 2009 at 10:58 AM, Stefan Behnel stefan...@behnel.de wrote:
Lisandro Dalcín, 22.12.2009 14:47:
While testing type inference in mpi4py, I noticed that code like the
one below is failing in the last line. It seems that in Py=2.6,
Python makes a coercion on kw and builds an actual dict instance
before calling.
class Foo:
def view(self, **kw):
print (kw)
for k in kw.keys():
print (k)
Foo().view(a=0, b=1, c=2)
class MyDict(object):
def __getitem__(self, k):
assert k == 'a'
return 7
def keys(self):
return ['a']
Foo().view(**MyDict()) # -- Here is the issue
Running on Py=2.6, the code above gives:
{'a': 0, 'c': 2, 'b': 1}
a
c
b
{'a': 7}
a
so that makes me think that at some point Python is building a tmp
dict out of MyDict instance.
Interesting. So, what's your point? It didn't work before and it works now
by passing in a real dict. Does this impact Cython in any way?
Sorry, I was not clear enough. My point is that the line below fails:
Foo().view(**MyDict())
see yourself:
In [1]: import pyximport; pyximport.install()
In [2]: import kargs
{'a': 0, 'c': 2, 'b': 1}
a
c
b
---
ImportError Traceback (most recent call last)
/u/dalcinl/tmp/ipython console in module()
...
--- 18 Foo().view(**MyDict())
ImportError: Building module failed: ['TypeError: keyword list must be
a dictionary\n']
So, in short Cython does not follow Python (=2.6, including 3.x).
Cython should generate some extra code to support this new Python
feature:
tmp =MyDict()
if not isinstace(tmp, dict):
tmp = dict(tmp)
Foo().view(**tmp)
PS: The support for new feature in core CPython is at Python/ceval.c,
function ext_do_call(). This feature was tracked here:
http://bugs.python.org/issue1686487
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] --embed on windows? Probably not the FAQ issue
On Tue, Dec 29, 2009 at 5:20 PM, Dan Stromberg strom...@gmail.com wrote: I'm trying to create a little standalone executable to help troubleshoot a problem on a windows system. The intent is not (necessarily) to have a fast program, but rather to have a single .exe without a bunch of dll's, so we don't have to copy more than one new file onto this production server. Take all my comments with care, I have very littly Win experience. 1) If you want a self-contained exe without any dependency on Python's DLL, then you definitely need to use a static library. 2) But if you use a static library, then I bet you have to #define Py_NO_ENABLE_SHARED or something like that (better to pass an appropriate option on the command line adding stuff to CFLAGS at your makefile), in order to make PyAPI_FUNC and PyAPI_DATA macros (in pyport.h) to adjust for the static library case. Other way could be to use a custom pyport.h, but IMHO #define Py_NO_ENABLE_SHARED is by far cleaner and easier Hope that help. Please let all as know about your success/failure. Here's my (cygwin) Makefile: CFLAGS=-Ic:/Python26/include #LDFLAGS=-static -Lc:/Python26/libs -lpython26 LDFLAGS=-Lc:/Python26/libs -lpython26 CC=/cygdrive/c/MinGW/bin/gcc PYTHON=/cygdrive/c/Python26/python CYTHON=c:/Python26/Scripts/cython.py V=python26 #CFLAGS=-Ic:/Python26/include #LDFLAGS=-static -L. -lpython26 ##LDFLAGS=-L. -lpython26 #CC=/cygdrive/c/MinGW/bin/gcc #PYTHON=/cygdrive/c/Python26/python #CYTHON=c:/Python26/Scripts/cython.py #V=python26 #lib$V.a: /cygdrive/c/Python26/libs/$V.lib # $(HOME)/bin/pexports c:/Python26/libs/$V.dll $V.def # dlltool --dllname $V.dll --def $V.def --output-lib lib$V.a seconds.exe: seconds.o # lib$V.a $(CC) $(LDFLAGS) -o seconds.exe seconds.o seconds.o: seconds.c $(CC) -c $(CFLAGS) seconds.c seconds.c: seconds.pyx $(PYTHON) $(CYTHON) --embed seconds.pyx clean: rm -f *.o *.exe *.c Things are OK until the link is attempted, at which point I get: /cygdrive/c/MinGW/bin/gcc -Lc:/Python26/libs -lpython26 -o seconds.exe seconds.o seconds.o:seconds.c:(.text+0x6f): undefined reference to `_imp__PyInt_FromLong' seconds.o:seconds.c:(.text+0x124): undefined reference to `_imp__PyTuple_New' seconds.o:seconds.c:(.text+0x1b8): undefined reference to `_imp__Py_InitModule4' seconds.o:seconds.c:(.text+0x200): undefined reference to `_imp__PyImport_AddMod ule' seconds.o:seconds.c:(.text+0x253): undefined reference to `_imp__PyObject_SetAtt rString' seconds.o:seconds.c:(.text+0x2a5): undefined reference to `_imp__PyObject_SetAtt rString' It goes on like that for quite a while, about a bunch of _imp__ functions being missing. Do I need to build my program with the same C compiler that my Python distribution was built with? I saw the FAQ about needing to build a libpython26.a, but 1) I have one already, and 2) pexports errored. I also googled quite a bit and didn't find anything that looked quite relevant. I'm using Python 2.6.4 from python.org on Windows XP SP3, Dave Cournapeau's Cython 0.11.2 installer for Python26, and MinGW (native gcc) 5.1.6. I'm using Cygwin make, but the rest is intended to be non-cygwin (though if a static cygwin executable will run without cygwin, that might work for me too). BTW, does distutils support building a --embed executable? Any suggestions? TIA! -- Dan Stromberg ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] Generate shorter string literals
On Fri, Feb 5, 2010 at 4:31 PM, Robert Bradshaw
rober...@math.washington.edu wrote:
On Feb 5, 2010, at 7:54 AM, Christoph Gohlke wrote:
Dear Cython developers,
This is related to http://trac.cython.org/cython_trac/ticket/50.
Cython 0.12.1 still generates string literals that can be too long
for MSVC*
compilers. Please consider the following patch.
diff -r 8bff3332e34f Cython/Compiler/Code.py
--- a/Cython/Compiler/Code.py Tue Feb 02 02:10:32 2010 -0800
+++ b/Cython/Compiler/Code.py Thu Feb 04 19:32:40 2010 -0800
@@ -667,7 +667,7 @@
decls_writer = self.parts['decls']
for _, cname, c in c_consts:
decls_writer.putln('static char %s[] = %s;' % (
- cname, c.escaped_value))
+ cname,
StringEncoding.split_docstring(c.escaped_value)))
if c.py_strings is not None:
for py_string in c.py_strings.itervalues():
py_strings.append((c.cname, len(py_string.cname),
py_string))
Thanks! http://hg.cython.org/cython-devel/rev/dc2a7157de42
I agree testcases would be good to have to ensure this doesn't happen
again.
Sorry, I should review the patch in the context of the whole code,
but... Is split_docstring() a proper name for the method, given that
IIUC it have to be used for any string literal and no just
docstrings... Sorry for being too pedantic ...
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
