IRC channel logs
2023-09-28.log
back to list of logs
<minima>haugh: you're right re the `set!' issue, i also can't reproduce it in a MWE <haugh>minima, I don't know the module internals enough to tell you exactly why this virtual path recursion (?) doesn't work. I think the problem has to do with you declaring the top level module from guile-user while the rest is read from the disk. I think your best bet for a REPL-debuggable `main' is to put it in (my-project main) and load that with (use-modules (my-project main)) from an executable <haugh>All of these archicture choices depend on exactly what your application is doing, who is initiating it, etc. <haugh>Couple of notes: your `%greeted' and `greeted' don't match, and `world' should be quoted in order to return itself as a symbol, not look up a nonexistant variable, <haugh>and you should double-check that your executable knows the load-path to the directory containing my-project <mwette>To be able to set! top-level variables in a module that module should have the #:declarative? option set to #f. It's "better" to make the variable a parameter or otherwise boxed object. <mwette>so that it can take on the default: #:declarative? #t <hugo>I'm writing a new test runner, and it fails on reader macros (read-hash-expand) which a weird error message regarding `map`. The runner runs with --debug set <hugo>Does anyone know anything about this? Or at least how I debug it? <rlb>wingo: just a ping wrt https://codeberg.org/rlb/guile/pulls/2 -- wondering if it's at least maybe interesting in general (parallel tests). I'm sure it'll need more work. It's also vastly smaller than the utf-8 branch (pulls/1 there) :) <minima>hi, is there a best practice when it comes to the order of the imported modules? e.g. should the "local" modules come before or after the "standard"/"external" ones? (although the term is probably incorrect, by "standard" i mean srfi and ice stuff) <minima>oh well, i had a look at some guile project and i see that srfi &co imports are at the bottom <minima>i can't tell whether it's just cosmetic convention or there's something more important going on, but i'll stick to that then <lloda>order of imports shouldn't matter <lloda>if there's a name conflict later import will override, but that should be avoided <minima>lloda: thanks - so it's mostly cosmetic then (provided conflicts are avoided as you say) <minima>and only partially related, any recommendations to lint away unused imports? <civodul>minima: there’s a new ‘-Wunused-modules’ warning in current ‘main’ <minima>(in main, that is possibly not packaged downstream yet?) <lloda>does someone else find it painful to extract a patch from the mailing list <civodul>minima: if you use Guix, you can add Guile as a channel and use the ‘guile’ package from there <lloda>even from the mbox there are replaced chars, extra whitespace, patches almost never apply cleanly <civodul>lloda: i don’t find it difficult technically, at least my mail client makes it easy <civodul>i do find it difficult in practice but that’s a different issue :-) <lloda>if you don't keep the messages tho <lloda>i guess you can download the mbox into your client and that works? is it the browser that messes up the format? <civodul>i browse the archive via gmane.org in Gnus <civodul>that gives access to the complete history of the mailing list <Arsen>shouldn't be, it should just be nntp access to the same <RhodiumToad>speaking of order of things, has anyone looked into fixing the bug with define-module where it processes re-exports before duplicates? <RhodiumToad>(this causes merge-generics not to work for re-exported symbols unless you do two separate define-module forms) <dthompson>hmm I may be entitled to financial compensation for this... link to the bug? <dthompson>it's been awhile but I have some weird goops + modules issues that I need to page back into my brain <RhodiumToad>simplest reproducer is to do something like a module (foo bar) that exports a generic (close obj) method, a module (foo) that re-exports (close), and observe that it doesn't get merged <dthompson>I think I have a different problem where I can't replace bindings when re-exporting <dthompson>like I have a project with a method named 'listen' (observer pattern) which I want to replace the built-in 'listen' (networking) <dthompson>yeah I guess generally re-exporting is flawed <RhodiumToad>it's not that, it's that re-exporting is done before setting #:duplicates so it's done with the default duplicates options <RhodiumToad>so when you're re-exporting or re-export-and-replace'ing a binding like (close) or (listen) then it just gets replaced, rather than being merged as a generic <antipode>sneek: later tell dsmith: The manual you linked to does not say they take "dir file port". Instead, it says it takes a "file port", and the variable is named "dir", indicating that the "file port" is a port for a file that is a directory. <sneek>antipode, you have 2 messages! <sneek>antipode, jackhill says: thanks! I actually hadn't run the linter on it since I thought there was enough to work on for a first pass. I'll have to check! <sneek>antipode, minima says: thanks for link to the `make authenticate' bug report! <antipode>sneek: later tell dmith: It's not a regular file port, it's a directory file port. <antipode>sneek: later tell dsmith: You make those the same way you make regular file ports, i.e., with 'open-file'. <antipode>sneek: later tell dsmith: Unless you have a special file system where you have regular files that are at the same time also directories, passing a regular file port won't do anything useful. <antipode>sneek: later tell dsmith: So no, most likely it isn't ‘regular file port that is in the same directory'. <antipode>sneek: later tell graywolf: You'll need to define a new macro (define-syntax + syntax-case), use scandir + call-with-input-file + that procedure that reads an entire file I forgot the name of to find and read the contents of files, use string->symbol to generate the name of the variables and use datum->syntax to turn the name (symbol) into an identifier that can be used in unsyntax <RhodiumToad>that's probably overkill for graywolf's question, the module-* version should be fine <graywolf>If I have a module that relies on (current-filename) to set some variables, how to make that work with geiser? Any tips? <sneek>graywolf, you have 1 message! <sneek>graywolf, antipode says: You'll need to define a new macro (define-syntax + syntax-case), use scandir + call-with-input-file + that procedure that reads an entire file I forgot the name of to find and read the contents of files, use string->symbol to generate the name of the variables and use datum->syntax to turn the name (symbol) into an identifier that can be used in unsyntax <antipode>graywolf: IIRC, current-filename is not the current file name. <antipode>Instead, IIRC, it is the file name of whatever module is currently being compiled. <antipode>You may need some macros to instead get the file name of the module at expansion time. <antipode>Or, without macros, maybe look at current-source-location instead? <antipode>All this is independent of Geiser though. <antipode>In short, it's the same way as how you make it work reliably without Geiser. <antipode>(Note: I'm assuming you aren't telling Geiser to load the module and that Geiser isn't deciding to ‘load’ it by just copy-pasting everything and evaluating it and worse without setting up current-filename etc appropriately) <graywolf>"whatever module is currently being compiled" - that is fine, I want to create an absolute path based on the module filename, basically (dirname (current-filename))... Well, in geiser (geiser-eval-buffer), (current-filename) returns #f, so I am thinking how to work around that. <RhodiumToad>do you want the files to be read at module compile time, at module load time, or some other time? <graywolf>Hm, from these options I assueme I want to get path to the filename at load time. Wait, how will that work with ~/.cache/guile? Will I get the .scm or .go file from (current-filename)? <graywolf>Honestly I am very new to guile, so I do not have great grasp on module compile vs module load vs other... <RhodiumToad>(current-filename) should always refer to the file containing the form <RhodiumToad>so the .scm file, even if it's currently loading a cached compiled version <RhodiumToad>note that (current-filename) is syntax, not a procedure <graywolf>Is there any functional difference between string= and string=? ? <antipode>From (guile)String Comparison: The first set is specified in R5RS and has names that end in ‘?’. <antipode>The second set is specified in SRFI-13 and the names have not ending <antipode>I don't think there is a difference except in naming. <graywolf>Right, I got from the docs there are two sets, one with ?, one without. But it was not clear to me if there is any difference beside the name. So thanks :) <antipode>There is a difference: they come from different standards. Probably not a difference that matters for you though. <old>One has good taste (predicate ending with ?) <antipode>How about #{is this string equal to}# ? The extra explicitness is probably not worth the verbosity though. <old>antipode: Ya nah. This is worst than Java :-p <antipode>I've gotten some use out of #{}# but I agree that this particular case is terrible. <antipode>What about |<expo:${:-}>|? I promise it makes sense in context. <RhodiumToad>I like postfix keywords, so I've ended up using #{ }# more than I'd like for prefix clauses on imports <RhodiumToad>kind of a tossup whether to use foo% or something rather than foo:, or use r7rs symbols <old>antipode: I wonder which context <antipode>old: <...>: record type, expo: expansion-position object, ${:-}: that shell environment variable expansion thingie <antipode>It's the record type of objects containing the position information (location of variable name and location of default value) of a shell expansion, in particular, the ${NAME:-VALUE} expansion! <antipode>It's used in a parser I wrote for Scheme-GNUnet. <old>so you have a (define-record-type <expo:${:-}> make... #{expo:${:-}?} ...) form ? <old>or something like this <old>oh I've heard this word before GNUnet <old>distributed network is that it? <weary-traveler>i am new to guile. what is the recommended learning resource? i've been using the reference manual, but today learnt that guile has docstrings (though i cannot find where it's documented in the manual) <weary-traveler>another question, what do i need to do to ensure that procedure-source returns something other than #f <antipode>old: yes, except that I now use |...| instead for more portability. <old>how is it more portable? <RhodiumToad>specifically, under the procedure-documentation function <old>I did not know you can do that. Is this a SRFI thing? <old>How does that work outside of evaluation? <antipode>weary-traveler: Change Guile's procedure-source to let it use program-sources (which does not return the sources, but rather the location of the sources) + use call-with-input-file & stuff to read it. <old>Say my Module M is imported by my script <old>where the read-enable go? <antipode>Instead, I pass the --r7rs argument to guild compile in the Makefile. <antipode>(Though quite possibly --r7rs does the r7rs-symbols behind the scenes) <antipode>By downloading the Guile source code, pointing a text editor at Guile's definition of procedure-source, and changing the implementation. <antipode>Basically, I think procedure-source needs a new implementation. <antipode>Though I would first just try to implement the new procedure-source without modifying Guile, as a separate procedure, say, new-procedure-source. <old>quite complicated for someone new to guile <RhodiumToad>procedure-source currently just gets the value of the 'source property of the procedure <antipode>At least the first time, it takes some work to set up a development environment for Guile itself, so I'd recommend implementing it as a library/moodule/ad-hoc definition whatever/... first. <old>still, a procedure aimed at debugging should work out of the box for users <dthompson>procedures store an arbitrary alist of key/value pairs. think of them as sticky notes. procedure-documentation gets the value associated with the 'documentation' key. <dthompson>I think procedure-source comes from a time when guile was but an interpreter, not a rather advanced compiler <old>weary-traveler: Typically if you use Geiser in Emacs, you can get the documentation quite easily with C-c d d <old>For source location, M-. works for local definition but does not work for external module .. <old>and working with Guile outside of Geiser is .. less fun and covenient I would say <weary-traveler>old: i don't have geiser set up properly, yet. but good to know that it provides conveniences for some of these things <weary-traveler>though i imagine the source-location would be "broken" in the sense as procedure-source is <old>dthompson: it is. but should it? <old>so anyone not using emacs is kind of screw <dthompson>interacting with a lisp system without something like slime means missing out on most of what makes development good <dthompson>I think slime/geiser-like tools should be available for every editor! <old>that would be awesome yes <dthompson>geiser is the best thing available right now. would be great if other tools could join it. <old>there is one I think yes <dthompson>I learned yesterday that LSP isn't really the same thing <dthompson>there is a partial LSP implementation for guile out there <old>I've seen a LSP for Guile somewhere on Github <dthompson>LSP apparently is more about static analysis <dthompson>whereas Slime, Geiser, etc. are about inspecting a running process <old>yeah like having the debugger inside your editor <dthompson>I think LSP support would still be nice because it's something more and more people will be familiar with <old>for auto-completion that would make sens <dthompson>but my understand is that as-is it could never replace Geiser <old>and discovery of project <weary-traveler>i think a feature-ful DAP implementation for guile could replace geiser <dthompson>would require some inspection to see if its built with the live coding workflow in mind <dthompson>which is related but different than debugging <dthompson>to me the most fundamental thing that has to work is that I can press a special key inside my editor and re-evaluate the expression that's under the cursor. if DAP could enable that, then that's a good start. <old>I wonder how does one handle multiple build tree? <old>In my projects, I have many directories build*. e.g. build-debug, build-release, build-benchmark, etc. <old>with different ../configure FLAGS <old>I typically work in C and use Guile for writing tests with bindings to the C library <dthompson>I avoid C at all costs these days but I do make extensive use of Emacs project awareness <old>the thing is, I would like a REPL for every build directory. I think this was not meant to be doable with the workflow proposed by Geiser <dthompson>I think treating them each as a separate project (as seen by project.el) would do the trick <dthompson>and then enabling per-project repls in geiser <old>I have not use the builtin project of Emacs yet. Still using projectile <dthompson>geiser might also work with that but would have to check the source <old>I'll have to take a look. Maybe helping emacs to understand that build directories are self-contained project would do <dthompson>I typically have at least 3 projects open at once <old>the thing is that if I do a C-c C-z, how do Geiser know which project it should go? Since build directories share the same Scheme source, but built the C libraries differently! <dthompson>I dunno sounds like you have a pretty unique situation <old>but that's a typicaly workflow for C in GNU project <old>rince and repeat for many builds you want <old>in the source project <old>sources are shared between build <old>build only have binaries <old>it is quite a mess for Geiser to handle <dthompson>you'd have to write the necessary elisp to be able to tell geiser which repl is associated with the current buffer <old>I think that having a global variable for the project might work <dthompson>if all those things share the same source then it would have to be a manual switch <old>so say you have 1 REPL per build tree. and each build has a name <old>select the current build <old>and now all geiser commands apply to this REPL <dthompson>daviid: I think in my case I was using replacing something being re-exported and guile didn't like that <weary-traveler>old: btw what geiser function is bound to "C-c C-d d *" for you (or equivalently the keymap bound to "C-c C-d d") <daviid>dthompson if you paste a snispet, or paste the repo and link, i can try to see if i can help ... <dthompson>daviid: it's been quite some time... I don't have a snippet handy. I'm not actively trying to debug it right now, somethign just reminded me of it earlier. <old>weary-traveler: geiser-doc-symbol-at-point <old>weary-traveler: you are using paredit ? That's like #1 on your list for Scheme <old>I guess if you say you had experience with Lisp <daviid>dthompson [ for info, there is dthompson2 nick here as well :) ] ok, just wanted to help - it definitely 'ought to wotk' in one way or another ... <dthompson>daviid: yeah I have another client online at the moment <RhodiumToad>daviid: that thing with connect looks like exactly the same issue I had with close, which was solvable by using define-module twice <old>dthompson: I'm writing on Geiser ML for advice to help Geiser understand my workflow <daviid>RhodiumToad: i don't think so, but anyway, i use and haved used a specific approach to solv ethis for about .. 2 decades or so :) <RhodiumToad>daviid: (libarchive base) has (define close (ensure-generic (@@ (guile) close) 'close)) which it exports in #:replace <RhodiumToad>(libarchive) re-exports that, which requires the extra define-module to get it to work right with merge-generics <dthompson>old: sounds good. you could also file an issue on gitlab. I've generally had good luck with that route when I have issues. <daviid>RhodiumToad: ah, the module thata re-export, as i said, i wrote a specific g-export macro, 2 decades ago :), which does what i want, and i find it a lot cleaner then your double module-define ... <RhodiumToad>the double define-module is only to work around the fact that #:duplicates is being processed in the wrong place <RhodiumToad>it's been a while since I analyzed it, but as i recall, what happens is that because re-export is having to find the imported definition, and it's run before duplicates is set, it always uses the default duplicate resolution <daviid>note that the module that grabs the connect guile def only replace, you can't be cleaner then that :) <mbakke>ArneBab: do you have tips for how to represent G-expression (or reader extension in general) with wisp? I did not find examples on that. <RhodiumToad>daviid: I think the main advantage of my approach is that it's not, as far as I know, forcing the default method to go through an extra (apply) <old>dthompson: filed an issue on gitlab instead <haugh>where can I find the code for the default interactive exception handler? I'd like to know if one can enter a debugger based on an exception object or if some essential context is lost. <haugh>That is, lost if the exception is not immediately captured by the debugger <RhodiumToad>I'd start looking in (system repl) or somewhere around there <haugh>yeah I'm poking around in system, just not finding where the default exception handler is installed <dthompson>haugh: so the repl installs its own error handler. call-with-error-handling in (system repl error-handling) <dthompson>currently outside influence on error handling is limited. the error handler can only be a built in of either debug, backtrace, report, or pass. <dthompson>I've been meaning to file a bug about this. the error handler has a case for if the error handler is an arbitrary procedure, but repl-option-set! doesn't allow anything but those 4 symbosl through :( <dthompson>I've done some kinda wild things to get the error handling I want out of the repl... <haugh>what does `le' refer to in `le-trap-handler'? <dthompson>git blame shows it was added in 2010 around the time there was a lot of "le whatever" on reddit on such <dthompson>but also people that maintain guile happen to live in france or thereabouts <haugh>you know you're on the bleeding edge when you can't discern French from comedy <daviid>RhodiumToad: 'forcing the default method to go through an extra (apply)', unless you change the topological sort mechanism used by goops, i don't see how that could even be possible <daviid>RhodiumToad: oh the 'core' connect, perfectly fine, it does not apply twice the method, the top-level method is selected by the dispatcher, and in this 'top-level' case calls apply upon a procedure ... nothing is called twice here <weary-traveler>okay looks like geiser-edit-symbol-at-point may be the function that i want to tweak <RhodiumToad>daviid: ok, so it looks like what goops does in ensure-generic is actually pretty much the same as what you did <RhodiumToad>daviid: even so, I still think my approach is better since that's ensure-generic's actual job <daviid>there is no miracle, it has to call apply ... which is perfectly fine ofc, and i still think my approach is better :) - note that it actually is not 'my approach', but wingo's approach ... not 'throwing the hot potato' :), but he certainly knew he could call ensure-generic ...