Neil Van Dyke wrote at 04/24/2012 03:13 PM:
One reason for avoiding linking native code libraries is that they are
often written in C/C++, and this means that memory-corrupting bugs
often exist in them. Memory-corrupting bugs can be a nightmare for
debugging, and I prefer to keep sources of th
An hour and a half ago, Neil Van Dyke wrote:
> I'd put those port close calls in a "dynamic-wind" cleanup thunk.
> I'd also catch the exceptions that could be raised by the
> port-closing procedure itself in the cleanup thunk. And I'd make
> sure that any custodian I was using didn't close the por
Calling these tools can be a little more complicated.
I'd put those port close calls in a "dynamic-wind" cleanup thunk. I'd
also catch the exceptions that could be raised by the port-closing
procedure itself in the cleanup thunk. And I'd make sure that any
custodian I was using didn't close
Galler wrote at 04/24/2012 01:14 PM:
Neil V. mentioned his preference for directly calling the OpenSSL
libraries
To be clear, OpenSSL includes both linkable native code libraries and
the "openssl" command-line executable. I have had good success using
various crypto algorithms by calling the
Yes. Absolutely correct. I should have done this.
Please include the following three lines to close the three ports
created by the (process..) call.
(close-input-port (first res))
(close-output-port (second res))
(close-input-port (fourth res))
R./
Zack
On Tue, Apr 24, 2012 at 1:21 PM,
One comment here: you really want to be sure that you close all three
of the ports that process returns, or else you'll run into problems if
you use this in a larger context.
Robby
On Tue, Apr 24, 2012 at 12:14 PM, Galler wrote:
>
>
> Neil V. mentioned his preference for directly calling the Ope
6 matches
Mail list logo
