IRC channel logs


back to list of logs

<daviid>spk121: I just sent an email to the 'guile s/w list' (earlier posted) link owner and maintainer so he adds guile-gi and g-golf ...
<spk121>daviid: ok, sweet. I think the next guile-gi (v0.2.2) will be stable enough to declare as a beta. 0.2.1 had a nasty bug where my callbacks were being garbage collected because their pointers were held in C
<daviid>spk121: great! I glad you found the bug you were tracking for a while ... cool!
<wdkrnls>How can I figure out what guile modules provides a procedure?
<wdkrnls>(help "function-name") seems to work well enough for now.
<lloda>actually I didn't know that (help "fname") and (help fname) did different things
<lloda>I only ever used (help fname)
<catonano>lloda: to me (help "fname") claims "fname" is not a symbol and it hangs
<catonano>(expecting symbol): "fname"
<catonano>what's your experience ?
<RhodiumToad>in my test, you only get that error if it didn't find anything using the string
<RhodiumToad>try e.g. (help "car")
***Server sets mode: +nt
<zig>catonano: do you have in ~/.guile the following line: (use-modules (texinfo reflection)) ;; help
<catonano>zig: yes
<catonano>RhodiumToad: thanks. I was in the user module
<catonano>oh wow
***janneke_ is now known as janneke
<wingo>is anyone able to debug the build failure that mwette reported?
<wingo>mwette: if you try to compile linker.go with GUILE_JIT_THRESHOLD=-1 but with -Oresolve-primitives, does it change the result?
<wingo>mwette: did you have this build error before 2.9.5 ?
<wingo>do you build with make -jN or is it a straight make
*civodul just stumbled upon
***ng0_ is now known as ng0
<jcowan>Astonishingsauce. I suppose now that Emacs is small potatoes rather than the biggest process on most people's systems, the overhead of keeping gcc in memory isn't that bad.
<jcowan>It certainly puts pressure on (a) ancient dynamically-bound Elisp code, which will run much more slowly, and (b) Guilemacs.
<jcowan>The last especially because it won't trigger any worries about splitting the community: you still have to write Elisp to customize Emacs, even though the definition of "Elisp" is changing over time.
<jcowan>Perhaps another approach is to provide an Elisp back end for Rapid Scheme (which currently has only a Scheme back end) to allow people to write Scheme-with-Elisp-libraries.
<jcowan>You'd have to either run RS outboard or translate it into Elisp, though.
<jcowan>(The latter is a much bigger job than adding Elisp support, though that's not trivial either.)
<wingo>i just did a fresh -j1 build with no failure
<jonsger>wingo: I finally start working on the power port of guile 3.0 this week again
<jonsger>let's see how far I can come
<str1ngs>jonsger: I have access to power8 and power9 if you need any help testing.
<jonsger>str1ngs: I have a blackbird my self and develop on it. But thanks for the offer :)
<str1ngs>jonsger: I've been meaning to look at that and some guix related power things. but been swamp with other projects lately
<str1ngs>I can at least run tests or something though
<jonsger>str1ngs: nice. Guix is a little difficult due to the stuff we have to change in the bootstrap process for gcc6...
<wingo>jonsger: nice :) i would start with lightening's test suite fwiw :)
<wingo>ah i guess you could get it working without jit first, i would guess it works already but who knows
<str1ngs>jonsger: I don't have root access on the power machines. so I created a rootless container to run guix which was neat in it's self.
<wingo>definitely try the libgc test suite too
<jonsger>wingo: so you mean guile-3.0 on power?
<wingo>yes regarding guile 3 on power i would do: (1) make sure libgc tests pass (2) build guile without jit, make sure it works (probably it does) (3) start to work on the power port of
<wingo>once those are done then guile 3 jit should work
<jonsger>1 and 2 should already be the case. I have already started on 3 in August, now I need to understand what I did :P
<jonsger>somehow guile 2.9.7 seems to be super slow to compile
<wingo>jonsger: is it a 64-bit big-endian system?
<jonsger>wingo: now powerpc64le
<wingo>64-bit little-endian should have prebuilt .go files fwiw
<jonsger>yes, it has
<mwette>wingo: with GUILE_JIT_THRESHOLD=-1 still segfaults; this did not happen with 2.9.4 IIRC; I can try again; I'm just using make
<wingo>mwette: interesting info, tx :)
<wingo>mwette: can you do "ulimit -c unlimited"
<wingo>then run it so it produces the segfault
<wingo>then "gdb libguile/.libs/guile path/to/core/file", then "bt"
<wingo>could be ubuntu stashes the core file elsewhere tho, you might need to look up how to get a core file
<mwette>(gdb) bt
<mwette>#0 abort_to_prompt (thread=0x56531d1b0d80, saved_mra=<optimized out>)
<mwette> at vm.c:1449
<mwette>#1 0x00007f1e462e960b in vm_regular_engine (thread=0x56531d1b0d80)
<mwette> at vm-engine.c:1106
<mwette>#2 0x00007f1e462ea9d4 in scm_call_n (proc=0x7f1e46736008,
<mwette> argv=argv@entry=0x7fff27bf38c8, nargs=nargs@entry=1) at vm.c:1586
<mwette>#3 0x00007f1e4626fea7 in scm_primitive_eval (exp=<optimized out>,
<wingo>that's exciting
<mwette>(gdb) p vp
<mwette>$3 = (struct scm_vm *) 0x56531d1b0d88
<mwette>(gdb) p vp->sp
<mwette>$4 = (union scm_vm_stack_element *) 0x7f1e4674c020
<mwette>p vp->sp - sp = -2059
<mwette>cont = 0x04
<RhodiumToad>this is linux on powerpc?
<RhodiumToad>how deep on the stack is that? because we (postgres) ran into an issue with stack extension on power
<mwette>mine is x86_64 on Ubuntu 18.04
<RhodiumToad>oh, ok
***ng0_ is now known as ng0
<jcowan>Removing -Oresolve-primitives from bootstrap/Makefile allowed me to build 2.9.7 on Ubuntu Xenial, and I'll try later today to build on Cygwin as well.
<jonsger>wingo: is there a reason why `jit_gpr` is a struct and not just an `uint8_t`?
<wingo>type safety
<wingo>does the power abi not pass it in a register?
<jonsger>wingo: no it's fine. Just seemed a little boilerplatish to me :P
<wingo>it goes away at the backend level :)
<wingo>the issue is, you don't want to confuse immediates, fprs, and gprs
<wingo>that kind of bug is really easy for the user to make if the type system doesn't help you out
<wingo>that's a problem the original lightning api as
<jonsger>ah, that's what I tought :)
<johnjay>jcowan: changing compiler flags for different platforms based on guesswork sounds like a nightmarish web
<jcowan>Yes, it's just a hack to get things going for me on my two boxen
<johnjay>maybe it's the fact you said ubuntu xenial
<johnjay>as in, it might compile on fedora but then for ubuntu the flags have to fiddled with
<johnjay>or like bionic -> xenial (i'm on 18.04)
<jcowan>I'm not running bionic, so I have no idea
<jcowan>$EMPLOYER will remain on xenial until the LTS runs out
<johnjay>i'm not sure what the LTS means in practice. i just went with 18 since security updates sounded good
<johnjay>but i think maybe i should have just used the latest one
<jcowan>It means that Ubuntu is providing support for five years after release, whereas other releases are supported only a short time
<wingo>regarding ubuntu 18.04, it's good that it's not a jit bug, and that the backtrace is in c rather than the vm. i suspect a gc bug fwiw
<wingo>someone will need to spend some time with a VM, but i am away for a couple weeks. have a nice holiday, ppl :)
<mwette>same to you !
<jcowan>so the current release (Eoan) willl expire next July, whereas bionic is good until 2023 and even xenial until 2021, *and* security patches until 5 years later in each case
<zig>might be interesting to fibers
<zig>"The new runtime detects blocking automatically. We don’t need spawn_blocking anymore and can simply deprecate it." Seems like a GC kind of work, we know what it brings in terms of feature, but do not know the price.
<zig>funny that is use the 'spawn' term, I made exactly the same choice of name a few years back.