>>
>> My concern is that the C compiler wont reject it, the program
>> will corrupt data or crash:
>>
>> int32_t *x=..; *x = 42;
>> int64_t *x=..; *x = 42;
>>
>> The C compiler will overwrite 4 or 8 bytes. Which one matters.
>
> As stated before, the C compiler will see the correct d
John Skaller2 schrieb am 01.02.20 um 15:38:
> On 1 Feb 2020, at 20:00, Greg Ewing wrote:
>> On 1/02/20 3:29 pm, John Skaller2 wrote:
>>> But the all hell breaks loose for pointers. Your hack only
>>> works for rvalues.
>>
>> Yes, using these it's possible for Cython to accept something
>> that will
> On 1 Feb 2020, at 20:00, Greg Ewing wrote:
>
> On 1/02/20 3:29 pm, John Skaller2 wrote:
>> But the all hell breaks loose for pointers. Your hack only
>> works for rvalues.
>
> Yes, using these it's possible for Cython to accept something
> that will later be rejected by the C compiler. It's
On 1/02/20 3:29 pm, John Skaller2 wrote:
But the all hell breaks loose for pointers. Your hack only
works for rvalues.
Yes, using these it's possible for Cython to accept something
that will later be rejected by the C compiler. It's not perfect,
but it gets the job done most of the time.
--
Gr
> 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 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
>
> 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
> 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
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
give us some idea of what these conflicting typedefs are!
ob
On 31/01/20 10:00 am, John Skaller2 wrote:
It works. Why Python would look for a linux extension only on MacOS I have no
idea.
It's not really a Linux extension. It goes back to when shared
libraries first appeared in BSD, from which large parts of MacOSX
are derived, and MacOSX also recognise
> On 30 Jan 2020, at 22:23, Greg Ewing wrote:
>
> On 30/01/20 8:58 pm, John Skaller2 wrote:
> import oldtest
> > Traceback (most recent call last):
> >File "", line 1, in
> > ModuleNotFoundError: No module named 'oldtest'
> What happens if you use a .so extension instead of .dylib?
I
> On 31 Jan 2020, at 00:22, Stefan Behnel wrote:
>
>> Seems these were mechanically derived from docs?
>
> They were manually copied over time.
Ouch. A lot of work.
>> 2. pyport is plain wrong. It contains conflicting C typedefs.
>
> PRs welcome.
Is this your prefered method (pull request)
John Skaller2 schrieb am 30.01.20 um 03:47:
> Ok, I have processed most of the Cython/Include/python/*.pxd files.
>
> Seems these were mechanically derived from docs?
They were manually copied over time.
> Because some of the bugs in the docs are also in these files. Not sure what
> you
> woul
On 30/01/20 8:58 pm, John Skaller2 wrote:
import oldtest
> Traceback (most recent call last):
>File "", line 1, in
> ModuleNotFoundError: No module named 'oldtest'
What happens if you use a .so extension instead of .dylib?
--
Greg
___
cython-
OMG. I don’t believe it.
Renaming the binary from *.dylib to *.so fixed it.
Both the Cython and Felix shared libraries can be imported and both run.
Sorry for the noise. Just didn’t occur to me that Python would want *.so
filenames on MacOS.
Until I remembered seeing some in Cython build direct
> On 30 Jan 2020, at 18:00, Yury V. Zaytsev wrote:
>
> On 30. Jan 2020, at 03:52, John Skaller2 wrote:
>>
>> However the shared library extensions I generate will always be linked
>> against a shared library. My build tech does not permit flat namespaces
>> for dynamic linkage. I know you CAN
> On 30 Jan 2020, at 18:44, John Skaller2 wrote:
>
>
>
>> On 30 Jan 2020, at 17:20, John Skaller2 wrote:
>>
>> Just FYI, trying to load my extension I get “ModuleNotFound”.
>
> ~/felix>/usr/local/opt/python/Frameworks/Python.framework/Versions/3.6/bin/python3.6m
> Python 3.6.5 (default, A
On 30. Jan 2020, at 03:52, John Skaller2 wrote:
>
> However the shared library extensions I generate will always be linked
> against a shared library. My build tech does not permit flat namespaces
> for dynamic linkage. I know you CAN get Python run time as a shared
> library on Debian based syst
> On 30 Jan 2020, at 17:20, John Skaller2 wrote:
>
> Just FYI, trying to load my extension I get “ModuleNotFound”.
using Cython I get a different result.
~/felix>cat oldtest.py
def testit():
print("Testit”)
Note the original name was test.py, changed so it cannot be loaded. Under the
orig
Just FYI, trying to load my extension I get “ModuleNotFound”.
A test *.py file in the same directory can be imported.
A check on the shared library (dylib on MacOS) shows that the required function
is exported.
Maybe my layout of the module table is wrong, its hard to say given so much
informatio
Ok, I have processed most of the Cython/Include/python/*.pxd files.
Seems these were mechanically derived from docs? Because some
of the bugs in the docs are also in these files. Not sure what you
would like to do so I’ll ask here before doing github issues.
1. Its not all there. I couldn’t find
Hi Stefan
On Fri, Sep 09, 2011 at 10:35:20AM +0200, Stefan Behnel wrote:
> Hi Romain,
>
> thanks for the feedback.
>
> Romain Guillebert, 08.09.2011 06:18:
> >The Google Summer of Code has ended and I didn't give the current status
> >to anyone yet (I was very busy with a report I had to write f
Hi Romain,
thanks for the feedback.
Romain Guillebert, 08.09.2011 06:18:
The Google Summer of Code has ended and I didn't give the current status
to anyone yet (I was very busy with a report I had to write for my
university).
There is still work to do on the project (there was more work than I
Hi
The Google Summer of Code has ended and I didn't give the current status
to anyone yet (I was very busy with a report I had to write for my
university).
There is still work to do on the project (there was more work than I
expected, especially because of semantic differences between Cython and
30 matches
Mail list logo
