<calher>Geiser. WHY ON EARTH do you LIKE this JUNK? <calher>It spits junk into my minibuffer, complaining ALL THE TIME: 'waaaa, i dont have autodoc'. IDK WTF autodoc is and I don't want it! I just want to C-x C-e Scheme code like I do Elisp. <calher>unless that's not what geiser does <davexunit>many of use use geiser *without issues* and are very happy. <calher>davexunit: I'm not cussing. What else do you want from me? <calher>davexunit: Well it kvetches about some stupid Autodoc nonsense. <calher>Well everything is ruined right now and it hurts. <davexunit>so you can A) debug it or B) punt on it and try again another time. <vanila>why don't you stop using geiser then? <calher>vanila: Because I should be able to C-x C-e Guile Scheme in Emacs. <vanila>i gave up on that and just switch between emacs and a terminal <davexunit>it's a simple way that works in the short-term while you resolve other issues with your setup <davexunit>take it a step at a time and don't bite off more than you can chew <calher>Everything sucks and I won't ever be able to fix it all. <vanila>i don't understand what the problem is, just be happy <calher>searched geiser in M-x list-packages. got nothing. can't remove. <davexunit>you can inspect the elisp load path and find it <calher>that sounds dirty and kludgy, like removing the binary of a program which may or may not have installed other junk to the system like man pages <vanila>well wouldn't it be gix remove geiser <davexunit>geiser is probably either in your system profile or user profile <calher>ew. i know i didnt put it in system profile. that's nastier than spoiled durian fruit <vanila>are you trying to make people uncomfortable <calher>What I'm trying to do is to not use curse words. <calher>Wait, it didn't work. I still get those messages. <calher>mark_weaver: I saved the settings. They were written to .emacs. I restarted Emacs, opened a Scheme file; still there. <mark_weaver>if it says (REPL A) in the mode line, then you have autodoc enabled there. if not (REPL), then you don't <calher>mark_weaver: In Scheme buffer: (Scheme Guix Chicken/A) <calher>In stupid buffer with a Guile shell in a dumb dumb terminal: (REPL) ***heroux_ is now known as heroux
<mark_weaver>calher: ah, I see. you need to also customize the 'geiser-mode-autodoc-p' variable <mark_weaver>calher: and by the way, M-x customize-apropos autodoc RET finds all of these <calher>dont you have to go thru each chapter and do C-s <mark_weaver>calher: you can use 's' to search the entire manual from the top, but in this case it's also in the index, which you can access by typing 'i' in info mode. <mark_weaver>next time, try reading the docs before spamming the channels with insults <calher>i still dont know all the tricks in Info <davexunit>I've spotted a pretty simple case that peval doesn't seem to take care of <davexunit>perhaps this is on purpose, but I see forms of the form (+ x 0) or (+ 0 x) in the output of ,optimize <davexunit>surely those can be reduced to just "x", right? <davexunit>yeah I suppose if + is bound to something else, which it could be, then you can't touch it. <davexunit>no way to prove that it's primitive addition. <mark_weaver>davexunit: I'm not sure of the reason behind it, but I'll also mention that (+ 0 x) checks the type of x, and that type check is lost when you convert it to x <davexunit>I knew there had to be a reason why something as simple as the identity of addition wasn't optimized away <davexunit>I haven't done benchmarks, but I rewrote my matrix multiplication routine in pure Scheme and it is indeed taking advantage of unboxed floating point ops <davexunit>haven't properly benchmarked to see what the performance diff is, but hopefully it's pretty decent. <davexunit>I think I might be able to get better bytecode output if I manually unrolled the loops. <mark_weaver>the reason you gave is a good one, more important than the one I mentioned, but actually guile's compiler does assume that the bindings for + - * / in the (guile) module are bound to the expected operators. <mark_weaver>note that in R6RS, any top-level binding that is exported from one module to another, must be immutable. <davexunit>sounds like that has some pretty serious implications for live hacking <mark_weaver>so the only top-level variables that can be mutable are bindings that are private to a single module <davexunit>I develop code across modules all the time by redefining publicly available bindings <mark_weaver>when developing, it's very convenient to be able to do that <mark_weaver>R7RS has something similar, but not quite as strict. <davexunit>time for sleep. thanks for the insights, mark_weaver ***amz32 is now known as amz`
***Armand is now known as Guest34319
<davexunit>I wrote some code that wrote some code to spit out a fully unrolled 4x4 matrix multiplication routine <davexunit>checked the disassembly with ,x on guile 2.1.2 <davexunit>I realized that I could make the code itself more terse by using a macro. <davexunit>rather than pasting in the full expanded form. <davexunit>oh, and a define-inlinable hack helped a bunch, too. <civodul>i'd like to check what the (guix monads) code gets compiled to on 2.2 <civodul>peval already does a lot of the heavy lifting <civodul>but i'm guessing that other optimizations can help <davexunit>so you can write functional code to describe an imperative rendering process <civodul>for (guix monads) i went to great lengths to have things resolved at expansion time as much as possible <civodul>to avoid creating lots of closures basically <davexunit>civodul: I haven't done any such optimization... perhaps I should just snarf (guix monads) :) <wingo>i suppose it's possible to use guix to build guix with guile-next <wingo>hopefully no incompatibilities <civodul>wingo: the GnuTLS bindings don't build, i need to fix it <wingo>davexunit: how is the perf for your matrix multiplication compared to 2.0 ? <davexunit>wingo: benchmarking is something I haven't done yet. I only just got the implementation to work. <wingo>civodul: just a configure issue i hope; maybe deprecated functions too? <wingo>are there any i686 successful build reports? <wingo>got an unsuccessful build report from mark from git <wingo>but i don't know who's building on 32-bit these days <civodul>wingo: deprecated functions in tests, because they were written to work for 1.8 as well <wingo>i tried to use guix but didn't succeed for various reasons <civodul>the --with-input=guile=guile-next thing is pretty useful to check whether things work with 2.2 <wingo>makes me happy, and frustrated only sometimes :) <davexunit>lots of fmul, fadd, and bv-f32-set! in the disassembly, and no scm->f64 or f64->scm <mark_weaver>wingo: hydra also failed to build guile-2.1.2 on i686, although interestingly the error happened in a different place <wingo>davexunit: the optimizer currently assumes every f32-ref aliases every f32-set!, so that's why it's reading and writing memory all the time <civodul>2.2 fails gracelessly if it stumbles upon a 2.0 .go in its search path <davexunit>wingo: oh, so is there more room for optimization here (that I can do)? <davexunit>I'm pretty pleased with this disassembly so far. <davexunit>i saw what it looked like before I started, lots of boxing and unboxing. <wingo>if you manually lift the 9 refs from matrices m1 and m2 to locals and work on them, you can avoid duplicating f32-ref on source matrices <wingo>would require more macrology tho :) <wingo>civodul: i don't know what the right thing to do there is. thoughts welcome :) <civodul>wingo: would be nice to silently skip the faulty .go, i think <civodul>so you could have a mixture of 2.0 and 2.2 things in the load path, maybe <davexunit>wingo: I'm fine with macrology. this part of the code is hit so many times I need all the performance I can get. <wingo>civodul: sounds like an error to have both things in your load path. i think 2.0 will carp if 2.2 things are in the load path <wingo>do we need versioned load paths? <mark_weaver>one relevant difference is that when compiling manually, I used gcc-5.3, whereas I guess the 'guile-next' package implicitly uses gcc-4.9.3 <civodul>wingo: during the transition period, users can easily have both things in their load path <civodul>for instance, i just built the shepherd with 2.2, but i had to clear GUILE_LOAD_*PATH to actually run 'herd' <wingo>civodul: it sounds like we need to avoid that. versioned load paths? <civodul>yeah possibly, like we did for libc locales <mark_weaver>civodul: GUILE_LOAD_COMPILED_PATH should be a purely versioned load path, shouldn't it? <civodul>so you would have, say, GUILE_LOAD_COMPILED_PATH=$HOME/.guix-profile/share/guile/site <mark_weaver>(although GUILE_LOAD_PATH should allow unversioned paths) <civodul>and 2.0 would append "/2.0", and 2.2 would append "/2.2" <wingo>it's kinda crap when building software that can run on either <wingo>like you are doing ./pre-inst-env and what environment var does pre-inst-env set <civodul>i think there env var name should remain unchanged though <mark_weaver>civodul: I think .go files should go in $HOME/.guix-profile/lib/guile/<version>/ccache, no? <civodul>that's right, but the problem remains <wingo>so maybe both guiles should be more forgiving, dunno <davexunit>civodul: I noticed that our guile-next package doesn't set the right native search pathes <civodul>yeah, that sounds like the easiest solution <davexunit>I fixed them locally last night, but haven't pushed a patch <mark_weaver>one problem is that some build systems for guile packages put the .go files in the same directory as the .scm files. <davexunit>civodul: build systems, such as guile-opengl's, use $(GUILE_EFFECTIVE_VERSION) as part of the path when installing modules. <davexunit>/2.2 instead of /2.0 in the case of building with guile-next <davexunit>but our guile-next package doesn't adjust the search paths accordingly. <mark_weaver>(at least not given how the purpose of share is traditionally defined) <civodul>mark_weaver: agreed, i've made that mistake several times ;-), but it's a separate issue <mark_weaver>well, I certainly agree that we should ensure that guile detects incompatible .go files and ignores them. <wingo>it certainly detects them :) ***karswell` is now known as karswell
<davexunit>wingo: this code is uglier than the previous version, but I decided to assign a local for each element of matrices m1 and m2, which of course removes all of the refs in the previous disassembly. the resulting instruction list is ~100 steps shorter. http://paste.lisp.org/display/307032#2 <amz3>got and idea for the potluck <amz3>it's a small Q/A framework, that might involve mk <amz3>I mean that it's bot basically <amz3>framework, well hopefully it's the first iteration over a real Q/A system <vanila>hmm id like to but i don't have an idea yet= <davexunit>wingo: microbenchmark says that the pure guile matrix multiplication routine is significantly faster than using the FFI to call GSL's CBLAS matrix mult function <davexunit>it's not as cool as you think because my routine is specialized for 4x4 matrices, the only kind you ever really deal with when doing graphics programming <davexunit>whereas the GSL routine is a generic one for any size matrix <davexunit>but having a specialized implementation in Scheme, without boxing or FFI call overhead, seems to be a huge win <davexunit>~3 seconds faster to do 1e7 matrix multiplications <davexunit>it's really nice to see things *speed up* significantly when they are moved from C to Scheme.