Re: [pypy-dev] RPython Darwin platform description so_prefixes empty

[John Zhang]

Hi Armin,
I think we can include 'lib' in so_prefix of all Posix platforms, is
that right?
I can’t seem to find a definitive answer for all POSIX platforms. But for all 
the ones that PyPy currently supports, I think the answer is true. So if you 
want to make the changes then I think it’s a reasonable assumption and a good 
idea.

I still have no
clue why all our tests still pass on OS/X
I think it’s because `rpython.translator.platform.Platform._finish_linking` 
function doesn’t include `so_prefixes` on the platform in the first place, so 
for tests like `test_lib_on_libpaths` will generate a shared library called 
`c_file.dylib`. Then in `get_ctypes_callable` function it prepends the library 
name with the currently empty prefix on Darwin platform, it can find the shared 
library file with the constructed absolute path. So the proposed fix will still 
work because it includes both ‘lib’ and empty prefix.
On the other hand, I wonder if it’s also reasonable to modify the 
`_finish_linking` function to include `platform.so_prefix[0]` to the generated 
shared library name (see the attached patch).
Regards,
John Zhang

--
John Zhang
Research Assistant
Programming Languages, Design & Implementation Division
Computer Systems Group
ANU College of Engineering & Computer Science
108 North Rd
The Australian National University
Acton ACT 2601
john.zh...@anu.edu.au





On 6 Dec. 2016, at 20:48, Armin Rigo 
> wrote:

Hi John,

On 6 December 2016 at 03:06, John Zhang 
> wrote:
So I think it’s right to make a simple fix as suggested in the patch to
include ‘lib’ in the so_prefix on Darwin platforms.

I think we can include 'lib' in so_prefix of all Posix platforms, is
that right?  It's already in linux, bsd and cygwin.  I still have no
clue why all our tests still pass on OS/X (apart from the skipped one
you found) but I guess that's a fine fix anyway.


A bientôt,

Armin.



_finish_linking_so_prefix.patch
Description: _finish_linking_so_prefix.patch
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] Request to make `makedev`, `major` and `minor` macros

[John Zhang]

Thanks Armin!
I will keep my eyes open for other cases and let you know. :)

Cheers,
John Zhang
--
John Zhang
Research Assistant
Programming Languages, Design & Implementation Division
Computer Systems Group
ANU College of Engineering & Computer Science
108 North Rd
The Australian National University
Acton ACT 2601
john.zh...@anu.edu.au





On 6 Dec. 2016, at 20:58, Armin Rigo 
> wrote:

Hi John,

On 6 December 2016 at 08:20, John Zhang 
> wrote:
I would like to request making the definitions of
`rpython.rlib.rposix.c_makedev/c_major/c_minor` include explicit macro
functions, i.e., passing `macro=_MACRO_ON_POSIX` to the `rffi.llexternal`
function.

Checked in 08ec669ddab9.  Note that the 'macro' keyword is used inside
PyPy for a single purpose: to teach the JIT that it cannot directly
write a call to the macro.  Instead it writes a call to the wrapper
generated by rffi.py.  In this case this problem was fixed by marking
the functions like "def makedev(..):" with "@jit.dont_look_inside",
which is equivalent from the point of view of the JIT.  But I have now
removed these dont_look_inside and instead added "macro=True"
arguments, as it is more natural---and also indeed more useful to
non-standard backends.  Feel free to ask if you find other similar
cases!


A bientôt,

Armin.

___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] Request to make `makedev`, `major` and `minor` macros

[Armin Rigo]

Hi John,

On 6 December 2016 at 08:20, John Zhang  wrote:
> I would like to request making the definitions of
> `rpython.rlib.rposix.c_makedev/c_major/c_minor` include explicit macro
> functions, i.e., passing `macro=_MACRO_ON_POSIX` to the `rffi.llexternal`
> function.

Checked in 08ec669ddab9.  Note that the 'macro' keyword is used inside
PyPy for a single purpose: to teach the JIT that it cannot directly
write a call to the macro.  Instead it writes a call to the wrapper
generated by rffi.py.  In this case this problem was fixed by marking
the functions like "def makedev(..):" with "@jit.dont_look_inside",
which is equivalent from the point of view of the JIT.  But I have now
removed these dont_look_inside and instead added "macro=True"
arguments, as it is more natural---and also indeed more useful to
non-standard backends.  Feel free to ask if you find other similar
cases!


A bientôt,

Armin.
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] RPython Darwin platform description so_prefixes empty

[Armin Rigo]

Hi John,

On 6 December 2016 at 03:06, John Zhang  wrote:
> So I think it’s right to make a simple fix as suggested in the patch to
> include ‘lib’ in the so_prefix on Darwin platforms.

I think we can include 'lib' in so_prefix of all Posix platforms, is
that right?  It's already in linux, bsd and cygwin.  I still have no
clue why all our tests still pass on OS/X (apart from the skipped one
you found) but I guess that's a fine fix anyway.


A bientôt,

Armin.
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] RPython Darwin platform description so_prefixes empty

[John Zhang]

