IRC channel logs

<quotemstr>You guys mark the stack conservatively during GC, right?

<mark_weaver>yes, although I think that on the master branch the VM stack is marked precisely.

<quotemstr>I'm trying to work on an Emacs GC bug, and I want to understand how you guys do it.

<quotemstr>Our encoded values are longs, and we walk the stack in four-byte jumps.

<quotemstr>Is that adequate, or do you need to walk byte-by-byte in case the compiler decides to store unaligned values?

<quotemstr>How are you precisely marking the stack?

<mark_weaver>mostly we use the bdwgc for garbage collection. that's what handles almost all the GC tasks.

<mark_weaver>as for the precise marking of the VM stack, I don't know the details -- wingo did that work -- but no doubt it involves the compiler making a map of each stack frame.

<mark_weaver>I would think that on common platforms, you can assume that pointers on the stack will be aligned on 4-byte boundaries.

<mark_weaver>intel processors handle unaligned accesses gracefully, but they are slower, so compilers generally arrange to keep pointers aligned.

<quotemstr>Odd thing is, all the crashes we've observed has been with -O0, so maybe it's a *failure* to align some pointer placement that's the problem.

<quotemstr>Anyway, thanks.

<quotemstr>s/align some pointer placement/optimize for alignment/

<mark_weaver>I'd be very surprised if pointers end up unaligned with -O0.

***linas_ is now known as linas

<nalaginrut>morning guilers~

***linas__ is now known as linas

<nalaginrut>/usr/include/gc/gc.h:1086:20: note: previous declaration of 'GC_move_disappearing_link' was here

<nalaginrut>I have updated gc from git, it's the latest

<nalaginrut>and this error occurred when compiling master

<nalaginrut>any idea?

*nalaginrut treat himself too cutting-edge...

<mark_weaver>nalaginrut: it sounds like possibly you've updated your libgc since you last ran ./configure. maybe you should run ./configure again.

*nalaginrut is trying...

<nalaginrut>mark_weaver: *.lo compiling passed, I think it's solved now, thx ;-)

<mark_weaver>np!

<nalaginrut>btw, I found there's a segfault bug in master when I tried to load a module

<nalaginrut>but I haven't figured it out clearly

<nalaginrut>I don't have time on debugging it, since I'm hacking another thing.

<nalaginrut>maybe later

<mark_weaver>wingo has been doing some major hacking on the compiler recently, and mentioned earlier that some bugs have been introduced.

<nalaginrut>mark_weaver: I see. Anyway, I know how to avoid this bug at present, so it won't effect my hacking. Then I let it go

<nalaginrut>I think there's no chance for Scheme to win Code Golf since the naming in Scheme is too long, so the program can hardly be reduced to few bytes. ;-(

*nalaginrut hate this rule

<nalaginrut>if it allow redefine the name of primitives, I think there's a chance ;-)

<civodul>Hello Guilers!

<nalaginrut>heay

<nalaginrut>heya

<jmd>What's the bitwise or operator in scheme?

<wingo_>i don't think scheme has one

<wingo_>guile has logxor and logior

<wingo_>corresponding to ^ and |

<wingo_>i guess r6rs defines some...

***wingo_ is now known as wingo

<jmd>ok thanks.

*taylanub is trying out 2.0.11 on OS X 10.9 in developer mode with Xcode 5.1 now.

<taylanub>hrm, http://sprunge.us/PLGI

<nalaginrut> https://www.crowdsupply.com/kosagi/novena-open-laptop

*taylanub tries -O0 for vm.c

<taylanub>Hrm, what's the best way to arrange for that to happen ? To add a flag for a certain file.

<wingo>whee, i have a cse pass that works on cps

<wingo>it turns (+ (+ a a) (+ a a)) into (let ((b (+ a a))) (+ b b))

<wingo>taylanub: touch libguile/vm.c; make CFLAGS='-g -O0'

<civodul>wingo: so that's a new one?

<taylanub>wingo: AIUI that causes other files to also get compiled with -O0, but I guess that's fine.

<taylanub>with -O0 it built; make check failures:

<taylanub>FAIL: srfi-18.test: thread-terminate!: termination destroys non-started thread

<taylanub>FAIL: srfi-18.test: thread-terminate!: termination destroys started thread

<wingo>civodul: yeah, the (+ a a) wouldn't get deduplicated with the tree-il CPS pass because it had no name

<wingo>s/CPS/CSE/

<wingo>whereas with CPS it does have a name

<wingo>i'm hoping the cps-based cse pass is much faster as well

<wingo>currently cse is the most costly pass on large files

<civodul>ok, sounds cool

