IRC channel logs


back to list of logs

<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
<narispo>this would be best for accelerating GNU Guile with FPGAs:
<narispo>if the FPGA can do DMA it's perfect
<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>^^ the purpose is unit-testing...
<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 ...
<daviid>the value of counter
<chrislck>daviid: agree but the use case is (define (big-function ...) (define (helper-fn ...) ...) ...) and I want to unit-test helper-fn
<chrislck>helper-fn is also a big ugly 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>all this is tricky
<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>the big function could do that
<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.
<sneek>Got it.
***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>hi rlb!
<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
<weinholt>rlb, here's another way:
<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): 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)
<civodul>or a pipe
<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>a pipe is a "file port" :-)
<civodul>file ports are ports backed by a file descriptor
<civodul>sockets are also "file ports"
<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>(to avoid deadlock)
<rlb>civodul, weinholt: thanks much.
***sneek_ is now known as sneek
<dsmith>sneek: botsnack
<dsmith>sneek: seen rlb?
<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)