IRC channel logs
2025-02-18.log
back to list of logs
<rlb>mwette: there's nothing like a (publically available) cursor right now, and overall, if you're looking at the commits from the start, you might also want to look at the overall "git diff -w START_HASH..utf8" since there's a lot of "noise" across the entire series as I tried to take things in very incremental, more reviewable steps. <rlb>mwette: there's also a transition where some things (like I think stringbufs) are withdrawn, api-wise, e.g. even if just internal _i_ interfaces. <rlb>i.e. there are some "transition points" in the series -- hopefully the commit messages make some of that clear-ish. <rlb>But regardless, I'd be more than happy to make adjustments, even if just to fix things you find unclear, or... <rlb>(There are also some internal helpers, e.g. the bulk 'find offsets' function, etc. <rlb>ACTION tried out (for no good reason) an x86 gcc intrinsics simd "is_ascii()" but it didn't seem to perform better, at least in some trivial testing. <sneek>I've been aware for one month <sneek>This system has been up 4 weeks, 2 days, 21 hours, 50 minutes <old>given a procedure object defined globally, is it possible to find its module? <wingo>yes, i think. but the same object can be exported from multiple modules <wingo>you are looking for its definition? <old>I'm looking to get the symbols of the module as in (ice-9 popen) from a procedure of it, say open-pipe <old>right now, I expect user to passe the module symbols and the procedure name along <old>but I would like to just pass a reference of the procedure instead <wingo>you can traverse the module tree and visit each module's public interface to build a reverse map from object to export <old>hmm not the prettiest I would say :p <old>You could have name collision also <wingo>i am assuming you are going from procedure in terms of eq? to module <old>see %apply-in-subprocess <old>and its syntax wrapper apply-in-subprocess <old>this does work like I intend <old>but user need to do: (apply-in-subprocess (a module) a-procedure arguments) <old>instead I would like to: (apply-in-subprocess a-procedure arguments) <old>assuming a-procedure is imported by the caller ofc <old>But yeah I could traverse the whole module tree + whole variables and compare with eq? <civodul>old: ‘known-variable-definition’ in (guix ui) may be of interest to you <sneek>civodul, you have 1 message! <sneek>civodul, janneke says: re #75658 me neither but thanks for the reminder, i've only been looking at core-packages-team a bit where glibc 2.41 landed just when i was working on 2.40 <old>civodul: Hmm I see it does a traversal from the root module and then submodules and so on <civodul>yes, it’s heavyweight, but it’s good enough for this use case <civodul>(providing hints to users on unbound variable errors) <old>Yes for an error path + hint to user the overhead is justified <mwette>rlb: I have a strong feeling that there needs to be a way to move around effeciently in a string (i.e., forward-char, backward-char). Currently, with fixed size chars, this is not an issue: just use an integer index. With variable-sized chars, something else is needed, IMO. <rlb>mwette: hmm, you mean something better than computing the new offset and calling string-ref or similar? <rlb>There are some cost savings to getting offsets in bulk, but other than that, what uses are you thinking of (and are you thinking of internal use, or top-level scheme use)? <mwette>rlb: With just an index, don't you have to go through the sparse-arrary every time? <rlb>Sure, but from the scheme level in a lot of cases, you probably want some other combination of operations, like string-for-each, etc. <mwette>Look at string-fold. Can you come up with a scheme implementation using utf-8? <rlb>char-by-char work should generally be avoided, I'd guess. <rlb>OK, so you're talking about new scheme level primitives (maybe internal-only) that allow you to implement things like string-fold? <rlb>And that wouldn't be served by the existing operations, or a new one? <rlb>OK, well then that's a more difficult api question, particularly if we're going to promise it "forever". <mwette>You could do string-ref but isn't that expensive? <rlb>But first I'd want to see if the existing operations can't do what's needed. <rlb>i.e. what's a good thing we don't have already covered, but could. <rlb>That'll tell us what we need, perhaps.