<zv>radical artyom-poptsov! <zv>i have had so much trouble with it <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. <zv>yeah, i know there are some challenges but it is really annoying not to have a working srfi <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? <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 libgc.so.1.0.3[6ba01d56a000+29000] <amz3`>[2203385.707617] grsec: From 80.15.162.25: 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_>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
<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_>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_>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. <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>it's about Truth Maintenance Systems and other AI topics, by some of Sussman's students <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 <wingo>paroneayea: great! i saw that mail, still catching up after holidays <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 <amz3>I am very happy with my talk proposal :D <paroneayea>a lot of nice proposals up there... I hope it happens <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>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 <paroneayea>man, one thing I hate being at geiser's REPL, which probalby isn't really geiser's fault but comint mode <davexunit>my single biggest issue with the geiser repl <paroneayea>sometimes I run the same procedure again, just so it'll invert it back :) <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>the first two probably being the most reasonable to have in (ice-9 ...) <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 <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>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 <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>I've started with guile's RNG, but I'm just nervous about people adopting software while it's alpha, which does happen <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? <amz3`>sorry, I was thinking about another project, I just STFW for pspp <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>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>still selling a CDROM full of random data seems out there. <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>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>(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 <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) . <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>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! <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" <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>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