IRC channel logs

2015-02-16.log

back to list of logs

<DeeEff>I believe "for // install" means for parallel install
<DeeEff>couldn't be sure though
<nalaginrut>sneek: later tell wingo I've tried to write an experimental generic assembler to support ARM in guile-compost. But I realized that our CPS-IR changed a lot since last time guile-compost updated. It cost me few hours to fix, but still failed. I decided to not fix it myself. And try a standalone experimental one. Anyway I guess I'll miss potluck...
<sneek>Got it.
<nalaginrut>morning guilers~
<joolean>Weird question: Is it possible to rethrow an exception from C code? Or to synthesize the stack for a new exception?
<please_help>(let ((time (get-time))) (do-something time (long-function))) ;<= is there any guarantee that get-time is resolved before (long-function) is run?
<nalaginrut>please_help: Scheme is applicative-order, which implies leftmost-innermost, so if you put 'time' to the left of (long-function), it runs first even if it's inlined while compiling
<mark_weaver>nalaginrut: no, you're wrong
<nalaginrut>mark_weaver: oops
<mark_weaver>the components of a procedure call may be evaluated in any order
<mark_weaver>the only guarantee is that they are done in some order. their evaluations may not be interleaved.
<nalaginrut>mark_weaver: is there any counterexample?
<mark_weaver>nalaginrut: I don't understand the question
<nalaginrut>mark_weaver: is there any case to prove that the right expr could run first?
<mark_weaver>if you're asking for an example that demonstrates this on Guile, it's irrelevant.
<mark_weaver>because whatever current guile does, there's no guarantee that we'll do left-to-right in future guile
<nalaginrut>I see
<mark_weaver>and I don't have time to try to cook up an example or to find out whether current guile ever does it differently.
<mark_weaver>please_help: ^^
<mark_weaver>however, there might be a guarantee that the right-hand-sides of the let are evaluated before the body. let me see.
<mark_weaver>yes, that is guaranteed
<please_help>alright, thanks
<mark_weaver>I probably shouldn't use the word "guarantee" though, because of course there's always the possibility of a bug in our optimizer.
<mark_weaver>but that's part of the semantics of scheme
<nalaginrut>alright, I think I understand something, RnRs doesn't constrain the order of evaluation, it just constrains that the order should be consistent
<nalaginrut>and it permit concurrent while eval, so it's not cool to constrain it
<please_help>(define (test-fn params ...) (display (list params ...)) (newline)) (test-fn 'hello 'world 'foo) ;=> wrong number of argument
<nalaginrut>"the effect of any concurrent evaluation of the operator and operand expressions is constrained to be consistent with some sequential order of evaluation." (R5RS sec. 4.1.3)
<please_help>(test-fn 'hello 'world) works fine
<please_help>what gives?
<mark_weaver>please_help: that '...' doesn't do what you think. those three dots only have special meaning in macro patterns and templates.
<mark_weaver>in what you wrote above, '...' is the name of the second argument
<please_help>ah I see
<mark_weaver>(define (test-fn . params) (display params) (newline))
<mark_weaver>or (define* (test-fn #:rest params) (display params) (newline))
<mark_weaver>the former is standard scheme, the latter is guile-specific
<lloda``>or (define test-fn (lambda params (display params) (newline)))
<mark_weaver>nalaginrut: I'm not sure what you mean by "and it permit concurrent while eval, so it's not cool to constrain it"
<mark_weaver>scheme does *not* permit concurrent evaluation of arguments
<mark_weaver>the arguments (and procedure) can be evaluated in any order, but there can be no interleaving.
<mark_weaver>also, the arguments (and procedure) must be evaluated before the procedure is called.
<nalaginrut>mark_weaver: well, then I don't understand "concurrent evaluation" mentioned in r5rs
<mark_weaver>the last bit is what it means to be "applicable order"
<mark_weaver>nalaginrut: well, what they're saying is that the optimizer can play some games as long as you can't tell the difference.
<nalaginrut>mark_weaver: so it permit concurrent eval in an optimizing compiler, right?
<nalaginrut>that's what I want to express
<mark_weaver>"the effect [...] must be consistent with some sequential order of evaluation"
<mark_weaver>I wouldn't agree with what you wrote though.
<nalaginrut>mark_weaver: yes, I don't have question about "there's no order guaranteed while eval" after you explained, the concurrent is another topic
<mark_weaver>a key point is that if you write (foo (bar x) (bar y) (bar z)) where 'bar' mutates some global data structure, you don't have to worry about locking or anything like that to prevent problems.
<mark_weaver>in other words, the compiler could do some interleaving, but only if it can prove that the end result is the same as if there was no interleaving.
<mark_weaver>I'm not even sure that's worth mentioning, and just adds confusion.
<nalaginrut>so the "concurrent eval" implies the concurrent within certain exprs, not handled by compiler?
<nalaginrut>well, these words are too confused for me...
<nalaginrut>I mean r5rs
<mark_weaver>I'm sorry, I'm having a lot of trouble understanding what you're saying, and don't have time to continue this discussion right now.
<nalaginrut>mark_weaver: I'm sorry too, this topic is not mature for me to discuss, so please let it go ;-)
<mark_weaver>no worries
*nalaginrut is leaving to station...
<slug__>hello
<zacts>lo guilers
<wingo>meep meep
<sneek>wingo, you have 1 message.
<sneek>wingo, nalaginrut says: I've tried to write an experimental generic assembler to support ARM in guile-compost. But I realized that our CPS-IR changed a lot since last time guile-compost updated. It cost me few hours to fix, but still failed. I decided to not fix it myself. And try a standalone experimental one. Anyway I guess I'll miss potluck...
*wingo could update guile-compost
<wingo>i updated it at some point, anyways...
<wingo> http://thread.gmane.org/gmane.comp.gdb.patches/104823
<wingo>wheee
<wingo>woo, i think i can interleave scheme and c frames on the stack
<wingo>the gdb backtrace stack i mean
<wingo>that would be swell
<mark_weaver>that would be fantastic! :)
<wingo>all thanks to the lovely srfi-41 :)
<mark_weaver>:)
<wingo> http://paste.lisp.org/display/145778
<wingo>mark_weaver: ^
<wingo>looks kinda gross but it does work at least
<wingo>would be nice if gdb could do the dwarf lookup for us i guess
<mark_weaver>wingo: those indented lines with the same frame number as the parent C frame, those are the ones you're adding in, right?
<wingo>mark_weaver: yes
<wingo>and the addresses correspond to VM ips
<mark_weaver>it's a nice start :)
<wingo>if you do a bt full you get all the locals, but by index and not by name
<wingo>the other thing in that bt is the annotated c functions
<wingo>e.g.
<wingo>#18 0x00007ffff7b37ba6 in peek-char [scm_peek_char] (port=#<port 3 6e29c0>) at ports.c:2252
<mark_weaver>oh, right!
<wingo>that's a silly little hack
<wingo>to look for s_scm_peek_char, for example
<wingo>and if it's present to print that name
<wingo>taking advantage of the way snarfing currently works :P
<mark_weaver>a nice touch :)
<wingo>it's all pretty gross :)
<wingo>anyway, hope doug gets a chance to look at my frame filter patch some time...
<mark_weaver>not so useful at present, but it looks promising :)
<mark_weaver>do you anticipate being able to show the scheme procedure names and argument names/values ?
<wingo>well gdb could at least the procedure names
<wingo>if it knew about our dwarf symbol tables
<wingo>and it could do it without us having to do anything
<wingo>it can't do arguments though
<mark_weaver>well, even just the procedure names would be helpful
<wingo>yeah
<wingo>i guess we need to figure out how to add our elf images to gdb
<mark_weaver>so gdb allows you to add these subframes(?) but only of a very restricted form?
<wingo>well
<wingo>the docs are in http://thread.gmane.org/gmane.comp.gdb.patches/104823
<wingo>but yeah, it's essentially a way to cosmetically alter backtraces
<wingo>you can synthesize frames but they are still associated with a gdb frame
<wingo>you can override the address, the function name, the arguments, the locals, and you can nest frames for presentation
<wingo>oh yeah you can set the filename and the line too
<wingo>but still the printing is done by gdb itself and not your annotator
<wingo>it has the minor virtue of still workign with the MI interface
<wingo>the python interface calls nesting "eliding" frames, but that seems a silly name to me, given that the frames are still there
<wingo>i mean, they are still there on the stack of course, but in python "elided" frames are the ones that are nested
*mark_weaver reads
<mark_weaver>wingo: if you can insert frames, and if frames can include arguments and locals, then could you insert new frames corresponding to the VM stack frames with the argument names/values ?
<wingo>mark_weaver: certainly
<wingo>getting the function name will not be hard; getting the arguments is tricker
<mark_weaver>ah, good!
<wingo>*trickier
<mark_weaver>*nod*
<mark_weaver>well, I very much appreciate your work on this :)
<wingo>you have to know the arity you are in, you have to grovel various sections to determine the argument names, you are doing it from gdb and not from the inferior, you have to do a CFA to determine if the values are dead or not, etc
<wingo>all this is what guile does when it makes a backtrace
<wingo>but doing it from another process is irritating :P
<wingo>i suppose you could just make a VM frame object and call scm_print_frame :P
<mark_weaver>yeah, makes sense
<wingo>but that's not something you want your backtrace printer to be doing
<mark_weaver>right
<mark_weaver>at least not by default.
<wingo>better perhaps to just get the function name, and then maybe have a util to print a frame in more depth
<mark_weaver>maybe it could be an option or something
<wingo>using the inferior
*mark_weaver is shamefully ignorant of gdb
<wingo>heh, no problem...
<wingo>hm, another option would be to ship the delimited continuation over the wire, and operate on that...
<wingo>i guess that wouldn't really work.
<wingo>but you could ship (elf file name, offset in elf file) pointers over and have gdb use normal guile functions for grovelling in that elf file
<wingo>for various things that map off of the instruction pointer, anyway
<wingo>that would be doable and avoid pain i guess
<wingo>hmmm, i could even walk guile's elf chain from gdb...
<daviid>hello guilers
<daviid>mark_weaver: i worked a bit more yesterday and after i changed all explicit 'guile ... -c' to '$(GUILE) ... -c' instead, both make and make check pass [g-wrap using guile-2.2[2.1 actually but the executables are all suffixed with '-2.2'. this is all good, but i need to solve 2 problems: (a) as it is, http://git.savannah.gnu.org/cgit/g-wrap.git/tree/configure.ac my understanding is that the variable GUILE should be defined and somehow
<daviid>'propagated' and available in all Makefile.am in the tree, but this is not the case and I don't know why [maybe because of this autogen.sh is manually written, not running autoconf, don't know], and (b) CFLAGS=-Wno-error=deprecated-declarations provides errors but i don't see the wrnings anymore, wrt to this, what would be the apropriate CFLAGS not to raise erros but to see the deprecate warnings?
<mark_weaver>daviid: the way it's supposed to work is this: the definition of GUILE_PROGS in guile.m4 includes AC_SUBST(GUILE), which is supposed to substitute its value for @GUILE@. and automake is supposed to automatically add GUILE = @GUILE@ to each Makefile.in. in each Makefile, that should turn into something like GUILE = guile
<mark_weaver>see the entries for AC_SUBST in the autoconf and automake manuals.
<daviid>mark_weaver: tx. in g-wrap, maybe because it has a manually written autogen.sh [which includes his friend autogen-support.sh], and does not run autoconf [?], this propagtion does not occur. you can see that the original author also defines his GUILE_EFFECTIVE_VERSION [which we should get rid of i guess]... so until we rewrite all this 'proper', we need to define GUILE there
<mark_weaver>daviid: autogen.sh includes the line: tool_run "$autoconf", which runs autoconf
<daviid>ok, i don't know, but it only works when i add GUILE=guile-2.2 AC_SUBST(GUILE)
<mark_weaver>can you grep GUILE in the relevant Makefile.am, Makefile.in, and Makefile, and tell me what you found?
<daviid>also you say 'which expand to guile' but you mean which expand to the guile executable it did find right? because i did setp up things so that /opt2 is the only 'visible' tree, so all it finds are guile-2.2, guild-2.2, guile-config-2.2 ...
<daviid>mark_weaver: ok, let me grab the info
<daviid>here: http://paste.lisp.org/+34HH
<daviid>i changed all guile ... -c for $(GUILE) $(GUILE_FLAGS) -c in all Makefiles.am, i did not touched any other file [except configure.ac of course]
<mark_weaver>daviid: I need to see the occurrences of GUILE in guile/g-wrap/gw/Makefile.in and guile/g-wrap/gw/Makefile
<mark_weaver>and those files won't even exist until you run autogen.sh and configure
<daviid>here is the configure.ac [not good yet, i know] with which 'make' and 'make check' work http://paste.lisp.org/+34HH/1
<daviid>ah, sorry i ran 'make clean; git clean dxf' let me run and paste
<daviid> http://paste.lisp.org/+34HH/2 [this is with the configure.ac that works], now i can comment what i wrote and use the matser version [the 1 wingo uses] ansd paste as well ?
<daviid>with the following configure [as in master] http://paste.lisp.org/+34HH/3
<daviid>i get this error: http://paste.lisp.org/+34HH/4
<daviid>the guile/g-wrap/gw/Makefile is not created. i can not paste the all config.log, too big, but an extract: http://paste.lisp.org/+34HH/5
<mark_weaver>the Makefile should be created when you run configure
<mark_weaver>unless there is more than one configure script. maybe the subdir has its own configure?
<daviid>but it fails before ?
<daviid>with the configure.ac as in master, not manualy defining GUILE, configure fails
<daviid>in the mean tiome, do you kow what CFLAGS value would gives me warnings [and not raising errors] ?
<daviid>i start to think it could be a guile.m4 problem [?] because i did [especially] setup things so that there is no guile, guild, guile-config, but guile-2.2, guild-2.2, guile-config-2.2 and the error message i get from running ./configure ... in g-wrap is the 1 that comes from guile.m4 [line 207]
<mark_weaver>I don't think our guile.m4 has any provision for finding a guile with a custom suffix.
<daviid>ok, but should it not? i naively [maybe] thought it was long being able to ... like how about having guile-2.0 aside guile-2.2, then you write a configure.ac for a script and/or an app requires 2.2, like ... GUILE_PKG([2.2])\\nGUILE_PROGS ... everything is in /opt, and this hypothetical user machine guile is still a symlink to guile-2.0, but guile-2.2 is there with his friends...
<daviid>i see that doc/version.texi is having the date at which it is build, and that is true for guile, guile-gnome ... is this expected [as opposed to a date at which there has been real modification?]
***karswell` is now known as karswell