<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 <RhodiumToad>in my test, you only get that error if it didn't find anything using the string ***Server sets mode: +nt
<zig>catonano: do you have in ~/.guile the following line: (use-modules (texinfo reflection)) ;; help <catonano>RhodiumToad: thanks. I was in the user module ***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 ***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 <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 https://gitlab.com/wingo/lightening <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? <wingo>64-bit little-endian should have prebuilt .go files fwiw <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>#0 abort_to_prompt (thread=0x56531d1b0d80, saved_mra=<optimized out>) <mwette>#1 0x00007f1e462e960b in vm_regular_engine (thread=0x56531d1b0d80) <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>, <mwette>$3 = (struct scm_vm *) 0x56531d1b0d88 <mwette>$4 = (union scm_vm_stack_element *) 0x7f1e4674c020 <RhodiumToad>how deep on the stack is that? because we (postgres) ran into an issue with stack extension on power ***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>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 <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 :) <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>"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.