Re: [Cython] Bug: llabs not defined in vs2008
Hi! None of the core developers uses MSVC, so we generally rely on Windows users to do their own testing and provide fixes. Hogan, Christopher schrieb am 30.09.2015 um 00:03: > I was trying to compile numpy v1.9.2 with Visual Studio 2008 and Cython > 0.23.1. This worked fine with Cython 0.22.x, but in 0.23.1 there are > some changes in Cython/Utility/TypeConversion.c that seem to cause this > error: > > mtrand.obj : error LNK2019: unresolved external symbol llabs referenced > in function __pyx_pf_6mtrand_11RandomState_24 choice > > llabs is not available in vs2008, but it ends up taking that "#elif" > branch in TypeConversion.c and defining __Pyx_sst_abs to be llabs. I > was able to fix this by swapping the order of the "#elif defined > (_MSC_VER) ..." block with the "#elif defined (__STDC_VERSION__) ... " > block. So, what you are saying is that VS-2008 is not C99 standards compliant (what a surprise) but claims to be? Are you passing any C compiler flags that requests C99 compliance? The last changes in this area were here: https://github.com/cython/cython/pull/403 The contributor claimed to be using MSVC 2008, too, so I wonder why you run into this problem but he didn't. > That probably won't fix the problem in all cases though. To me, your proposed change seems a reasonable thing to do. What cases are you thinking of? Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug: llabs not defined in vs2008
Hi, On 9/30/2015 12:13 AM, Stefan Behnel wrote: Hi! None of the core developers uses MSVC, so we generally rely on Windows users to do their own testing and provide fixes. Hogan, Christopher schrieb am 30.09.2015 um 00:03: I was trying to compile numpy v1.9.2 with Visual Studio 2008 and Cython 0.23.1. This worked fine with Cython 0.22.x, but in 0.23.1 there are some changes in Cython/Utility/TypeConversion.c that seem to cause this error: mtrand.obj : error LNK2019: unresolved external symbol llabs referenced in function __pyx_pf_6mtrand_11RandomState_24 choice llabs is not available in vs2008, but it ends up taking that "#elif" branch in TypeConversion.c and defining __Pyx_sst_abs to be llabs. I was able to fix this by swapping the order of the "#elif defined (_MSC_VER) ..." block with the "#elif defined (__STDC_VERSION__) ... " block. So, what you are saying is that VS-2008 is not C99 standards compliant (what a surprise) but claims to be? Are you passing any C compiler flags that requests C99 compliance? The last changes in this area were here: https://github.com/cython/cython/pull/403 The contributor claimed to be using MSVC 2008, too, so I wonder why you run into this problem but he didn't. I can't reproduce this either. Probably __STDC_VERSION__ is somehow defined on Christopher's system. Christoph That probably won't fix the problem in all cases though. To me, your proposed change seems a reasonable thing to do. What cases are you thinking of? Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Non-type template parameters
Ian Henriksen schrieb am 29.07.2015 um 23:56: > On Tue, Jul 28, 2015 at 12:37 PM Robert Bradshaw wrote: >> On Tue, Jul 28, 2015 at 11:18 AM, Ian Henriksen wrote: >>> On Tue, Jul 28, 2015 at 1:36 AM Robert Bradshaw wrote: On Mon, Jul 20, 2015 at 2:06 PM, Ian Henriksen wrote: > I've spent a little time working on adding support for non-type > template parameters. In doing this, it has been very easy to add > support for doing something like the following: > > cdef extern from "add_const.hpp" nogil: > int myfunc1[i](int) > def test(): > print myfunc1[2](a) > > The downside of this is that it does not let the Cython compiler > distinguish between different kinds of template parameters. > > Stricter checking could be added using a syntax like this: > > cdef extern from "add_const.hpp" nogil: > int myfunc1[int i](int) > def test(): > print myfunc1[2](a) > > The downsides here are that the syntax doesn't really match the > existing template syntax. It will also complicate the Cython codebase > since we'll have to go to greater lengths to allow or disallow all the > different special cases for templates. > > Which version would be preferable? I think I'd prefer the [int i] syntax. Hopefully it shouldn't complicate things too much. >>> >>> Okay, I think I see a way to make that work. On the other hand, since >>> there >>> weren't any replies here, I've already nearly finished implementing the >>> first >>> syntax. I'll spend another hour or two finishing it off later today and >>> submit a PR >>> so you can look it over. I originally favored the first syntax because it >>> minimizes >>> the number of fancy template features (SFINAE, for example) we have to >>> worry about on the Cython end. I'm still open to discuss it though. >> >> I think this falls into the "explicit is better than implicit" bucket. >> That and getting obscure template errors that could have been caught >> at Cython compile time will be very nice. >> > On a similar note, for variadic templates, would we prefer something > like > > cdef extern from "my_variadic.hpp" nogil: > T myfunc2[T,...](T, ...) > > or something like: > > cdef extern from "my_variadic.hpp" nogil: > T myfunc2[T, Types...](T, Types... args) > > Again, the latter syntax is more explicit, but it will require much > more > complicated code in Cython. It also doesn't match the existing syntax > very well. The former syntax matches the existing syntax for templates > better, but will make it hard for Cython to raise errors early on in > compilation. Hmm... this is a tougher call. Let's go with the former for now. >>> >>> >>> I like the former a lot more. It will keep the syntax simpler on our end >>> and I >>> haven't been able to find any case that it doesn't cover. This will also >>> be significantly easier to implement. I'll take a look at it soon. >> >> Sounds good. >> >> There's also the question of default arguments. Let's adopt the [type >> T = *] syntax for that. > > Yep, I can see why that syntax makes sense. I'm a little worried I may not > be able > to finish adding all of this in the near future. Adding all the of this type > checking for templates goes a long way toward implementing the full syntax > for declaring them. That said, it seems sensible to catch errors early if > possible. I'd like to see this feature merged rather sooner than later. Would it help if we only require a type to be there (so that people get the syntax right in their code) but do not validate it for now? Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug: llabs not defined in vs2008
Stefan Behnel schrieb am 30.09.2015 um 09:13: > Hogan, Christopher schrieb am 30.09.2015 um 00:03: >> I was trying to compile numpy v1.9.2 with Visual Studio 2008 and Cython >> 0.23.1. This worked fine with Cython 0.22.x, but in 0.23.1 there are >> some changes in Cython/Utility/TypeConversion.c that seem to cause this >> error: >> >> mtrand.obj : error LNK2019: unresolved external symbol llabs referenced >> in function __pyx_pf_6mtrand_11RandomState_24 choice >> >> llabs is not available in vs2008, but it ends up taking that "#elif" >> branch in TypeConversion.c and defining __Pyx_sst_abs to be llabs. I >> was able to fix this by swapping the order of the "#elif defined >> (_MSC_VER) ..." block with the "#elif defined (__STDC_VERSION__) ... " >> block. > > So, what you are saying is that VS-2008 is not C99 standards compliant > (what a surprise) but claims to be? Are you passing any C compiler flags > that requests C99 compliance? > > The last changes in this area were here: > > https://github.com/cython/cython/pull/403 > > The contributor claimed to be using MSVC 2008, too, so I wonder why you run > into this problem but he didn't. > > >> That probably won't fix the problem in all cases though. > > To me, your proposed change seems a reasonable thing to do. What cases are > you thinking of? I applied your change for now, it's in the 0.23.x. maintenance branch: https://github.com/cython/cython/commit/8bf936e5449592b8b69dd56c09640db8c0ab12ff Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug: llabs not defined in vs2008
> So, what you are saying is that VS-2008 is not C99 standards compliant (what > a surprise) but claims to be? > Are you passing any C compiler flags that requests C99 compliance? We have to use the flag /Qstd=c99. I guess it's more a Microsoft problem than anything. > To me, your proposed change seems a reasonable thing to do. What cases are > you thinking of? If someone is using any VS version > 2008, then _abs64 will be defined instead of llabs. I'm not sure if one is preferable to the other though. > I applied your change for now, it's in the 0.23.x. maintenance branch: Thank you. Chris Hogan Scripting Tools Engineer Scripting, Analyzers and Tools Intel Corporation ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Non-type template parameters
> > I'd like to see this feature merged rather sooner than later. Would it help > if we only require a type to be there (so that people get the syntax right > in their code) but do not validate it for now? > > Stefan > > Stefan, Sorry for the delay, I've been mulling over what to do about this and haven't been fully satisfied with any of the answers. Not requiring the checks for now would definitely make this faster to implement though. My biggest concern is that, in C++, the types can actually play a significant role in the implementation of a given operation, and many of the things that go into determining what type may be returned are things that we don't want to have visible in Cython. Features like SFINAE and enable_if may be difficult for us to support, but syntactically, they don't use much fancy syntax. At some point, it seems to be in the best interest of our users if we let the C++ compiler finish off the type checking rather than requiring that all the type information be present in Cython. As near as I can tell, adding type specifiers to non-type template parameters won't put us into much murky water though, so I'll take another shot at adding the new syntax. Thanks for following up here. Best, -Ian Henriksen ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