<davexunit>is it possible to change the stack frame of the debugger? not sure I'm using the correct language here, but today I used a cool ruby/rails feature that allowed me to pick an arbitrary stack frame while I was at the debugging REPL.

<mark_weaver>davexunit: do you mean like ,up and ,down ?

<davexunit>mark_weaver: that sounds promising. I'll check it out.

<mark_weaver>gdb also has 'up' and 'down' for that sort of thing.

<mark_weaver>wingo: ooh, that improved CSE sounds nice :)

<davexunit>mark_weaver: that's exactly it. thank you!

<mark_weaver>np!

<davexunit>speaking of debugging, I'm wrestling with how to handle exceptions that occur within guile-2d's main loop. when working at the REPL, a user could define a procedure that evaluates without error, but when called throws an error. when that procedure is to be called by the game loop, the program crashes and the user has to restart. it really kills the live coding flow.

<mark_weaver>hmm.

<davexunit>I don't know the best way to allow for debugging when this happens. there's no way to somehow push the debugging to a remote REPL. it seems the best job I can do is use call-with-error handling and leave them at a debugging REPL in whatever terminal they started the program from.

<davexunit>but that's inconvenient because it breaks your emacs flow and its harder to go and fix the actual problem without geiser.

<mark_weaver>well, you could redirect all the 'current' ports of the main program to your remote REPL.

<davexunit>I'll take the inconvenient method over a crash, for sure, but I can't help but wonder if I could do better.

<mark_weaver>you could make some convenient procedure that sets the main 'current' ports to the current 'current' ports.

<davexunit>mark_weaver: that's true, but I don't think those ports are exposed to the outside.

<mark_weaver>I think all you have to do is queue a job in the agenda that sets them, no?

<davexunit>ah, so from the REPL I could get the current ports and set the debugging ports for the game loop.

<mark_weaver>right

<davexunit>I will have to try that.

<mark_weaver>something like (let ((repl-port (current-input-port))) (queue-this-to-be-run (lambda () (set-current-input-port repl-port))))

<mark_weaver>filling in 'queue-this-to-be-run' for whatever it should be, and doing the same for the other ports.

<davexunit>cool. an additional step after that would be to make it happen automagically when the REPL is used.

<mark_weaver>sure, though you might consider what should happen when you have more than one repl.

<davexunit>yeah, maybe it's not worth doing because of that.

<davexunit>the user can simply call the procedure to say "this is my current REPL, send all input/output here"

<davexunit>thanks for helping me work this out, mark_weaver.

<mark_weaver>davexunit: I can see one complication: the standard 'call-with-error-handling' saves a copy of the 'current-ports' when it is called, and restores them on error.

<davexunit>hmm, okay. I'll keep that in mind when I go to work on it.

<mark_weaver>for now, you could make a customized copy of that module, and modify it so those 'saved' ports are exposed and externally modifiable.

<davexunit>yeah.

<mark_weaver>not ideal, but workable for now. maybe we should expose a new API for that in a 2.0.12.

<davexunit>an API for configuring REPL ports?

<mark_weaver>I'm not sure what the API should look like, but it seems like it would be useful to be able to change the ports used by an existing invocation of 'call-with-error-handling' to something else after the fact, for the sake of debugging event-loop-based programs from a remote REPL.

<davexunit>would adding additional keyword args to call-with-error-handling be sufficient?

<mark_weaver>one possibility would be to store those "saved ports" not in lexicals, but rather in fluids/parameters. and then anyone within the dynamic extent of 'call-with-error-handling' would be able to set those fluids/parameters.

<mark_weaver>I guess we're trying to move to parameters, so maybe we should use those.

<davexunit>okay. so we'd need parameters for the input, output, and error ports.

<davexunit>and the procedure called by call-with-error-handling can set them if it wants to.

<mark_weaver>so then, where we currently wrap 'call-with-error-handling' with a big 'let' that saves the ports, that 'let' would be replaced by 'parameterize'.

<mark_weaver>it would parameterize the relevant parameters, maybe called something like 'current-debug-{input,output,error}-port'.

<davexunit>yeah, that sounds good.

<mark_weaver>setting their values to the 'current-{input,output,error}-port'.

<mark_weaver>we might want to add 'warning' in there too, while we're at it.

<mark_weaver>and then 'with-saved-ports' would consult the values of those parameters.

<mark_weaver>davexunit: cool. maybe at some point you could prepare a patch for stable-2.0 along these lines?

<mark_weaver>(after experimenting with them and seeing if it works well in practice)

<wingo>you can probably also turn a delimited continuation into a debugging session

