IRC channel logs
2018-07-29.log
back to list of logs
<atw>amz31: I had wondered if you had heard of datomic <sneek>Welcome back atw, you have 1 message. <sneek>atw, g_bor_ says: I would like you to have a look at my clojure patch. mbakke said that you are familiar with clojure stuff. It would be nice if you could confirm that this does not interfere with typical clojure usecases. It is here. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32295 <rlb>2.2.4+1-1 uploaded to debian unstable -- let's hope the buildds like it better than 2.2.3... <rlb>(the ppc64el and arm64 buildds in particular) <sneek>spk121, jralls says: Thanks, but it's a clean build in a freshly-created build directory from a freshly-cloned guile branch tracking wip-mingw-guile-2.2. <thomassgn>Um, I get 'ERROR: Wrong type to apply: 0' from geiser(guile) from the following: '(define pc (system "upower -i /org/freedesktop/UPower/devices/line_power_ADP1"))' But if I remove define and just run the system procedure it's all fine. what am I missing here? <thomassgn>oh, to clarify, I get the error from running (pc), not from the define... <ft>you're evaluating (system ...) and define pc to be the result of that. <ft>An integer. Then you try to apply that integer to an empty list. And since the integer is not a function, that fails. <thomassgn>oh, is this a matter of (define (pc) ...) versus (define pc ...)? <ft>No it's a matter of (pc) which is the same as (0) <ft>I guess you want: (define pc (lambda () (system ...))) <thomassgn>but, huh. maybe. Is that necessary for making dynamic procedures? <ft>What is it, that you're trying to do? Maybe this will lead us to a resolution quicker. :) <ft>It looks like you're trying to define something that you can later call, that asks the OS to run that command from you. <thomassgn>so you're tip about using lambda reminded me of something from some guile book I've read a while ago. Basicly, (define (name) ...) is a shorthand for (define name (lambda () ...)) or what it is. Not sure why I started using (define name ...) instead of (define (name) ...). <thomassgn>tried to find the reference I'm making... I thought it was from the guile info pages introduction or something. <thomassgn>that's such a relief, last time I was hacking on this project a different strange error was just ruining everything, turns out I was making it happen on my own by not checking the nagging in the back of my head about how defines (shortcut) syntax works... :P <thomassgn>My goal is to first check if the computer is connected to electricity by matching on 'online: [yes|no]' (output from the upower command) and then check the percentage of the battary if computer is not connected - also by matching against output from upower. Then I'm going to react by throwing a notification if power percentage of battery is low-ish. <thomassgn>dddddd: hahaha, wow. Thanks - today is the day of silly mistakes. :-P <megane>guile -c '(let ((f 1)) f (define (f) 2) 1)' <megane>unknown file:1:15: definition in expression context, where definitions are not allowed, in form (define (f) 2) <daviid>megane: the inner define is not allowed, see the manual for inner define position <daviid>megane: ... not allowed in that context, there are strict rules about where you can use define within define(s) <megane>define is not allowed inside let? <daviid>megane, see the manual about where in a defintion you are allowed to use define <megane>shii... toplevel means at the top of the begin expression? <daviid>megane 6.12.3 Internal definitions <daviid>"... Internal definitions are only allowed at the beginning of the body of an enclosing expression. They may not be mixed with other expressions..." <mwette>guile -c '(let ((f 1)) (define (f) 2) 1)' will work <mwette>the defines must appear before non-defines in the body <daviid>mwette: indeed, but i prefer to point users to the relevant part of the manual ... imo, it brings a lot more to them, and generally they will read other part of the manual, clicking links ... hence my suggestion to megane ... <weinholt>rlb, most builds seem fine but sparc64 still fails on "after-gc-hook gets called", so the bug is probably still lurking <weinholt>rlb, i had a look at the hurd-i386 failure. the (pause) call in test-guild-compile somehow doesn't let through SIGINT. after removing that line, the tests pass. i didn't verify it, but the kfreebsd builds have the same problem according to the logs. <rlb>weinholt: thanks -- for now, I've mostly just been focusing on the release architectures, but I'm happy to fix the others too if we can. Regarding after-gc-hook, that one's "easy", if we just do what I did for mips(el) and ignore it. I'll try to remember to do that for sparc64 in the next release. <rlb>(as far as release architectures go, just waiting on mips(el) -- guessing probably take ~6hr once it starts) <rlb>ok, I've added sparc64 to the "mark unresolved on failure" list for that test. <rlb>(should be in the next upload)