<flatwhatson>sneek: later tell civodul I've tested with libgc-7 and confirmed it doesn't have the mmap(PROT_NONE) bug. The difference is that libgc-7 defaults to `--disable-munmap` where libgc-8 defaults to `--enable-munmap=6`. Building with a libgc-8 with `--disable-munmap` doesn't suffer from the bug. ***sneek_ is now known as sneek
***apteryx_ is now known as apteryx
<civodul>flatwhatson: thanks for digging the libgc/--disable-munmap issue! <civodul>do you know if there are other implications of building with --disable-munmap? <civodul>i suppose the effect is that GC memory is never reclaimed, right? <flatwhatson>civodul: correct, so more likely to get oomkilled if it's a legit memory exhaustion <flatwhatson>otherwise i think it's not a big deal, especially as libgc-7 defaulted to having it disabled <flatwhatson>disabling it until upstream fixes the bug seems sensible to me <civodul>i'll change the libgc@8 package in Guix <wingo>civodul: issue with flipping jit permissions is if thread A is running code from partially-filled page P, and thread B goes to add to that page, it would probably cause a fault <wingo>a solution is, each jitted function starts on its own page. but that is terrible for memory <civodul>perhaps you can have one function per page on macOS if that's what it wants <civodul>and on GNU/Linux you'd make it read-only only once it's filled <wingo>yeah i think that makes sense as a short-term solution <wingo>not sure what an optimal solution looks like. apple silicon is really memory-constrained so i can't imagine that's their optimal use case <amirouche>hello, anyone can tell me how much time the following program take in seconds with a recent guile version? <amirouche>with guile 3.0.1 coming with ubuntu 20.04 (LTS), it runs forever. <wingo>probably similar on more recent guile, because it uses call/cc <wingo>should use call-with-prompt if you want it to go faster <flatwhatson>i think there is another bug here around "error creating finalization thread", spawn_finalizer_thread() sets the notifier callback to notify_finalizer_to_run regardless of whether start_finalization_thread succeeds, so we'll never retry launching the finalizer thread <wingo>do you think the finalizer thread should be the one to set the finalizer notifier? <wingo>i.e. move that call up to line 214 or so <flatwhatson>i was thinking 266 but yeah, maybe better to do it from the thread? <wingo>i guess i would want to make sure that entering guile didn't throw an exception -- assuming that in this case we're talking about severe OOM <wingo>so perhaps better to do so in the inner function, once we know that the thread is ready to do the finalizations <civodul>(i don't recall what the impetus was nor why i dropped the ball) *wingo cheers civodul and flatwhatson on :) <lampilelo>is it better to (let ((proc-input-param (modify proc-input-param))) (use proc-input-param)) or (set! proc-input-param (modify proc-input-param)) (use proc-input-param)? <leoprikler>if you need to extract that logic though, let is friendlier <lampilelo>(use1 proc-input-param) (use2 proc-input-param) ... <lampilelo>my question is more about what's the best practice, set! wouldn't allocate as much as let <leoprikler>As long as you don't use set, the compiler can optimize very much. <leoprikler>once you do alter variables, things are no longer so clear <leoprikler>see also the good old tail recursion loop equivalence <leoprikler>davexunit: For set! you need boxes IIRC, for let you don't <leoprikler>so if a variable is never set! you can just pass the pure value around <leoprikler>if OTOH it is, you need to implicitly generate variable-refs etc. <davexunit>I don't use set! much. I do use the generic method set! in goops code, though. <davexunit>but most of my low level code is using special setters for bytevectors and such <lampilelo>that's good to know, i try to avoid set! but now i think i'll avoid it more ***rekado_ is now known as rekado
<rekado>there seems to be a bug with r7rs include-library-declarations <rekado>getting errors like this: unknown location: source expression failed to match any pattern in form (((include "test-runner-simple.body.scm"))) <rekado>or this: unknown location: unexpected syntax in form () <rekado>I don’t know where this extra wrapping in parentheses comes from. <rekado>(I’m trying to package Taylan’s scheme-srfis) <wklew>rekado: I don't know if it's related, but cond-expand in r7rs define-library forms is also broken <wklew>it leads to similar looking errors <wklew>actually the same error: (from that post): unknown location: source expression failed to match any pattern in form (((begin (define foo 42)))) <wklew>oh wow looks like wingo just patched it! <wklew>I'm really excited for that, trying to develop portable R7RS libraries has been frustrating <amirouche>replacing either of the call/cc with call/ec does work too. <RhodiumToad>you can (I believe) do generators with delimited continuations, but (as the name implies) the dynamic scope of the generator has to be delimited somehow *RhodiumToad has played around with shift/reset to do some of this kind of stuff <amirouche>It seems like make-coroutine-generator can not be implement with delimited continuations. I have no practical experience with delimited prompt, even if I understand they re not "unlimited" <RhodiumToad>in particular, the thing you can do with call/cc that you explicitly can't do with call/ec is to store the continuation somewhere and reuse it after the call/ec has returned <RhodiumToad>using prompts is better, IMO, but you can't just switch call/cc for call/ec <amirouche>The way I say it is: given (call/ec proc), PROC will take the continuation as argument, and that continuation must be called during the extent of PROC, once PROC has returned the continuation is invalid. <amirouche>I was doing benchmarks about call/cc but I only tested wall clock time with bash's time. I need to also benchmark memory use, but that is more complicated. <amirouche>I mean, I think it is difficult to predict what will be on the stack in real program, and whether it matters. <RhodiumToad>it took me a couple of days of serious study to get my brain around shift/reset, mostly by using some stuff I found on oleg's site at okmij.org/ftp <RhodiumToad>I got to the point of being able to do a tree comparison coroutine-style <RhodiumToad>(i.e. given two generators each of which walks a tree, do they generate the same sequence) <wingo>i will be honest, i never got my head around the shift/reset formulation of prompts. the only concept that stuck was call-with-prompt / abort-to-prompt <RhodiumToad>is that why the documentation on them is so sketchy? :-) <civodul>wingo: same for me (and i'm glad i'm not the only one :-)) <apteryx>It seems the syntax-parameter value doesn't stick when the syntax recurses itself <wingo>RhodiumToad: yeah probably :) <leoprikler>W.r.t. 3.0.7, has 45131 made it upstream yet? :P <wklew>i think of shift/reset as being like prompt/abort except that the inner operator (shift) is "in control" <wklew>as opposed to abort, which acts like a handler <wklew>it is a funky inside out way of looking at a program <wklew>sorry, meant to say prompt acts like a handler, since it receives the continuation from the outside <RhodiumToad>e.g. (define (k3) (shift c (c 1) (c 2) (c 3))) (reset (let ((x (k3)) (y (k3))) (pk x y))) <apteryx>is it possible to pass an ellipsized value as an argument to a syntax helper procedure? <RhodiumToad>not by itself, it would have to be inside a #' form I believe <RhodiumToad>(define (myhelper s) (pk (syntax->datum s)) s) (define-syntax foo (lambda (s) (syntax-case s () ((_ blah ...) (myhelper #'(blah ...)))))) <RhodiumToad>(foo write 1) then pk's ((write 1)) and then writes 1 <leoprikler>btw. I just noticed, that ice-9 match doesn't handle #nil :( <lampilelo>ok, i hope my adventure with geiser problems is over, i made a patch, don't know if it's 100% correct but works for all cases i tested for, of course throwing away some syntax metadata but whatevs! i just want it to work <lampilelo>who needs the outer syntax data from #<syntax:unknown file:7:24 (#<syntax:unknown file:7:25 "foo"> #<syntax:unknown file:7:31 "bar">)> anyway <lampilelo>the thing is it's passed as `(,proc ,@args) to eval anyway <lampilelo>i wanted to change it to `(apply ,proc ',args) without passing args through syntax->datum but it produces some strange warnings i don't know the origin of *civodul thinks we may have a problem with thread->sleep_pipe and fork <civodul>sorry, that's not related to what you were discussing <civodul>but it looks like child processes can end up using the same sleep_pipe as their parent <RhodiumToad>um, well, fork and threads have never worked well together <apteryx>any clue how to make the following pattern work (is it possible?): (_ stem (field (field-type def ...) doc custom-serializer ...) ... (no-serialization ...)), where no-serialization should act as a present/absent toggle switch, rather than the catchall glob it seems to be currently behaving as <RhodiumToad>if so, you need to add it to the list of keywords in syntax-rules or syntax-case <apteryx>hm, I'm not sure I want it to be a syntactic keyword; I want it to be provided by the user of the macro <RhodiumToad>I mean, do you want the user to have to write literally (no-serialization whatever) <apteryx>e.g. (define-configuration my-config (some-field (number 10)) (some-other-field (string)) (no-serialization)) <RhodiumToad>because you're looking for the symbol no-serialization rather than some arbitrary (foo) <RhodiumToad>rather than having two rules, one with it and one without <apteryx>the macro body is rather complex and doesn't factorize out well (it makes use of with-syntax for example) <apteryx>it may be that my macro foo is too weak (it is!), but I couldn't make it work that way (via 2 patterns), short of copying most of the logic at both places <RhodiumToad>you want to omit the (serializer ...) clauses from the output if no-serialization is set?