<wingo>not sure if that's useful tho

<wingo>i think make-stack can take a continuation as its arg)

<mark_weaver>wingo: hmm, not sure what you mean, or how this would work, but I'm certainly open to ideas!

<mark_weaver>I confess I'm mostly ignorant of how our debugger works.

<davexunit>mark_weaver: yeah I can make that patch.

<wingo>i just mean that you can start a repl to examine a captured delimited continuation after the fact

<davexunit>and of course implement it differently per wingo's suggestions if needed. :)

<mark_weaver>wingo: ah, I see.

<mark_weaver>that would be nice :)

<mark_weaver>I think it may be somewhat orthogonal to this.

<davexunit>could I get some further explanation?

<wingo>cool, just mentally associating :)

<wingo>davexunit: if it's not possible to debug from inside the error, for whatever reason, you could save the continuation and then debug it later from some other context (like an ssh repl)

<mark_weaver>actually, this reminds me that it will probably be problematic for the debugger to try to read from the REPL's input port while the other 'reader' thread is trying to do the same.

<wingo>it wouldn't be live -- if you returned from that repl you wouldn't continue the continuation (or possibly you could, but if you could you'd debug it from the original point...)

<mark_weaver>so now I'm thinking that this approach isn't quite right.

<mark_weaver>it may be that wingo's suggestion is closer to how this should be done.

<mark_weaver>so, on error, the continuation is captured and saved in some kind of list of pending continuations to debug.

<mark_weaver>and then make some easy to way start a debugging session on that captured continuation from an existing REPL.

<mark_weaver>I don't know enough about the debugger to know how exactly this should be done, though.

<wingo>it's not that bad -- the debugger is just the repl, basically

<wingo>if the repl has associated debugging state, it's a debugger

<wingo>the associated debugging state is just the vector of frames, or something like that

<wingo>and you can make that state from a captured continuation

<mark_weaver>wingo: how would a caller to 'call-with-error-handling' arrange to capture the continuation, and how would a debugger later be run on that continuation?

<wingo>mark_weaver: arrange for the on-error handler to save the stack, and from there the protocol is yours...

<mark_weaver>wingo: save it by calling 'abort', for example?

<wingo>mark_weaver: make-stack

<wingo>see the 'debug case

<mark_weaver>wingo: ah, okay, looking at that code helps make it clearer, thanks!

<mark_weaver>although it occurs to me that continuing the event loop after the error happens is probably not a good idea anyway.

<davexunit>mark_weaver: yeah, the loop should be waiting for something before continuing.

<mark_weaver>actually, since the debugger is just a REPL, we could run it in a "cooperative REPL" mode, where it gets the input from the existing 'reader' thread that's already waiting for input.

<mark_weaver>davexunit: take a look at module/system/repl/error-handling.scm.

<davexunit>okay.

<mark_weaver>search for "#:debug"

<mark_weaver>there are two cases in there where it starts a new debugging REPL. the first one is for traps, and the second is when the debugger is called on an error.

<davexunit>yes, I see that.

<mark_weaver>so, when using a cooperative REPL, it would be good to be able to start those REPLs in such a way that they have the same repl option that sets the reader to wait for input from the existing 'reader' thread.

<davexunit>I wonder how we can do that.

<davexunit>there's no REPL option for the reader thread stuff.

<mark_weaver>to be honest, I've forgotten the precise details of how exactly the cooperative REPLs are set up.

<mark_weaver>but basically, you want to start these debugging REPLs the same way that are you start the cooperative REPLs.

<mark_weaver>more or less...

<mark_weaver>well, not quite.

<davexunit>I'm having a hard time seeing how spawning a new cooperative repl server will help.

<mark_weaver>davexunit: the issue is that you've already got a separate thread waiting for input from the socket.

<davexunit>yeah, and the other issue is that the coop REPL will only evaluate things when it is polled.

<mark_weaver>if you want the debugger to run on that same socket, you have to either stop that thread from trying to read while the debugger is running, or arrange to let that thread do all the reading for you.

<davexunit>so even if we get the debugger into the REPL, something needs to be polling it and then eventually continuing with the loop.

<mark_weaver>anyway, I have to go afk for a while, good luck!

<davexunit>mark_weaver: thanks for your help.

<davexunit>I'll have to do some experimenting and see what turns up.

<davexunit>there needs to be some way to inject a cooperative REPL client with a debugging context.

<bhattigurjot>Hi, I just replaced the <guile/gh.h> with <libguile.h> as suggested but now the make gives the error :"fatal error: libguile.h: No such file or directory

<bhattigurjot>compilation terminated."

<davexunit>where is libguile.h located on your filesystem?

<davexunit>sudo find /usr -name libguile.h

<davexunit>bhattigurjot ^

<bhattigurjot>davexunit: /usr/local/include/guile/2.0/libguile.h

<bhattigurjot>/usr/include/guile/2.0/libguile.h

<davexunit>change <libguile.h> to <guile/2.0/libguile.h>

<bhattigurjot>is that a valid syntax?

<davexunit>I assume this in an #include macro, yes?

<davexunit>s/in/is in/

<mark_weaver>no, that's not right.

<bhattigurjot>davexunit: yeah

<davexunit>no? what's going on then? I haven't used the C API in awhile.

<mark_weaver>bhattigurjot: the build system should be adjusted to look up the proper compilation flags for guile-2.0

<mark_weaver>there's an autoconf macro for that.

<mark_weaver>basically it does the equivalent of running 'pkg-config --cflags guile-2.0'

<davexunit>oh, right. I used to use pkg-config.

<mark_weaver>which adds a -IPREFIX/include/guile/2.0

<bhattigurjot>mark_weaver: i already ran autoconf

<mark_weaver>and 'pkg-config --libs guile-2.0' to get the linker flags.

<davexunit>bhattigurjot: you need to add the macro, or use the pkg-config commands.

<mark_weaver>I'm fairly ignorant of build systems, alas.

<davexunit>bhattigurjot: this isn't a wonderful Makefile, but it does show you how to use pkg-config to get the right include path and libs. https://github.com/davexunit/gnumaku/blob/master/Makefile

<bhattigurjot>davexunit: already has GUILE_FLAGS macro there

<davexunit>can you check to make sure that the gcc commands being run have the right -I flag for guile 2.0?

<mark_weaver>bhattigurjot: what does 'pkg-config --cflags guile-2.0' print for you?

<mark_weaver>hmm, although that build system is old enough that it problem uses guile-config

<mark_weaver>s/problem/probably/

<bhattigurjot>mark_weaver: -pthread -I/usr/local/include/guile/2.0

<mark_weaver>bhattigurjot: can you look in the configure.* source file and see what it's using to find the guile compile flags?

<mark_weaver>bhattigurjot: also, what does "guile-config compile" print?

<bhattigurjot>mark_weaver: it prints -pthread -I/usr/local/include/guile/2.0

<mark_weaver>okay, so I guess the configure in dr geo is not using either of those

<bhattigurjot>configure.ac file has GUILE_FLAG written

<bhattigurjot>which is defined in aclocal.m4 file

<bhattigurjot>wait I'll show the content

<mark_weaver>bhattigurjot: where can I find the drgeo source code that you're starting from?

<bhattigurjot>mark_weaver: http://git.savannah.gnu.org/cgit/dr-geo.git

<bhattigurjot>mark_weaver: did you see the file? or shall I paste the link to the content?

<mark_weaver>bhattigurjot: thanks. so, first of all, if you haven't done so already, you should regenerate the configure script using a modern autoconf/automake

<mark_weaver>(and using the modern guile-2.0 autoconf macros)

<bhattigurjot>you mean change the aclocal.m4 file?

<mark_weaver>normally "autoreconf -vfi" is the thing for this.

<bhattigurjot>ok i did that and same error..

<mark_weaver>running "autoreconf -vfi" will regenerate the aclocal.m4 file

<bhattigurjot>but i can see while it configured it gave

<bhattigurjot>checking libguile compile flags... -pthread -I/usr/local/include/guile/2.0

<bhattigurjot>checking libguile link flags... -L/usr/local/lib -lguile-2.0 -lgc

<bhattigurjot>so I think it checked the correct paths

<mark_weaver>okay, good.

<mark_weaver>btw, you should commit the results of running "autoreconf -vfi" as a separate commit, as part of your work. but only after verifying that nothing broke, of course :)

