IRC channel logs

2014-08-26.log

back to list of logs

<nalaginrut>morning guilers~
<nalaginrut>wow, 80 people here, maybe the highest record
***Lajjla is now known as Ahli[DE]
<Ahli[DE]>nalaginrut, hi.
<Ahli[DE]>I can't sleep.
<Ahli[DE]>How good are your lullaby's.
<nalaginrut>hmm...bot?
<Ahli[DE]>This is the second time you asked me that.
<Ahli[DE]>You are quite suspicious.
<Ahli[DE]>I don't think Alan Turing had foreseen human beings not passing the turing test.
<nalaginrut>the second time? why you change your id frequently?
<nalaginrut>I didn't realize it's you
<Ahli[DE]>nalaginrut, people have asked me that a lot, and truth be told, I don'tknow really why I should keep it, I just change it to whatever I think is funny at the time.
<Ahli[DE]>I have the feeling that most people come to see their "name" as part of themselves and I never did really.
<Ahli[DE]>That'sall.
<nalaginrut>if name could be changed without any concern, why we use name, we just need uid. And we don't have to remember it
<Ahli[DE]>Probably because the protocol allows it.
<Ahli[DE]>It's just a funny field you can set for me.
<Ahli[DE]>I sort of see it as a signature on a forum I guess or an avatar.
<Ahli[DE]>Something you can change at any point to whatever you think is funny.
<Ahli[DE]>But I must admit, I've acquired some ire over it. Someone on this network even admitted that he or she thoroughly dislikes me but came to the conclusion that pretty much the only reason for that is my lack of a fixed nickname which is apparently perceived as extremely frustrating.
<dje42>Looks like I need all libgc threads and all guile internal threads (e.g. the finalizer thread) to block SIGCHLD.
<sneek>Welcome back dje42, you have 1 message.
<sneek>dje42, ijp says: remove unbound-variable from the #:warnings option in %auto-compilation-options
<dje42>Not sure how to do it in a way that would be approved.
***Ahli[DE] is now known as libquebec-dev
<taylanub>sneek: later tell bipt in the latest wip commit of your guile repo, `eval-tree-il' is missing in module/language/tree-il/eval.scm. (I just defined it to (lambda (x) (eval1 x '())) and it seems to work; you'd know if that's correct.)
<sneek>Got it.
<taylanub>wow, I'm very far into the emacs compilation now (guile compiled with that one trivial fix)
<taylanub>and this is on OS X (though using GCC 4.9 and some other things from MacPorts)
***Guest75588 is now known as micro
<taylanub>sneek: later tell bipt also, module/language/elisp/runtime.scm misses #:use-module (language tree-il eval)
<sneek>Will do.
<taylanub>hm, building emacs still takes eons
<taylanub>so emacs built but apparently the .el files aren't compiled, thus startup still takes long, there's a huge performance regression, and it even segfaulted while opening a file, though I'm on OS X and built half of the C code with GCC 4.2 (until I hit a file that relied on some modern GCC extensions)
<davexunit>taylanub: bipt noted that elisp on guile is currently much slower than the current elisp interpreter due to issues with dynamic scoping.
<taylanub>I'm probably suffering from uncompiled elisp on top of that. if I got it right it should compile the .el files to .go?
<taylanub>I also tried 'guild compile -f elisp foo.el' on some file but an (eval-when-compile (require ...)) made it fail
<davexunit>I dunno. not sure what crazy things need to be done in order for things to work. I know that you need a special version of guile.
<taylanub>oh I have that one, it built with only two minor issues
<taylanub>(even on OS X)
<davexunit>nice
<taylanub>(and with GCC 4.2 I think)
<davexunit>would be cool to make guix packages for that version of guile and emacs for testing purposes.
<taylanub>they're in kinda dirty states, would probably need a little more cleanup before it becomes worth to test them more publictly
<dsmith-work>taylanub: Ah! You have bipt's repos compiling. Cool.
<taylanub>yup, after the latest commits (there were some new ones)
<lloda>hey taylanub, Guile builds for me on OS X using GNU gcc only (4.8 last time I did it). I wonder if mixing compilers might be trouble, especially one as old as gcc 4.2.
<taylanub>lloda: I touched all .c files and re-ran make && make install, still get a segfault when I open a file buffer
<taylanub>building it on Debian with GCC 4.7 from stable now
<taylanub>might require .8+, will see
<taylanub>weird, had to set LD_LIBRARY_PATH myself for the bootstrap-emacs to find libguile2.2, during make
<taylanub>(it's in $LIBRARY_PATH and ./configure and all seem to have found it without issues)
<lloda>here's my compile line http://paste.lisp.org/display/143512
<lloda>no particular options, but I compiled libgc from source, and libgmp, libunistring, and libiconv from macports.
<taylanub>I didn't need any special flags. hm, didn't run tests btw
***sethalve_ is now known as sethalves
<taylanub>neat, on Debian I don't get segfaults when opening file buffers :P
<taylanub>(compiled fine with GCC 4.7 from Debian stable by the way)
<dsmith-work>taylanub: Always a good thing
<tub>rcirc running fine on Guile-Emacs :)
<davexunit>:D
<dsmith-work>tub: Cool!
<dsmith-work>taylanub: Got a list of the things you needed to do to get guile-emacs working?
<taylanub>dsmith-work: for Guile, '#:use-module (language tree-il eval)' in module/language/elisp/runtime.scm, and "(define (eval-tree-il x) (eval1 x '()))" in module/language/tree-il/eval.scm
<taylanub>then it should compile fine, given you have libgc 7.4.2 and the other usual dependencies
<taylanub>for Emacs, just a lot of re-runs of make with -k :P
<dsmith-work>heh
<taylanub>oh and a recent GCC for that one. though 4.7 seems to be enough
<dsmith-work>I've gcc 4.7.2
<dsmith-work>I can't remember at all what libgc I'm running. Debian I thing
<taylanub>AFAIK it needs to be the latest release, 7.4.2. I just compiled that myself.