IRC channel logs


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>goops modules ...)
<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>Hey guys, I just finished this script for weechat: and I was wondering if any of you had any tips on improving the regular expression generating code around line 127
<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
<adhoc>ok, thanks wingo
<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
<mg_>lloda: thanks :)
<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.
<davexunit>in that case, does the getter suspend?
<davexunit>okay so the getter doesn't block at all
<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?
<wingo>just the first
<davexunit>that really clears things up
<davexunit>wingo: unrelated, but I've found a situation in which I think u64s are being needlessly boxed.
<wingo>tell me :)
<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
<wingo>with ,opt
<davexunit>will do
<davexunit>before I was just looking at disassembly
<davexunit>and I had a hard time finding a consistent pattern to it, I have a few places where this occurs
<davexunit>sometimes there's an ash op in the middle
<davexunit>sometimes there's a mul
<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> v1
<wingo> (* (bytevector-u64-native-ref v2 0) 4))
<wingo> (* (bytevector-u64-native-ref v2 0) 4) might overflow
<davexunit>ah I see
<davexunit>darn :(
<wingo>use a u32vector instead?
<davexunit>I could
<davexunit>I'll give that a shot
<wingo>that should prevent boxing
<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> 14 (bv-u32-ref 1 1 0)
<wingo> 15 (ulsh/immediate 1 1 2) at (unknown file):3:3
<wingo> 16 (bv-f32-ref 2 2 1)
<davexunit>I will definitely give this a try later.
<davexunit>wish I thought of this on my own.
<davexunit>thanks again!
<davexunit>I will certainly never exceed the u32 range
<davexunit>I just assumed that u64s would yield better bytecode because they were the size of a word
<davexunit>so naive!
<davexunit>okay, time for day job.
<dsmith-work>Monday Greetings, Guilers
<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>or linker
<wingo>linker, i would imagine?
<civodul>wingo: (system vm elf)
<wingo>ah, that isn't used at run-time
<wingo>only at compile-time
<wingo>and when looking for procedure documentation and so on
<wingo>right, see libguile/loader.c
<civodul>oh indeed
<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
<civodul>i see
<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>seems to come from 'make-promise':
<civodul> 3 (make-promise #<procedure 7f879fa6d100 at gnu/packages.scm:231:18 ()>)
<civodul>In system/vm/debug.scm:
<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>hahaha apparently not :)
<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))
<civodul>that should be the "cheap" case no?
<wingo>that's terrible :)
<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
<civodul>in try_parse_arity right?
<wingo>i have a patch
<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
<handsome_pirate>Y'all, I am consistently getting a test to fail on i686:
<handsome_pirate>Same test fails on power64:
<handsome_pirate>I can also reproduce with older versions of things:
<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, to create a bug report
<handsome_pirate>wingo: sure, give me a few
<wingo>ACTION goes afk
<handsome_pirate>As an aside, anyone know of anyone that is hiring right now?
<mejja>ACTION thinks we should mandate 64-bit machines!
<handsome_pirate>mejja: heh, i686 has become a secondary arch in Fedora :)
<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.
<dsmith-work>Most people that know that stuff are retired now.
<dsmith-work>And it's not being taught in schools.
<paroneayea>hi everyone
<paroneayea>oh hey it's handsome_pirate
<handsome_pirate>paroneayea: ahoy :)
<handsome_pirate>dsmith-work: alas, that is outside my rane of experience.
<handsome_pirate>wingo: email sent.
<paroneayea>gush is starting to get reasonably good
<lfam>Greetings! I'm looking at Guix code and I have a question about format strings. What is the difference between ~a and {~a}, which is used here:
<wingo>is that related to gettext?
<wingo>otherwise no idea
<lfam>Now I understand, those are literal brackets, and not part of the format specifier
<dsmith-work>Later Guilers. Last day here is seems!