IRC channel logs


back to list of logs

<frofroggy>Hello guilers
<calher>Geiser. WHY ON EARTH do you LIKE this JUNK?
<davexunit>please stop it.
<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.
<davexunit>us use*
<calher>davexunit: I'm not cussing. What else do you want from me?
<calher>davexunit: Well it kvetches about some stupid Autodoc nonsense.
<davexunit>to stop spamming guile related channels
<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.
<davexunit>option B looks pretty good right now
<calher>I can't fix anything. I suck.
<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
<calher>That is gross.
<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.
<calher>*fix enough
<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>it's coming from somewhere.
<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>are you using guix?
<calher>I did -s geiser and got nothing
<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.
<mark_weaver>calher: M-x customize-variable
<mark_weaver>turn it off
<calher>Wait, it didn't work. I still get those messages.
<mark_weaver>it only affects newly started Geiser REPLs.
<mark_weaver>M-x geiser-autodoc-mode
<mark_weaver>within a Geiser REPL to toggle it
<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
<mark_weaver>do you see (REPL A) in the mode line?
<calher>mark_weaver: In Scheme buffer: (Scheme Guix Chicken/A)
<calher>In stupid buffer with a Guile shell in a dumb dumb terminal: (REPL)
<mark_weaver>does M-x geiser-autodoc-mode get rid of the A?
***heroux_ is now known as heroux
<calher>That works, mark_weaver
<mark_weaver>calher: ah, I see. you need to also customize the 'geiser-mode-autodoc-p' variable
<mark_weaver>turn that one off too
<mark_weaver>calher: and by the way, M-x customize-apropos autodoc RET finds all of these
<mark_weaver>as does looking in the geiser manual for "autodoc"
<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>I think...
<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>or is this some spell I am not aware of?
<wleslie>it flips the sign if x is a float
<wleslie>to say nothing of other + methods
<davexunit>yeah I suppose if + is bound to something else, which it could be, then you can't touch it.
<davexunit>makes sense.
<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>yeah, that makes sense, too.
<davexunit>I knew there had to be a reason why something as simple as the identity of addition wasn't optimized away
<davexunit>but hey, ,optimize is really neat!
<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.
<davexunit>ah, interesting.
<mark_weaver>note that in R6RS, any top-level binding that is exported from one module to another, must be immutable.
<davexunit>hmm, interesting.
<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
<healer>amz32: hi
***amz32 is now known as amz`
***Armand is now known as Guest34319
<davexunit>so this was a fun little hack
<civodul>davexunit: which one? :-)
<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>all unboxed floating point math
<civodul>pretty neat
<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>so I shall do that.
<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>oh interesting
<davexunit>I'm also curious
<davexunit>Sly uses a monad for rendering
<davexunit>so you can write functional code to describe an imperative rendering process
<davexunit>and I hope it's not too expensive :)
<civodul>heh :-)
<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?
<davexunit>I'm going to put together a little test.
<wingo>excellent :)
<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
<wingo>to cross-build, i mean
<civodul>the --with-input=guile=guile-next thing is pretty useful to check whether things work with 2.2
<wingo>guix is great :)
<wingo>makes me happy, and frustrated only sometimes :)
<civodul>it's a package: it gives both ;-)
<davexunit>wingo: here is the relevant snippet of code + disassembly
<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
<mark_weaver>let me dig up the URL
<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.
<mark_weaver>compare with the failure I saw building manually:
<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
<civodul>what do you mean?
<wingo>like you are doing ./pre-inst-env and what environment var does pre-inst-env set
<civodul>ah yes
<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?
<dsmith-work>Thursday Greetings, Guilers
<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
<civodul>ok, but go ahead ;-)
<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.
<mark_weaver>and 'guix' is an example of this
<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>architecture-specific files don't belong in share
<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.
<mark_weaver>I have to go afk for a while, ttyl!
<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.
<amz3>got and idea for the potluck
<vanila>what is it?
<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>sounds fun :D
<amz3>vanila: do you a plan?
<amz3>do you plan a dish?
<vanila>hmm id like to but i don't have an idea yet=
<amz3>hmm... the hard part ;)
<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>6 vs. 9 seconds, roughly.
<davexunit>it's really nice to see things *speed up* significantly when they are moved from C to Scheme.