<ArneBab>manumanumanu: keep in mind that the algorithm itself must stay the same because of benchmarkgame rules ***catonano_ is now known as catonano
<daviid>dsmith-work: do we have a bot goops tutorial pointer? <guix-vits>Cool, in /query sneek one can say things without prefixing them with 'snеek:' <sneek>Sewni was last seen in (here?) 9 months ago, saying: I didnt realise you were using the bot :P. *guix-vits Actually not so: "*** snееk is an erroneous nickname" <marusich>Where can I find a good explanation of how to understand the use of ellipsis (...) in match clauses? <elliotpotts>I have a notice about the definition of the `SCM_UNPACK(x)` macro: in c++20, `volatile` on the left hand side of an assignment is deprecated <elliotpotts>so this thing will "soon" be invalid c++: `#define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x))` <elliotpotts>it's forcing the `*(volatile SCM *)` to be compiled though never evaluated... in order to typecheck x, I think... <elliotpotts> The 0?: constructions makes sure that the code is never executed, and that there is no performance hit. However, the alternative is compiled, and does generate a warning when used with the wrong pointer type. We use a volatile pointer type to avoid warnings from clang. <elliotpotts>I guess there could be a check for c++20 and replace it with decltype and static_assert <janneke>marusich: i guess that's what syntax-case does for you :-/ <janneke>(use-modules (ice-9 match) (guix build utils)) <janneke>,expand (substitute* '("foo" "bar") (("baz") "bla")) <janneke>IWBN if there was a way not to expand the "match" macro...hmm <janneke>then ,expand => (MATCH '("foo" "bar") <janneke> (for-each substitute-one-file files)) <janneke> '((? string? f) (substitute-one-file f))) *RhodiumToad is not finding this documented <janneke>ah yes, where i said syntax-case, make that syntax-rules, stop the clock <RhodiumToad>so I'm seeing by experiment that (... ...) inside a syntax-rules is a "quoted" ... identifier <RhodiumToad>aha. that part is defined in r6rs, but not mentioned in the guile docs <dsmith-work>daviid: Doesn't look like it (goops tutorial link). Do you know of one? <lloda>sneek: later tell elliotpotts easiest solution is to compile your code with -DSCM_DEBUG_TYPING_STRICTNESS 2 <lloda>I already argued for that to be the default <lloda>i didn't know dsmith-work thank you <civodul>wingo: would you be available to push 3.0.3 or would you like me to take care of it? <civodul>(not right now, sometime in the coming days) <wingo>civodul: humm, am a bit overloaded atm. if you have the cycles, plz do it :) <wingo>need to merge the arm patch to lightening tho!! <civodul>wingo: did that the arm fix need more work or more testing? <civodul>actually how do you handle merges of lightening in guile.git? <dsmith-work>civodul: It definitely some real problems. Though I was seeing some errors, most probably unrelated. <dsmith-work>civodul: There have been some update since I did any testing, and I haven't been able to get back to it. <civodul>dsmith-work: alright, we'll synchronize when i get around to preparing the release, then <wingo>civodul: lightening is merged via git merge -s subtree ***rekado_ is now known as rekado
<civodul>%after-gc-thunk shows high in profiles <wingo>i wonder if it is fake somehow <wingo>like if SIGPROF arrives during gc, will it necessarily be counted as after-gc-thunk? <wingo>or is it real and either the thunk it being called too often somehow, or taking too long <wingo>i don't recall seeing it at the top of profiles in the past <civodul>after all, statprof is just sampling the stack <dsmith-work>wingo: So I'm trying to remmember where I was at with jit on armv7. When the env var was set to always jit, it caused more problems. <dsmith-work>wingo: Any thoughts on why? Stress on mem allocation? Overwriting some bounds? <dsmith-work>The backtraces from core dumps seem to indicate a corrupt stack. <guix-vits>Hi daviid: Is GAsyncReadyCallback, and GCancellable are supported yet in g-golf? <daviid>guix-vits: not yet, actually at this moment, any function that accepts callback(s) will accept #f (which 'is' NULL), but not yet a 'real' callback - I statd to think about it, had a few very long chat wth the GI folks, g-golf will get there, but don't hold your breath <daviid>guix-vits: are you using the very latest g-golf? a source clone, checkout the devel branch ... the guix package is 'late', I wouldn't use it till ther is a g-golf release <daviid>guix-vits: in the paste you should remove line 47, a comment I made to myslf at the time, but that has been fixed, as line 48 shows ... <guix-vits>daviid: + on Guix there is no /bin/bash by defauld (only /bin/sh, and those /run/current-system things). Cool. ***slyfox_ is now known as slyfox