IRC channel logs


back to list of logs

<narispo>hey, thanks a lot to the devs for Guile 3 JIT. What would it take to obtain a ppc64[le,be] JIT as well?
<dsmith>sneek: botsnack
<dsmith>sneek: later tell dsmith Testing
<sneek>Got it.
<sneek>Welcome back dsmith, you have 1 message.
*sneek yawns
<dsmith>sneek: later tell dsmith Testing again
<sneek>Will do.
<sneek>Welcome back dsmith, you have 1 message.
<dsmith>Ok, why would for-each be unbound?
<daviid>dsmith: being in a module that doesn't use core guile? this quiz you asked on the ml ... maybe related, don't know
<dsmith>sneek: later tell dsmith Testing again
<sneek>Got it.
<sneek>Welcome back dsmith, you have 1 message.
<dsmith>sneek: later tell dsmith Testing again 3
<sneek>Will do.
<dsmith>sneek: later tell dsmith Testing again 4
<sneek>Welcome back dsmith, you have 1 message.
<dsmith>sneek: later tell dsmith Testing
<sneek>Got it.
<sneek>Welcome back dsmith, you have 1 message.
<dsmith>"Unbound variable: for-each" How can that be?
<dsmith>sneek: later tell dsmith Testing
<sneek>Got it.
<sneek>Welcome back dsmith, you have 1 message!
<daviid>dsmith: do you have a repl, while working on this bot code? you could try things like (module-bound? the-root-module 'for-each), (module-bound? (current-module) 'for-each) ...
***jonsger1 is now known as jonsger
<dsmith>sneek: later tell dsmith Testing
<sneek>Got it.
<sneek>Welcome back dsmith, you have 1 message!
<dsmith>sneek: later tell dsmith Testing
<dsmith>sneek: later tell dsmith Testing
<dsmith>sneek: later tell dsmith Testing
<sneek>Got it.
<sneek>Welcome back dsmith!, you have 1 message!
<dsmith>sneek: later tell dsmith Testing
<sneek>Got it.
<sneek>Welcome back dsmith!, you have 1 message!
<sneek>dsmith, dsmith says: Testing
<dsmith>Well. Sorry for the noise
<dsmith>sneek: later tell dsmith-test Testing 1
<sneek>Will do.
<dsmith>sneek: later tell dsmith-test Testing 2
<sneek>Got it.
<dsmith>sneek: later tell dsmith-test Testing 3
<sneek>Got it.
***dsmith is now known as dsmith-test
<sneek>Welcome back dsmith-test!, you have 3 messages!
<sneek>dsmith-test, dsmith says: Testing 1
<sneek>dsmith-test, dsmith says: Testing 2
<sneek>dsmith-test, dsmith says: Testing 3
***dsmith-test is now known as dsmith
<dsmith>sneek: botsnack
*sneek wags
***dftxbs3e_ is now known as dftxbs3e
<dsmith>sneek: later tell civodul Topic needs updating!
<sneek>Will do.
<dsmith>sneek: later tell wingo Topic needs updating!
***jonsger1 is now known as jonsger
<nly>ah, thanks zig
<dsmith>akhetopnu: You are on 64bit intel? (well, "amd") right?
<dsmith>not ppc or mips or something?
<dsmith>sneek: later ask wingo Why would for-each be unbound?
<rlb>wingo: bootstrap time here for 2.2.6 ~44m, for 3.0 ~30m.
<str1ngs>hello daviid, I have been porting my key events to g-golf. And so far it's working great.
***ChanServ sets mode: +o wingo
***wingo changes topic to 'Welcome to #guile. See for more information. Guile 3.0.0 is out! <>. This channel is logged, see <>. Bug database at <>.'
***wingo sets mode: -o wingo
<akhetopnu>dsmith: yes I'm on 64bit
<akhetopnu>I did `guix pull` twice and it failed both times, it can't compile some dependencies...
<civodul>Hello Guilers 3! :-)
<natrys>it could be great if there was a docker image or maybe an alpine package
<civodul>someone could do that with "guix pack"
***w2gz is now known as w1gz
<civodul>natrys: here's a tarball: (+ .asc)
<civodul>you can unpack it anywhere on your file system and run "./bin/guile"
<akhetopnu>will it properly setup all the dependencies?
<civodul>it's entirely self-contained
<natrys>civodul: can confirm it works, thanks :D
<civodul>awesome :-)
<akhetopnu>I downloaded the binary, and after running it and typing ctrl+c ctrl+d it gets into an infinite loop of messages
<akhetopnu>is that supposed to happen?
<wingo>akhetopnu: don't think so, it just keeps printing things out?
<sneek>Welcome back wingo!, you have 2 messages!
<sneek>wingo, dsmith says: Topic needs updating!
<sneek>wingo, dsmith says: Why would for-each be unbound?
<akhetopnu>wingo: yes
<wingo>works for me, fwiw
<akhetopnu>then when I type <Return> (or 'enter') i get a backtrace
<wingo>ah yes i see it now :P
<wingo>that is a bug :P
<civodul>the first 3.0 bug i guess, congrats! :-)
<akhetopnu>lol nice
<wingo>i wonder why it fails to install the locale
<wingo>civodul: do you know?
<civodul>the binary?
<wingo>i run /tmp/bin/guile and it prints the warning
<civodul>i guess it lacks the relevant locale data
<civodul>wingo: you're not testing on a Guix machine, are you?
<civodul>(you'd get different results)
<wingo>i am testing on an ubuntu machine with guix userspace
<wingo>the binary does work tho
<civodul>i guess we could include glibc-utf8-locales in the pack
<wingo>would be nice if it included readline too :)
<civodul>ah yes
<civodul>lemme try again then :-)
<wingo>wow the C-c thing is bonkers, there seems to be a thread that outlives guile
<wingo>like it appears to put me back at the shell but then the next thing i press, infinite series of fport-related errors
<civodul>i think it happened to me on 2.2, though i don't remember under which circumstances
<wingo>i wonder if it's somehow specific to the wrapper in packs
<civodul>wingo, akhetopnu, natrys: i've uploaded a new version in place that contains guile-readline and locale data
<civodul>you need to do ". ./etc/profile" to set up env vars though
<civodul>wingo: it could be
<civodul>would be nice to strace it
<akhetopnu>I downloaded it again, ran . ./etc/profile and then ./bin/guile but the issue persists
<akhetopnu>and this time pressing Enter at the end doesn't stop it
<wingo>no code for module (ice-9 readline)
<wingo>civodul: ^
<wingo>also still no locale data
<wingo>didn't know about the profile thing
<lloda>really readline should be set up by default
<lloda>it's a bump
<civodul>wingo: does it work if you do ". ./etc/profile" first?
<wingo>i had tried to do `bash --init-file etc/profile -c bin/guile` but lemme check sourcing the profile
<wingo>yeah same error
<civodul>so ". /etc/profile" has no effect?
<wingo>no effect on the behavior
<wingo>i do ". /tmp/etc/profile" of course
<wingo>because i extracted in /tmp but it splat gnu/, etc/, and bin/ right there
<wingo>which i thought was a bit rude but whatever :)
<civodul>it is a bit rude, indeed :-)
<civodul>i don't get why ". /tmp/etc/profile" wouldn't be enough
<civodul>it should define GUILE_LOAD_PATH & al, and they should be valid in the namespace of ./bin/guile
<civodul>wingo: BTW, is it on purpose that exception-with-kind-and-args?, quit-exception? etc. are not exported?
<wingo>civodul: regarding exception-with-kind-and-args?, i think the intention was that you would know when you need kind and args, and in that case just call exception-kind / exception-ars
<wingo>with the understanding that if guile migrates to more structured exceptions, it could be those calls build the kind and args on the fly
<wingo>for quit-exception? i think it was simply that i didn't want to add to the default environment. but (ice-9 exceptions) should probably export it
<civodul>adding quit-exception? to (ice-9 exceptions) sounds good to me
<wingo>plz do :)
<civodul>re exception-with-kind-and-args?, yeah, got it
<civodul>in my case, i have a srfi-34 handler and i wanted to check whether i have a key & arg thing so i can get the same behavior as on 2.x
<civodul>so i need to distinguish between &exception-with-kind-and-args and something else
<civodul>it's transitional though, so it's not all that important
<wingo>i see, yeah
<wingo>like you would pass on the exception in that case, if it's not a srfi-34 exception?
<wingo>i would use (exception-predicate &exception-with-kind-and-args) in that case i guess
<wingo>though it's tricky to know what you want, there
<civodul>yes, i've used exception-predicate, so no big deal
<civodul>i was just wondering why it wasn't exported
*wingo nod
<wingo>if you decide to export it that's fine too
<wingo>though it would need good docs to discourage use :)
<wingo>maybe write a mail to guile-user about how to manage the srfi-34 transition
<janneke>hmm, it seems guile does not find module files named `'
<civodul>wingo: yeah maybe it's best to not export this one
<civodul>i'll add the quit-exception? export though, for consistency
<janneke>although does work ( baz)
<janneke>eh. ( baz)
<civodul>actually make-quit-exception is not exported either, i guess it should?
<civodul>hey janneke
<civodul>janneke: is that on 2.2?
<wingo>civodul: i guess!
<janneke>yeah! oops
*janneke not even tested it on 3.0
<janneke>civodul: also on GNU Guile 2.9.8 /me goes to update guix
<janneke>should this be fixen in 3.0?
<civodul>janneke: no idea, i was just wondering
<civodul>perhaps it's still there
<janneke>yeah, i guess so
<janneke>i tried overriding %search-path, which also seems to have this bug; but it seems module loading does not use that, down the rabbit hole
<janneke>yes, also with guile 3.0
<akhetopnu>what would be the closest equivalent of common lisp's defstruct in guile? I'd like to define a struct like (defstruct item id value) and then have all the functions generated for me, i.e. (item-id item) or (item-value item) returning corresponding slots in the struct
<natrys>civodul: shouldn't paths in etc/profile be relative for it to work? (it's absolute now e.g. /gnu/...)
<lloda>or goops I guess
<civodul>natrys: they are absolute, but they're valid in the context of the running ./bin/guile
<wingo>janneke: i think it would be the same on 2.2 and 3.0
<civodul>natrys: i've just tested it on Trisquel and it works for me BTW, so not sure what's going on
<str1ngs>hello janneke, using scheme what is the best way to catch emacsy-ran-undefined-command?. I seem to have to call emacsy-tick twice which doesn't seem right.
<str1ngs>janneke: I fixed this in the examples for C. but maybe I'm missing something in scheme.
<janneke>wingo: yes, it's the same
<janneke>str1ngs: what do you mean "catch"; i think "emacsy-ran-undefined-command?" is just a boolean?
*janneke hasn't looked at this for quite some time
<janneke>i seem to remember there was an unsolved puzzle here; great that you made it work in C!
<str1ngs>emacsy_tick sets emacsy-ran-undefined-command? which indicates an unknown key. so keys can be passed down to controls
<str1ngs>the problem is in scheme you need to call (emacsy-tick) twice to test emacsy-ran-undefined-command? which works but causes other issues like minibuffer contents to be overwritten.
<str1ngs>janneke: I'll look into this more. seems like a common pain point.
<str1ngs>janneke: in short (emacsy-tick) needs to be called twice to catch emacsy-ran-undefined-command
<jonsger>Guile 3.0 news hit, a big German tech site, including your benchmark graph wingo :)
<wingo>jonsger: neat :)
<jonsger>one comment: "Webassembly is Guile - just s-expressions" ("Webassembly ist quasi Guile - alles S-Expressions!")
<nly>hello zig
<nly>are you planning to add srfi-173, hooks to Guile?
<zig>I had no such plan
<zig>nly: sorry I got disconected. No I had no plans to add srfi-173 to Guile, the implementation is straight forward, feel free to use / fork it.
<dsmith>wingo: What could possibly cause for-each to be unbound? I ended up use'ing srfi-1 as a workaround.
<wingo>dsmith: no idea! how did you produce that bug?
<wingo>did you perhaps #:export (for-each) in a module?
<wingo>or make a module #:pure?
<dsmith>Nope. And nope.
<dsmith>wingo: Other files in same dir have no problem.
<dsmith>wingo: So there is code that queries the db for "later tell" messages.
<dsmith>It could return a list or #f
<dsmith>Mostly it returns #f.
<wingo>can you point me to the code?
<dsmith>sneek: paste?
<sneek>paste is
<dsmith>wingo: deliver-messages
<wingo>dsmith: does any of the other modules you import export a for-each ?
<dsmith>../scripts/bot/infobot.scm: (for-each (lambda (line) (bot:say to line)) lines)
<dsmith>../scripts/bot/infobot.scm: (for-each
<dsmith>../scripts/bot/parsing.scm: (for-each (lambda (tok)
<dsmith>../scripts/bot/tell.scm: (for-each send messages)))))
<dsmith>That's a grep
<dsmith>Indeed. for-each is in boot-9. You would think other stuff would be broke too.
<dsmith>wingo: Is there a way to disable some optimizations locally, like for one fuction?
<wingo>are these files even compiled?
<wingo>and you don't get a warning about for-each being unbound?
<dsmith>Well, there are .go files.
<wingo>do you have a link to the git
<dsmith>No. It't not in a repo.
<wingo>yeah dunno tho, i have to guess it's something about whatever it is that makes you need to call (module-public-interface (current-module))
<dsmith>Yeah, that was suspicious to me. That's the bobot++ code doing that.
<dsmith>Not sure what that is attempting to do.
<dsmith>Adding the bobot code to the guile module I think.
<dsmith>This is 32bit x86, btw
<civodul>can you imagine? sneek may well end up being 4 times faster!
<civodul>perhaps it'll reply before we're done typing?
*sneek giggles
<dsmith>sneek: later tell dsmith-testing something
<sneek>Will do.
<dsmith>sneek: later tell dsmith-testing something else
<sneek>Got it.
<dsmith>sneek: later tell dsmith-testing even more stuff
***dsmith is now known as dsmith-testing
<sneek>dsmith-testing!, you have 3 messages!
<sneek>dsmith-testing, dsmith says: something
<sneek>dsmith-testing, dsmith says: something else
<sneek>dsmith-testing, dsmith says: even more stuff
***dsmith-testing is now known as dsmith
<dsmith>Working now.
<dsmith>Very puzzling
<dsmith>And suprising
<dsmith>wingo: Thanks again for all your efforts!
<dsmith>Amazing work.
<wingo>what did you change? :)
<dsmith>Using srfi-1 for-each
<chrislck>one of these days we'd need some help setting up a good environment for debugging guile-3.0 in gnucash... don't think other the devs have time for this
*janneke sent bug+patch for module
<dsmith-work>Happy Friday, Guilers!!
<mwette>I have a four-day weekend -- yay.
<daviid>happy friday!
<daviid>str1ngs: good! fyi, I just pushed a code review patch about event and event strucutres, the thing is, while talking about this on #introspection, one of the main dev highly recommended not to parse the gdk event structures, but rather, use their respective accessors - the main reason being that in GTK4, GdkEvent is an actual GObject, and it's completely opaque
<daviid>this means that forward-compatible code should consider GdkEvent and friends opaque pointers even in GTK3
<daviid>because of this change, I also (had to) remove some of the previously defined <gdk-event-key> accessors, the git log list those that I removed and those that are kept
<civodul>how does one disassemble the code around $ip, like "x" in GDB?
<daviid>wrt <gdk-event-key>, users should probably only be interested by the gdk-event-key:state, gdk-event-key:keyval and gdk-event-key:keyname (which is not a 'real accessor', but I thought much better to make it appear 'as if' then to impose users to call gdk-keyval-name on the gdk-event-key:keyval ...
<daviid>now I should start to work o other gdk event structures, if you have a pririty wish let me know :)
***ng0_ is now known as ng0
<spk121>daviid: good to know.
<daviid>spk121: yes indeed :)
<lispmacs[work]>hi, last night I was troubleshooting some Guile code embedded in a C application linked to Guile 2.6.6. The program is multi-threaded (pthrea) where some guile code is running in a main thread and some in another thread. I was getting this strange effect where if lots of calculations were happening in the child thread, (sleep) calls in the main thread would complete faster than they were supposed to
<lispmacs[work]>like, a 10 second sleep was finishing nearly instantaneously, but if I reduced the amount of calculations in the other thread, it would increase to a 3 seconds wait
<lispmacs[work]>just wondering if anybody had any thoughts on what might explain that. It was running on a Gnu Guix amd64 system
<manumanumanu>lispmacs[work]: using srfi-18 threads or regular guile threads?
<akhetopnu>hello. I'm playing with fibers and I'm running the example through geiser. When I evaluate the (run-fibers ...) part everything is ok, however when I press C-c to have it evaluate in quick succession after about 2 seconds I get a message in the REPL: `scheme@(guile-user)> Aborted` and guile exits. I should probably add I'm running `guile --listen` in the terminal and then connecting to it from emacs using `M-x connect to guile RET RET`
<lispmacs[work]>manumanumanu: regular quile threads, though near as I can tell in the source thread-sleep! just maps to a sleep call
<lispmacs[work]>I suppose if Guile is just binding to coreutils sleep, than it would have to be some quirk of that C function
<lispmacs[work]>oh wait, coreutils is the command line version
<zig>akhetopnu: oops :)
<lispmacs[work]>I'm reading all kinds of interesting stuff in the libc info manual about how unsafe sleep() is
<akhetopnu>what is the recommended websocket library for guile? dthompson's guile-websocket?
***ng0_ is now known as ng0
<ng0>announcement of new major guile ve[20:44:12] *** Quits: lfam (~lfam@2607:fb90:631d:37ec:bd12:d1b9:ff09:41be) (Ping timeout: 260 seconds)
<str1ngs>daviid: okay good to know will this mean gtk can be dropped as a dependency as well?
<str1ngs>daviid I have no priorities, most of what I need is there in the accessors you mentioned already. But I will report any if I run into. Thanks
<daviid>str1ngs: I removed the 'explicit' gtk+-3.0 dependency in the a little while ago - I only added it because I tried something in libg-golf, which needed the gtk libs and flags
<daviid>str1ngs: but I am a bit confused now, because the (g-golf init) module gained (define %libgdk (dynamic-link "libgdk-3")) - on debian, is part of the libgtk-3-dev:amd64 - so i think I might have to add it again?
<str1ngs>daviid right libgdk-3 makes gtk a dependency
<zig>ng0: neat ;)
<daviid>spk121: what do you do in guile-gi? wrt gdk event/gtk dependency i mean?
<str1ngs>but you can might need need libgtk-3-dev. since dynamic-link makes it a runtime dependency . not sure how to test this in though. pkg-config is nicer but not exactly required.
<str1ngs>not need*
<str1ngs>maybe it's best to just use pkg-config for now so it all works nicely. I'm just thinking in cases where people are just using clutter or some lower other GI not related to GTK
<daviid>str1ngs: make will fail if it can't find "libgdk-3"
<daviid>str1ngs: it iwould next to impossible to use clutter without gdk events either
<str1ngs>I think it depends on the tests. I know libgirepository-1.0 is used during the test.
<str1ngs>in which case I'd test in if clutter needs gdk
<daviid>i definitely need to get rid of using clutter in the tests
<daviid>but that is something else
<str1ngs>I think the clutter tests are still useful right now. but I understand your reasoning.
<str1ngs>maybe you can move clutter tests in a place that is not called by make check maybe make check-clutter
<str1ngs>so clutter is not a depend to run API checks
<daviid>str1ngs: i used clutter just as a convinient way of, but all tests can/should oly depend on what configure checks to be installed
<str1ngs>that's understandable. though with GI it's nice that things are not required explicitly since they are all loading at runtime. It's one of the benefits over C
<str1ngs>I guess I did'nt want the clutter tests to goto waste since they are convenient tests as you mentioned.
<daviid>i beleive if guile-gi offers gdk event support, it checks at configure time that libgtk-3-dev:amd64 is installed
<str1ngs>that makes sense, but as I mentioned if you don't use libgtk in headers or C files. you only need libgtk-3-0 not libgtk-3-dev. maybe too much of a nuance?
<daviid>i don't beleive it is possible to compile guile-gi without libgtk-3-dev, if it offers gdk event support?, let's see what spk121 has to
<daviid>*has to say :)
<str1ngs>sounds good, this ban be revisited when there are more users. I'm stilling groking how best to handle dynamic GI depends myself. in regards to scheme.
<daviid>i'll check the guile-gi file - i think guile-gnome does only offer support when it finds gtk, but that complicates quite a lot the autotool chain 'arrangement' so to speak, maybe 'imposing' PKG_CHECK_MODULES(GTK, gtk+-3.0 >= 3.24.0) is ok- after all, trying to use a GI typelib without gdk event sound highly improbable?
<daviid>have to go, bbl
<str1ngs>daviid that is the easiest way yep
<str1ngs>daviid I think though it would be nice to check only for libgdk useing dlopen if possible using autotools. but PKG_CHECK_MODULES will suffice for now.
<civodul>it seems that the md5 test of the latest guile-lib "hangs" with Guile 3
<civodul>has anyone tried?