IRC channel logs
2023-11-03.log
back to list of logs
<apteryx>record-type-description on a &compound-exception condition returns #f; is this expected? <RavenJoad>What is the best way to express a configuration option? I currently have (define (%default-db-location) (string-append "/thing/" "later.sqlite")). But I want to let someone change this eventually (and to make unit testing easier). <RavenJoad>A parameter seems like the right way to handle this, but I'm not sure. <haugh>RavenJoad, parameters are pretty much ideal if you're only exposing an API. If you want to load config files you'll probably want to look at guile-config, though I recall some lighter-weight config library floating around which escapes me atm <RavenJoad>haugh: The config for this program will also be a guile "program", like Emacs' config, so no need for a fancy parser. Plus, I have not gotten that far yet either. <haugh>Parameters really threw me for a loop because they were the first time I'd encountered dynamic scope but it's safe to say that they're a gigantic boon <RavenJoad>The other thing is that these values are not really all that dynamic. You set them once and "forget them". I just need to change them for unit tests for now. <haugh>apteryx, on 3.0.5: (record-type-descriptor (make-exception)) => #<record-type &compound-exception> <haugh>RavenJoad, I don't use parameterize that much either, but just having that procedural interface is so much cleaner than regularly mutating the top level <flatwhatson>current-output-port is a good example of sensible use of parameters; generally "set and forget" but you can control them in scopes where you need to <RavenJoad>Fair enough. In this case %default-db-location could be renamed %db-location and done with a make-parameter. That way tests can put the test db (and store) in a reasonable location. <flatwhatson>they're also nice to use from the repl as a library user <RavenJoad>flatwhatson: That is really good to know, since I intend for this program to be usable from the REPL too. <RavenJoad>I may get a more concise answer here. What is the difference between a fluid and a parameter? <flatwhatson>RavenJoad: a parameter is just a nice interface around a fluid <RavenJoad>Is that really it? The manual seems to indicate that they are quite different. <flatwhatson>that's really it. fluids are an older idea for dynamic variables in scheme, but parameters are the distillation of that idea that got standardized in SRFI-39 <flatwhatson>> General dynamic binding mechanisms exist in several implementations of Scheme under various names, including "fluid" variables and parameter objects. The parameter objects specified in this SRFI are compatible with the semantics of all implementations of Scheme we know which currently support parameter objects (in the sense that it is possible to implement this SRFI so that old code works the same as before). <RavenJoad>Huh. Interesting. Good to know. Is there ever a time when a fluid is the correct tool, rather than a parameter? <flatwhatson>when bootstrapping support for parameters in your own scheme implementation, perhaps? :) <RavenJoad>I mean... that is not the case here, so I guess using a fluid is a moot point then. <flatwhatson>generally no, i don't think there's a practical reason to use fluids directly <RavenJoad>But I just refactored the three major configuration paths to be parameters rather than just functions, so hopefully running tests where I add documents to the store work nicely. <flatwhatson>guile is pretty old, so has accretion layers like this <RavenJoad>At some point, those layers will be removed though, right? <flatwhatson>why? you'd just break code that depends on fluids, to make them rewrite on an API that does exactly the same thing <RavenJoad>Fair enough. More just a "this thing is old and you should move to the new thing which is identical in functionality, but is supported by everyone" kind of idea. <flatwhatson>yes, that's generally the evolution of scheme features. implementations come first with something useful, then some effort goes into standardization of those ideas, then implementations play catch-up implementing the standardized API <haugh>well yes but Guile has been consistently innovative for 30 years so there's... a lot <flatwhatson>most successful standardization efforts work like that! <flatwhatson>i'm not sure guile can be claimed to be the innovator of a lot of these ideas, but it's done a good job of adopting useful stuff from other schemes which are now defunct or less popular than guile <RavenJoad>How does srfi-64 play with Make's -j flag? I seem to fail tests when I use -j, but never fail them without the flag. The srfi-64 srfi web page does not mention this topic at all. <apteryx>that depends of how your test runner works <apteryx>it can only parallelize modules at a time, not individual tests, as far as I know <mwette>parameter is not good if you have multiple threads and want to share among threads; then what you have is OK (or atomic-box) but use (set! %define-def-db-loc (const (string-append "/path/" "my-db"))) <apteryx>the garbage collector used in Guile is Boehm's, right? <apteryx>info '(guile) Conservative GC' says yes <apteryx>srfi-9 records do not support inheritance, right? <mirai>there's two senses for inheritance <apteryx>so we don't have generic record inheritance in guile yet <apteryx>I assume srfi-35 may be too condition-specific to be generally useful as a record type? <apteryx>what about R6RS records '(rnrs records syntactic (6))'? does it support inheritance? <mirai>I think SRFI-136 calls this 'parent fields' <mirai>so it might not be inheritance per se <mirai>you can read that SRFI to see what it says <apteryx>just noticed @i is not rendered at all in texinfo, at least in the info output <daviid>apteryx: there is no @i in textinfo, afaict, you should use @samp, iiuc <apteryx>but it's only meaningful for printed mediums or HTML <apteryx>is someone interested in reviewing the integration of srfi-128 in guile? <daviid>apteryx: you should ask that quiz on guile-devel <apteryx>I'll just send it over there, but was asking in case someone wants to be in CC directly. <daviid>better never cc, causse those who are there receives twice the same email ... unecessary <apteryx>some people filter mail like myself; CC goes to inbox, otherwise it goes to a guile-devel directory <daviid>i stand by my receommendation :) - do as you wish ofc <apteryx>./meta/guild is not usable in my build; I get: ./meta/guild: line 3: /usr/local/bin/guile: No such file or directory <apteryx>seems I need te export GUILE to ./meta/guile 