Hi Armin,
The test `rpython.rtyper.lltypesystem.test.TestPlatform.test_prefix` 
illustrates the problem quite well. Currently this test is skipped on non-linux 
platforms. When that is turned off, the test fails on macOS X.
With `Darwin_x86.so_prefix == (‘’, )`, line ll2ctypes:1218 will fail, because 
it’s trying to load `c_file.dylib` rather than `libc_file.dylib`.
Shared libraries on macOS X should also have ‘lib’ prefix just as on linux.
According to man page of `ld`:
-lx This option tells the linker to search for libx.dylib or libx.a in the 
library search path. If string x is of the form y.o, then that file is searched 
for in the same places, but without prepending `lib' or appending `.a' or 
`.dylib' to the filename.
And on Apple developer website 
(https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html):
The filename of a dynamic library normally contains the library’s name with the 
lib prefix and the .dylib extension. For example, a library called Dynamo would 
have the filename libDynamo.dylib.

So I think it’s right to make a simple fix as suggested in the patch to include 
‘lib’ in the so_prefix on Darwin platforms.

The attached is a suggested solution patch.

Regards,
John Zhang


--
John Zhang
Research Assistant
Programming Languages, Design & Implementation Division
Computer Systems Group
ANU College of Engineering & Computer Science
108 North Rd
The Australian National University
Acton ACT 2601
john.zh...@anu.edu.au





On 1 Dec. 2016, at 04:56, Armin Rigo 
> wrote:

Hi John,

On 30 November 2016 at 04:14, John Zhang 
> wrote:
`so_prefixes`. This is causing me some problems with not being able to find
my shared libraries on macOS X.
I’m wondering if that’s intentional, or just a mistake? It should be a
simple fix if it’s a mistake.

I don't know, and that's a good question.  But the first question is:
how does it work for PyPy on OS/X?  All (or most) tests pass there.
Can you pinpoint the difference?  If not, can you point us to your
version of the code, so that we can have a guess at what the
difference might be?


A bientôt,

Armin.



fix_darwin_so_prefix.patch
Description: fix_darwin_so_prefix.patch
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] Request to make `makedev`, `major` and `minor` macros

[John Zhang]

Forgot the attachment, sorry!

--
John Zhang
Research Assistant
Programming Languages, Design & Implementation Division
Computer Systems Group
ANU College of Engineering & Computer Science
108 North Rd
The Australian National University
Acton ACT 2601
john.zh...@anu.edu.au





On 6 Dec. 2016, at 18:18, John Zhang 
> wrote:

Hi all (Armin?),
I would like to request making the definitions of 
`rpython.rlib.rposix.c_makedev/c_major/c_minor` include explicit macro 
functions, i.e., passing `macro=_MACRO_ON_POSIX` to the `rffi.llexternal` 
function.
These functions are macros on both Linux and macOS (the comment above the code 
acknowledges this fact). Without explicitly saying they are macros, these 
functions can’t be called using rffi. The attached patch also adds another test 
in test_rposix.py, which exposes the problem.
The reason that they don’t currently affect the existing PyPy is because PyPy 
compiles to C anyway. But I’m working on another backend (Mu Micro VM), so I’d 
appreciate the ability to call these external functions from shared libraries 
directly. I think the macro wrapper generation is a great idea and its existing 
work is something that I can try to incorporate in my backend.
I would appreciate someone can patch the change (it’s a bit tricky on my end 
using git-remote-hg. :P ).
Regards,
John Zhang
--
John Zhang
Research Assistant
Programming Languages, Design & Implementation Division
Computer Systems Group
ANU College of Engineering & Computer Science
108 North Rd
The Australian National University
Acton ACT 2601
john.zh...@anu.edu.au








makedev_macro.patch
Description: makedev_macro.patch
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev

[pypy-dev] Request to make `makedev`, `major` and `minor` macros

[John Zhang]

Hi all (Armin?),
I would like to request making the definitions of 
`rpython.rlib.rposix.c_makedev/c_major/c_minor` include explicit macro 
functions, i.e., passing `macro=_MACRO_ON_POSIX` to the `rffi.llexternal` 
function.
These functions are macros on both Linux and macOS (the comment above the code 
acknowledges this fact). Without explicitly saying they are macros, these 
functions can’t be called using rffi. The attached patch also adds another test 
in test_rposix.py, which exposes the problem.
The reason that they don’t currently affect the existing PyPy is because PyPy 
compiles to C anyway. But I’m working on another backend (Mu Micro VM), so I’d 
appreciate the ability to call these external functions from shared libraries 
directly. I think the macro wrapper generation is a great idea and its existing 
work is something that I can try to incorporate in my backend.
I would appreciate someone can patch the change (it’s a bit tricky on my end 
using git-remote-hg. :P ).
Regards,
John Zhang
--
John Zhang
Research Assistant
Programming Languages, Design & Implementation Division
Computer Systems Group
ANU College of Engineering & Computer Science
108 North Rd
The Australian National University
Acton ACT 2601
john.zh...@anu.edu.au





___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev