IRC channel logs

<cmhobbs>nalaginrut, a little late but hello!

<sneek>cmhobbs, you have 1 message.

<sneek>cmhobbs, fps says: yes, gnunet is available

<cmhobbs>well, that's a useful bot

<lcl___>hi all - just tried guile 2.1.1 on a FreeBSD 10.2 system, and encountered a bunch of issues

<lcl___>easiest way to reproduce is to get on a FreeBSD 10.2 system and then configure with: --with-libltdl-prefix=/usr/local --with-libgmp-prefix=/usr/local --with-libunistring-prefix=/usr/local --without-threads

<lcl___>you'll then see a bunch of compiler warnings (clang 3.4 being the default $CC on such a system)

<wingo>lcl___: 32 bit or 64 bit?

<lcl___>wingo: 64-bit

<wingo>interesting

<lcl___>(sorry for the delay, am reproducing myself now)

<wingo>np

<lcl___>now; the build will get to: "GEN guile-procedures.texi"

<lcl___>and it will segfault

<lcl___>the trace is (give me a minute) :

<wingo>segfaults are bad :)

<wingo>that step is where the newly-built guile is run for the first time

<lcl___>indeed! they are bad

<lcl___>so, I get this trace:

<lcl___>Program received signal SIGSEGV, Segmentation fault.

<lcl___>0x0000000801c2dbb0 in __bsd_iconv () from /lib/libc.so.7

<lcl___>(gdb) where

<lcl___>#0 0x0000000801c2dbb0 in __bsd_iconv () from /lib/libc.so.7

<lcl___>#1 0x0000000800908475 in rpl_iconv (cd=0x24071b0, inbuf=0x0, inbytesleft=0x0, outbuf=0x0, outbytesleft=0x0) at iconv.c:448

<lcl___>#2 0x00000008009069ce in mem_cd_iconveh_internal (src=0x6c80d0 "ice-9/eval.scm", srclen=14, cd=0x24071b0, cd1=0x24071c0, cd2=0x24071d0, handler=iconveh_question_mark, extra_alloc=8, offsets=0x0, resultp=<value optimized out>, lengthp=0x1fff) at striconveh.c:412

<lcl___>#3 0x0000000800907b06 in mem_iconveh (src=0x6c80d0 "ice-9/eval.scm", srclen=14, from_codeset=<value optimized out>, to_codeset=<value optimized out>, handler=iconveh_question_mark, offsets=0x0, lengthp=<value optimized out>) at striconveh.c:1023

<lcl___>#4 0x00000008008de9fa in scm_to_stringn (str=0x6d2420, lenp=0x0, encoding=<value optimized out>, handler=SCM_FAILED_CONVERSION_QUESTION_MARK) at strings.c:2241

<lcl___>#5 0x00000008008903df in search_path (path=0x6d0450, filename=0x6d2420, extensions=0x304, require_exts=0x4, stat_buf=0x7fffffffe690) at load.c:570

<lcl___>#6 0x00000008008910a2 in scm_init_eval_in_scheme () at load.c:1093

<lcl___>#7 0x00000008008882aa in scm_i_init_guile (base=<value optimized out>) at init.c:506

<lcl___>#8 0x00000008008e6a73 in with_guile_and_parent (base=0x7fffffffe7a8, data=0x7fffffffe7d8) at threads.c:713

<lcl___>#9 0x0000000800b73f1b in GC_call_with_stack_base () from /usr/local/lib/libgc.so.1

<lcl___>#10 0x00000008008e489b in scm_with_guile (func=0x24071b0, data=<value optimized out>) at threads.c:829

<lcl___>#11 0x0000000800887ed5 in scm_boot_guile (argc=1, argv=0x7fffffffe8d0, closure=0x0) at init.c:321

<lcl___>#12 0x0000000000400bea in main (argc=1, argv=0x7fffffffe8d0) at guile.c:101

<lcl___>now, this problem disappears

<lcl___>if I get rid of the "rpl_" stuff

<wingo>the rpl_* is from gnulib

<lcl___>and make iconv()/iconv_open()/iconv_close() calls actually go right through to the libc iconv functions

<wingo>i tried to update gnulib before releasing but there were unrelated failures

<lcl___>ah

<lcl___>is gnulib still maintained?

<wingo>yes, fairly actively afaiu

<lcl___>okay

<lcl___>well, just FYI, one of the (many) clang warnings is:

<wingo>it could be that we require gnu iconv. but i don't know. this failure rings a bell but a segfault is a pretty bad failure mechanism

<lcl___>iconv_open.c:111:18: warning: implicit declaration of function 'iconv_open' is invalid in C99

<lcl___>*nod*

<wingo>perhaps civodul remembers

<lcl___>okay, well, i'll try to investigate that a bit more (update gnulib maybe)

<lcl___>there's a "workaround" here, I *think*, which is: build with GCC

<lcl___>...give me a minute

<lcl___>;)

<wingo>:)

<wingo>this doesn't sound like a clang/gcc issue fwiw

<lcl___>yes, I agree

<lcl___>well

<lcl___>in that multiple versions of clang behave in the same way

<lcl___>(including the latest release)

<lcl___>however, if I build with GCC...

<lcl___>(while waiting: I suspect clang is just being strict, and there is a genuine issue with gnulib)

<wingo>one thing to check: was your libunistring built with iconv support?

<lcl___>i don't know if clang has a 'pretend to be GCC' mode on freebsd, maybe it does

<wingo>at least it used to be the case that somehow this was optional

<wingo>and it could cause freebsd compilation errors

<lcl___>interesting - any idea how I would check?

<lcl___>(I know nothing about iconv/libunistring to be honest)

<wingo>e.g. http://thread.gmane.org/gmane.lisp.guile.bugs/5381/focus=5496

<lcl___>thanks!

<lcl___>umm

<lcl___>ok, so my build with GCC 4.8 (which just happened to be installed) is going

<lcl___>that 'GEN' appears to complete, and now I see:

<lcl___>BOOTSTRAP GUILEC ice-9/eval.go

<lcl___>it stays there for nearly two minutes

<lcl___>and then I see:

<wingo>so after that point comes the wait

<lcl___>yep

<lcl___>hang on, waiting ;) )

<wingo>it takes a ridiculously long time

<lcl___>oh that's good to know

<wingo>it's building the compiler while it's compiling the compiler etc

<lcl___>ok :)

<lcl___>any minute now

<lcl___>yep, here we go: (spam warning)

<wingo>assuming you kicked it off with -j4 or something, expect about 3 minutes for eval.go, 20 for the next file, then things parallelize and it will take another 40 minutes

<lcl___> BOOTSTRAP GUILEC ice-9/eval.go

<lcl___>Backtrace:

<lcl___>In unknown file:

<lcl___> ?: 19 [primitive-load-path "language/cps/utils" #<boot-closure 1d9dba0 ()>]

<lcl___> ?: 18 [primitive-eval (define-module (language cps utils) #:use-module ...)]

<lcl___> ?: 17 [apply-smob/1 #<boot-closure af6300 (_)> (define-module # #:use-module ...)]

<lcl___> ?: 16 [primitive-eval #]

<lcl___> ?: 15 [apply-smob/1 #<boot-closure 2a92f60 ()>]

<lcl___> ?: 14 [apply-smob/1 #<boot-closure 2a92e40 ()>]

<lcl___> ?: 13 [apply-smob/1 #<boot-closure 2a92dc0 ()>]

<lcl___> ?: 12 [apply-smob/1 #<boot-closure 2a921c0 ()>]

<lcl___> ?: 11 [primitive-load-path "language/cps/intmap" #<boot-closure 2a92140 ()>]

<lcl___> ?: 10 [primitive-eval (define-module (language cps intmap) #:use-module ...)]

<lcl___> ?: 9 [apply-smob/1 #<boot-closure af6300 (_)> (define-module # #:use-module ...)]

<wingo>ACTION waits as the flood comes through

<lcl___> ?: 8 [primitive-eval #]

<lcl___> ?: 7 [apply-smob/1 #<boot-closure 262ff60 ()>]

<lcl___> ?: 6 [apply-smob/1 #<boot-closure 262fe40 ()>]

<lcl___> ?: 5 [apply-smob/1 #<boot-closure 262fdc0 ()>]

<lcl___> ?: 4 [apply-smob/1 #<boot-closure 262f020 ()>]

<lcl___> ?: 3 [primitive-load-path "srfi/srfi-18" #<boot-closure 264bfa0 ()>]

<lcl___> ?: 2 [primitive-eval (if # #)]

<lcl___> ?: 1 [scm-error misc-error #f ...]

<lcl___> ?: 0 [apply-smob/1 #<boot-closure cd8760 (_ . _)> misc-error ...]

<lcl___>ERROR: Makefile:1892: recipe for target 'ice-9/eval.go' failed

<lcl___>so, just to clarify: I get that backtrace if I build with GCC4.8

<lcl___>*or* clang (3.4+) so long as I zap the "rpl_" iconv stuff

<wingo>oook

<wingo>so srfi-18 is the date/time library. it relies on some locale-related facilities from the host.

<lcl___>aha.

<wingo>just to check, have you been able to build a 2.0 guile?

<lcl___>I haven't tried!

<wingo>ah i lie!

<wingo>srfi-18 is the thread library

<lcl___>brb, phone

<wingo>soooo

<wingo>interesting.

<wingo>maybe you built without threads and that carps? there is something in that file that wants the value of (current-thread)... hum

<wingo>for the purposes of that file, returning #f for (current-thread) would be acceptable

<wingo>and indeed, loading srfi-18 without threading support will throw. hum.

<wingo>lcl___: if you are up for it, just remove the line from intmap.scm that says

<wingo> #:use-module (srfi srfi-18)

<lcl___>sorry, back

<wingo>because the binding that module needs, `current-thread', is actually provided by the (guile) as well

<wingo>but i will fix it too

<wingo>thank you for the report :)

<lcl___>ok, removed that line

<wingo>godspeed ;)

<lcl___>...waiting :)

<wingo>dogslow ;)

<lcl___>(oh, you've probably guessed but building with --with-threads doesn't work)

<lcl___>there it's a silly issue, on freebsd the thread-capable boehm GC library has a different name

<lcl___>it's -lgc_threaded or something

<lcl___>libgc-threaded.so

<lcl___>I *assume* that if the configure script knew or could be taught that, the linker errors (can't find GC_blah_blah()) would go away

<lcl___>ok

<lcl___>I hereby declare your fix successful!

<lcl___>it has been sitting here for 3.5 minutes already

<lcl___>thanks, wingo! :)

<lcl___>wrote `ice-9/eval.go'

<lcl___>:)

<wingo>and now, ignore the build process for an hour or so :)

<wingo>i have a blog post pending about why things are so slow and things to make it faster, but we should also probably print out a message warning people about what's happening :)

<lcl___>*nod*

<lcl___>well, thanks in advance for fixing that srfi-18 thing

<wingo>np, thanks for the report. happy hacking :)

<lcl___>thanks! i have to run away now, but i'll be back (tm)

<wingo>i'll give a go building guile with clang sometime

<lcl___>yep, the warnings should be informative. but probably to the gnulib folk as much as to you :(

<lcl___>have fun too :)

<lcl___>*waves*

<rjmacready>hey

<rjmacready>i wanted to use guile as a scripting language for a c++ command line application

<rjmacready>i was wondering if anyone can point to resources beyond http://www.gnu.org/software/guile/docs/guile-tut/tutorial.html

<rjmacready>or if there's some application i can look up to

<alezost>rjmacready: I think the main resource is the guile manual (I'm not competent though :-))

<rjmacready>alezost: hmm so i guess all functions under section 6 ("API Reference") of http://www.gnu.org/software/guile/manual/guile.pdf are exposed by libguile.h ?

<rjmacready>scm_with_guile shows up there

<davexunit>the manual documents which procedures have C variants

<rjmacready>ACTION scrolls through the manual

<alezost>yes, there are many "scm_*" procedures all over the manual

<rjmacready>hmm, so i assume that if i want to load a file, i have to run scm_c_primitive_load( ...filename... )

<rjmacready>very nice

<rjmacready>does anybody have any fancy setup for developing in scheme? other than straight emacs / vi / whatever?

<davexunit>rjmacready: Emacs + Geiser + Paredit

<davexunit>that setup really unlocks the awesome

<davexunit> http://geiser.nongnu.org provides the bridge between Emacs and Guile

<rjmacready>gotta check that out

<rjmacready>i have some experience with emacs + slime + sbcl

<davexunit>Geiser is our SLIME

<paroneayea>rjmacready: yeah geiser is a lot like slime for scheme

<paroneayea>rjmacready: also add company-mode onto what davexunit recommended for nice autocomplete :)

<davexunit>geiser does completion

<paroneayea>autocomplete is less immediately needed than the other things, but super nice :)

<paroneayea>davexunit: ah right, it does... just not as fancily

<davexunit>does company integrate with geiser somehow?

<paroneayea>davexunit: sure does

<davexunit>otherwise i don't know how it could possibly know what Scheme symbols are available

<rjmacready>hmm thx

<paroneayea>davexunit: geiser-company-backend

<davexunit>paroneayea: oh cool, I thought it was just one of those "complete things that you've typed before" things

<paroneayea>is what you want

<paroneayea>nope

<davexunit>paroneayea: awesome

<paroneayea>davexunit: it peers into guile itself!

<davexunit>didn't realize it was real completion

<paroneayea>yeah

<paroneayea>it's a delicious feature

<davexunit>that's how completion should be done!

<davexunit>no ctags/etags/whatever

<paroneayea>davexunit: right

<davexunit>amazing how many things become easier with a running system to talk to

<paroneayea>rjmacready: I'll argue that once you start using guile + geiser, the main problem you'll have is that you might have to go back to using some other language, and it's just not as nice as an environment :)

<davexunit>"hey Scheme environment, what things begin with 'foo'?"

<paroneayea>rjmacready: I say as a person who does a lot of python (and runs a big python project!)

<paroneayea>davexunit: yes

<rjmacready>paroneayea: ahah :)

<davexunit>paroneayea is right. I've become a spoiled, bitter Geiser user.

<paroneayea>davexunit: I think maybe I should build a whole second tutorial for guile which is how to get the optimal guile + emacs setup :)

<paroneayea>(obviously it does not belong in the main tutorial)

<paroneayea>ACTION tacks that on top of the teetering pile of projects on his plate

<paroneayea>"what's one more"

<davexunit>hahaha

<davexunit>paroneayea: that would be good though for more experienced users

<davexunit>a "here's to unlock all the awesome" tutorial

<paroneayea>hey wingo, I had an email exchange with Jonathan Rees, and he said that the W7 security kernel had "barely anything to it" but that he'd release it publicly anyway, and here it is: https://github.com/jar398/w7

<rjmacready>also, silly question, does anybody uses guile for web applications?

<davexunit>yes

<davexunit>for example, in the GNU Guix project, we have a small application called 'guix publish' that is a guile web server

<davexunit>I'm working on an implementation of the WebSocket protocol for Guile https://git.dthompson.us/guile-websocket.git

<davexunit>web programming with Guile is nice, just needs more bells and whistles

<rjmacready>ah nice

<rjmacready>websockets would be nice

<paroneayea>davexunit: a friend of mine recently said they use the web interface regularly

<paroneayea>so apparently its being put to good use!

<paroneayea>davexunit: it's not merged into guix yet I think right?

<wingo>paroneayea: nice!

<davexunit>paroneayea: wait, my guix web UI?

<davexunit>or Guile's web API?

<davexunit>ACTION is confused

<wingo>nice re: jar's w7

<paroneayea>davexunit: guix's

<davexunit>paroneayea: I had no idea that people other than rekado used that

<davexunit>it's only useful for searching things at the moment

<davexunit>I haven't hacked on it in months

<paroneayea>:)

<davexunit>phew, finished up assigning Scheme symbols to SDL2's keycode and scancode constants.

<davexunit>that was one of the most tedious things I've done in awhile

<davexunit> https://git.dthompson.us/guile-sdl2.git/commitdiff/2751b1a7380d52ff14e1cd50eac8f042252a02ac

<paroneayea>davexunit: oh excellent

<paroneayea>davexunit: holy damn, that file

<davexunit>yup

<davexunit>craziness!

<davexunit>but I'm past it!

<davexunit>not too many more events to wrap before I've covered all of what Sly uses.

<davexunit>then I just need to wrap a handful of things from SDL_ttf, SDL_mixer, and SDL_image and I'm ready to rock.

<davexunit>I'll release version 0.1 and request patches to add more stuff.

<nalaginrut>davexunit: nice done!

<davexunit>thanks nalaginrut

<davexunit>do you have any use for SDL2 bindings?

<davexunit>:)

<nalaginrut>I was, but now we have sly huh?

<davexunit>sure, but there's other uses :)

<nalaginrut>I always want to use SDL for games, but we have game engine now

<nalaginrut>;-)

<davexunit>I'm just curious because I hope to recruit more helpers

<nalaginrut>I hope I can help, but I spend much time on Artanis and compilers...alas, maybe we need more people ;-P

<davexunit>it's OK if you can't :)

<davexunit>we all have many projects

<davexunit>just hoping to eventually not be the only one maintaining some of this stuff :)

<davexunit>if you build it... they will come?

<nalaginrut>I think documents are important, especially some "internal document" to help people know your design and the principle, or they can hardly help

<davexunit>yes

<davexunit>guile-sdl2 0.1 will not have a manual, but subsequent releases will.

<nalaginrut>besides, we need more posts to help people learn Guile

<davexunit>that too

<nalaginrut>read the manual is the most important way, but not the interesting way

<nalaginrut>inotify works, Artanis will have file monitoring to load modules automatically in debug-mode

<nalaginrut>ACTION go to sleep

<nalaginrut>zzzZZZ

<davexunit>isn't this what a REPL is for?

<paroneayea> https://www.fsf.org/blogs/community/fsf-announces-support-for-gnu-guix

<paroneayea>posted!

<civodul>thanks, paroneayea!

<rjmacready>is it normal for scm_call_* to crash if it's called in the not-main thread?

<rjmacready>crash with segmentation fault

<rjmacready>ah the chapter 5.4.5 seems to imply that any thread that wants to call guile needs to run one of the initialization functions

IRC channel logs

2015-12-16.log