IRC channel logs


back to list of logs

<artyom-poptsov>zv: Hi. FWIW, I ended up with defining 'test-equal' macro myself:
<zv>radical artyom-poptsov!
<artyom-poptsov>Yes, I know.
<zv>i have had so much trouble with it
<zv>thank you!
<artyom-poptsov>IIRC, there were some problems with original 'test-equal' macro; and I had to re-define it anyways, because I wanted the macro to perform some additional function calls.
<artyom-poptsov>zv: You're welcome.
<zv>yeah, i know there are some challenges but it is really annoying not to have a working srfi
<zv>(srfi-64 at least)
<zv>thank you artyom-poptsov
<tfm>I'll try that if I can't figure out the shared lib approach. Thanks, mark_weaver.
<zv>in genereal, is there any way to setup a `test-assert' such that I can control the 'expected' and 'actual' fields?
<zv>like if i wanted to actually get my log file populated with the REAL 'expected-value and 'actual-value without using test-{eqv,eq,equal}, how would i do so?
<amz3`>zv: I did not understand
<tfm>Are there any good guides on writing extensions to Guile in C? The docs aren't very clear to me on this. I've built an so, but it always comes back with "file not found" no matter where I put it - /usr/lib64, /usr/local/lib64, $PWD/lib. It's a little confusing what I should be doing.
<tfm>I figured it out in the end - I used the C procedure available for defining new Scheme procedures directly in my source instead of using a shared library file. I still wish I figured that out though, it might be useful one day.
<amz3`>the hn processed crashed with this msg in dmesg:
<amz3`>[2203385.707363] traps: guile[25266] general protection ip:6ba01d57c2d5 sp:6ba00267b3f0 error:0 in[6ba01d56a000+29000]
<amz3`>[2203385.707617] grsec: From Segmentation fault occurred at (nil) in /usr/bin/guile[guile:25266] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/zsh5[zsh:24371] uid/euid:1000/1000 gid/egid:1000/1000
<amz3`>I'm restarting the process with 'ulimit -c unlimite'
<amz3`>I'm restarting the process with 'ulimit -c unlimited'
<rekado_>davexunit: yeah, reading and parsing the body directly from the socket would be better, but for that I'd have to modify things in Guile's web modules.
<rekado_>right now I don't want to do this
<rekado_>I'll first operate on the bytevector directly. At some later point I'll try to come up with a patch to Guile to handle this earlier.
***dsmith is now known as dsmith-work
<dsmith-work>Happy Friday, Guilers!!
<rekado_>I rewrote the bytevector splitter without ports and it's much faster than before, but still quite slow.
<rekado_>processing a 33 MiB body takes about 10 seconds.
<rekado_>The code is here:
<rekado_>I guess I could speed it up by not using bytevector-copy! twice for each part.
<rekado_>but then I'd have to make bytevector-partition less general.
<davexunit>rekado_: I recommend trying it out with guile 2.1 and benchmark again
<davexunit>if it's still slow, I can offer a few pointers.
<davexunit>I've had decent luck reading the 2.1 disassembly and optimizing
<rekado_>that's guile-next in Guix
<rekado_>will I have to update Geiser, too?
<rekado_>what I mean is: does the new Geiser work with *both* Guile versions?
<davexunit>depends on the version of geiser. there was a bug where it didn't work, but it has been fixed.
<davexunit>rekado_: the geiser-next package works
<rekado_>I guess I'll also need to rebuild guile-json for guile-next
<rekado_>don't think I can finish this today :-/
<davexunit>sorry, don't mean to send you down a rabbit hole
<rekado_>nah, it's good. I'll try this next week, maybe. But if you see something obviously slow in bytevectors-partition I'd be happy for some comments.
<paroneayea>amz3`: davexunit: you two might like Building Problem Solvers, which now has a gratis PDF version online:
<paroneayea>er, amz3
<paroneayea>it's about Truth Maintenance Systems and other AI topics, by some of Sussman's students
<davexunit>paroneayea: oh neat!
<paroneayea>heya wingo
<wingo>rekado_: for a small speedup maybe replacing equal? with eqv? or eq? in your loop
<paroneayea>wingo: btw I moooostly got in the tests for the ports stuff, though two of them fail, and I haven't figured out why yet
<wingo>but yeah the big speedup will be switching to guile-next i think
<paroneayea>though it's a lot of hacky copy-pasta
<wingo>paroneayea: great! i saw that mail, still catching up after holidays
<paroneayea>wingo: hope you enjoyed your holidaze
<wingo>'twas lovely
<paroneayea>twas brillig
<amz3>paroneayea: thx
<paroneayea>I have a copy of Building Problem Solvers on my shelf... I pick it up and thumb through it now and then. Maybe some day it'll be a good exercise to port the code they released to Guile
<paroneayea>ACTION pushes it onto the infinite project queue
<paroneayea>I'm snarfing so much code from Guix for Pubstrate that maybe I should just make Guix a dependency ;)
<paroneayea>ACTION going through the gcrypt support code right now
<dsmith-work>wingo: wb
<amz3>I am very happy with my talk proposal :D
<paroneayea>very cool amz3 !
<paroneayea>a lot of nice proposals up there... I hope it happens
<paroneayea>last year's FOSDEM room was *so good*
<davexunit>I think pjotr added a talk on my behalf ;)
<davexunit>I will almost certainly not be at fosdem.
<paroneayea>davexunit: aw man, I got excited :)
<paroneayea>davexunit: maybe you should give one at LP!
<paroneayea>though I guess LP remains pretty non-deeply-technical
<paroneayea>maybe a high level overview about why guile is a progressive environment for GNU
<paroneayea>would be cool
<paroneayea>could talk about a number of fun things happening here
<davexunit>I did make my voice heard that I think LP should have some more technical talks
<davexunit>yeah that would be a good talk for LP
<paroneayea>man, one thing I hate being at geiser's REPL, which probalby isn't really geiser's fault but comint mode
<paroneayea>when you get a value like
<paroneayea>$19 = #<canonical-sexp 371e440 | 7f0609768840>
<paroneayea>and FOOP all your colors invert
<paroneayea>also something like #<foo "bar baz ...>
<OrangeShark>paroneayea: oh ya, that is annoying
<paroneayea>I'm not sure how easy it would be to fix though
<davexunit>yeah I hate that
<davexunit>my single biggest issue with the geiser repl
<paroneayea>sometimes I run the same procedure again, just so it'll invert it back :)
<davexunit>so you've learned that hack, too :)
<paroneayea>so here's a list of really nice guix modules I'd love to see either factored into independent modules, or moved into guile proper:
<paroneayea>base32/base64 encoding; monads; gcrypt stuff
<paroneayea>the first two probably being the most reasonable to have in (ice-9 ...)
<paroneayea>in the meanwhile, I'm just snarfing things :)
<davexunit>paroneayea: base32 and base64 should absolutely go in
<davexunit>I've snarfed a module or two for guile-websocket
<paroneayea>so I'm still worried about Guile's RNG, because the manual doesn't inspire confidence :)
<paroneayea>first of all, it's not clear that it's seeded by /dev/urandom, there's no way to force that guarantee
<paroneayea>and maybe that's ok
<paroneayea>if I can get a big random number from libgcrypt
<jmd>paroneayea: I'm not an expert on such matters. But not all platforms have /dev/urandom. If you want a high quality RNG use somthing from gsl
<paroneayea>jmd: right
<paroneayea>well, libgcrypt has a random number generator also
<jmd>There are lots of RNGs in many packages. But which is best for your application ... well it depends.
<jmd>To quote Donald Knuth, "the choice of which random number generator to use, should not be made at random".
<paroneayea>well even if I get a large number, I'm not sure if guile's RNG is "good enough"
<paroneayea>for example, I intend to generate unique ids for a bunch of things
<paroneayea>ie, is a pretty cary read
<paroneayea>er, scary
<jmd>paroneayea: I am by no means an expert in such matters. I think there is guile binding for gsl however, and that has several high quality RNGs. You do have to however know what you are doing when you decide which one to use.
<paroneayea>jmd: I think I'm going to have to, in this case, defer a little bit of trust to "what libgcrypt believes to be good RNGs" in the interest of time :)
<paroneayea>it seems like libgcrypt is probably used for enough similar purposes where (eq? (good-enough?) #t)
<jmd>paroneayea: Well you can probably start off with an arbitrary RNG whilst developing, and later get some advice on what you need before you go "live".
<jmd>Chaning RNGs should not be hard, I don't think.
<paroneayea>jmd: that's probably true
<paroneayea>I've started with guile's RNG, but I'm just nervous about people adopting software while it's alpha, which does happen
<jmd>I know!
<amz3`>at last some quality time for hacking :)
<jmd>Some years ago, somebody took a random commit from the pspp repository and posted a windows binary on the web. That gave rise to a number of scathing reviews saying that pspp was a heap of crap, kept crashing etc.
<jmd>So then I started putting a big ugly warning on the titlebar for the non-released versions and I got complaints about that too.
<jmd>Be assured. Whatever you do , you will get complaints.
<amz3`>jmd: pspp le live streaming p2p protocol?
<jmd>amz3` ???
<amz3`>sorry, I was thinking about another project, I just STFW for pspp
<amz3`>ppsp is the other project:
<jmd>amz3`: On most search engines the "real" pspp comes up number 1 (assuming you type it correctly)
<paroneayea>ACTION shoots an email inquiring about secure random information to the guile-user list
<paroneayea>guile's random.c talks about using the "Multiply With Carry" RNG described here:
<paroneayea>that line was added in 1999
<paroneayea>when apparently it was still a safe idea to do this:
<paroneayea>I have just completed the file structure and will, in January, have a master made to press several hundred copies of a CDROM of random numbers. This CDROM will contain 4.8 billion random bits, in sixty 10-megabyte files. They were produced by a combination of several of the best deterministic random number generators (RNG's), together with three sources of white noise, as well as black noise (from a rap music digital recording). My
<paroneayea>intent is to provide an unassailable source for those who absolutely positively have to have a large, reliable set of random numbers for serious simulation (Monte Carlo) studies. The CDROMS will be distributed free of charge to interested scientists (except for a shipping/handling charge of $186.47&emdash; whoops, just kidding, to get your attention as well as indicate exasperation with the usual shipping/handling ruse. However, there
<paroneayea>may be a true charge for shipping, probably around $5.)
<paroneayea>a CDROM full of random numbers! good enough for everyone.
<paroneayea>I guess for monte carlo it makes sense
<paroneayea>probably the aim was not crypto I guess
<paroneayea>still selling a CDROM full of random data seems out there.
<paroneayea>the world chanes though, I guess.
<daviid>paroneayea: what guile version did you use to time?
<paroneayea>daviid: 2.0.11... probably I should have tried with 2.1.X
<daviid>ah ok, I wonder if 2.0.12 is faster, just curious really, *nod* 2.1.3 will boost these...
<paroneayea>daviid: I doubt it will improve the libgcrypt part, but it's probably fine on that end
<paroneayea>partly, I want to know
<paroneayea>how good is our RNG? how trustable?
<paroneayea>SCM_GLOBAL_VARIABLE_INIT (scm_var_random_state, "*random-state*", scm_seed_to_random_state (scm_from_locale_string ("URL:")));
<paroneayea>the initial (not-from-platform) state is from the diehard url? :)
<paroneayea>seems like the diehard stuff is pretty solid, and is pretty neat
<paroneayea>interestingly also talks about v8 using Multiply-With-Carry, whereas most of the rest of the world uses Mersenne Twister
<paroneayea>(not that v8's PRNG is what caused problems there)
<paroneayea>I know almost nothing about RNG's though. This is an interesting dive-in to learn though...
<zv>debugging guile is really quite something huh
<paroneayea>I really like debugging guile, though my debugging guile methods seem to be rather different than debugging say, python
<paroneayea>a lot more injection of pk, occasional use of ,trace and vm trap stuff..
<paroneayea>in python I just dump "pdb.set_trace()" somewhere
<paroneayea>it's different..
<zv>python has the convienent advantage of 1. source maps that work, 2. a whole host of debuggers with different debugging facilities 3. support for skipping particular functions if particular conditions are met
<zv>i'm sure i could write a trap to do any of the following, but that is so ridiculous on the face of it
<zv>all programs are EQUALLY powerful to debug because int3 is handled by the operating system and can essentially perform any action after receipt of the interrupt
<zv>i am so frustrated for so many different reasons with guile right now.
<zv>you have no idea how much i want to love guile, especially for writing gdb extensions without the totally whacky existing GDB langauge (and not python)
<zv>i know so much hard work goes into guile and i really appreciate weavers work but its just like.. incorrect code get generated, 2/3rd of the testing harness SILENTLY FAILING, a debugger that requires extensions and writing a set of elisp functions to be workable (although thats arguably more geisers fault, there is plenty that the debugger could do) .
<paroneayea>zv: the debugger doesn't require geiser
<zv>paroneayea: yes i know
<paroneayea>I don't use any of the geiser features for debugging (though I do use geiser)
<paroneayea>I don't know what you mean about 2/3 of the test harness failing
<zv>guile it's been a topic at least three times in the past 3 weeks
<zv>somone in fact wrote their own implementation of test_equal and test_eq to work around it
<zv>paroneayea: srfi64
<paroneayea>zv: yeah I know what srfi64 is, I use it
<paroneayea>I'm not familiar with it silently failing
<zv>even before that mark came back and said "oh yeah, you should really only use test_eqv because equal and eq can fail their assert"
<zv>except that the whole logical of srfi is to catch errors
<zv>*err, logic of srfi64
<zv>i mean, i get what he is saying and it is logical, not to mention he is a smart guy, but it is just extremely painful.
<zv>the debugger on the other hand, nothing is *broken* about it. I just need to debug a large amount of guile code and that means the following (without writing elisp)
<zv>,l "whatever", ,breakpoint fun, ,s ,s ,s ,s ,s ,s ,bt ,s ,s ,s ,s ,s ,s ,s ,s ,s ,bt (lookup tracepoints, find out guile tracepoints arent tracepoints in the GDB sense and arent particularly useful)
<zv>needless to say, geiser doesn't update my source window, although again that's not guiles fault
<zv>it works great with racket and chicken though!
<paroneayea>huh, test_equal isn't reliable?
<paroneayea>that seems surprising
<zv>paroneayea: i thought the same thing
<zv>paroneayea: i have tested it with every concievable change
<zv>i switched guile versions, that just made *different* things fail
<zv>i used the default and a custom test runner, no different
<zv>I can use (test-assert (equal?)) and (test-eqv) but not equal and sometimes not eq
<daviid>zv: did you look at guile-lib, it has apicheck and unit-test modules, just fyi, and also for info, guile-gnome, guile-clutter, guile-cairo, g-wrap ... use these
<paroneayea>it still doesn't make sense to me why test-equal would be considered unreliable though. How hard could that be to get to work?
<mark_weaver><zv> even before that mark came back and said "oh yeah, you should really only use test_eqv because equal and eq can fail their assert"
<mark_weaver>zv: am I the "mark" referred to there? ^^
<zv>i think so
<zv>whoever wrote srfi64
<mark_weaver>I don't think I would have said that
<daviid>I actually don't know these modules very well, I should. And I need to pickup a solution to start to write tests for my modules, it seems from what you wrote here that srfi-64 is to be dis-considered?
<zv>i think it was you but it might not have been
<mark_weaver>I didn't write SRFI-64, although I ported it to Guile 2 and imported it.
<zv>mark_weaver: sure sure, perhaps not the specification itself but it's implementation in guile
<mark_weaver>anyway, I think the most sensible thing to do here is to find out what's going wrong for you, and fix it.
<zv>mark_weaver: this is where my debugger issue comes in
<zv>also, i couldn't get macroexpand to work there either, although that could very well be an issue with my geiser or guile setup
<zv>daviid: i haven't checked that out, although that is neat
<OrangeShark>hmm, it looks like test-equal, test-eq, and test-eqv all have the same macro
<zv>OrangeShark: they do
<zv>whoever (person who was or wasnt mark) said that it has to do with the implementation of eq,eqv and equal? themselves
<zv>now, a frequent error I get is a regular old (error "EQ? such and such arent comparable") (paraphrasing), despite the fact that the code clearly runs in a `catch'
<zv>like just now, I got 'ERROR: Assertion failed (eq? x y)' inside of a test-eq
<zv>with `test-equal', nothing goes wrong even when it should have
<zv>it will either totally skip it without any warning (and wont update the passed count) or wont do anything and WILL update the passed count even if it failed