IRC channel logs
2024-06-23.log
back to list of logs
<Noisytoot>After switching to ecmascript with ,L in the repl, doing 1 + '1';, then switching back to scheme, why does (+ 1 "1") evaluate to "11" rather than being an error as before? <rlb>Noisytoot: can reproduce here, and seems like a bug, unless we don't promise you can switch back or something... <rlb>I know the reader doesn't work the way I'd expected, i.e. iirc it doesn't reset at the end of a module, for example, so maybe there's some other state that's not being properly restored when you switch back. <rlb>(at least doesn't reset keyword syntax changes) <mwette>Noisytoot, rlb: emacscript makes + generic. I wonder if that leaks out. <mwette>see language/emacscript/impl.scm, line 121 <Arsen>heh, perhaps + shouldn't translate into + <mwette>Maybe the bug is that emacscript/spec.scm doesn't use #:make-default-environment <mwette>but elisp doesn't use (make-fresh-user-module); scheme does <apteryx>(these changes were originally submitted to guile-devel about 6 months ago) <rlb>apteryx: looks like 71303 has been applied, and I'm not sure about the other two. I don't know/recall the policies around larger doc imports (srfi or otherwise, e.g. wrt licensing, etc.), and I'd need a bit of time to learn/investigate cond-expand carefully. Though, for that change, and if we don't have any already, I wondered if we might also want even a simple test(s) to go with it. Also wondered about returning unspecified <rlb>instead, if any of our existing precedents are relevant. <rlb>Finally (and unfortunately I can't recall the precise concern offhand), I wondered about listing else as a literal. I ran in to a number of subtle scoping issues when working on lokke that required using a syntax->datum based guard/fender instead of a literal, to avoid "aliasing" in some cases. <rlb>But also possible I was misunderstanding and hence "doing it wrong" myself. <graywolf>Hi. I am trying to make a new meta command. However for ,foo I keep getting Unknown meta command: foo. This is (all) of my code: (use-modules (system repl command)) (define-meta-command (foo repl) "todo" (display "hi!\n")) <rlb>graywolf: not sure yet, but if you annotate some of the operations in command.scm, you can see that add-meta-command! does nothing if there's no category, and a (define-meta-command (x y) ...) has no category -- i.e. ends up expanding to (name #f) in define-meta-command. <rlb>i.e. it ends up being added to *command-infos*, but not to the *command-table*. <rlb>No idea if that's what's actually intended there. <graywolf>Oh... Can confirm (define-meta-command ((foo xx) repl) ...) works. <graywolf>I was looking at the definition but so did not notice this. <rlb>Looks like a bunch of existing defs like ,warranty end up in the same boat. <rlb>If say ,warranty is supposed to work, then looks like we might need some additional tests... <graywolf>Oooh I see now, apropos works only because it is explicitly added to *command-table* <rlb>I suspect this might be a bug, but not sure, and 8fdd85f834aa1e0ed76542cdc8ce63d323dc6c1e looks suspiciously on point... <rlb>(If you'd like to pursue it.) <rlb>Though first I'd want to know what was actually expected to happen with commands with no category -- clearly that was an anticipated case... <graywolf>Not sure whether I should. This whole area is not even documented, so I have no idea what expected behavior is... <rlb>Fair enough -- even if it's a bug, doesn't have to be *your* bug :) <rlb>Wish I had a handy 1.9.13 around so I could try ,warranty there :) <rlb>graywolf: it looks like that change may just not have been consistent wrt the category. i.e. I suspect that it either needed to have some catch-all category, or to require a category. Right now any commands without a category effectively just disappear. So the only ones that work (I think) are those that are already mentioned in a clause in the *command-table*'s initial value, i.e. help, show, appropos, etc. <rlb>But others like ,warranty ,copying ,version can't be reached. <graywolf>There is this comment: `warranty', `copying' and `version' are "hidden" meta-commands, only <rlb>Oh, well then I take it back :) <graywolf>Those 3 seem intentional; not sure why thoug <rlb>So maybe that form of define-meta-command is really somewhat a hack to allow filling in entries for the *command-table* initialization entries... <rlb>I think I might rather just have an empty init value, disallow "no category", and fill in the table solely via define-meta-command invocations, but either way, some additional docs for define-meta-command would be nice *if* it's actually intended for broader use. <graywolf>At least Guix uses it, honestly that is how I've learned that it is even a thing. <rlb>graywolf: does this match your current understanding too? <rlb> ;; These cases (with category #f) will only produce functional <rlb> ;; commands if the name is already in the *command-table*. <rlb>(For the last two patterns in define-meta-command.) <rlb>(Maybe save future us a bit of time :) ) <mwette>graywolf: tldr; oh, it looks like you have it: (define-meta-command ((cmd cat) cmd . args) ...) <mwette>Thanks. It does not fully work, as I don't have access to locals. I got brned out trying to get more debugging into into the dwarf section. <trev>can someone give me a hint on what to use when you want to generate functions for a record using a macro? <trev>i think i need to be sure that the macro expands after the record type has been expanded (?) <wingo>what do you mean, functions for a record? <trev>context: guile-json doesn't support defining records with setters, so i want to generate my own <wingo>ah. basically the idea is to expand to a `(begin (define-json-record-whatever) (define my-getter ..) ...)` <wingo>for the my-setter, easiest way is to make the right-hand-side of the setter be something like `(record-modifier <my-record-type> 'my-field-name)` <wingo>the problem comes in how to name the setter, easiest if your macro form includes the name directly <trev>i do kind of have that already (working in the repl). just can't seem to get it to expand to all the (set-[record-type]-[field]! ...) procs <apteryx>rlb: you are right about 71303 having been merged, thanks to lloda! <rlb>...and I now see we're already using other literals elsewhere in there, so whatever my issue is/was, this change probably wouldn't be changing anything on that front. <rlb>Also, I see the "unspecified" question is orthogonal since your change isn't adding that. <apteryx>ah, it was closed already, I just needed to refresh <apteryx>rlb: re licensing attributions, I think I've done more than what we were doing so far <apteryx>e.g. mentioning parts of the doc is under the Expat license (MIT) and giving credits to the spec author for the doc (since I've mostly snarfed it, adapted for texinfo from the original html spec text) <apteryx>and I've ensured the SRFI implementations used (mostly as-is) all have their license and copyright notices in the file (via SPDX comments) <rlb>Oh, I'm just saying that *I*'m not yet familiar enough with what our "rules" are to be comfortable on that front, so that change will likely need to wait for someone else. <apteryx>OK :-) I'm giving the extra info to give confidence, if needed, that I've done my due dilligence (and then some) :-) <apteryx>adding SPDX metadata for all the files in the various SRFI repos is an ongoing effort, but it's been written down in their process that new SRFIs should carry these and pass the 'reuse lint' check. <rlb>I haven't looked closely yet, but does the else not need a begin? <rlb>(i.e. (else decl ...) -> (begin decl ...) or similar) <rlb>(Not at all sure yet, just wondered offhand.) <wingo>ACTION attempts to tag 3.0.10 <rlb>ACTION already has an emacs cve to finish packaging... :P <wingo>(we can have a quick 3.0.11 with many other patches, just gotta grease this train) <rlb>(well, not actually sure if it's a cve yet...) <rlb>wingo: sounds good to me. <apteryx>rlb: the 'begin' is one of the <library-declaration> forms <apteryx>r7rs define-library's cond-expand else clause may contain 0 or more library-declaration clauses <rlb>(I was reading the wrong cond-expand docs in the pdf...) <apteryx>(thanks for taking a look, by the way!) <rlb>OK, so at least to the extent to which I understand the docs, etc. now (and with the caveat that I've never really worked with r7rs libraries myself yet), it looks reasonable to me. <apteryx>wingo: since you are the compiler person, and time allowing, I'd like your input on #71301, which are just a few docstrings I've added while I was trying to make sense of that part of the code. I'm not sure I was successful, so you feel free to scrap it if you think it confuses more than helps. <rlb>I'd be tempted to merge it, but "not right now". I'm guessing wingo might not be very (plesantly) excited by that. <haugh>lechner, presumably you're asking about the lexical environment, not the module, which you can check with `defined?`; for local stuff I would do something like (guard (ex ((eq? (exception-kind ex) 'unbound-variable) 'N OPE)) not-bound) <haugh>oh i'm sorry, that was an old post that appeared at the bottom of my screen <daviid>wingo: it seems make-c-struct still is missing from the manual, fwiw <cpli>is it possible to get the source code of a procedure during compile time? <wingo>release done, will update web site tomorrow