IRC channel logs

2013-10-11.log

back to list of logs

<nalaginrut>morning guilers~
<civodul>Hello Guilers!
<sneek>civodul, you have 1 message.
<sneek>civodul, nalaginrut says: I tried the latest stable-2.0, then 'interrupt system call' bug is gone, but I found the handler called delayed
<civodul>nalaginrut: delayed?
<mark_weaver>delayed until the system call finished, I expect
<civodul>ah, right
<civodul>well, no
<civodul>there's an SCM_ASYNC_TICK in there
<mark_weaver>the problem is that signal delivery is mediated by another thread, and that other thread doesn't reliably queue the async before the system call is restarted.
<mark_weaver>I think perhaps the right fix is to get rid of the signal thread entirely, and instead arrange for signals to be delivered directly to the thread that the user asked them to be delivered to.
<mark_weaver>and queue the async directly from the signal handler.
<mark_weaver>it would of course require careful handling of the async queues.
<civodul>argggh
<civodul>what a tricky topic :-)
<civodul>that rings a bell, indeed
<nalaginrut>civodul mark_weaver thanks for reply ;-)
<lloda`>hello there
<nalaginrut>heya
<lloda`>I rebased my array patches on master recently, make check ran without issues. Perhaps I could ask again to have them reviewed?
<lloda`>hi nalaginrut
<nalaginrut>heya
<nalaginrut>oops
<lloda`>not a sexy subject I know...
<taylanub>Out of curiosity: what would be the best way to generate a unique identifier anywhere in the code, which remains identical between repeated passes through that code ? Akin to { static foo_t foo; /* use &foo here as a token */ } in C.
<lloda`>I'm thinking of __COUNTER__, but if it must be identical between passes, maybe __LINE__?
<taylanub>I meant to ask about Scheme/Guile.
<lloda`>oh sorry
<wingo>ahoi
<lloda`>hello wingo, could you guys have a look at my array patches? I did rebase again on top of master and there were no conflicts. The first rebase was http://lists.gnu.org/archive/html/guile-devel/2013-05/msg00037.html
<wingo>sure
<wingo>will take me a few days to get to it, it seems
<wingo>lloda`: ok if I take a look next week?
<lloda`>no particular hurry, just a reminder :)
<wingo>please keep reminding me :)
<wingo>i have more time now, starting from this week, and given my preferences i usually spend it on the compiler -- but other things are important too, so thanks for keeping them in my mind :)
<lloda`>np
<gzg>So is "guile-wm" currently usable at all?
*jaimef ponders the complete lack of guile2 support in macports, pkgsrc, home brew
<mark_weaver>guile 2 is in homebrew, but you need to pass --devel (or something like that)
<jaimef>oh?
<davexunit>yeah use homebrew
<davexunit>brew install --devel guile
<jaimef>thanks. did not come up in search list
<jaimef>gotcha thanks
<mark_weaver> https://github.com/mxcl/homebrew/blob/master/Library/Formula/guile.rb
<wingo>hey mark_weaver
<wingo>greets
<mark_weaver>hi wingo! you've been doing some nice hacking on the compiler, I see!
<wingo>i wonder, could i see your SCC code?
<wingo>tx :)
<wingo>getting close to fixing the loop compilation bug :)
<wingo>the dead-after-use? proc doesn't do the right thing for variables that flow into loops
<wingo>likewise for dead-after-branch?
<wingo>but fixing that means more analysis :)
<mark_weaver>wingo: my SCC code is here: http://www.netris.org/~mhw/strongly-connected.scm
<wingo>mark_weaver: tx
*mark_weaver is currently bootstrapping Guix for MIPS N32 (on his YeeLoong)
<wingo>whee
<wingo>sounds like fun :)
<wingo>many of those old tarjan papers are only under paywall, unfortunately
<mark_weaver>yeah, it's a drag
<mark_weaver>sorry the code isn't very nice to look at, but it handles large graphs efficiently.
<wingo>np
<mark_weaver>(I had to hack in an explicit stack to prevent stack overflows on large graphs)
<wingo>i am currently trying to implement "Identifying loops using DJ graphs"
<wingo>boo stack overflow :(
<wingo>i had to implement this once at work but i have completely forgotten how
<wingo>nothing like graph theory to humble a hacker
<mark_weaver>hehe
<wingo>at least, until it works ;)
<wingo>it's pretty easy to make irreducible cfg's in scheme
<jaimef>undefined ref to scm_new_smob, from return scm_new_smob (lisp_vectorlike_tag, (scm_t_bits) p);
<mark_weaver>jaimef: are you sure you linked to libguile?
<mark_weaver>jaimef: if you have trouble, it might be worth trying to use the same compiler that was used to compile libguile.
<jaimef>not finding a def for that in any of the headers
<mark_weaver>it's defined in libguile/smob.h
<jaimef>hmm mine lacks it
<jaimef>must be newer than 2.0.5
<mark_weaver>jaimef: what's the copyright date at the top of libguile/smob.h?
<mark_weaver>(the most recent one, that is)
<jaimef>2011
<jaimef>guile-dev 2.0.5+1-1 latest ubuntu...
<mark_weaver>jaimef: ah yes, scm_new_smob was added in 2.0.6
<mark_weaver>if you need to support older versions, use SCM_NEWSMOB
<jaimef>nope, no need for older versions
<jaimef>must say, getting guile from git to build, or finding a more recent package for the most popular distro is a real pita
<add^_>jaimef: eh?
<mark_weaver>jaimef: it's easier to start with a tarball
<add^_>Which version on git?
<add^_>And which os? (I remember having more problems on OS X than on GNU/Linux..)
<mark_weaver>jaimef: on Debian-derived distros, just do 'apt-get build-dep guile-2.0' to get everything you need and then compile the tarball.
<add^_>Maybe it's easier nowdays..
<mark_weaver>libgc-7.2d is a good idea as well. the version in Debian wheezy is quite old
<mark_weaver>but I think Ubuntu already has that.
<mark_weaver>also note that Debian testing (jessie) has guile-2.0.9
<mark_weaver>jaimef: Ubuntu raring has Guile 2.0.7
<jaimef>linux/ubuntu
<mark_weaver>and saucy has 2.0.9
<jaimef>oh well thanks
<add^_>Uh, I wonder, if I do `C-c C-k´ in emacs with geiser and have a record there, what happens when I have a "define-record-type" in that file? Am I missing something here?
<ijp>hmm, didn't know about C-c C-k
<add^_>Well
<add^_>It breaks it
<ijp>add^_: what do you mean "breaks"
<ijp>if you mean old records do not reflect the new definition, you are correct
<add^_>If I evaluate the code with C-x C-e it works normally
<add^_>Example record
<add^_>(define-record-type <test> (make-test test) test? (test get-test))
<ijp>what did you type, what happened, what did you expect
<add^_>(define sigh (make-test 1))
<add^_>(test? sigh)
<add^_>error
<add^_>after running C-c C-k ofcource
<ijp>define-record-type isn't in the default environment, you know
<add^_>No
<add^_>It's with srfi-9
<add^_>I just forgot to write that here
<ijp>works for me
<add^_>However, if I had run C-x C-e it would have worked..
<add^_>Really?
*add^_ scraches his head
<ijp>well, define worked
<ijp>it certainly compiles the file just fine
<add^_>Well that's not the part that fails
<ijp>_what_ fails
<add^_>It fails when running (test? sigh)
<ijp>oh that, that's pebkac
<add^_>:-/
<ijp>the file is compiled, not loaded
<add^_>Eh?
<ijp>you compiled the file
<add^_>But if I run C-x C-e and then C-c C-k it still breaks
<ijp>compiling a file is not the same thing as loading it
<add^_>Even though C-x C-e fixes it, C-c C-k breaks it again?
*add^_ is confused
<add^_>I need to look up the geiser thingy...
<ijp>you're not giving me anything to go on
<add^_>"C-c C-k geiser-compile-current-buffer Compile and load current file"
<add^_>So it should load it...
<add^_> http://www.nongnu.org/geiser/geiser_5.html#Cheat-sheet
<ijp>and it works for me
<ijp>imagine I'm a complete idiot; give me step by step instructions saying what you expected and how what you got differs
<add^_>I'm writing it on paste.lisp
<add^_> http://paste.lisp.org/display/139395
<add^_>Actually, I needed to evaluate the last part too.. Hmm..
<add^_>So I guess your right in a way, it's not properly loading the changes?
<add^_>Or something
<ijp>I don't get that error
<ijp>and because of that, the reevaluation makes (test? sigh) fail, as I'd expect
<add^_>Hum
<ijp>because sigh was created before the record type was
<add^_>Ah
<add^_>Uh
<ijp>maybe goops can do the upgrade, but dunno
<ijp>add^_: by fails, I meant returns #f
<add^_>Maybe it's a bug in the version of guile I use, that is fixed in yours?
<ijp>or geiser
<add^_>Maybe
<add^_>I dunno
<add^_>Well, this was confusing at the very least.
<add^_>What's your guile version?
<ijp>the literal version isn't going to help you much
<ijp>but suffice to more recent than 2.0.9
<ijp>to say*
<add^_>..
<add^_>Oh well
<ijp>geiser 0.4
<add^_>Same as me.. 32 bit? 64 bit?
<ijp>32 bit
<add^_>Probably doesn't matter.
<add^_>Same as me
<add^_>argh
<ijp>do you have two geiser repls open?
<add^_>no
<ijp>and did you try with a _fresh_ repl
<add^_>I'm running guile with --listen though
<add^_>hm
<add^_>I'll try
<add^_>same error
<add^_>It might be pebkac I suppose :-/
<add^_>Well, at the very least, it doesn't load the record functions. But the other stuff is loaded fine, but when that is that way, it fails because like you said, the records isn't loaded..
<add^_>Gosh, I don't know anymore. I'll just shut up and try to keep the peace in here..
<Ankhers>Can anyone tell me what exactly 'guild: unknown script "/path/to/script"' means? The path is proper to a script.
<ijp>what exactly did you type?
<ijp>because I expect you did "guild /path/to/script"
<Ankhers>apparently a giant type.
<Ankhers>indeirrectly, yes.
<Ankhers>indirectly even
<ijp>the second argument to guild is the command to execute, like in git, etc.
<Ankhers>I apologize for my stupidity. Thanks for the help.
<ijp>so if you want to compile foo.scm it is "guild compile foo.scm"
<Ankhers>Follow up question. Is anyone familiar with org-mode from emacs?
<ijp>sort of, whyu
<Ankhers>specifically around code block execution
<ijp>just say what is actually bothering you :)
<Ankhers>I am wondering if the session header is compatible with guile. I am having issues with it.
<ijp>I'd use scheme, not guile
<ijp>sorry, session header
<Ankhers>I apologize, I don't understand what you meant.
<ijp>Ankhers: mixup, ignore it
<Ankhers>oh, okay.
<dsmith>Ankhers, I use org-mode, but not code blocks, sorry