***daviid is now known as Guest70811
***Guest70811 is now known as daviid
***Server sets mode: +nt
***geokon1 is now known as geokon
***logicmoo is now known as dmiles
***rekado_ is now known as rekado
<janneke>found it, (debug-enable 'debug) now is: wrap call in `call-with-error-handling' :-) <civodul>it's very handy, more than the old 'debug-enable' :-) <janneke>civodul: yes, i'ts very nice...just could only remember the old meme :) <lloda>The manual really needs a 'hands-on' or 'howto' section I think. You cannot figure out how to do a number of things without googling the mailing list or irc. <lloda>for example I've hit the debugger countless times and I still don't know how to do anything there beyond ,bt <lloda>I'd want to do things like set variables, continue from this point, go step by step <lloda>none of these things seem to work <civodul>but note that there are things you can't do at all in the debugging, such as step-by-step execution :-) <wingo>civodul: is that because it's broken? source-line stepping should work <wingo>but expression-by-expression stepping doesn't of course <civodul>wingo: oh! i guess that's just because i never do source-line stepping <wingo>confession: i never use breakpoints or stepping <wingo>maybe i don't code enough in an environment in which i can rely on my tools, because i broke them all <civodul>you end up being the one who writes the tools and rarely takes advantage of them ;-) <janneke>i just started looking at the debugger again *janneke still has an old, non-finished patch to have backtraces use gnu style locations and fix break-at-source, i think <janneke>will see if i can give that some love ***unCork is now known as Cork
***rain1 is now known as rain2
<lloda>civodul: right, so it's there. Was exaggerating earlier, I already do ,frame ,up etc <lloda>but ,locals is useless most of the time <lloda>and it's all about inspecting; there's no relationship to the source and you cannot *do* anything in the frame <lloda>the example doesn't show stepping, continuing... <lloda>I'm sorry to not be more positive! <lloda>but in the end I just pk & reload 99% of the time :-/ <civodul>lloda: i pk most of the time as well :-), but when i do get a backtrace, the debugger is helpful for me <civodul>my guess is that when writing in a functional style and doing "REPL-driven dev", step-by-step etc. are not so useful <wingo>for me ,locals is often helpful fwiw <wingo>just had a successful ./check-guile run with jit threshold of 1000 :) now going for 0, it caught a few more things <lloda>civodul: the manual looks ok now that I've read it! if one can actually do source-line stepping, then showing that would be nice <lloda>wingo: for me ,locals shows mostly renamed variables and a lot of them missing altogether <lloda>I may be doing something dumb <wingo>i haven't checked that these things work, not recently anyway <wingo>they have a way of bitrotting <wingo>but it's like stepping gcc-compiled code at -O2 or something, not that bad but it's still not totally obvious <wingo>you can step instructions of course <wingo>ok there are just 10 failing tests now, 9 related to lack of hooks in jit code, one a bug in case-lambda* compilation <wingo>with GUILE_JIT_COUNTER_THRESHOLD=0 <wingo>also i think jit compilation is faster because we're using a custom code allocator instead of the one in lightning <wingo>basically i think lightning is open for business, speed golfing to continue after i figure out what to do with hooks <lloda>wingo: I have a benchmark where lightning w/ jit is ~9 times slower than lightning w/o jit or stable-2.2, but I haven't been able to make it standalone <davexunit>wingo: planning any pre-release thing that makes it easy to test out the new jit? <davexunit>I'm interested in seeing how programs with lots of floating point math perform.