OMG. Python is moving backwards. Some people just have no understanding
of tech. As of 3.8, extensions must not be dynamically linked to libpython.
This doesn’t apply to Windows or MacOS because that’s the only way on those
platforms.
But Debian/Ubuntu was always wrong and now the error is being
> I agree there's some fat that could be trimmed there, but not sure
> it'd be worth the effort.
You’re probably right. Its a problem writing a compiler in a language
wholy unsuited for the job. Even with a more suitable language,
emitting code, in the right order, with just the things actually r
>
>> Is there an option to use an #include for the standard stuff?
>
> There are upsides and downsides to that as well.
Hence an option. But it could be work to implement so I’m just
exploring at the moment.
> The way
> things are, the generated file is self-contained, and can
> be shipped with
> On 1 Feb 2020, at 09:49, Greg Ewing wrote:
>
> On 1/02/20 3:03 am, John Skaller2 wrote:
>> So this is some kind of hack way
>> of getting something a bit like Haskell type classes,
>> you’re basically saying int32_t and int64_t are of class “Integer”.
>
> I suppose you could think of it that
On Fri, Jan 31, 2020 at 3:17 PM Greg Ewing wrote:
>
> On 1/02/20 3:17 am, John Skaller2 wrote:
> > When I ran Cython on a two line Python function I got this from wc:
> >
> > 4276 13798 161338 oldtest.c
>
> That seems a bit excessive.
>
> > A lot of the emitted code appeared to be run time
On 1/02/20 3:17 am, John Skaller2 wrote:
When I ran Cython on a two line Python function I got this from wc:
4276 13798 161338 oldtest.c
That seems a bit excessive.
A lot of the emitted code appeared to be run time and compile
time support code which wasn’t actually used.
Not sure
On 1/02/20 3:08 am, John Skaller2 wrote:
I don’t think that is true in C99 but I’m not sure.
You may be right, I haven't been keeping up with all the
twists and turns of recent C standards. The gcc I just
tried it on allowed it, but warned about it.
In any case its a bad idea in an interface
On 1/02/20 3:03 am, John Skaller2 wrote:
So this is some kind of hack way
of getting something a bit like Haskell type classes,
you’re basically saying int32_t and int64_t are of class “Integer”.
I suppose you could think of it that way, but it's really
not that formal.
This also explains t
When I ran Cython on a two line Python function I got this from wc:
4276 13798 161338 oldtest.c
It took a while to actually find the implementation of the function.
A lot of the emitted code appeared to be run time and compile
time support code which wasn’t actually used.
Eliminating stu
>
> Yes, there is -- the default type in C is int.
I don’t think that is true in C99 but I’m not sure.
Its definitely not allowed in C++.
I know because I actually moved the motion on the C++ ISO committee
to disallow it :-)
In any case its a bad idea in an interface specification even if it’
> On 1 Feb 2020, at 00:36, Greg Ewing wrote:
>
> On 1/02/20 12:25 am, John Skaller2 wrote:
>> cdef extern from "Python.h":
>> ctypedef int int32_t
>> ctypedef int int64_t
>> ctypedef unsigned int uint32_t
>> ctypedef unsigned int uint64_t
>
> These work because Cython doesn't n
On 1/02/20 12:34 am, John Skaller2 wrote:
Ok, but now the syntax is made very context sensitive.
To interpret it correctly, you have to know “ob” is not a type.
Yes, Cython mostly follows C declaration syntax, and C also has
this property.
In C this would not work because there is no default
On 1/02/20 12:25 am, John Skaller2 wrote:
cdef extern from "Python.h":
ctypedef int int32_t
ctypedef int int64_t
ctypedef unsigned int uint32_t
ctypedef unsigned int uint64_t
These work because Cython doesn't need to know the exact
sizes of these types. All it needs to know
ob should be PyObject*
>>>
>>> No, the declaration looks correct to me. The input is an object.
>> I don’t understand. ob isn’t a type, is it? A type is required.
>
> It's a (dummy) parameter name. Cython defaults to "object" when a
> type isn't specified.
>
> Looking at the other decla
Hi,
I opened a feature ticket: https://github.com/cython/cython/issues/3342
It describes my current prototype based on OpenMP.
Any feedback?
Also, I would like to do some more advanced analysis to improve the
map-clauses. I do not want to go to a complex index analysis or alike, but a
simple ac
> On 31 Jan 2020, at 16:51, Greg Ewing wrote:
>
> On 31/01/20 9:47 am, John Skaller2 wrote:
>
2. pyport is plain wrong. It contains conflicting C typedefs.
>>>
>>> PRs welcome.
>> Is this your prefered method (pull request)?
>
> I'm sure PRs are very welcome, but at the least you could
> The mystery to me is why MacOSX introduced .dylib instead of
> sticking with .so.
There were *.so files and hacks to load them. But the structure od dylib
is different and uses a slightly different loader, dyld. I guess they wanted
to make a distinction. The had some kind of Obj C dynamic plugi
17 matches
Mail list logo
