<jcowan>okay, configure ran, now in the CC stage <jcowan>Ouch, I had a hard crash: can anyone diagnose this? <jcowan> BOOTSTRAP GUILEC srfi/srfi-1.go <jcowan>/bin/sh: line 6: 51400 Segmentation fault (core dumped) GUILE_AUTO_COMPILE=0 ../meta/build-env guild compile --target="x86_64-unknown-cygwin" -O1 -Oresolve-primitives -L "/home/rr828893/Downloads/guile-2.9.7/module" -L "/home/rr828893/Downloads/guile-2.9.7/guile-readline" -o "srfi/srfi-1.go" "../module/srfi/srfi-1.scm" <mwette>wingo: so guile-2.9.7 is not building for me on ubuntu; crashes building linker.go; if I remove "-Oresolve-primitives" it works; if I run under gdb-uninstalled-guile I get end up with "Inferior 1 (process 10064) exited normally]" but the linker.go file is not created. I tried ... <daviid>mwette: it compiles fine on debian buster - did you make sure to clean any previous compilation <jcowan>Okay, I am getting the same crash on Ubuntu Xenial ***ZombieChicken is now known as ZombieGoose
***ZombieGoose is now known as ZombieChicken
***ng0_ is now known as ng0
<lampilelo>how can I make guile compiled by me to know where to find system's gnutls module? <civodul>seems there's some eager binding resolution taking place <lampilelo>adding system's stuff to GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH doesn't seem to work, maybe I'm doing something wrong <civodul>lampilelo: what error do you get specifically? <civodul>normally, if gnutls.scm is in GUILE_LOAD_PATH, it should just work <lampilelo>Throw to key `gnutls-not-available' with args `("(gnutls) module not available")'. <lampilelo>I don't have gnutls.scm, just gnutls.go but I'm not sure how to load it <zig>lampilelo: you use guix? <lampilelo>I compiled 2.9.7, installed it in /usr/local/* and http-get stopped working <lampilelo>so for now, I'll use /usr/bin/guile until I figure it out <zig>while importing triples, 2.9.7 is 2% faster than 2.9.6 <zig>I will compare nomunofu against blazegraph <zig>well blazegraph is can not be installed on ubuntu 18.04, I will try 4store instead. <mwette>lampilelo: you may need to use LD_LIBRARY_PATH to specify location of shared object; that is find out where libgnutls.so is and provide that in executing guile: LD_LIBRARY_PATH=/path/to/dir guile yourscript.scm <lampilelo>now it aborts with "incompatible bytecode kind" <zig>4store is 4 times faster. <zig>4store is around 4 or 3 times faster. It is written in C. <mwette>lampilelo: yes, guile needs to find gnutls.scm and gnutls.scm needs to find libgnutls.so <civodul>lampilelo: the system gnutls is probably built against Guile 2.2 though, not 2.9 <johnjay>are there any applications completely written in guile <johnjay>or is guilt meant literally to just extend an existing program in a non-scheme? <zig>5 times slower than virtuoso (which the biggest player foss competitor) <zig>I did compare query times against virtuoso, but virtuoso cache query results very aggressively and report a query time of 0ms. <zig>query times over a smaller than ram database seems very similar. <zig>;; 0.014304s real time, 0.011656s run time. 0.000000s spent in GC. <zig>or does it?! 0.014 is 14ms unlike virtuoso which report 2ms <zig>first query virtuosos query, before caching, takes around 15ms ie. the same time. <str1ngs>lampilelo: it's probably easier to just build gnutls with guile support into the same prefix as guile <rekado_>I’m getting this error when using (fibers web server): In procedure custom_binary_input_port_read: Value out of range: 1024 <rekado_>I only see “1024” as the size argument of read-bytes, get-bytevector-n!, and port-read. <rekado_>I don’t see this error when using (web server) <rekado_>the error is triggered by the use of xml->sxml *rekado_ checks if there’s a flag to play with