IRC channel logs
2025-04-30.log
back to list of logs
<ieure>ArneBab, First one is someone's half-b <ieure>ArneBab, First one is someone's half-complete patch, which has at least one response, second has a response, third is someone saying they'll work on a patch. <ieure>ArneBab, What kind of "looking at" do these need? <ArneBab>ieure: the first needs the info whether someone’s working on wrapping (or whether I need to try it the weekend after the next when I hope I’ll have some more time). Second seems stale. The third I should not have posted here, because it seems to be active … (sorry) <ArneBab>arg, but the wine issues should have gone to guix, not here ☹ — I forgot switching the IRC channels after switching the issue tracker project :-( <ArneBab>I’m sorry … I think I should go to bed. <lechner>Hi, how may I obtain the record-type from an arbitrary record, please? I see it with pk <dsmith>lechner, take a look at pk. It's in boot-9.scm I believe <lechner>dsmith / no, i mean programmatically <lechner>dsmith / thanks, but that works only for record types over here. i have an instantiated record <dsmith>lechner, So.. use record-type-descriptor to get that? <wingo>rlb: i think if whippet works then we should branch 3.0, make master the integration branch, and start to integrate whippet, utf8, etc there <rlb>wingo: ok, thanks -- so I suppose that means that whippet's not likely to change the assumptions the C side depends on too dramatically to begin with. <rlb>By branch, do you think it'll probably need to be a Y or X release? <wingo>rlb: by branch, yes i think we need an abi break, should preserve api compat mostly, minus deprecation removal etc <wingo>it could be 3.2 or 4.0, i would just call it 4.0 tbh <rlb>OK, might want to ponder that a bit -- I can't recall offhand, but I think I remember some things I noticed while working on utf8 that might be nice to deal with if we have the flexibility. <wingo>yes we have time to do things :) <wingo>fwiw my whippet timeframe is 6 months or so <rlb>Also, I'd thought about moving some more of the code to scheme, but ran aground iirc with, I think, an issue where I couldn't get that to work as early as it was "bootstrapping" wise. <rlb>(string-related I meant) <rlb>I think I was trying to make one of the srfis (13, maybe) part scheme -- so some functions could be written in scheme, and ran into trouble. <rlb>(Don't recall the details, though.) <old>I'm trying to understand what's making guile load time slow: <old>$ time guile -q -c '(primitive-exit 0)' <old>perf(1) told me: 14.38% guile libc.so.6 [.] __strcmp_avx2 <old>I don't know if there's way to reduce this load-time <old>lookin at strace(1) output, I see a bunch of stat(2) syscalls and some mmap for extensions <old>it seems that unsetting GUILE_LOAD_PATH helps a little. I guess the amount of stat(2) syscalls is proportional to the length of %load-path <dsmith>I wonder if `fstatat` would impove things? (Just happened to see this the other day) <old>In term of loading time, Guile is 0.001 better than Python3 hmf <old>dsmith: actually Guile use: newfstatat <dsmith>It used to take multiple seconds to load guile (especially if you used the syncase module) <old>but the logic used by Guile seems slow here. It does the following <dsmith>I think a goal back then was to make it faster than Python <old>stat(1) a .scm to see if it's in a certain path in %load-path <old>then stat(1) a corresponding .go file <old>then openat(1) that .go file if both of the above worked <old>why not just do openat(1) and remove the second stat(1) entirely? <old>It would be nice to have a little faster loading time <old>shell loading time is 0.003 s x3 faster <old>but shell is so dumb I take it's normal <weary-traveler>old: how much time does the stat vs openat call take? i.e., if the file doesn't exist how much time does stat take vs openat? <old>weary-traveler: it's not one vs the other. It's the accumulation of both <old>if stat is only used for checking if a file exist, might as well just do the openat, saving a syscall <old>I think the culprit is in: load_thunk_from_path <weary-traveler>old: i'm aware it's not one vs the other. however, if the performance of those two syscalls differ and openat is more costly, then it would make sense (as a performance optimization) to guard it with the cheaper stat call. however, this potential benefit is only realizable when the openat would've been wasteful. hence my question <weary-traveler>if it turns out that the cost of doing a stat vs openat for a nonexistent file is the same, then i agree there's little reason to have the stat check. if however, there is a benefit, then it needs to be weighed against the cost of both doing a stat and openat when file exists <gabber>is there a guile way of parsing formatted input, e.g. like the scanf equivalent of printf? <old>weary-traveler: interesting <old>my benchmark show for none-existing file <old>stat(2): 0.0008 ms/syscall <old>open(2): 0.0013 ms/syscall <old>so you are right about that <old>that's actually an optimization <gabber>weary-traveler: no, more like in reading formatted (non-scheme) text into predefined variables <gabber>i'm parsing a (nginx) access log file <weary-traveler>yeah, you'd have to define the grammar in some way. if regexp works, use that. there's also PEG parsing <dsmith>ISTR that civodul had a custom reader package.. <dsmith>woah! ancient. Latest news reports Guile 2.0 support! Woo <gabber>i'll give the regexes a try - though i can not understate how much i miss a simple scanf rn <ieure>gabber, It's not really idiomatic in Lisps to parse stuff that way, like it is in other langs. In-memory, you keep it in a list structure, and if you want to send that between processes, you use the printer and reader. <ieure>This obviously doesn't cover situations where you're moving data between a Lisp and a non-Lisp. <humm>scanf is as unidiomatic as it gets in C as well <gabber>be it as it may - how would one parse a log file (and write the contents to an SQL db, let's say) in an idiomatic way? <humm>there’s any number of ways to write a parser and they aren’t Guile-specific <weary-traveler>gabber: if i care about maintaining the code, i'd define a PEG parser for the specific log file syntax <gabber>i have no experience with PEG parsing as of yet <gabber>but just glancing over it i somewhat doubt the gain in maintainability <ArneBab>gabber: that sounds like a classical case for a regexp — with parentheses to get specific groups. The main challenge is then to make the regex portable … (supported features vary wildly) <ArneBab>And thet process line-by-line (if it’s a line-based log) <dsmith>And as I always like to mention: Guile regexps are C regexps for C strings. NUL not allowed. (usually not a problem, but be aware) <gabber>ArneBab: portable? from Scheme implementation to Scheme implementation? <gabber>the regexp ([0-9]{1,3}(\\.[0-9]{1,3}){3}) now matches a whole IP address and also the last triplet. why? or better: how can i group a subexpression (for the {3} part) without matching against it? <ray1729>gabber: the internal parens introduce a capture group. With Perl-compatible regulare expressions you'd make this non-capturing with `(?:)` but I don't think this is supported by Guile's POSIX regular expressions. <ray1729>...so simplest thing would be just to write it out long-hand instead of using a repeat <dsmith>Or just don't use that capture group <ray1729>But I don't like this regex, it will also match things that aren't valid IPv4 addresses. <ieure>Lot of places are moving to JSON logs for this and other reasons. <ieure>Parsing log files sucks in any language. <gabber>well, the source of the data is to be trusted <gabber>and the purpose is not really about the integrity of the IP addresses (or timestamps or any other field itself) <gabber>yeah, does not seem like the "?:" worked :( <ArneBab>gabber: I meant portable between different languages. <gabber>ArneBab: i see. not sure what the benefit of such a portability were <ArneBab>The benefit would be that you could have a log format that can be parsed for every tool with one regex. But that’s far off … <ArneBab>irregex may actually be the best choice, yes … (didn’t think of that) <ArneBab>if you don’t need portability to different languages. <gabber>ray1729: that looks pretty cool! <dsmith>It would be great to have Scheme regexes, especially after rlb's utf-8 stuff lands <rlb>old: particularly if we're going to have an X release (though not sure it'd be required), I'd like to consider changes to the load behavior, i.e. the way it currently (I think) will fall back to a stale .go file when the "first choice" .scm compilation fails. Right now, I feel like that's undesirable -- and it has caused me trouble when guile was unexpectedly running the wrong (stale) code because the fix in the "scm" wasn't quite right <rlb>(i.e. I think guile should just crash immediately when the first compilation fails.) <ArneBab>rlb: during initial loading, yes, but during interactive development that would be annoying. If you want to re-load a module and made a mistake and then the whole state is gone that wouldn’t fly well. <rlb>No strong opinion about interactive behavior there atm, just concerned with the behavior when eventually deployed. <rlb>Oh, and by "crash" I mean stop the "load" process (throw or whatever), not (exit ...) :) <rlb>i.e. don't keep looking. <lechner>mwette / that might also help with load paths on Guix <lechner>mwette / as you know I don't usually care about typos but there may be a letter T missing in the title... saapp, for sand-alone app, for guile <mwette>sorry the saapp code is a little unpolished - i'll try to get the demo going <lechner>i am going to play with it, too. maybe all Guix executables should run that way. What's not quite working, please? <gabber>is guile-irregex not available as a module? how can i import it? (use-modules (irregex)) in a guix profile with guile-irregex does not do the trick <lechner>gabber / i use it all the time. will you please share your code? <lechner>mwette / also, thanks for all that high-quality software you produce. you really know how to fill the gaps with useful stuff <mwette>updated; after running look at xo.d/xoload.ci <mwette>guile-saapp would like to see scm_c_pointer_to_bytevector externalized in libguile <gabber>lechner: guix shell guile guile-irregex -- guile -e '(use-modules (irregex))' <lechner>gabber / try using -D -f guix.scm with an appropriate guix.scm <gabber>i feel like this is not the answer i'm looking for <lechner>automatic in the sense that it scans all inputs for Guile modules, but that's really something for #guix <gabber>lechner: could you show me how you import/use the irregex module in Guile? <gabber>and what was that -D -f guix.scm all about? <lechner>I am not sure Guile modules become available via GUILE_LOAD_PATH when not in development mode, but i'm not sure <gabber>at least in a profile with `guile' <old>mwette: yess! this. I don't see why we need to lookup all basic modules every time <old>Furthermore, the more you add to %load-path, the more you slowdown bootime because of that initial search <gabber>is there a way to make an irregex sexp non-capturing? <gabber>i want something like (with-open-db "db.sqlite3" (query "SELECT * FROM foo") (query "SELECT * FROM bar")) to work <gabber>or does that *only* work with vectors? <shawnw>Hmm. Looks like this dbi-query function only takes 2 arguments, so it can be simplified a bit to reflect that.