<wklew>you're right, i had it backwards. what I'm thinking of is something like the dual of append-map <wklew>where each element is itself a stream that gets folded down to a single value <chrislck>Dear All. I know we can access an unexported var in a module via (@@ (module name) private-var) as long as private-var is toplevel in (module name). <chrislck>Is there any access to private-var if it is in a function? <chrislck>(define (make-counter) (let ((counter 0)) (lambda args ... etc))) <chrislck>^ can we possibly access counter from outside? <chrislck>^^^ to unit test large functions I am currently refactoring into toplevel small functions. wondering if there is a less drastic way. <daviid>chrislck: i would define a getter, like the guile manual withdrawal example <daviid>then you can use th gettr to test ... <chrislck>daviid: agree but the use case is (define (big-function ...) (define (helper-fn ...) ...) ...) and I want to unit-test helper-fn <daviid>chrislck: i don't think you can access th counter 'from outside', so to spak <daviid>but for testing purposes, you could/may set an external var to the val of the local ... using sort of 'if debug? set %e-counter counter), then access %e-counter <daviid>accessing locals would break fundamental rules of hygiene ... as you prob know <chrislck>yeah. I want my functions to not know they're being tested ;) <daviid>i would define getters, even if only to debug <daviid>i mean literally follow the withdrawal example is the only sane approach i see <daviid>otherwis i se the testing code being so error prone that it would be mpossible to trust the tests :):) <apteryx>rekado_: thanks for tipping in bug#41956. I've replied now. ***wxie1 is now known as wxie
<manumanumanu>sneek: later tell wklew you can use srfi-171 as well, which is also useful for stream processing, but with eager semantics. It does a kind of stream fusion of map/filter etc. For a (list-transduce (tmap 1+) rcons (list 1 2 3 4 5)) it is slightly slower than regular map, but already at (compose (tfilter odd?) (tmap 1+)) it is faster, at least in guile3. ***jonsger1 is now known as jonsger
***terpri_ is now known as terpri
***dddddd__ is now known as dddddd
<rlb>Is with-error-to-port an appropriate way to intercept stderr from open-pipe*? I ask because it doesn't seem to work for me (though of course I might well be doing it wrong). I'm using a bytevector-output-port. It doesn't complain, but I wondered if that was supported yet, i.e. I want the bytes. <civodul>rlb: it only works if current-error-port points to a file port <civodul>see scm_piped_process in libguile/posix.c <rlb>So we can't capture stdout and stderr right now? <rlb>(without a physical file?) <rlb>Also, I wonder if for now it should throw an exception or something if current-error-port is incompatible so you know you're "doing it wrong"... <weinholt>rlb, it should be possible to use (pipe) and hook up the subprocess' stderr to the write side <weinholt>rlb, if the subprocess writes to both stderr and stdout then a careful program should not block on reading from one of them <rlb>weinholt: you mean if you were to just not use open-pipe* and do handle it all yourself? <weinholt>rlb, i'm suggesting you can use (pipe) instead of what you're doing now with a bytevector-output-port <rlb>Sure, that's what I meant wrt "not use open-pipe*". <rlb>civodul: seems like it might be nice to support something like that with open-pipe* (or some derivative, built in to guile). <rlb>Fwiw, clojure has a much more restricted convenience function (though it does provide access to :err): https://clojuredocs.org/clojure.java.shell/sh Much like python's subproc.communicate(), it side steps deadlock/streaming concerns, but isn't very flexible. <civodul>rlb: correct, we can't capture both without going through a file (which is annoying) <rlb>Wait, will it let me use a pipe there? If so I misunderstood, I thought it required a *file* port. In any case, I can just use a temp file for now if I have to. <civodul>file ports are ports backed by a file descriptor <rlb>oh, then I *definitely* misunderstood weinholt :) <rlb>OK, well that's fine then. I'm already having to use some future shovel(s). <rlb>civodul, weinholt: thanks much. ***sneek_ is now known as sneek
<sneek>rlb was last seen in #guile 36 minutes and 23 seconds ago, saying: civodul, weinholt: thanks much.. <dsmith>(had a few minute power outage a little bit ago)