IRC channel logs
2023-09-16.log
back to list of logs
<spk121>dthompson: in chickadee, is the search for assets just relative paths from the location of the scheme files? Or do you need to declare an asset directory path <dthompson>spk121: chickadee doesn't do anything. if you use a relative file name the lookup will be based on $PWD <dthompson>there's no special chickadee asset path or anything <spk121>cool. Last time I poked at guile-on-mingw it was for the last game jam. I wonder if I could make a win32 chickadee runner in time for October <dthompson>spk121: I would be *very* curious to hear updates about that if you do try <dthompson>like I really want to be able to ship games on windows but I just don't know how to fix all the stuff that's wrong with guile on windows <dthompson>performance will suffer greatly without jit, but one step at a time. <spk121>When game jam happens I never actually ship a game, haha. I get caught up in infrastructure. I'll just have to rest on my laurels from my 10th place back in 2018 <dthompson>it's very easy to get caught up on infrastructure. gotta get that done pre-jam <haugh>Not sure how to word this, but why do some 'procedure record printers' show the names of procedure arguments, while some show only underscores? <haugh>Aging user base. Greybeards don't pull all-nighters :) <cow_2001>Hmm. Nomad browser is in a prolonged hiatus, right? <FlaminWalrus>Is there a clean, standard way to inject values from the current environment into that of an =eval= call? I could define the world's tiniest module, but that doesn't seem right. <rrobin>as in (eval-string "..." #:module (current-module)) or something similar for eval <FlaminWalrus>rrobin: hmm...I have a local binding, which doesn't appear to get passed along that way. <rrobin>ah what about module-define! to set the binding manually <rrobin>that is what i'm using to set local bindings inside mine <rrobin>maybe there are better ways, i think there was some method to pass a list of bindings - but then I only needed one binding :D <RhodiumToad>obviously lexical bindings don't extend into an eval <old>how can I check for a OR close in match and still get the result? <old>(match (something) ((or "FOO" "BAR") the-someting)) <old>(and (or "FOO" "BAR") the-something) ? <mwette>old: did you look at the (? ...) form? <old>that works for predicate I guess <old>I could wrap the "FOO" "BAR" check into a lambda <old>but in the end, the and works! <minima>hi, i'm thinking of saving some config data in a text file (e.g. csv) - but then i worry about possible concurrency issues <minima>i suppose my options are to add some locking mechanism or to use sqlite and offload the locking mechanism to it? <minima>any other alternative that comes to mind? <rlb>Are you worried about corruption, or "lost updates"? i.e. is "last one wins" OK as long as the file is consistent? <rlb>If so, then you can probably just use the traditional atomic rename approach, and if solid durability is important, you can implement the "f(data)sync dance" with the parent dir, etc. <minima>rlb: hey, thanks, re corruption i guess there's little i can do (unless i went for a proper db but that'd be an overkill); i suppose an ordinary file vs a sqlite db bring similar corruption risks? i think i'm more worried about race conditions <minima>e.g. if an instance of the app tries to read the file while another is in the middle of a write operation <rlb>If the last one wins approach is OK, then you may not need sqlite. i.e. I think the traditional approach for last one wins is: <rlb> - Write the entry data to a temp file, <rlb> - fdatasync() the temp file, <rlb> - rename() the temp file to the final name, <rlb> - and fsync() the parent directory. <rlb>i.e. maildir algorithm (more or less) <rlb>May be an additional step or two you need if you also want to handle NFS in most cases. <minima>i think the last-one-wins approach would be actually perfect - i feel a bit stupid not thinking of it, it's a clever trick to make the operation atomic; this is brilliant!! thank you *so* much! <rlb>fwiw, debian policy describes/requires (or did) the more elaborate "NFS-safe" version. <rlb>(for all debian packages, or did) <rlb>And liblockfile implements it. <rlb>Certainly (and if you happen to need a quickstart for getting that working with the jvm, just let me know -- also have that handy (and it's a much bigger mess than in C) :) ). <minima>wdym the liblockfile? no prob, i'll look it up - i may need to do a bit of research, but i think this solves my problem <rlb>In debian, you don't have to use that, but you can -- and unless something's changed, you *do* have to do something equivalent. <rlb>ACTION is now curious, goes to see if policy still has that requirement... <rlb>Hmm, don't see it offhand, maybe that ship has sailed :) <minima>rlb, i suppose i'd need the read operation to also be atomic though? <rlb>Not if the reader opens the file and never closes it, I think? i.e. if you keep using the same file descriptor, you'll keep the snapshot you started with. Also, if it matters, this may not work at all on windows, i.e. iirc, you can't unlink/rename a file that's open or similar. <rlb>Alternately, the reader could open it, make a copy, and work from the copy (if it needs to re-open/close the file multiple times for some reason). <rlb>But if it's critical, suggest double-checking me on all this :) <minima>windows is not a concern but thanks for mentioning it; sure, i'll double check things, thanks, very helpful