IRC channel logs
2024-07-10.log
back to list of logs
<daviid>rlb: ^^ you might consider using module-use! to, as it 'dynamically' import the module-public-interface of the modules listed in args ... <rlb>graywolf: not a lawyer, but maybe? Also, you may have noticed, but it's mostly dual licensed (did that so that both communities can benefit if anyone ends up interested in any parts of lokke -- the clojure world's mostly EPL...): https://codeberg.org/lokke/lokke#license <rlb>daviid: not sure I quite followed that <daviid>rlb: it allows to make changes to the module public interface of the modules you 're-export' after you called the re-export-public-interface macro, an absolutely essential feature afaic <rlb>In this case, I just want to re-export all the other module's symbols as-is. Are you saying module-use! would do that better somehow? <daviid>rlb: well, we have diff design opinions i guess, because imo, (1) you sould not re-export the names that are not part of the public interface of those module 'you manually parse'; (2) if you make changes to that public interface 'later on', in your implementation, you're not gone be able to use those. <daviid>rlb: and (3) no one should 'manually' parse a module interface (especially not a non public interface) to get access to ... from another module that is - all this can be solved nicely by adequately call module-use!, as shown by wingo himself :-) a long long tinme ago, in guile-gnome ... my 2c <rlb>daviid: oh, well that function was for very specific cases where the public interface (exports) of one module, e.g. "clojure core", is explicitly designed as the union of it and another module or modules, e.g. (lokke ns clojure core) -- i.e. that's an internal implementation detail that's nobody's business :) <rlb>In any case, I'll look at module-use! and see if it seems applicable/preferable. Thanks. <daviid>rlb: fine, but i stand by my comment - you're welcoe, no pun ofc ... <rlb>Fair enough -- still don't think I completely understand what you're suggesting, but I can delve later. <rlb>In this case I have a module that is specifically intended to re-export whatever another module exports. That's the current use case. I can't tell if you're saying I should do that a different way, or that I shouldn't want to do that in the first place. <rlb>(and it's all internal) <daviid>rlb: i am suggesting that to acheive that goal (not that you shouldn't do it), you use module-use!, not module-map - that it is internal doesn't matter <graywolf>daviid: I am looking at your example (thanks btw), why is there the (if #f #f)? <daviid>rlb: and if you allow me, 'by all mean', when a user here asks how to re-export the public interface of a module - it's a faq here - i think we should _all and always_ point the solution proposed by wingo in guile-gnome, not to suggest to 'manually parse', which is, by definition, 'static' <daviid>graywolf: not sure :-), but i think wingo wanted to return, in that situation, either undefined or nothing (as in (values)), we'd have to ask him, i copied that code a couple of centuries ago /j <graywolf>Ah, I see. I suspected that might have been the reason, but was not sure why not just use (unless (null? args) ...) instead. <graywolf>I have to say I do not really understand how it works, I will take your word that it does. Currently looking through guile manual for description of "interface". <rlb>daviid: Ahh, I'd missed the link in the scrollback -- OK, I'll have to understand what that's doing (and doing differently) better later. <graywolf>My understanding is that the main difference between this and module-map approach is that if I add some definition later, this will automatically pick it up as well, in contrast to the module-map approach. <graywolf>I admit I also do not fully understand why it is macro instead of a function. <daviid>as you did spot, i renamed it to re-export-public-interface <daviid>graywolf: so users may pass the module names without having to quote them ... <graywolf>I wish the guile manual would be bit heavier regarding this module stuff. I am pretty sure it is not possible to figure out re-export-public-interfaces by reading the info pages. <daviid>graywolf: right, it's not - you need to dig in the code ... <graywolf>So, if I get it right, resolve-interface return *public* interface of the resolved module, but for some reason REPL shows it as #<directory ...> instead of as #<interface ...> <graywolf>Sigh, I will return to it tomorrow, it is bit late for this <craigbro>doh, homerow mod fail, sorry... on that note tho. I noticed that there are not many, if any, docstrings defined for funcs and macros in guile, like define and define* is that an intentional decision, or is it just lack of time? <graywolf>Uff, scratch that, I was using resolve-module instead of resolve-interface <graywolf>Ooooh, and I can use (module-use! (module-public-interface (current-module )) (resolve-module '(ice-9 popen))) to import all non-exported binding as well. Pretty sure I do not want to do that, like ever. <rlb>So I'm not positive yet, but wrt current guile printing '?' for invalid argument bytes, it looks like it may actually be that libunistring (here) is broken wrt iconveg_escape_sequence, i.e. "guile $'\xb5'" in a utf8 locale should produce an escaped string in program-arguments because in strings.c we ask for SCM_ICONVEH_ESCAPE_SEQUENCE (I'm still inclined to think it should be an error by default), but instead it produces an ascii <rlb>question mark, as if we'd specified SCM_ICONVEH_QUESTION_MARK. <rlb>(I'll probably pursue this later, unless someone else does.) <rlb>ACTION wonders if libunicode upstream has tests for that... <rlb>s/libunicode/libunistring/ <dsmith>rlb, How is SCM_ICONVEH_ESCAPE_SEQUENCE ever defined? <rlb>scmconfig.h, and it looks like the value's right. <rlb>I think I just found it, but can't give a pointer to the source because the relevant libunistring code is autogenerated (in striconveh.c). <rlb>I'll file a bug later (if it is a bug). libunistring just doesn't have the escape handler at all in that code path. <rlb>i.e. it only checks for the error or replacement_char handler, and if neither, just does "?". <rlb>There's a *lot* of code in there :) <rlb>Looks like that also means that if we *did* switch to the error handler (so you'll actually know your data was corrupted by default), then that handler would actually work. <attila_lendvai>should a non-toplevel use-modules "work"? i.e. should this work in a file compiled to .go? (begin (use-modules ...) [some symbol referenced from a used module]) <civodul>if you the module is used to get bindings at run time, it’s ok <civodul>otherwise it won’t work: macros provided by that module won’t be visible at macro-expansion time <civodul>long story short: keep ‘use-modules’ at the top-level