Re: [NEW] devel/py-wurlitzer 1.0.2
On Wed, Feb 13 2019, Daniel Jakots wrote: > On Mon, 11 Feb 2019 16:17:15 -0300, "Elias M. Mariani" > wrote: > >> Bumping this. >> I really need it to update devel/spyder. > > I don't think it's really clean but in the absence of a better solution > ok danj@ Same here. A nice way to handle this would be to provide the stdin, stdout and stderr in libc. Not very hard, but it raises a few questions. I would suggest the following tweaks to your proposal, the most important one being getting rid of "eval" in the shell script. :) ok jca@ with or without my tweaks py-wurlitzer.tgz Description: Binary data -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [NEW] devel/py-wurlitzer 1.0.2
On Mon, 11 Feb 2019 16:17:15 -0300, "Elias M. Mariani" wrote: > Bumping this. > I really need it to update devel/spyder. I don't think it's really clean but in the absence of a better solution ok danj@
Re: [NEW] devel/py-wurlitzer 1.0.2
Bumping this.
I really need it to update devel/spyder.
Cheers.
Elias.
On Tue, Jan 15, 2019 at 6:12 PM Elias M. Mariani wrote:
>
> Sorry to add more noise to the list but is there someone who can give
> comments on this one ?
> I think that the first version was OK (attached), as Sebastien said,
> is not pretty but it works ok.
>
> Cheers.
> Elias.
>
> On Thu, Jan 3, 2019 at 1:42 PM Elias M. Mariani
> wrote:
> >
> > Well I have been trying to use the fdopen approach that Sebastien proposed.
> > I get different results. (Test fails with this method).
> > I'm not proficient with C, but I'm guessing that using fflush with a
> > different struct changes the expected result ?
> >
> > This is the code that I'm using for testing:
> >
> > fdopen = libc.fdopen
> > fdopen.restype = ctypes.POINTER(ctypes.c_void_p)
> > fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p]
> > c_stdout_p = fdopen(1, b"w")
> > c_stderr_p = fdopen(2, b"w")
> >
> > The original version segfaults, for some reason I have to pass a
> > ctypes.POINTER to the functions, if you pass a int(ctypes.c_void_p) it
> > breaks...
> >
> > Again, maybe someone with better eyes for python/C interfacing sees
> > something that I'm missing.
> > I attach the not working version for those who want to test other things...
> >
> > Cheers.
> > Elias.
> >
> > On Sun, Dec 23, 2018 at 3:32 PM Sebastien Marie wrote:
> > >
> > > On Thu, Dec 20, 2018 at 10:54:28AM -0300, Elias M. Mariani wrote:
> > > > Sorry for pinging, I forgot to add:
> > > > A issue has been opened in upstream's github about this 16 days ago,
> > > > no reply until now:
> > > > https://github.com/minrk/wurlitzer/issues/23
> > > >
> > > > Just to see if they have a more python-sided way of handling this.
> > >
> > > Personally, I found the way it is currently done to be a bit ugly, even
> > > if it is technically correct.
> > >
> > > I think it could be more simple (and portable) to use a fdopen() call
> > > with `1' as descriptor to get a FILE *stdout. It will not be exactly the
> > > same pointer than "stdout" as the FILE struct around the descriptor will
> > > be a new struct, but it should be as functional as "stdout".
> > >
> > > Something like:
> > >
> > > libc = ctypes.CDLL(None)
> > >
> > > fdopen = libc.fdopen
> > > fdopen.restype = ctypes.c_void_p
> > > fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p]
> > >
> > > stdout_p = fdopen(1, "w")
> > > stderr_p = fdopen(2, "w")
> > >
> > > Note that for stderr, the FILE* is normally unbuffered whereas here it
> > > will be buffered (it is ok for stdout).
> > >
> > > > > The main problem is to get the length of FILE, is 152 bytes in amd64,
> > > > > and 88 bytes in i386, no idea in other platforms, but given that this
> > > > > lengths can change, hardcoding this numbers is ugly and bad...
> > >
> > > Well. usually I would agree that hardcoding is bad style.
> > >
> > > But I doubt the underline struct FILE will change often, I think having
> > > it here hardcoded could be acceptable.
> > >
> > > It could be done at the Makefile level this way to have SIZEOF_FILE per
> > > architecture:
> > >
> > > ONLY_FOR_ARCHS =amd64 i386
> > >
> > > # printf("%lu\n", sizeof(FILE));
> > > SIZEOF_FILE-amd64 = 152
> > > SIZEOF_FILE-i386 =88
> > > SIZEOF_FILE = ${SIZEOF_FILE-${MACHINE_ARCH}}
> > >
> > > SUBST_VARS += SIZEOF_FILE
> > >
> > > pre-configure:
> > > ${SUBST_CMD} ${WRKSRC}/wurlitzer.py
> > >
> > > Thanks.
> > > --
> > > Sebastien Marie
py-wurlitzer.tar.gz
Description: GNU Zip compressed data
Re: [NEW] devel/py-wurlitzer 1.0.2
Sorry to add more noise to the list but is there someone who can give
comments on this one ?
I think that the first version was OK (attached), as Sebastien said,
is not pretty but it works ok.
Cheers.
Elias.
On Thu, Jan 3, 2019 at 1:42 PM Elias M. Mariani wrote:
>
> Well I have been trying to use the fdopen approach that Sebastien proposed.
> I get different results. (Test fails with this method).
> I'm not proficient with C, but I'm guessing that using fflush with a
> different struct changes the expected result ?
>
> This is the code that I'm using for testing:
>
> fdopen = libc.fdopen
> fdopen.restype = ctypes.POINTER(ctypes.c_void_p)
> fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p]
> c_stdout_p = fdopen(1, b"w")
> c_stderr_p = fdopen(2, b"w")
>
> The original version segfaults, for some reason I have to pass a
> ctypes.POINTER to the functions, if you pass a int(ctypes.c_void_p) it
> breaks...
>
> Again, maybe someone with better eyes for python/C interfacing sees
> something that I'm missing.
> I attach the not working version for those who want to test other things...
>
> Cheers.
> Elias.
>
> On Sun, Dec 23, 2018 at 3:32 PM Sebastien Marie wrote:
> >
> > On Thu, Dec 20, 2018 at 10:54:28AM -0300, Elias M. Mariani wrote:
> > > Sorry for pinging, I forgot to add:
> > > A issue has been opened in upstream's github about this 16 days ago,
> > > no reply until now:
> > > https://github.com/minrk/wurlitzer/issues/23
> > >
> > > Just to see if they have a more python-sided way of handling this.
> >
> > Personally, I found the way it is currently done to be a bit ugly, even
> > if it is technically correct.
> >
> > I think it could be more simple (and portable) to use a fdopen() call
> > with `1' as descriptor to get a FILE *stdout. It will not be exactly the
> > same pointer than "stdout" as the FILE struct around the descriptor will
> > be a new struct, but it should be as functional as "stdout".
> >
> > Something like:
> >
> > libc = ctypes.CDLL(None)
> >
> > fdopen = libc.fdopen
> > fdopen.restype = ctypes.c_void_p
> > fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p]
> >
> > stdout_p = fdopen(1, "w")
> > stderr_p = fdopen(2, "w")
> >
> > Note that for stderr, the FILE* is normally unbuffered whereas here it
> > will be buffered (it is ok for stdout).
> >
> > > > The main problem is to get the length of FILE, is 152 bytes in amd64,
> > > > and 88 bytes in i386, no idea in other platforms, but given that this
> > > > lengths can change, hardcoding this numbers is ugly and bad...
> >
> > Well. usually I would agree that hardcoding is bad style.
> >
> > But I doubt the underline struct FILE will change often, I think having
> > it here hardcoded could be acceptable.
> >
> > It could be done at the Makefile level this way to have SIZEOF_FILE per
> > architecture:
> >
> > ONLY_FOR_ARCHS =amd64 i386
> >
> > # printf("%lu\n", sizeof(FILE));
> > SIZEOF_FILE-amd64 = 152
> > SIZEOF_FILE-i386 =88
> > SIZEOF_FILE = ${SIZEOF_FILE-${MACHINE_ARCH}}
> >
> > SUBST_VARS += SIZEOF_FILE
> >
> > pre-configure:
> > ${SUBST_CMD} ${WRKSRC}/wurlitzer.py
> >
> > Thanks.
> > --
> > Sebastien Marie
py-wurlitzer.tar.gz
Description: GNU Zip compressed data
Re: [NEW] devel/py-wurlitzer 1.0.2
Well I have been trying to use the fdopen approach that Sebastien proposed.
I get different results. (Test fails with this method).
I'm not proficient with C, but I'm guessing that using fflush with a
different struct changes the expected result ?
This is the code that I'm using for testing:
fdopen = libc.fdopen
fdopen.restype = ctypes.POINTER(ctypes.c_void_p)
fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p]
c_stdout_p = fdopen(1, b"w")
c_stderr_p = fdopen(2, b"w")
The original version segfaults, for some reason I have to pass a
ctypes.POINTER to the functions, if you pass a int(ctypes.c_void_p) it
breaks...
Again, maybe someone with better eyes for python/C interfacing sees
something that I'm missing.
I attach the not working version for those who want to test other things...
Cheers.
Elias.
On Sun, Dec 23, 2018 at 3:32 PM Sebastien Marie wrote:
>
> On Thu, Dec 20, 2018 at 10:54:28AM -0300, Elias M. Mariani wrote:
> > Sorry for pinging, I forgot to add:
> > A issue has been opened in upstream's github about this 16 days ago,
> > no reply until now:
> > https://github.com/minrk/wurlitzer/issues/23
> >
> > Just to see if they have a more python-sided way of handling this.
>
> Personally, I found the way it is currently done to be a bit ugly, even
> if it is technically correct.
>
> I think it could be more simple (and portable) to use a fdopen() call
> with `1' as descriptor to get a FILE *stdout. It will not be exactly the
> same pointer than "stdout" as the FILE struct around the descriptor will
> be a new struct, but it should be as functional as "stdout".
>
> Something like:
>
> libc = ctypes.CDLL(None)
>
> fdopen = libc.fdopen
> fdopen.restype = ctypes.c_void_p
> fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p]
>
> stdout_p = fdopen(1, "w")
> stderr_p = fdopen(2, "w")
>
> Note that for stderr, the FILE* is normally unbuffered whereas here it
> will be buffered (it is ok for stdout).
>
> > > The main problem is to get the length of FILE, is 152 bytes in amd64,
> > > and 88 bytes in i386, no idea in other platforms, but given that this
> > > lengths can change, hardcoding this numbers is ugly and bad...
>
> Well. usually I would agree that hardcoding is bad style.
>
> But I doubt the underline struct FILE will change often, I think having
> it here hardcoded could be acceptable.
>
> It could be done at the Makefile level this way to have SIZEOF_FILE per
> architecture:
>
> ONLY_FOR_ARCHS =amd64 i386
>
> # printf("%lu\n", sizeof(FILE));
> SIZEOF_FILE-amd64 = 152
> SIZEOF_FILE-i386 =88
> SIZEOF_FILE = ${SIZEOF_FILE-${MACHINE_ARCH}}
>
> SUBST_VARS += SIZEOF_FILE
>
> pre-configure:
> ${SUBST_CMD} ${WRKSRC}/wurlitzer.py
>
> Thanks.
> --
> Sebastien Marie
v2.tar.gz
Description: GNU Zip compressed data
Re: [NEW] devel/py-wurlitzer 1.0.2
On Thu, Dec 20, 2018 at 10:54:28AM -0300, Elias M. Mariani wrote:
> Sorry for pinging, I forgot to add:
> A issue has been opened in upstream's github about this 16 days ago,
> no reply until now:
> https://github.com/minrk/wurlitzer/issues/23
>
> Just to see if they have a more python-sided way of handling this.
Personally, I found the way it is currently done to be a bit ugly, even
if it is technically correct.
I think it could be more simple (and portable) to use a fdopen() call
with `1' as descriptor to get a FILE *stdout. It will not be exactly the
same pointer than "stdout" as the FILE struct around the descriptor will
be a new struct, but it should be as functional as "stdout".
Something like:
libc = ctypes.CDLL(None)
fdopen = libc.fdopen
fdopen.restype = ctypes.c_void_p
fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p]
stdout_p = fdopen(1, "w")
stderr_p = fdopen(2, "w")
Note that for stderr, the FILE* is normally unbuffered whereas here it
will be buffered (it is ok for stdout).
> > The main problem is to get the length of FILE, is 152 bytes in amd64,
> > and 88 bytes in i386, no idea in other platforms, but given that this
> > lengths can change, hardcoding this numbers is ugly and bad...
Well. usually I would agree that hardcoding is bad style.
But I doubt the underline struct FILE will change often, I think having
it here hardcoded could be acceptable.
It could be done at the Makefile level this way to have SIZEOF_FILE per
architecture:
ONLY_FOR_ARCHS =amd64 i386
# printf("%lu\n", sizeof(FILE));
SIZEOF_FILE-amd64 = 152
SIZEOF_FILE-i386 =88
SIZEOF_FILE = ${SIZEOF_FILE-${MACHINE_ARCH}}
SUBST_VARS += SIZEOF_FILE
pre-configure:
${SUBST_CMD} ${WRKSRC}/wurlitzer.py
Thanks.
--
Sebastien Marie
Re: [NEW] devel/py-wurlitzer 1.0.2
Sorry for pinging, I forgot to add: A issue has been opened in upstream's github about this 16 days ago, no reply until now: https://github.com/minrk/wurlitzer/issues/23 Just to see if they have a more python-sided way of handling this. Cheers. Elias. On Wed, Dec 19, 2018 at 11:02 AM Elias M. Mariani wrote: > > https://github.com/minrk/wurlitzer > https://pypi.org/project/wurlitzer/ > > Capture C-level stdout/stderr pipes in Python via os.dup2. > > This package is required to update devel/spyder/py-spyder-kernels and > devel/spyder/spyder. > > Taking Maintainership. > > > A weird patch has to be made in order to make this package to work properly: > The original script calls to the function fflush from libc with a > parameter to stdout or stderr, for that a pointer is needed. > In linux: > c_stdout_p = ctypes.c_void_p.in_dll(libc, 'stdout') > > But OpenBSD doesn't have a defined symbol for 'stdout' in libc, but an > array of FILE structs called __sF, where __sF[1] corresponds to stdout > and __sF[2] to stderr. > > So in order to bring this array to python we need to know the length > of FILE, create an array and then get a pointer for the elements 1 and > 2 of that array. > > The main problem is to get the length of FILE, is 152 bytes in amd64, > and 88 bytes in i386, no idea in other platforms, but given that this > lengths can change, hardcoding this numbers is ugly and bad... > > That's why I added a small C code and a sh script to get the > sizeof(__sF[1]) and passing that value to sed to then patch the python > script. > > Maybe there is a better way of handling the issue, I don't see it... > My only doubt is that libc is used by the package inside the python > script, and if the size of FILE changes, the package should be rebuilt > to refresh the value of the given size. > Should I add libc as a WANTLIB ? > > > Cheers. > Elias.
[NEW] devel/py-wurlitzer 1.0.2
https://github.com/minrk/wurlitzer https://pypi.org/project/wurlitzer/ Capture C-level stdout/stderr pipes in Python via os.dup2. This package is required to update devel/spyder/py-spyder-kernels and devel/spyder/spyder. Taking Maintainership. A weird patch has to be made in order to make this package to work properly: The original script calls to the function fflush from libc with a parameter to stdout or stderr, for that a pointer is needed. In linux: c_stdout_p = ctypes.c_void_p.in_dll(libc, 'stdout') But OpenBSD doesn't have a defined symbol for 'stdout' in libc, but an array of FILE structs called __sF, where __sF[1] corresponds to stdout and __sF[2] to stderr. So in order to bring this array to python we need to know the length of FILE, create an array and then get a pointer for the elements 1 and 2 of that array. The main problem is to get the length of FILE, is 152 bytes in amd64, and 88 bytes in i386, no idea in other platforms, but given that this lengths can change, hardcoding this numbers is ugly and bad... That's why I added a small C code and a sh script to get the sizeof(__sF[1]) and passing that value to sed to then patch the python script. Maybe there is a better way of handling the issue, I don't see it... My only doubt is that libc is used by the package inside the python script, and if the size of FILE changes, the package should be rebuilt to refresh the value of the given size. Should I add libc as a WANTLIB ? Cheers. Elias. py-wurlitzer.tar.gz Description: GNU Zip compressed data
