<civodul>actually there was a similar patch by someone else right before <daviid>mwette: just a curious/learning quiz of mine: reading your email wrt enable_tmpnam, I see in the test - if test "$enable_tmpnam" = yes - you have spaces 'around' the = sign, and I sort of remember I did read somewhere that this was 'incorrect', in shell expressions, i wonder if i miss remember or miss red, wdyt? <RhodiumToad>no, the spaces are required in shell test expressions <RhodiumToad>test a = b # the "a", "=" and "b" are all separate arguments to the "test" command <mwette>yea. The man page for test indicates spaces. Some posts have quotes around yes (i.e., "yes") but I can't believe that is required. <RhodiumToad>if there are no expansions of any kind in a word, it doesn't need quoting (but it does no harm) <mwette>civodul: I see it the prev patch on #21076. I have no pref on which you take. <rlb>From within say syntax-case, is there a way to find out which module a given top-level binding came from, i.e. to find out that for say (some-syntax reduce), reduce actually came from (srfi srfi-1)? ***wxie1 is now known as wxie
***wxie1 is now known as wxie
<wxie>Hi, is geiser not needed anymore? <wxie>Emacs is asking for deleting geiser package. <wxie>GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5) of 2019-09-23, modified by Debian <rlb>Hmm, (module-import-interface (... (syntax-module #'x)) (syntax->datum #'x)) might be in the general direction of what I wanted, depending on the details... ***wxie1 is now known as wxie
<luni>Hi all... i'm in troubles using modules. I have a module defined in a .scm file but when do in the repl (use-modules (my-module)) or ,reload my-module looks like the updates made in the .scm file are not considered at all. Any kind advice to solve? Thank you in advance <lloda>luni does the (use-modules (my-module)) work the first time? or is it just the reload that doesn't do anything? <lloda>if a module is already loaded then (use-modules ...) won't do anything, this is normal. <luni>anyway if i modify a function no problem even after ,reload my-module .... but with macros i'm having difficulty since updates are not considered <luni>yes... what i have to do? <lloda>I'd put the macros in a different module so you can ,reload the rest independently <lloda>you may need strategic use of (eval-when (load compile eval) macro-def) <lloda>worst case restart Guile :-/ <Zelphir>The hammer method for times when not using the REPL and calling guile from command line is using the `--fresh-auto-compile` flag. <Zelphir>Not sure what that maps to when using REPL. <hugo>Hi! Does anyone have some good examples of how to handle user config in a program. Similar to init.el for emacs. <hugo>Currently in my main I do a prmitive-load on a config.scm, along with a module filled with parameters which the user can override. But it doesn't feel that solid <rlb>hugo: not sure which kind of solid you're more concerned about, but if you're worried about some flavors of safety, there's (ice-9 sandbox) and friends. <rlb>(Or I suppose even just a #:pure module where you add back in just the functions you need.) <hugo>rlb: I'm mostly concerned about program scaleability, and the ease of having a ton of config options <hugo>Since it's up to the user to actually run the code I'm not concerned about runtime safety <rlb>Depending on your needs, in clojure, nested maps/sets/lists/vectors are common for config values, and are assisted by get-in, assoc-in (assoc there is the opposite of scheme's), and destructuring. You could arrange something similar for guile if that were part of your issue (even if just via nested lists, etc., assisted perhaps by (ice-9 match). <rlb>But not sure that's the kind of concern you're contemplating. <mwette>civodul: sent "git format-patch" version to #29001 <hugo>Do you mean that the user provides some form of struct close to everything? <hugo>I think I want something close to how emacs init.el work. Where almost any code can easily add configuration options, and the user can setq on a whole bunch of values <rlb>maybe, or just by having "chunkier" (more complex) config values, you might be able to simplify the set of functions you need to provide, or... <rlb>(if that were anything you were concerned about, but it sounds like that's not a concern) <abcd>hugo: I am trying to do a similar thing, but I am very new to guile so it is taking me a while to figure out everything <hugo>abcd: Have you made any progress? <abcd>my idea is a bit different than yours, I would like to use guile to parse the CLI and parse a configuration file from the user that is in JSON <abcd>since I do not trust the user I can check if the JSON is properly formatted with guile <abcd>but I am not loading a scm file <hugo>It's still the problem of exposing the right set of options <hugo>I would recommend to not use json for configuration files. It's teadius and error prone for humans to write, and it doesn't support comments! <abcd>I am wondering why would you need a full configuration script instead of a file with some configuration parameters <rlb>abcd: if you're not set on JSON (or receiving it from somewhere else), I tend to prefer sexps for config files, i.e. just use read/write or similar. <hugo>A full scripting language for configuration allows infinite extensions. I keep pointing towards emacs, and for a good reason. Configurations and plugins are the same thing <rlb>(particularly if it's a schemeish audience) <abcd>we have been using JSON for some years now, I think my users would be really pissed off if I change <rlb>ahh, no of course then :) <abcd>besides the users come from a C/C++ background so they would be even more pissed of from a scheme syntax (I think) <hugo>A good reason for keeping JSON support. I would however still recommend adding sexp support alongside the json <abcd>at the time I chose JSON because it is ubiquitous and the syntax is not that bad <abcd>and it is very practical to ship it over sockets <abcd>the lack of comments is still the most annoying part <abcd>we sorta solved it adding fields that are not significant for the parser, i.e. {"note": "this is a comment"} <rlb>(specified as a "json superset" I think) <abcd>I will look into it, thanks! <abcd>there are some JSON parsers that would allow comments, though <rlb>Of course you could also just define your own comment syntax and then have a pre-parser that strips them out, but that's potentially messy, depending on how careful you want it to be i.e. effectivelly grepping out all lines that start with whitespace followed by #... is not very pretty :) (And of course doesn't work if you don't control all the consumers. <rlb>Yeah. I'd imagine it's a common extension. <hugo>I would recommend /* block comments */ over newline-ended comments for json. Since it's much safer when minifying the json <abcd>going back to the initial topic, I managed to embed the guile script in the source of my C program <abcd>I pass to the guile script the argc and argv values and I do the parsing in there <abcd>if the config file is specified I read it with a JSON parser <abcd>it is actually straight forward the implementation of this, now that I figured it out <abcd>it is just a few lines of code <abcd>what I am missing is pushing the configuration back to the C side <hugo>Guile can call C procedures. So just have a procedure in C lang which takes the parsed config <abcd>yup, that is what I am working on right now *alextee[m] is writing his first program in guile <mwette>alextee[m]: have fun ... it can be addicting <hugo>alextee[m]: Exiting! Writting anything in scheme before? <hugo>(Another scheme that is) <alextee[m]>thanks :) only guix packages and i loved it. i'm very excited <hugo>It's not my favorite language without reason <alextee[m]>i normally program in C but i'm trying to make it my go-to language for scripting instead of using python. just writing some scripts to produce files for my builds now <hugo>Sounds like a good project. My recommendation is to do everything in s-expressions as far as possible, and only serialize to strings at the very end