<tupi>taylanub: actually gzip leads to 104757 and xz to 46892 <taylanub>I see. Still great, 1/2 difference. I usually think of it as being a minor difference. <tupi>the original size is 2842071 <tupi>damned it compiled the latest stable-2.0 git-clone too! so sorry to have lost your time guys, but i didn't know it needed a 'git clean -dxf' every build, or is it because of the version number change? <taylanub>I don't think one should need to use anything other than make(1) for cleaning. Perhaps distclean. <tupi>i did git pull; make then it failed, then i did ./autogen.sh --prefix=/opt; ./configure --prefix=/opt; make then it failed again, finally i thought of this git clean cmd, redo the all sequence and it succeeded <tupi>yeh i agree, i should have <taylanub>Hrm, what's the best way to test the code-coverage of my test-suite over my module ?.. <ijp>there is a code coverage thing, but it isn't particularly good <ijp>(info "(guile) Code Coverage") <taylanub>Yeah, I meant to ask how to use that to actually do code-coverage testing of my module. It has this `with-code-coverage' function which takes a thunk, but what exact code's coverage will it test ? Presumably of the thunk itself. <taylanub>So I wonder how to make my module part of the thunk itself ... <taylanub>I guess the code-coverage tools should ideally directly work on module objects. One would usually want to test whole modules at once. <ijp>(call-with-values (lambda () (with-code-coverage (the-vm) (lambda () (load "testfile.scm")))) ...) <taylanub>OK, while the installation and usage are all kinds of stupid, it's at least simple and the result very nice. <taylanub>Hrm, I'm having a hard time interpreting LCOV's visual (HTML) output, and am worried if it might be plain wrong in some ways. :P <nalaginrut>civodul: how about adding epoll if configure detected sys/epoll.h? <civodul>nalaginrut: i think wingo wrote an (ice-9 epoll) module in the past <nalaginrut>civodul: hmm...are you sure that it's not poll.scm? Or a new feature never merged? <nalaginrut>is there TODO list for ethreads? I can contribute something <civodul>there was some discussion on the mailing list <civodul>roughly it was not satisfying, because it came with a "parallel" implementation of ports <nalaginrut>anyway, I'm glad that guile inner server is well extensible <civodul>so the issue with epoll is portability <janneke>civodul: iow, we need to wait a couple of years for windows to die first? <civodul>it's just that we need to think about how to expose it <civodul>so far we've managed to avoid exposing OS-specific things, as for sendfile <taylanub>When using #!/usr/bin/env, I'm out of luck wrt. passing ARGV ? <civodul>taylanub: yeah apparently it gets everything in argv[1] <taylanub>Well I know that's how pretty much all unixen behave wrt. the shebang; thought there might be some hack we can use to get around it, as we get around it when not using /usr/bin/env. <taylanub>Perhaps Guile should always look at the second line of the file when the first line has a shebang, or specifically #!/usr/bin/env ... <civodul>actually doesn't `env' tokenize its arguments? <taylanub>Just tried; doesn't seem to, at least on OpenBSD. <civodul>so the problem is: how do we determine whether argv[1] needs to be tokenized? <taylanub>Yeah .. I needn't solve this issue at the moment though. I seem to remember reading that mark_weaver or someone else had plans to clean up the whole ARGV-passing system by the way, presumably having this issue in mind. <civodul>anyway, except for simple scripts, it's nearly impossible to use Guile in shebangs currently <taylanub>I mean on the mailing-list or so, someone had mentioned willingness to rework the whole strategy of how we handle the ARGV. <taylanub>Why is it nearly impossible to use Guile in shebangs, except for the /usr/bin/env issue ? I thought we can otherwise pass any argument via the \\ hack. <civodul>taylanub: because of non-tokenization, and because there's no command-line option for GUILE_LOAD_COMPILED_PATH, for instance <taylanub>Hrm, I think the "meta switch" functionality of Guile tokenizes according to some simple syntax, and we recently seem to have gotten a -C switch which adds to %load-compiled-path if that's what you mean. <civodul>taylanub: i think what's in "The Meta Switch" is not implemented, is it? <taylanub>That'd be nasty; I think it's been in the manual for quite some time. :P Let's try .. <dsmith>civodul, iirc the libev package does a pretty good job of using select, poll, epoll, kqueue, and other os-specific interfaces in a consistent way. <dsmith>You can chose one and let it fail, or let it fall back to something else. You can let it choose the "best" for your os. etc. <taylanub>Hrm, apparently one cannot get the name of a file created with `tmpfile', assuming it ever exists on the filesystem at all ... <brendyn>what would be the lamdba form that would produce a procedure that takes the exact same arguments display can? <fbs>(lambda (port string . args)) ? <fbs>oh wait, display only takes a port right? <fbs> (obj . port), or maybe use lambda* <brendyn>alright and then i need some kind of (when (exists? port) port) to pass on the arguments <brendyn>(im just writing displayn which does display but adds a newline <civodul>dsmith: yeah, i know there are such libraries, but maybe we don't want to add a dependency ***fbs_ is now known as bas
***bas is now known as fubs
<mark_weaver>brendyn: (define* (displayn obj #:optional (port (current-output-port))) (display obj port) (newline port)) <mark_weaver>taylanub: one way to get around the limitations is to make the top of your script a shell script that's within a scsh-style block comment (#! ... !#), followed by the guile script. See meta/guild for an example. <mark_weaver>of course there's an efficiency hit for doing that though. <mark_weaver>if you can avoid using /usr/bin/env, then you can use the meta switch effectively. <add^_>jao: hey, is there any other way to come around the åäö problem with geiser besides deleting the lines with one or more of those characters in geisers history? It's becoming annoying :-P <add^_>A page shows up asking if I want to convert text to some format. <jao>do you know how you end up with those characters in your history? <add^_>å ä and ö characters that is <add^_>Are you suggesting I should stop? ;-) <taylanub>Perhaps setting some encoding variables of Emacs ? <jao>i guess. is it reading or writing the file? <add^_>I'm not sure, I think when I shut down geiser, it needs to read the old history <add^_>And there the characters are, and it causes it to get confused <jao>if it's when you shut it down, it's writing <add^_>Why does it need to write the old history again though? <add^_>Doesn't it just need to "append" the new history stuff? <jao>it's a ring that comint mode puts in memory <jao>what's the normal buffer encoding in you emacs? <jao>add^_, it's indicated in the modeline <add^_>Eh? Doesn't say anything like latin or Unicode.. <jao>the characters at the beginning <jao>hover your mouse there <jao>that looks good enough <add^_>Wait, hm, in the normal text-editor it says undecided-unix, I was hovering over the REPL <jao>it might be a problem with comint-mode <jao>it could be writing utf-8 in the repl and reading back non-utf-8 <jao>i'll take a closer look later tonight <add^_>It might just be my fault too <jao>add^_, can you try the latest geiser? i just pushed a patch without thinking too much <taylanub>Hrm, when I run my code-coverage stuff from a script, it says zero coverage; copy-pasting the same code to the REPL works. <add^_>Should I uninstall the emacs-package one? <add^_>Ah, I can just update the repo and install the new one right? <jao>add^_, you can have both. just change the way you require geiser. <taylanub>Anyone have an idea why `with-code-coverage' would result in in zero coverage when run from a script as opposed to from the REPL ? <dlowe>so, I'm trying to update xchat-guile to guile-2.0 here <dlowe>and for some reason, every time it goes through scm_internal_catch, it crashes <dlowe>it dies on scm_call_3(), which seems to indicate that it tried to call the handler <dlowe>which is set to scm_handle_by_message_noexit <dlowe>oh, yeah. it also seems to work fine if I just scm_call_1() the function instead of using scm_internal_catch <dlowe>I assume if there's a problem, though, it'll blow up <dlowe>maybe not. It seems to use scm_call_3() regardless <dlowe>huh. does anyone use this thing? <taylanub>I wonder if there's a way from Scheme to get the size of pointers for the running platform ? <ijp>you can probably get it from (system foreign) <taylanub>I've been looking there, any idea how exactly ? <add^_>jao: tested now, it seems to work, I'll try it more some other time. <add^_>Well, I tried shuting down emacs and trying just for a last try. Didn't work.. <add^_>Whatever, I'll just stop using those characters for now <add^_>It's mostly something I discovered a while back and forgot to tell you about.. <jao>seems comint mode's history function are not aware of encodings, or at least i'm not making them aware of them <jao>so i'll need to investigate further <add^_>In the latest version of geiser <add^_>When I hit enter/return (apparently not all the time???) geiser complains and says "Invalid function: (eval compile)" <jao>that's a bit vague. i'd suggest toggle-debug-on-error and a backtrace... and maybe switch to #geiser. *dlowe resorts to building libguile with debugging symbols on *dlowe is amused at the .go suffix of guile object files. <dlowe>ok, I give up. It's dying with what looks like an invalid fluid num offset, and I have no freaking clue how all that works. <taylanub>Whoa, cool, our optimizer looks into vectors already. <civodul>dlowe: if you hit a build failure, could you report it to bug-guile@gnu.org? <dlowe>civodul: it's not a build failure. <taylanub>And cons cells. Both only when literal, by the way. Hrm, I wish it would literalize those that aren't mutated. I wonder if there's anything hindering that ? <civodul>dlowe: a run-time failure as well :-) <add^_>civodul: it's an old-program-not-working-with-current-guile failure <civodul>well, it's still worth reporting, of course <dlowe>The API is being used properly (in my version) <dlowe>The "standard" xchat-guile is all sorts of broken <dlowe>The intersection of xchat users and guile users is probably tiny <civodul>you could try to debug it, and then report whatever status you reached on bug-guile@gnu.org 