What would be the best way to go about this?
Thanks!
-Ian Henriksen
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
>On 04.08.2014 21:11, Ian Henriksen wrote:
>> Hi all,
>> I noticed that some time ago there was a pull request
>> (https://github.com/cython/cython/pull/144) open that was trying to
>> implement basic arithmetic operations with arrays. This seems to have
>> als
t of thing were already a part of Cython. All
things considered though, most of what I'm looking for seems to be there.
Thanks!
-Ian Henriksen
On Thu, Aug 7, 2014 at 1:58 AM, Matěj Laitl wrote:
> On Monday 04 of August 2014 13:11:13 Ian Henriksen wrote:
> > Hi all,
> > I no
I'd like to work on it. That was why I asked. It's been bothering me for
some time that we don't have this feature yet. This will take me some time
though since I'm not at all familiar with Cython's internals. I've used it
in relatively small settings for speeding up array operations and wrapping
e
On Fri, Aug 8, 2014 at 12:02 PM, Julian Taylor <
jtaylor.deb...@googlemail.com> wrote:
> On 08.08.2014 19:36, Stefan Behnel wrote:
> > Hi,
> >
> > please don't top-post.
> >
> > Ian Henriksen schrieb am 08.08.2014 um 18:47:
> >> I'd like t
On Fri, Aug 8, 2014 at 3:09 PM, Ian Henriksen <
insertinterestingnameh...@gmail.com> wrote:
> On Fri, Aug 8, 2014 at 12:02 PM, Julian Taylor <
> jtaylor.deb...@googlemail.com> wrote:
>
>> On 08.08.2014 19:36, Stefan Behnel wrote:
>> > Hi,
>> >
>&g
On Sun, Aug 10, 2014 at 12:41 PM, Sturla Molden
wrote:
> Ian Henriksen
> wrote:
>
> > Maybe I should clarify a little about why eigen is a good place to start.
> > According to > href="http://eigen.tuxfamily.org/dox/TopicLazyEvaluation.html";
On Fri, Oct 24, 2014 at 2:36 AM, Stefan Behnel wrote:
> Ian Henriksen schrieb am 09.08.2014 um 00:15:
> > On Fri, Aug 8, 2014 at 3:09 PM, Ian Henriksen wrote:
> >> On Fri, Aug 8, 2014 at 12:02 PM, Julian Taylor wrote:
> >> Stefan, thanks for the direction. I thin
it
isn't particularly clean or concise. If the syntax is going
to change, it would be good to change it to something nicer
than that. I don't think this one would be worth making the change.
All things considered, the Numba syntax looks like the best idea.
The arrows are intuitive as well,
es are
two other things that would be very nice to see.
Thanks!
-Ian Henriksen
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
gt; Happy debugging :D
>
> ~ mic_e
>
> _______
> cython-devel mailing list
> cython-devel@python.org
> https://mail.python.org/mailman/listinfo/cython-devel
There was a patch for this in
https://mail.python.org/pipermail/cython-devel/2015-February/004328.html.
I'm not sure what ever became of it though. I wrote up a workaround on SO
at http://stackoverflow.com/a/25955546/1935144 a while ago.
Best of luck!
-Ian Henriksen
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
his code.
>
> Ulrich
>
> ___
> cython-devel mailing list
> cython-devel@python.org
> https://mail.python.org/mailman/listinfo/cython-devel
What is the status on this? The most recent patch appears to work
if the first two changed lines are ignored. If it would help move this
along, I can open a PR with the modified patch and a commit that still
attributes the patch to the original author.
Thanks!
-Ian Henriksen
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
On Mon, Jun 22, 2015 at 3:13 PM Ian Henriksen <
insertinterestingnameh...@gmail.com> wrote:
> On Tue, Feb 17, 2015 at 2:51 AM Ulrich Dobramysl wrote:
>
>> On Fri Feb 13 2015 at 11:07:39 PM Greg Ewing
>> wrote:
>>
>>> Ulrich Dobramysl wrote:
>>>
hon.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
This is an interesting discussion. Thanks
On Thu, Jul 2, 2015 at 9:50 PM Robert Bradshaw
wrote:
> To clarify, any choice of int64_t + unsigned long will be wrong on one
> platform or the others, but getting the wrong sign seems preferable to
> getting the wrong number of bits.
>
That makes sens. Thanks for looking at it!
-I
urning references to be used as lvalues, but I'd really appreciate any
alternative solutions.
Thanks!
-Ian Henriksen
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
On Sat, Jul 4, 2015 at 12:43 AM Stefan Behnel wrote:
> Hi Ian!
>
> Ian Henriksen schrieb am 04.07.2015 um 00:43:
> > I'm a GSOC student working to make a Cython API for DyND. DyND
> > <https://github.com/libdynd/libdynd> is a relatively new n-dimensional
> >
can give such surprising results. On the other
hand I don't see any particularly clean way to deal with this
incompatibility between C/C++ and Python.
Thanks!
-Ian Henriksen
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
On Wed, Jul 8, 2015 at 11:20 AM Stefan Behnel wrote:
> Ian Henriksen schrieb am 08.07.2015 um 03:50:
> > On Sat, Jul 4, 2015 at 12:43 AM Stefan Behnel wrote:
> >> Ian Henriksen schrieb am 04.07.2015 um 00:43:
> >>> I'm a GSOC student working to make a Cyt
eciate any input on the best syntax for either use-case.
Regards,
-Ian Henriksen
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
On Tue, Jul 28, 2015 at 1:36 AM Robert Bradshaw wrote:
> Sorry for not getting back sooner... responses below.
>
> On Mon, Jul 20, 2015 at 2:06 PM, Ian Henriksen
> wrote:
> > Hi all,
> > I've spent a little time working on adding support for non-type
> > tem
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:
> >>
> >> Sorry for not getting back sooner... responses below.
> &g
Since Cython already tries to make division of C integers behave like
Python
division, I'd expect python-like behavior (mimicking python 2 or 3 as
needed) by
default and unchanged C integer division when the cdivision directive is
set.
Best,
-Ian Henriksen
On Mon, Sep 7, 2015 at 9:55 PM R
#x27;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
nstance of that particular class. In Python
3 that particular builtin function doesn't exist. It'll work fine in Python
2, but
since the codebase supports both it's not clear when that would actually
be useful.
Best,
-Ian Henriksen
___
cython
her
unnecessary layer of indirection through the source files to connect the
C++ code
back to its Python bindings.
With regards to the dllexporting/dllimporting of things: given that public
declarations
are already designed to export things through the shared object interface,
we may
as well fix the current setup to export the right things. It's a bad design
that
probably ought to be deprecated or at least documented better so people
know not
to use it unless their case actually requires sidestepping best practices.
On the
other hand, it's also a supported interface, so there's value in "fixing"
it.
I think the best way to do that is the following:
- mark public symbols as dllimport unless a given (module specific)
preprocessor
define is set.
- people using the public header outside of the module exporting the symbols
should not have to set the define at all.
- people using the public header to compile other source files that are
linked in to
the same Python module should set the preprocessor flag for that module.
On top of that, at some point we still need to fix our api and public
headers so that
they still work when included into the translation unit for the main
Cython-generated
c/cpp file. This use-case should just forward-declare everything since the
needed
symbols are all defined later on in the Cython module. Since static
variables
cannot be forward declared in C, this will require that api declarations
use shared
object local symbols or that the main generated c/cpp file use some ifdef
guards
when it initializes the various pointers in question.
As far as making an additional header goes, I personally prefer the extra
preprocessor define. On the other hand, if people think an additional
header is
easier to use, then why not make it do something like
#define USE_DLLEXPORT_NOT_DLLIMPORT_FOR_PARTICULAR_MODULE
#include
I think, that'd cover all the use cases better.
Anyway, sorry for the length of my remarks on this. There are several
issues here
that have been bothering me for quite some time.
Best,
-Ian Henriksen
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
On Mon, Apr 11, 2016 at 11:50 AM Ian Henriksen <
insertinterestingnameh...@gmail.com> wrote:
> To answer the original question about define macros, it appears that the
> canonical
> way to pass preprocessor defines through distutils is to use the
> define_macros
> keyword w
On Tue, Apr 12, 2016 at 2:35 AM Erik Bray wrote:
> On Mon, Apr 11, 2016 at 7:49 PM, Ian Henriksen
> wrote:
> > That aside, I agree with Nathaniel that exporting public declarations as
> a
> > part of the
> > shared object interface was a design mistake. That aside,
On Tue, Apr 12, 2016 at 2:35 AM Erik Bray wrote:
> On Mon, Apr 11, 2016 at 7:49 PM, Ian Henriksen wrote:
> > With regards to the dllexporting/dllimporting of things: given that
> public
> > declarations
> > are already designed to export things through the shared object
On Mon, Apr 11, 2016 at 12:36 PM Ian Henriksen <
insertinterestingnameh...@gmail.com> wrote:
> On Mon, Apr 11, 2016 at 11:50 AM Ian Henriksen <
> insertinterestingnameh...@gmail.com> wrote:
>
>> To answer the original question about define macros, it appears that the
On Tue, Apr 26, 2016 at 2:56 PM Robert Bradshaw wrote:
> On Tue, Apr 26, 2016 at 8:36 AM, Erik Bray wrote:
>
>> On Tue, Apr 26, 2016 at 5:16 PM, Dima Pasechnik
>> wrote:
>> > Hi,
>> > certainly we did something with Sage on cygwin to work around these...
>> > Just in case,
>>
>> From what I can
like a nice idea up front, but in practice it's less
clear what that
would mean and how exactly all the accompanying semantics would work.
Thanks for raising a lot of these issues though. Interfacing between Python
and
modern C++ is definitely worth the discussion.
Best,
Ian Henrikse
or file bugs as necessary.
>
> Thanks,
> Robert
>
I ran a quick test against dynd-python with master this morning. Everything
looks fine there. Thanks for managing the release.
Best,
Ian Henriksen
___
cython-devel mailing list
cython-devel@p
_
> cython-devel mailing list
> cython-devel@python.org
> https://mail.python.org/mailman/listinfo/cython-devel
FWIW, depending on your CI needs using the no-cython-compile option can
speed
things up pretty drastically. Cython files don't compile quite as q
Actually, this seems like a pretty reasonable SciPy feature request. Feel
free to open an issue there.
Thanks,
Ian Henriksen
On Mon, Jul 30, 2018 at 3:18 PM 'Chris Barker' via cython-users <
cython-us...@googlegroups.com> wrote:
> BTW,
>
> Please don't spam so man
It's been a while since I've used MinGW to compile any extensions. The CRT
incompatibility is a hassle to worry about unless you are using a custom
Python build and MSVC 2015 and 2017 are pretty good. That said, there is a
workaround for this one. See https://stackoverflow.com/a/30881190/1935144.
36 matches
Mail list logo
