<davexunit>has anyone else noticed that geiser breaks when trying to connect to a guile repl over a unix domain socket? <adhoc>is that not the default behaviour ? <davexunit>I had never used the geiser-connect-local function until tonight <davexunit>(use-modules (system repl server)) (spawn-server (make-unix-domain-server-socket #:path "/tmp/repl")) <adhoc>so you are spawning a process you want to attache to separately ? <davexunit>I do this all the time with tcp server sockes <adhoc>hmm my version of emacs/geiser doesn't have geiser-connect-local <adhoc>it doesn have a geiser-connect, which asks for hostname and port <adhoc>i think thats what ships with this version of ubuntu <please_help>is the garbage collector working correctly in 2.0.11? My memory usage keeps growing despite the fact I iterate and never use stuff from the previous iteration. <please_help>hell, it just got killed with "Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS" after using up around 21GB of ram. <please_help>It looks to be related to eager comprehensions. Possibly my :array/array-ec code, but I haven't seen that problem before. <mark_weaver>please_help: it really grates on me that whenever your program doesn't work, your first thought is that it must be a bug in guile. <please_help>Considering that the code didn't change and the only noteworthy difference is a change in guile version, it's a logical explanation. <please_help>The behavior right now is that it just starts eating more and more memory after a set amount of time despite nothing changing inside each iteration. <mark_weaver>I would recommend trying to incrementally reduce it to a minimal, self-contained demonstration of the problem. <mark_weaver>perhaps, along the way, it will become clear where the problem is. if not, then the end result may be small enough that we can reasonably investigate it as a possible guile bug. <mark_weaver>alternatively, you could do a git bisect between whatever version of guile worked and guile-2.0.11, to determine which commit introduced the problem. <mark_weaver>I'm assuming that the two versions of guile in question were linked against the same libraries, most notably: the same libgc. <mark_weaver>if not, you should rule out the possibility that it was a change in libgc that introduced the problem. <please_help>That is the case as far as I'm aware, but I'll double-check that too. ***lloda` is now known as lloda
<amz3>My new favorite procedure is `compose`, I try to use it all the time <amz3>`compose` with `cut` is helpful <paroneayea>amz3: ohhhhh I was looking for that procedure :) <amz3>I need to spend more time on it... this seems like learning wht OOP is when I was still young and foolish PHP programmer <amz3>I found it on your timeline ^^ <paroneayea>amz3: and yeah, I'm still immersing myself in monad-land <amz3>I discovered a new bindings in emacs, C-t which swap current letter by the previous <amz3>this doesn't seem, much but once you get use to it, it's precious <amz3>haha! I have a way to keep you people under the radard now! <amz3>the code is too simple to publish right now <civodul>BTW, davexunit & paroneayea: you should have your blog subscribed to planet.gnu.org <civodul>that would increase the value of p.g.o to me ;-) <davexunit>I guess their site will explain somewhere... <civodul>"Please write to planet@gnu.org for blog aggregation requests or suggestions." <dsmith-work>Sorry for the off-topic question: does anyone know of any command line tool to display an image using xosd? Preferably an svg. <amz3>let say I have a composition of `step` procedures, each `step` feeds the next `step`, e.g. (define steps (compose-step add-one multiply-by-two half)) <amz3>1) `steps` composition takes, we will say, a stream for now (it's more complicated), how does look like the the compose-step procedure ? <amz3>compose-step must be lazy, ie. it must not consume fully the stream before returning the result <amz3>well I will look the stream doc <amz3>2) to explain fully, I add this question. The preceding/previous "streams" must be closed if they are not useful anymore, e.g. (define steps (composte-step add-one multiply-by-two (limit 10) half)) <amz3>say I call `(steps (my-stream-iota 20))` the `half` step will only see the first 10 numbers. <amz3>and the other 10-20 numbers will never be generated in the first place, by `my-streap-iota`, since it build things on demand <alezost>dsmith-work: AFAIK xosd can be used only to display text, not images <dsmith-work>alezost: Here is the thing. With gnome 3 on my laptop, I get these really nice looking images when I use Fn keys, like volume, monitor and keyboard brightness, etc. I want to do that with awesome instead. <mark_weaver>gnome-shell is based on clutter. I don't see why they'd use another tool to show those graphics when they already have clutter to do the job. <dsmith-work>About 13 years ago we had thinkpads, and there was thing that got those Fn keys workin in Linux. And used some kind of on screen display overlay. ISTR it was "osd" or "xosd". But that was a while ago, and my memory .... <amz3>there is probably a solution with monads to my problem <davexunit>amz3: I'd try to help a bit, but I don't really understand. <amz3>Thanks, I will do it later, I'll focus on getting the whole thing done in a way I can understand right now <amz3>well, i think i found a solution. My python has the same bug actually. <amz3>ie. not closing database cursor when your drop part of the generator <amz3>I will kind of use a similar approach as my python code :/ <please_help>I used ghetto-tier debugging since creating a minimal test case was a problem. I installed an after-gc-hook and found that the hook stops being called as the memory starts leaking. What are alternative explanations to a GC-related bug? The number of calls to the hook does not seem to affect whether or not GC will stop. <please_help>I have this problem with boehm-gc 7.4.2 with guile-2.0.11