IRC channel logs


back to list of logs

<minima>haugh: you're right re the `set!' issue, i also can't reproduce it in a MWE
<minima>ACTION investigating
<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>which can live anywhere.
<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
<sneek>Welcome back dsmith :D
<dsmith>sneek, botsnack
<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 -- 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)
<abcdw>sneek: botsnack
<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>oh! super, thanks civodul
<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
<minima>excellent, thanks civodul
<civodul>i do find it difficult in practice but that’s a different issue :-)
<lloda>i see
<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 in Gnus
<civodul>that gives access to the complete history of the mailing list
<lloda>i can't access that atm, but is it different from e.g. ?
<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>er. I don't recall if there was a bug report
<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
<RhodiumToad>example of workaround:
<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)
<RhodiumToad>that's probably the same problem
<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
<dthompson>ah okay
<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!
<sneek>Got it.
<antipode>sneek: later tell dmith: It's not a regular file port, it's a directory file port.
<sneek>Will do.
<antipode>sneek: later tell dsmith: You make those the same way you make regular file ports, i.e., with 'open-file'.
<sneek>Got it.
<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.
<sneek>Got it.
<antipode>sneek: later tell dsmith: So no, most likely it isn't ‘regular file port that is in the same directory'.
<sneek>Will do.
<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
<sneek>Got it.
<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>(or module-*, like RhodiumToad wrote)
<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)
<antipode>(Perhaps these assumptions are wrong.)
<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 ?)
<graywolf>Yeah I prefer the ? :)
<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>| instead of < ?
<RhodiumToad>docstrings are documented in a weird place
<old>how is it more portable?
<antipode>old: | instead of #{}#
<RhodiumToad>specifically, under the procedure-documentation function
<old>I did not know you can do that. Is this a SRFI thing?
<antipode>old: No, it's a R7RS thing.
<old>antipode: I see
<RhodiumToad>(read-enable 'r7rs-symbols) to enable |...|
<RhodiumToad>(needs to be in an eval-when for obvious reasons)
<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>and M is compiled
<old>where the read-enable go?
<antipode>old: I don't use read-enable.
<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)
<old>ah I see
<weary-traveler>antipode: i'm confused. change guile's procedure-source how?
<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.
<weary-traveler>antipode: ah. okay
<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
<weary-traveler>well new to guile, but not programming
<weary-traveler>nor lisp
<RhodiumToad>procedure-source currently just gets the value of the 'source property of the procedure
<weary-traveler>and that's likely underused
<RhodiumToad>and as far as I know, nothing currently sets that
<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
<weary-traveler>old: agreed.
<old>weary-traveler: Typically if you use Geiser in Emacs, you can get the documentation quite easily with C-c d d
<old>C-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
<dthompson>geiser is a must-have imo
<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
<old>that's very true
<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.
<weary-traveler>there's no lsp implementation?
<RhodiumToad>ACTION doesn't use geiser
<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
<weary-traveler>(i use emacs anyway, so this is mostly for curiosity)
<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
<weary-traveler>dthompson: there's an associated protocol for debugging as well
<old>full power
<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> DAP
<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?
<dthompson>like multiple projects?
<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
<dthompson>which Geiser integrates with as well.
<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
<old>hmm I see
<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
<dthompson>and a geiser REPL for each
<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>oh I thought these were completely separate
<old>no no
<dthompson>I dunno sounds like you have a pretty unique situation
<dthompson>not sure how that would work
<old>for Scheme I agree
<old>but that's a typicaly workflow for C in GNU project
<old>mkdir build
<old>cd build
<old>../configure FLAGS
<old>rince and repeat for many builds you want
<dthompson>but that's the binary, not the source?
<old>in the source project
<dthompson>I'm talking about editing source files.
<old>sources are shared between build
<old>build only have binaries
<old>and generated files
<old>so *.go for example
<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
<daviid>dthompson: wrt your replace quiz above, fwiw, this works for me (snarfed from guile-gnome) - - lines 50, 88 - 93 [ just replace, no re-export ] - then in (g-golf hl-api signal), a specific gobject connect method is added, and connect is re-exported
<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
<weary-traveler>yeah, paredit
<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
<dthompson>testing out quassel
<daviid>ah ok
<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
<RhodiumToad>I regard this as less ugly than your method
<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
<dthompson>haugh: one sec I can tell ya...
<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.
<haugh>okay thanks much
<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>I think it's just french :)
<haugh>s/omg/mon dieux
<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
<RhodiumToad>you defined a method containing an explict (apply)
<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 ...