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 <semarie@online.fr> 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