<mark_weaver>there may be other things to fix, but obviously if -I/usr/local/include/guile/2.0 is passed to the compiler, it should now find <libguile.h>.

<bhattigurjot>okay will do that..but what about the error then?

<mark_weaver>does /usr/local/include/guile/2.0/libguile.h exist?

<bhattigurjot>yes

<mark_weaver>when I ran "autoreconf -vfi" in dr-geo on my system, it gave some warnings, including: Makefile.am:7: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')

<mark_weaver>(and the same for geo/Makefile.am)

<mark_weaver>so it sounds like you should change INCLUDES to AM_CPPFLAGS in those Makefile.am's, and then rerun "autoreconf -vfi", and try again.

<bhattigurjot>okay

<mark_weaver>so these changes should be in a separate commit from anything else.

<mark_weaver>this is basically updating the build system for modern autoconf/automake.

<mark_weaver>(and modern guile.m4)

<bhattigurjot>mark_weaver: after cloning what was the first command you ran?

<mark_weaver>autoreconf -vfi

<zacts>lo

<bhattigurjot>okay

<mark_weaver>it may well be that other changes are needed to configure.ac and the various Makefile.am files, to properly update this build system, but this is a weak area for me.

<bhattigurjot>I re-cloned and ran the autoreconf -vfi command

