Fixing `flush-output-port` for R6RS transcoded ports
Hi!
As I reported in #39610 [0], `flush-output-port`, aka `force-output` is
no longer working for R6RS transcoded ports. It was still working in
Guile 2.0; the regression was introduced in Guile 2.2, via commit
"8399e7af5 ("Generic port facility provides buffering uniformly").
I'd be interested in fixing this, but I'm unclear how to tackle it. From
a glance at the current code, it seems to me that there is no mechanism
in place that can be used to achieve that, as the `flush` method for
port types is no more, and I see no way to pass the `flush` operation on
transcoded port to the port it is wrapping. My gut approach would be to
re-introduce the `flush` operation, but I'm not sure that would be
sensible and/or fit into the re-architected ports.
If someone, perhaps @wingo (being the author of the re-factoring), could
sketch an implementation strategy (or just affirm that re-introducing
`flush` is sensible), I would be grateful, and would be one step further
in resurrecting my R6RS Scheme code after almost a decade of abandon.
[0] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39610
Kind Regards, Rotty
Re: Segfault while building on 64-bit Cygwin
Excellent, and thank you all! I've been WIndowsless for a few weeks, but that should change again soon. On Sun, Feb 16, 2020 at 6:23 PM Mike Gran wrote: > On Fri, Feb 14, 2020 at 09:46:04AM -0800, Charles Stanhope wrote: > > Andy, I don't know if you'd want to continue this here or on > > lightening's gitlab page, but I looked into this a little bit a few > > minutes here and there this past weeek. The x86 "fast-call" calling > > convention used on Windows x64[0] and shared by Cygwin[1] requires > > that the caller reserve 32 bytes of memory on the stack for the callee > > to spill the register parameters (even if the callee takes fewer than > > four parameters). I think lightening is currently missing that for the > > x64 case for Cygwin. > > > > To test the idea, I made a small modification (patch attached) that is > > *not* intended as a solution as it doesn't work for the general case, > > but it does allow the tests to pass on Cygwin 64. > > I can confirm that Charles's patch, plus another one line patch > to define CPU_SETSIZE, is enough to get Guile 3.0.x to build and run > on my box. All tests pass except strptime in French, and the absence > of crypt. This is a 64-bit build. > > -Mike Gran >
Re: Segfault while building on 64-bit Cygwin
On 2/16/20, Mike Gran wrote: > On Fri, Feb 14, 2020 at 09:46:04AM -0800, Charles Stanhope wrote: >> Andy, I don't know if you'd want to continue this here or on >> lightening's gitlab page, but I looked into this a little bit a few >> minutes here and there this past weeek. The x86 "fast-call" calling >> convention used on Windows x64[0] and shared by Cygwin[1] requires >> that the caller reserve 32 bytes of memory on the stack for the callee >> to spill the register parameters (even if the callee takes fewer than >> four parameters). I think lightening is currently missing that for the >> x64 case for Cygwin. >> >> To test the idea, I made a small modification (patch attached) that is >> *not* intended as a solution as it doesn't work for the general case, >> but it does allow the tests to pass on Cygwin 64. > > I can confirm that Charles's patch, plus another one line patch > to define CPU_SETSIZE, is enough to get Guile 3.0.x to build and run > on my box. All tests pass except strptime in French, and the absence > of crypt. This is a 64-bit build. Mike, thanks for going further with the Guile build. The CPU_SETSIZE issue was what was hanging me up from compiling before Andy's comment got me to look at lightening. I assumed I had some configuration, package, or compiler issue. Good to know there's a simple fix. Just a further warning to anyone watching, that patch I posted is a real hack job just to test my theory of the cause of the segfault. I would expect it to fail when you have fewer than four arguments in a JITed function call. I wouldn't try doing much else with that Guile build besides run the tests. :) -- Charles
