<laertus>in a scheme-mode buffer, i typed (define abc 'def) and then eval'ed it in guile repl i have hooked up through geiser, then with point on "abc" i did: M-x geiser-edit-symbol-at-point and got these errors: "Geiser:cannot edit symbol at point" "Symbol error message:Couldn't find edit location for 'abc'" and "Module error message:Couldn't find edit location for '(define abc 'def)'" <apteryx>could someone explain what the (= field pat) pattern form of an (ice-9 match) match works? <apteryx>the doc says it matches "a ``field'' of an object". <apteryx>in Guix, I see this pattern used as: (= string->number transferred) <apteryx>where string->number is a procedure and transferred, a pattern that becomes a binding, apparently. <apteryx>I guess it just binds transferred to the result of applying string->number to the item at that position, but that'd make the doc lie, no? <dsmith>laertus: Did you eval the expression, like with C-x C-e ? <laertus>dsmith: i used (geiser-eval-definition) <laertus>but in my case there was no file associated with the scheme-mode buffer i was editing <laertus>so i have a feeling the error i got was due to that <dsmith>Yes. Geiser just passes the code to be eval'ed to the guile repl. Guile has no source file property for it. <ane>apteryx: if you compile the file C-c C-k then Guile should understand the source location <leoprikler>Is there a way of referring to the (- depth N) value of a fluid? <leoprikler>I could probably (save-current-state) somewhere and restore it, now that I think of it <mwette>Maybe fluids are not what you want ? Are you using with-dynamic-state or threads? <leoprikler>I'm kinda using them like boxes, but with a bit of manual set-current-dynamic-state <leoprikler>[context: Writing a game engine, want to load everything with variables in their initial state] <mwette>fluids provide thread-local bindings <leoprikler>There is no other thread to care about, though, except maybe GC. <mwette>Say you create a module-level binding (define x (make-fluid 1)). Then create two threads. In the first you eval (fluid-set! x 2), in the second you eval (fluid-set! x 3). x will be 2 in the first thread and 3 in the second thread: the assignments won't stomp on each other. <dsmith-work>Hasn't been a previsous message on that list since 2012! <civodul>yeah, Guix has been the target of spammer(s) recently :-/ <civodul>but yeah, the Guix list admins and IRC moderators know more <civodul>it's literally taken hours of hacker time to deal with this over the last few weeks <leoprikler>still, fluids are perfectly fine for my purpose, since everything is single-threaded <leoprikler>meaning I won't have the problem, that some variable gets stuck in a thread and can't escape <leoprikler>perhaps thread-shared fluids would make sense for some language implementations (like elisp), but I doubt that <civodul>leoprikler: fluids/parameters are per-thread <leoprikler>Is this due to how fluids are implemented or due to how threads are implemented? <leoprikler>I suppose somewhere in the thread startup routine with-dynamic-state is called, is that right? ***bchar_ is now known as bchar
***ecraven- is now known as ecraven
<mwette>leoprikler: check out pthread_key_create on the interwebs <leoprikler>so fluids are fancy wrappers around a pthread_key_t? <str1ngs>why not just tar xf $(guix build guile -S) :P <leoprikler>because tar xf unpacks everything when I really just want to get to fluids.h and fluids.c <str1ngs>gotcha so you use file-roller to cherry pick the files? <leoprikler>okay, it seems each thread has its own dynamic-state and fluid-ref accesses that of the current thread <leoprikler>IOW to implement thread-shared fluids you'd only need a thread-shared dynamic state <str1ngs>file-roller is probably still better for this if the tarball is unknown. a hack to do this with tar would be something like. tar --wildcards -x "*/libguile/fluids*" -f $(guix build guile -S) <leoprikler>except that file-roller cleans up after me and everything <leoprikler>okay, so I've learned, that while fluids aren't exactly pthread_key_ts, they are indeed not more than lookup keys to a dynamic-state structure <leoprikler>[which is probably similar to how pthread_key_t operates <str1ngs>leoprikler: gotcha, I'll may try this workflow myself. I have a tendency to use a terminal too much. <RhodiumToad>"thread-shared dynamic state" seems to be rather a contradiction <civodul>in bytestructures, what's the way to ask the offset of a field in a descriptor? <leoprikler>RhodiumToad: it probably sounds less exciting if I just call it "nested hash table" <RhodiumToad>you just want a hash table shared between threads? that's possible but requires using a mutex <leoprikler>but nah, what I actually mean is something like ((<procedure foo> . <hashtable>) (<procedure bar> . <hashtable>) ...), which may or may not require a[n array of] mutex[es] if I were to actually use it <leoprikler>or even just (list <hashtable> <hashtable> <hashtable> ...) <leoprikler>But again, no threads so I can use fluids just fine. <leoprikler>And if I ever need threads, I'll have my nested hashtables and call 'em... solids <cjv>Is there an alterative to creating a binding to TIOCGWINSZ for getting the width and height of the terminal? <leoprikler>These procedures, if called after initscr has been called, will return the size of the screen at the time initscr was called. <cjv>yeah, I was trying to avoid using ncurses, but that would definitely be the easiest <leoprikler>if not, you should probably adhere to the "COLUMNS" environment variable <cjv>COLUMNS and LINES are as shell variables, they aren't exported by default <cjv>(it will only work in the REPL) <cjv>that's the first thing I tried :P <cjv>I tried to figure out how guile's repl grabs them <cjv>but I didn't find anything <cjv>thanks for taking a look <cjv>seems like that's the closest we can get to a native solution <mwette>civodul: look at bytestructure-unwrap* - I think that might help <nckx>dsmith-work: Is sneek all right? <nckx>I didn't expect so many random people to ask in #guix the past few days, but (s)he is missed. Yay! <nckx>I can look that up. Sec. <nckx>[2020-09-30 04:46:39] *** Quits: sneek (~user@95.181.110.196) (Client Quit) <nckx>Unrelated: is it possible to get sneek to drop messages I know I have waiting, either to /dev/null or (say) a private query buffer? <nckx>Say it might be nasty stuff that needn't be repeated. <nckx>I'll try but I doubt it to. <nckx>Or invite them into a temporary ##sneek-insults channel? Does sneek accept them? <dsmith-work>It really ought to replay the message in the #chan where it was sent. <nckx>Oh, I thought that was a feature. <nckx>At least betwixt #guix & #guile. <dsmith-work>I'm off all next week (furlough!) so maybe I can put in some bot work. <str1ngs>dsmith-work: hello, sneek has been on holidays for some days. would it be okay to ping you when that happens in the future? <nckx>Well, these botsnacks are starting to smell, so I look forward to sneek's return. Thanks! <nckx>sneek: smelly botsnack xxx <nckx>str1ngs: I just did above š Poor dsmith is going to be inundated next time. <nckx>By the way: I probably asked this before, but sneek is privately owned & operated, right? No viewsource & pullhub? <dsmith-work>nckx: It's mostly the old sarahbot that was on #scheme long ago ported to Guile and bobot++ *nckx not cool enough to remember ā#scheme long agoā. <nckx>Heh, yep, at least that help message is familiar. Thanks for the background. <nckx>(Did sneek support the .repl? If so, sneek, I hardly knew ye.) <dsmith-work>No. I did have an eval enabled for a bit, but just for my nick. <dsmith-work>Guile didn't have the sandboxing then that it does now. <nckx>I was expecting that answer, but it was too cool not to try. <sneek>Welcome back nckx, you have 2 messages! <sneek>nckx, GooGooKnox says: Hey honey! I am going for vacation. Take care my sweet-heart! <nckx>Oh neat. sneek was already gone when the worst happened. <dsmith-work>I had my wonderful wife brave the dark and mysterious basement, fraught with scary electronic things, a powercyle the bot's box. <nckx>For a brief moment I wondered ā...wait why send your wife that's horribleā but then I remembered to read your nick. <nckx>Thank her, and I'll let you get back to actual work now. <dsmith-work>bah. I'm in short-timer mode anyway. Off all next week. <dsmith-work>str1ngs: And bot down pingage is best applied to dsmith. <str1ngs>dsmith-work: thank you, we do miss the little guy :) ***rekado_ is now known as rekado
<rekado>with the nyacc built with Guile 3 (instead of 2.2) I see this error when doing āguild compile-ffi ffi/drmaa.ffiā: āfailed to create path for auto-compiled file "ffi/drmaa.scm"ā <rekado>I see the same with āguild compile ffi/drmaa.scmā <mwette>rekado: is the path ffi/drmaa.scm consistent with the module name (ffi drmaa) ? <mwette>and I can't find that error message source <rekado>yes. It works with the older nyacc from Guix that was built with 2.2. <rekado>but the problem here appears to be with Guileās āguild compileā