IRC channel logs
2017-04-03.log
back to list of logs
<daviid>paroneayea: so, feel free to clone guile-lib, 'git checkout devel' (I prefer to work on new stuff in a devel branch, and keep master as the 'most up-to-date' stable) ... I suggest a new toplevel module (e-goops) (for extending goops, unless you or others have a better suggestion (or should we create a goops dir and have these extension as modules in that sub dir? then we just have to make sure we do not have name clash with guile's <daviid>janneke: amz3 davexunit ... anyone, feel free to propose new modules of course, and let's talk about these here and on guile-user... <zv>To give a quick overview of what I'm trying to do here: This is a guile script for the IRC client "weechat", that code reads out some values stored by the user of the format "(freenode #radare r2tg <NICK>) (freenode #test-channel zv-test NICK:)" for a list of IRC gateways <zv>Takes each of those and replaces the irc gateway username with the *true* username <zv>e.g "<slack-irc-bot>: <zv> This is zv using slack to access IRC" => "zv: This is zv using slack to access IRC" <zv>Also, it's the first plugin using guile for weechat :) <adhoc>is there a build guide for building guile on macos? <wingo>not that i know; i suggest mailing guile-user or guile-devel. also it could be there is a homebrew package <mg_>how do I handle optional arguments in the C api? That is when defining a function with scm_c_define_gsubr("some-func", 0, 3, 0, some_func);, how do I handle the 3 optionals/provide a default? <lloda>mg_: if (SCM_UNBNDP (first_opt_arg)) { first_opt_arg = first_opt_arg_default; } etc <davexunit>wingo: hi, I have a question about channels in fibers. let's say there are 2 senders waiting in putq, and a getter is added to getq. does the first sender in putq send their message and the getq is cleared, leaving the second sender waiting for another getter? <davexunit>asking because I am trying to write a much simplified version of a channel for use in a single-threaded, cooperative environment. <wingo>so if there are two senders waiting, or any sender is waiting, the getter will not add itself to any queue. it will pop off the sender from the queue, take the value on offer, and resume the sender. <wingo>the queue either has senders or receivers in it but not both. <wingo>correct. that's a detail tho, not a guarantee <davexunit>but it makes sense. no need to block because there's a message waiting <davexunit>if there are multiple getters, is the message sent to all of them or just the first in the queue? <davexunit>wingo: unrelated, but I've found a situation in which I think u64s are being needlessly boxed. <wingo>or send to list, that is fine too <davexunit>I have a program that uses a u64vector to store pointers into an f32vector. if I do something like (f32vector-ref v1 (u64vector-ref v2 0)) the boxing occurs <davexunit>the u64 is read from v2, boxed, and then unboxed for the f32vector-ref call <wingo>check how it expands, could be something goes wrong with the srfi-4 / bytevector translation <davexunit>and I had a hard time finding a consistent pattern to it, I have a few places where this occurs <davexunit>but I will check with ,opt next time I am able. I didn't know about this tool. <wingo>,opt (f32vector-ref v1 (u64vector-ref v2 0)) <wingo>$1 = (bytevector-ieee-single-native-ref <wingo> (* (bytevector-u64-native-ref v2 0) 4)) <wingo> (* (bytevector-u64-native-ref v2 0) 4) might overflow <davexunit>I suspect this is killing performance for me in a crucial area <davexunit>trying to perform a merge sort to sort particles by their y coordinate before rendering <wingo>for me that prevents boxing here <wingo> 11 (load-u64 0 0 0) at (unknown file):3:21 <wingo> 15 (ulsh/immediate 1 1 2) at (unknown file):3:3 <davexunit>I just assumed that u64s would yield better bytecode because they were the size of a word <civodul>wingo: BTW, the ELF loader ends up calling the bytevector procedures rather than the builtins, due to the endianness not being known at compile time <civodul>i wonder if we should somehow specialize the procedures for a given endianness <wingo>ah, that isn't used at run-time <wingo>and when looking for procedure documentation and so on <wingo>right, see libguile/loader.c <wingo>it's like the two views on ELF (segments and sections) <wingo>the loader loads up the segments -- not much work to do there <civodul>it was showing up in profiles of Guix, i should investigate where that comes from <wingo>(system vm elf) can read the sections <wingo>yeah it shouldn't show up in guix, that needs fixing somewhere <wingo>could be you are using procedure-property or something, or some arity checking maybe? <wingo>at link-time i never found it to be important but i could be wrong <civodul>right, things like (procedure-property original 'documentation) <civodul>so when you do that at run time (system vm elf) enters in action, right? <civodul> 3 (make-promise #<procedure 7f879fa6d100 at gnu/packages.scm:231:18 ()>) <civodul> 549:46 2 (find-program-minimum-arity 140220475795676 _) <civodul>wingo: oh that's because make-promise, does SCM_VALIDATE_THUNK, and scm_thunk_p needs the arity <civodul>and +/- each 'package' form in Guix calls make-promise <wingo>scm_thunk_p should use something else... <wingo>there is a cheaper check for thunk? <wingo>civodul: do you use smobs or something for procedures? <wingo>normally thunk? x should be cheap <wingo>ACTION just did a ,trace (thunk? map) <wingo>civodul: ok i think i figured it out, thunk? on some procedures is expensive. like case-lambda procedures. <wingo>things end up going to programs.c:scm_i_program_arity <wingo>which tries to just parse the bytecode to find the arity without doing the whole ELF dance <wingo>but evidently there is some case for which that's not happy <wingo>some common case where parsing the bytecode bails out <civodul>here it's just expressions like (delay foo) <civodul>which expands to (make-promise (lambda () foo)) <wingo>so i don't think it's the (system vm elf) that's too slow, it's thunk? that's not hitting the happy cas <wingo>ah -- doesn't have a case for assert-nargs-ee/locals <wingo>civodul: if your guix is against guile from git, have a go and see :) <wingo>maybe you are already on guile from guix tho <wingo>that test is kinda gnarly, i suggest you add "(exit 77)" to the top of test-suite/standalone/tests/test-out-of-memory while we fix it for 2.2.1 hopefully <wingo>the issue being that that test will exhaust available memory, and where it happens and what code paths get exercised depend a lot on your system <wingo>it should work but evidently it doesn't :P <wingo>handsome_pirate: would you mind mailing those links to bug-guile@gnu.org, to create a bug report <mejja>ACTION thinks we should mandate 64-bit machines! <dsmith-work>handsome_pirate: Yes we are, but for extremely experienced analog engineers. The kind that can design the analog frontend for a 8.5 digit DMM, for example. <lfam>Now I understand, those are literal brackets, and not part of the format specifier