<bhattigurjot>but I get configure.ac:40: required file `./config.rpath' not found

<bhattigurjot>:P

<bhattigurjot>shall I do "touch ./config.rpath" ?

<bhattigurjot>would that be a wrong step?

<mark_weaver>hmm, I wouldn't assume that making an empty file is the right thing.

<mark_weaver>I see that error too.

<mark_weaver>also notice the warning about AM_INIT_AUTOMAKE being called in a deprecated way. better look at the manual page it recommends.

<mark_weaver>in guile, config.rpath is a rather large script.

<mark_weaver>ah, from libtool.

<bhattigurjot>where is that warning? i see a suggestion regarding "libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and

<bhattigurjot>libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.

<bhattigurjot>libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am."

<mark_weaver>ah, looks like you should run 'libtoolize"

<bhattigurjot>i did and the same warning

<mark_weaver>it's probably because you and I have different versions of autoconf/automake/libtool. I'm running very recent versions of all of those.

<bhattigurjot>btw autoreconf -vfi did ran aclocal and libtoolize

<mark_weaver>I think you should investigate and follow the suggestions. if your goal is to revive drgeo, getting its build system up-to-date is an important prerequisite.

<bhattigurjot>yeah.

<bhattigurjot>and the error comes at "autoreconf" yeah?

<mark_weaver>well, autoreconf runs libtoolize

<bhattigurjot>i guess I should have the latest versions of all these tools..

<mark_weaver>so I think you should follow its suggestions, and then return autoreconf -vfi.

<mark_weaver>bhattigurjot: what distro are you using? (you may have already told me, but I forgot)

<bhattigurjot>what's the best command to remove them? purge?

<bhattigurjot>I'm on Linux Mint 15

<mark_weaver>bhattigurjot: automake is the main thing that's been updated recently, and it's easy to upgrade by installing a more recent debian package.

<bhattigurjot>but isn't it better if I remove the older version before installing the new one?

<mark_weaver>automake is isolated enough (text files only, etc) that you can just download the *.deb from here: https://packages.debian.org/jessie/all/automake/download

<mark_weaver>and then install it using "sudo dpkg -i automake_1.14.1-3_all.deb"

<mark_weaver>that will automatically remove the old one. it's a package upgrade.

<bhattigurjot>ok

<mark_weaver>I'd recommend sticking to the debian packages, it will save you headaches I think.

<bhattigurjot>mark_weaver: these warnings I see in the "autoreconf -vfi" command, i.e #1 libtoolize consider adding... #2 warning: AM_INIT_AUTOMAKE #3 warning: 'INCLUDES' is old name..

<bhattigurjot>shall I solve them in one commit

<bhattigurjot>?

<bhattigurjot>or separate commits?

<mark_weaver>I would do it all in one commit, a build-system update commit.

<bhattigurjot>ok

<atheia`>re: conversation from about [17:04], wow I'm so not using Guile to its full potential yet oO

<mark_weaver>giving timestamps in your local time makes it rather inconvenient for us to figure out what you're referring to :-(

<mark_weaver>I guess he's in Belgium. hmm, what time it is there now?

<bhattigurjot>mark_weaver: what about this error now "configure.ac:41: error: required file './config.rpath' not found"? Checking the line number 41 of configure.ac file I can see that it is related the path file for guile

<bhattigurjot>am I doing something wrong here?

<mark_weaver>looks like libtoolize has an option to install missing auxiliary files

<mark_weaver>maybe try: libtoolize --copy --force --install

<bhattigurjot>same error

<bhattigurjot>i even did "autoreconf -i" to install the missing auxiliary files

<mark_weaver>bhattigurjot: run "gettextize -f"

<mark_weaver>and then rerun "autoreconf -vfi"

<mark_weaver>it recommends running 'aclocal' and 'autoconf', but those are run by 'autoreconf'

<bhattigurjot>woah! that worked! what does "gettextize" do?

<mark_weaver>look itup

<bhattigurjot>looking :)

<bhattigurjot>it is hanging on ./configure step.. it just sits there.. :(