IRC channel logs

2021-01-24.log

back to list of logs

<justin_smith>Sven_vB: that should be (req #:key foo bar)
<Sven_vB>thanks for the confirmation. someone should fix it then.
<leoprikler>I don't think that FAQ will be updated soon ;)
<Sven_vB>in https://www.gnu.org/software/guile/libraries/ chapter "hashing", there's an odd "<*ENTITY*>hellip"
<rekado>Sven_vB: this comes from the texinfo conversion
<rekado>I fixed the same bug in the converter for the Guix website
<rekado>here’s the commit: https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/commit/website?id=ef4c897b919fcfba5db4225d175b8de7e55b4e70
<rekado>I don’t know how the Guile website is generated, but AFAIK the libraries section is generated from Guix packages.
***X-Scale` is now known as X-Scale
***amiloradovsky1 is now known as amiloradovsky
<spk121>janneke_: I got a basic mingw guile 3.0 checked in a branch of the upstream Guile repo.I'm going to try to pull in some of your mingw guile 2.2 patches
<alextee[m]>anyone know if there are windows binaries for guile somewhere?
<alextee[m]>one of those click click install things
<spk121>alextee[m]: probably doesn't exist
<alextee[m]>well i can't build my software with msvc then, it needs guile to generate some stuff
<alextee[m]>maybe I should switch to another scheme for that
<spk121>you can still get a pre-build guile 2.0 from eli over at https://sourceforge.net/projects/ezwinports/files/
<spk121>a fork of guile 2.2 is known to build on windows, but, I don't know of a package of it
<alextee[m]>what are the main differences between guile 2.2 and 2.0?
<alextee[m]>it looks like i set a strict requirement to >= 2.2, don't remember why
<alextee[m]>let me try with that prebuilt 2.0
<spk121>better VM, better Unicode mostly
<alextee[m]>it should be fine then i think, I only need it to run a couple of scripts to generate some files
<spk121>It appears that I'm the one who is furthest along in a windows build for Guile 3.0. I really should get that finished but, it is not fun.
<alextee[m]>yeah anything windows related is very frustrating
<alextee[m]>but a lot of users there
<alextee[m]>how can I fix this? Throw without catch before boot:
<alextee[m]>Throw to key misc-error with args ("primitive-load-path" "Unable to find file ~S in load path" ("ice-9/boot-9") #f)Aborting.
<alextee[m]>I copied the bin/ stuff in my path but I'm not sure where to copy the lib/ stuff to maek guile find it
<alextee[m]>i guess i can pass GUILE_LOAD_PATH
<alextee[m]>didn't work, I guess I'll stop here lol
<terpri>spk121, is there an eli5-level explanation for what makes it so un-fun? i would've guessed mingw and similar would be useful, but guile seems like the sort of program that would hit the margins of what it can handle gracefully...
<terpri>(i was able to do guile-emacs testing probably back in the 2.x days, using mingw iirc, but that was a while ago. i generally don't use windows at all except for $work)
<spk121>terpri: there are a couple things. The MinGW version of gcc doesn't handle Ctrl-C for break.
<spk121>sorry I meant gdb
<terpri>oof
<spk121>Also, configure is just much slower on Windows because it is running on MSYS which is itself running on a emulation layer. I get so bored of watching configure run, haha
<spk121>And also, at least back when Mark W was active maintainer, he'd insist that OS-dependent code should be fixed in Gnulib, not in Guile, so that is a lot of stop energy right there.
<leoprikler>tbf guile development would probably be easier if all portability woes are taken care of through gnulib
<joshuaBPMan>leoprikler  May I ask how much work is involved in doing that?  Also would that mean adding more C code to guile's code base?
<leoprikler>well, it would mean moving some stuff from guile's C and Scheme code to gnulib, but I don't really know how much
<joshuaBPMan>gotcha.
<leoprikler>For instance, file-is-directory? is implemented purely in scheme and does a weird hack when posix is not defined
<leoprikler>(basically, the non-existence of stat itself is why we can't have a C++-like filesystem library)
<joshuaBPMan>Would it be fairly easy to replace the scheme code for file-is-directory with the gnulib version?  I'd be happy to submit a patch.
<joshuaBPMan>also what's a C++-like filesystem library?  A library that has objects?
<leoprikler>Not quite, I just mean procedures that more or less cover the range of std::filesystem
<joshuaBPMan>hmmm...
<spk121>leoprikler: the difficulty with a gnulib-only approach is that gnulib doesn't implement windows versions of posix calls that don't map 100%. So instead of having approximate versions of 'ttyname' or 'getuid' or a dozen other things, gnulib doesn't bother. So Guile on Win32 just doesn't define a bunch of posix calls. And thus the test suite is full of '(if (defined? '...)' special cases
<leoprikler>well, perhaps having an approximate getuid is asking a bit much, but an approximate file-is-directory? should be possible
<leoprikler>(implemented through stat on linux and through something else on windoof)
***X-Scale` is now known as X-Scale
***amiloradovsky1 is now known as amiloradovsky
<ruffni>is there an easy way to save a program state (eg some variables) as the scheme code to produce those objects in a file? is `quote' laying in the right direction?
<ruffni>hmm. i doubt this was understandable. i'm exploring chickadee and would like to (optionally) read game state from a file at startup and save the modifications i make when the program exits. internally i'm handling data with GOOPS objects. should i write methods to handle the transformation from goops-object to string manually (format) or is there an "easier" way?
<rlb>ruffni: many options, and imagine it depends on your needs, i.e. could define your own serialize/deserialize methods, or you could consider just specializing write, or...
<ruffni>ok, but manual labor is required :)
<rlb>Not sure how many people would want it, but if I get time, I'd like to propose a module providing some kind of edn support. (That could allow type-specific reading via tagged literals.)
<rlb>but still requires "manual labor" to define the tag handlers.
<ruffni>EDN?
<rlb>There might be one, but I don't know of any automatic goops serializer/deserializer helpers. Though I suppose you could probably create a limited one automatically via reflection...
<ruffni>:) but what does "EDN" stand for/mean?
<rlb>i.e. one that prints an object-specific tag, walks any objects slots, serializes them, etc.
<rlb>But you'd have to define the protocol, etc.
<ruffni>with protocol you mean binary or characters?
<rlb> https://github.com/edn-format/edn
<ruffni>yeah, i was thinking exactly in this direction
<rlb>basically just slightly fancier sexps
<rlb>(and a bit more succinct)
<rlb>I mean it could be binary, but I just meant that if you're going to produce something that can be read by the normal scheme reader, you'd have to come up with conventions for the serialization.
<rlb>(object 'something #:slots ((foo 5) (bar 6))) etc.
<rlb>for a really naive approach, etc.
<ruffni>what conventions do you mean? naming? or more like white-spacing?
<rlb>(edn is just a subset of clojure syntax)
<rlb>No, I just mean the s-expression structure and semantics of your serialization.
*rlb would stick to s-expressions or json or... i.e. not interested in writing a new syntax.
<rlb>lexer, etc.
<ruffni>i'm not sure if i'd change *anything* about the syntax. just the same as i'd do within the code
<ruffni>maybe save it as a hash with names for the different loadable parts of the program
<rlb>Put another way, if you have an object with two slots, what does the serialized representation look like, i.e. what's the s-expression representing that object?
<rlb>(see #:slots above for a vague example)
<rlb>that's all I meant
<ruffni>(make my-obj #:slot1 13 #:slot2 12)
<ruffni>so that my program will simply create equivalent objects from the definitions saved to the file
<rlb>Ok, could be fine -- and if there are any security concerns, you might still want to write a function to handle parsing/unseralizing instead of relying on eval.
<rlb>if you're needs are simple enough, might be able to use (ice-9 match) to handle it. Of course if you have no security concerns, then maybe eval is fine.
<rlb>s/you're/your/
<rlb>(i.e. eval (and load) are completely unsafe, fsvo "unsafe")
<ruffni>by unsafe you mean anything could be executed by guile? well... i guess that's ok. it's not about parsing unknown input but about creating a scriptable utility
<ruffni>and being in the creative domain it should have to hold up too high security standards
<rlb>Right, just mentioning it in case we're talking about a config file or something that shouldn't be able to erase your home directory :)
<ruffni>yeah no :) but thanks for the hint!
<leoprikler>ruffni: kinda different from what you're trying, but in Tsukundere I simply use pretty-print :)
<ruffni>but just for preferences and history?
<leoprikler>well, yeah, but that's my entire game state
<ruffni>so you reinterpret all of the history?
<ruffni>that's cool!
<leoprikler>not quite
<leoprikler>on devel, we can actually skip parts of it
<leoprikler>because devel has a script stack mechanism
<ruffni>so you're figuring out which parts are necessary for the ultimate game state to load?
<leoprikler>more or less
<leoprikler>by default, we first init the history and then skip towards the script position
<leoprikler>(skipping meaning we call the resume thunk without an UI)
<leoprikler>however, this position is nested
<leoprikler>e.g. you can have stuff like (0) => (0 0) => (0 1) => (1) => (2)
<leoprikler>if you load (1), then it will evaluate (0) and (0 0), but not (0 1) and then (1)
<leoprikler>Moreover, Tsukundere allows games to set their own state.
<leoprikler>e.g. if you need to save variables outside the history, you can synchronize them as #:ruffnis-variable value, assuming you can (read (write value))
<leoprikler>In one of my games I use that to detect whether someone has loaded the game already.
<leoprikler>you can also count how many times someone has saved the game with such a mechanism
<ruffni>huh! this project sounds fun! i'll check that out sometime soon