IRC channel logs

2014-09-20.log

back to list of logs

<daviid>wgl: i perso don't know, but there has been a talk related to guile-snarf, here, earlier today, so if you look at the log you may find something that will help you, good luck
<ijp>snarf is usually a red herring
<ijp>it's the first place the interpreter is actually used, so it's what finds the bug, rather that it being the bug
<wgl>daviid: Thanks.
<dsmith-work>Arrr
<rlb>mark_weaver: new error on armhf (after (I think) switching back to guile 4.8): https://buildd.debian.org/status/fetch.php?pkg=guile-2.0&arch=armhf&ver=2.0.11%2B1-5&stamp=1411186013
<mark_weaver>rlb: that's related to lines 82-84 of vm-engine.h. those are used to explicitly choose the registers for three local variables in the VM declared on lines 42-44 of vm-engine.c. maybe ask wookey if he has suggestions about which to choose? or just leave any/all of {FP,SP,IP}_REG undefined, and then GCC can choose freely.
<mark_weaver>rlb: that code (the register choices for ARM) has not been touched since 2001 (!!)
<mark_weaver>(literally from the initial commit of our VM from Keisuke Nishida "New VM." 17e90c5e25a7a2e453742044ee6a3fa5f27e9e5d)
<mark_weaver>sneek: later tell rlb: that's related to lines 82-84 of vm-engine.h. those are used to explicitly choose the registers for three local variables in the VM declared on lines 42-44 of vm-engine.c. maybe ask wookey if he has suggestions about which to choose? or just leave any/all of {FP,SP,IP}_REG undefined, and then GCC can choose freely. that code (the register choices for ARM) has not been touched since 2001 (!!)
<sneek>Okay.
<wvxvw>Hi, I've heard about guile-emacs project, I could find the sources and build it, but I'm seeing a lot of errors related to third-party Emacs libraries. Where would I report those (and possibly get updates on the progress of the project)?
<mark_weaver>bipt, here on channel, is the author of guile-emacs, and he's been around quite a bit lately. you might ask him.
<mark_weaver>I'm not sure if there's a dedicated mailing list for guile-emacs yet, but for now I guess guile-devel@gnu.org is the place to send problem reports.
***micro is now known as Guest56725
<wvxvw>ah, ok, thanks, mark_weaver
***mario-go` is now known as mario-goulart
***stablerobber is now known as prickler
***prickler is now known as stillroof
<rlb>mark_weaver: oddly, unless I got my compiler selection wrong, it looks like only armhf has the register problem (armel doesn't).
<sneek>rlb, you have 1 message.
<sneek>rlb, mark_weaver says: that's related to lines 82-84 of vm-engine.h. those are used to explicitly choose the registers for three local variables in the VM declared on lines 42-44 of vm-engine.c. maybe ask wookey if he has suggestions about which to choose? or just leave any/all of {FP,SP,IP}_REG undefined, and then GCC can choose freely. that code (the register choices for ARM) has not been touched since 2001 (!!)
<rlb>mark_weaver: so any issue with not defining FP_REG for armhf? i.e. is that likely to cause trouble somewhere, break an ABI, etc.?
<rlb>and more generally, why is guile choosing registers in the first place if it's possible to let gcc decide (under the assumption that gcc probably has more horsepower behind its allocator)?
<rlb>Is guile post-processing the gcc output before final assembly? If so, one proposed theory is that the offset out of range problem was created there -- i.e. guile's mucking about pushes the reference out of range (when it was fine as gcc left it).
<rlb>Ahh -- ok, so someone's pointed out that it might be an edge case with the inline asm: https://gcc.gnu.org/onlinedocs/gcc/Size-of-an-asm.html#Size-of-an-asm
<rlb>Is there an easy way to get the guile build to stop hiding the actual gcc command lines?
*rlb thinks if it really has to hide them, then it should still probably print the failing command when it fails...
<rlb>(otherwise important information is lost, and people have to go track down porterboxes, and set up build envts, etc. to possibly find out something that would have been obvious in a less obscured build log)
<rlb>aha excellent -- it's automake, and there's a knob -- "fakeroot debian/rules V=1 build"
*rlb may enable that by default for debian builds...
<stis_>heya guilers, I'm surfing on some happy adrenaline atm, got coroutining into guile-log!
<davexunit>woooo!
<stis_>you can use it in kanren as well!
<stis_>e.g. guile-log's kanren interface :-)
<stis_>yeah and you don't need to worry about using a modded gc, that's only for the brave that can use ./configure correctly
<stis_>use --with-logical-gc you brave ones and read the docs to get your kanren server to not run out of memory
<bipt> http://hcoop.net/~bpt/tmp/.elisp.txt feedback requested on a mostly-technical argument for porting emacs to guile instead of CL, in response to stefan monnier's comments
<davexunit>bipt: small typo: "you have two choices basic choices"
<bipt>davexunit, thanks, fixed now
<stis_>I don't get it, if they want common lisp, why not implement common lisp iin guile.
<stis_>It's the VM and compiler infrastructure that are used
<stis_>Cl does is not scheme, have no support for delimeted continuations
<bipt>stis_, yes, that route makes sense to me. elisp already has a lot of the library functions and guile provides a lot of the missing parts (GOOPS and condition systems at least)
<stis_>scheme has and you can probably just write a compiler for common lisp ontop of guile's VM without modifications of the VM
<davexunit>bipt: finished reading. I think it's a really good technical argument for guile.
<davexunit>I'd like to see what mark, ludo, and wingo thing
<stis_>so why on earth does not people like Stefan join the guile effort and start coding a CL implementation
<stis_>bibt: otherwise I like your style.
<taylanub>ugh, guile-devel turned into ethical philosophy now .. and damn, I now realize I started it. :( trying to end it ASAP
<davexunit>taylanub: you can help stop it by not replying.
<davexunit>Ian Grant is a weird fellow.
<bipt>the only winning move is not to reply
<davexunit>thanks joshua. :)
<taylanub>:D
<bipt>ok, it's up. thanks for reviewing!
<davexunit>\\o/
<taylanub>bipt: I just read it too; very nice. :)
<bipt>now i just have to convince rms that guile-emacs is beneficial even if people continue to use elisp :p
<bipt>thanks
<taylanub>haha
<bipt>he did say "we should use guile if at all possible," which is enough of an endorsement for me
<taylanub>just when I "chickened" a bit and moved focus to the Elisp benefits, RMS goes out and says he just wanted Scheme :P
<davexunit>RMS wants Scheme?
<taylanub> http://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00638.html davexunit
<davexunit>I would have expected him to stick to elisp
<davexunit>for practical reasons
<bipt>he doesn't like common lisp and does seem to like scheme (did you know he invented dynamic-wind while working on a scheme chip at mit?)
<davexunit>rms invented dynamic-wind? damn.
<davexunit>it's easy to forget about rms's technical achievements
<davexunit>I wish he still wrote code...
<bipt>"I can assure you that the original reason that Richard Stallman invented dynamic-wind (in 1980 for the Scheme-81 chip) was to complement call-with-current-continuation [...]" Sussman in a 1993 email to the rrrs-authors list
<davexunit>wow
<davexunit>you're full of awesome fun facts :D
<bipt>i like lisp history. atm i'm working on designing a new edition of the common lisp ansi draft in my spare time (:
<bipt>(edition as in printed edition with updated typography, i mean)
<davexunit>:)
<davexunit>sounds neat
<bipt> https://groups.csail.mit.edu/mac/ftpdir/scheme-mail/HTML/rrrs-1993/msg00097.html the sussman message
<rlb>bipt: nice commentary
<rlb>(wrt .elisp.txt)
<bipt>rlb, thanks!