IRC channel logs

2014-04-15.log

back to list of logs

<didi>Can I list all bindings exported by a module?
<ijp>(define (module-exports mod) (hash-map->list (lambda (k v) k) (module-obarray (module-ref mod '%module-public-interface))))
<didi>Thank you.
<ijp>module-public-interface may be more future-proof than module-ref
<didi>Is there a "core" module? (guile-user) doesn't seem to export bindings.
<ijp>that would be (guile)
<didi>Nice.
<didi>Tho it doesn't seem to have a %module-public-interface.
<ijp>hmm, no
<ijp>but it does work with the module-public-interface procedure
<didi>Hum, `module-public-interface' is not mentioned in the manual.
<ijp>it's not obvious which module- procedures are to be considered public
<didi>oy, `module-public-interface' is defined inside ice-9/deprecated.
<ijp>read the comment
<didi>Uh, 1851 bindings.
<nalaginrut>morning guilers~
<b4283>morning
<b4283>nalaginrut: did you try sxml-match yesterday?
<b4283>amendment: it wasn't a exception but a syntax error
<nalaginrut>b4283: I'm using master, maybe different
<b4283>bah !
<b4283>i know why now
<b4283>there was an separate module (sxml match)
*b4283 always skip through manual too quickly :/
<nalaginrut>b4283: I missed reading manual for long long time, I have read it carefully 3 years ago, but there're lots of update nowadays
<b4283>:P
<b4283>nalaginrut: the SXML Overview is waiting for you to write it
<nalaginrut>b4284: IIRC, there's some bugs in SXML, but I don't know if it's fixed. I've read it long time ago, but I gave it up for its 1000 lines macro...
<b4284>1000 lines o_o
***_zxq9_ is now known as zxq9
<wingo>meep meep
<nalaginrut>heya wingo
<civodul>Hello Guilers!
<wingo>heya civodul :)
*wingo finally has a plan for local variable information
<civodul>yay!
<wingo>instead of residualizing an NLABELS*NVARS table of available vars -- expensive to compute, and large to store -- i'll just serialize a table of VAR-IDX, VAR-SYM?, DEFINITION-OFFSET
<wingo>and parse the bytecode and do data-flow analysis on it at runtime to determine which vars are available at a given point
<wingo>more expensive at runtime, but only computed when needed, and saves space
<wingo>it also can allow us to start re-using the closure and argument slots
<wingo>with that, a simple recursive map is safe for space, and only holds onto the unprocessed tail of the list
<wingo>the barrier before was debuggability -- now we will be able to say that an argument has been optimized out
<wingo>though a ,bt full would give you the locals
<wingo>(VAR-SYM? would be a link to the name of the var, if any)
<civodul>ok, interesting to move some of the analysis to run time
<wingo>yeah
<wingo>it means that for native compilation we will have to parse native code :/
<wingo>but i guess that's doable
<wingo>you just have to compute the expression boundaries and compute the set of values clobbered by each instruction
<civodul>hmm, sounds tricky to do with native code
<wingo>yes, but you only have to deal with the code you emit, so it's not unreasonable
<wingo>anyway we'd want scheme-level disassemblers anyway
<wingo>and we already have lots of metadata on the code from dwarf and other object file sections
<ArneBab>civodul: pattern matching sounds interesting, but it’s even one step more abstracted. I find it harder to understand than caar (but I am used to seeing dddr).
<wingo>pattern matching is the only way to go!
<ArneBab>w
<ArneBab>wingo: (match '(1 2 3) ((car caar caaar) caar)) ☺
<nalaginrut>ArneBab: http://nalaginrut.com/archives/2014/04/15/simple%2C-but-not-so-simple
<ArneBab>nalaginrut: cool!
<ArneBab>nalaginrut: “interprete the IR to get the meaningful result”
<ArneBab>do you mean IL?
<nalaginrut>oops
<nalaginrut>fixed ;-D
<ArneBab>can you make Dragon Book[0] into a link?
<ArneBab>
<ArneBab>on my konqueror, 50 lines and 'create a language' are prefixed by lots of whitespace. Is that intentional?
<nalaginrut>ok
<nalaginrut>no, it's fine with my chromium
<ArneBab>(I hope it’s OK that I post correction ideas while reading)
<nalaginrut>ArneBab: is konqueror problem still exist?
<ArneBab>yepp
<taylanub>Aren't IR and IL synonyms, R for "representation" and L for "language" ?
<nalaginrut>well, my original purpose is to use IL
<nalaginrut>anyway, I think the uniform is better
<nalaginrut>it's very late for me, see you guys tomorrow
<ArneBab>good night
<nalaginrut>night
<wingo>civodul: what do you think should happen if you seek beyond the end of a binary output port?
<wingo>don't look at the source :)
<ArneBab>cu and Happy Hacking!
<tupi>hello guilers
<tupi>my last debian updates reported this message:
<tupi>Processing triggers for libc-bin (2.18-4) ...
<tupi>/sbin/ldconfig.real: /opt/lib/libguile-2.0.so.22.7.2-gdb.scm is not an ELF file - it has the wrong magic bytes at the start.
<tupi>
<tupi>for info
<didi>tupi: There is a thread on devel about it on the ml.
<didi>tupi: <http://article.gmane.org/gmane.lisp.guile.devel/17027>
<tupi>didi: tx, i forgot it's been mentionned already
<didi>tupi: I wonder if LSB covers it.
<didi>A .scm file inside $prefix/lib/ doesn't look standard but I don't know.
<civodul>this is the way GDB recommends
<didi>Interesting.
<tupi>wingo: yesterday i've been very audacious :), added my first enties in clutter-support.[hc] and clutter-spec.scm for 1 of the new types in 1.12, point, copying from margin, the closest existing example, and miracle, it is not reported as an opaque type anymore. like margin, point is a struct of float [not gfloat] and I see that for margin, you used scm_from_double in scm_clutter_margin_to_scm, but scm_to_uint8 in
<tupi>scm_scm_to_clutter_margin: still being very much in the fog :), i have to ask: should it not be scm_to_double instead?
<didi>Is there a predicate for GOOP generic functions? `program?' and `macro?' are #f, but `procedure?' is #t.
<didi>Hum, (is-a? obj <generic>) might be the answer.
<tupi>(eq? (class-of your-generic-here) <generic>)
<didi>tupi: Thank you.
<tupi>didi: your solu is better actualy :)
<didi>tupi: More of a wild guess than a "solution". ;^)
<tupi>didi: good guess, and also a solution: a generic function is indeed a container...
<davexunit> http://debug.elm-lang.org/
<davexunit>wow, guile-2d needs this time-based debugging, but I fear it's not possible.
<taylanub>davexunit: http://www.sourceware.org/gdb/news/reversible.html
<davexunit>that's cool, but doesn't seem fit for my use-case.
<davexunit>if you watch the Elm videos, you'll see that they're not really reversing the program, but going back in the history of events and replaying them.
<davexunit>and because they have access to that history they can do things like the trace you see with the mario example.
<ijp>that's because haskell has access to Control.Monad.Tardis
<ijp>(this is a real package)
<taylanub>Dr. Who's time-travel police-box space-ship thing ?
<ijp>yes
<ijp> http://hackage.haskell.org/package/tardis-0.3.0.0/docs/Control-Monad-Tardis.html
<davexunit>I think I could accomplish a similar debugger for guile-2d, but it will require a lot of work. There's no singularity in the signal graph, so it's currenly impossible to traverse the whole thing. Furthermore, there's no global scheduler that handles all time-based events.
<afdds>I want to get a list of unique integers. I also don't want to expect the same list twice. Here's my attempt, which doesn't work: http://slexy.org/raw/s21bNJ7YBK Note that the state is not shared between the 'foo' calls (see the first occurrence of lst: () in the output). In an imperative language I'd use a global variable, what's a pure functional way?
<afdds>(The above is an attempt to model a harder problem using numbers and lists.)
<afdds>I've already tried to use a fold with two seeds. It also fails, but I can't remember why.
<wingo>usually the answer is some kind of tree fold
<afdds>In the original problem, I have a DAG, so I want to make sure that I'm not expecting the same thing twice.
<wingo>if you can define a fold such that the procedure is called on each list and the previous seed value, that's probably the thing for this problem
<wingo>sorry, meant to say each leaf
<wingo>not each list :)
<afdds>Okay, I doubt that I'll succeed, though.
<afdds>I've been fighting this for quite a while.