Bumping this. I really need it to update devel/spyder. Cheers. Elias.
On Tue, Jan 15, 2019 at 6:12 PM Elias M. Mariani <marianiel...@gmail.com> 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 <marianiel...@gmail.com> > 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 <sema...@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
py-wurlitzer.tar.gz
Description: GNU Zip compressed data
