IRC channel logs
2023-09-30.log
back to list of logs
<haugh>RhodiumToad, can you explain more? <old>what tool is using the .x-sc* file in the guile repo? <old>I suspect sc is for syntax check <minima>(very minor observation, i tend to suffer from "module fatigue" where i never remember what a particular srfi-NUMBER is for or, conversely, in which module to find a certain symbol) <minima>the srfi numbering mechanism is not super user-friendly <haugh>the website has a nice real-time search bar though, and it gets easier than you think (though I still whiff it sometimes) <haugh>That's the only thing I don't like about Guile's policy for SRFI adoption; I much prefer the descriptive module names <haugh>also FYI duckduckgo and searxng have SRFI bang shortcuts so you can search `!srfi 42' or `!!srfi 42' respectively to pull up the doc nobody bothered to convert for the Guile manual :) <RhodiumToad>haugh: leapseconds are updated infrequently and in an unpredictable way. Therefore people don't update them in an automated way, which means that they never get updated <RhodiumToad>with luck, they will be abolished before the next one would happen, but that's not guaranteed <RhodiumToad>(fortunately the earth had something of a hiccup a while back, changing the day length slightly, making leapseconds unlikely for some years but risking the possibility of a negative leapsecond, which is an untested concept) <haugh>I vote we burn the whole system down and start over <RhodiumToad>that doesn't solve the problem that the year isn't a whole number of days <RhodiumToad>or the problem that the earth's rotation isn't quite stable <mwette>If you don't like leapseconds then just use the Julian Date system. <haugh>my sister dated a guy named Julian who was a huge douche so I abstain on that basis, which makes about as much sense as trying to keep time when any one of us could be closest to the nearest black hole <RhodiumToad>leap seconds have gone from almost one per year in the early days of UTC to only 5 since 1999 <dsmith>Ya, that's why TAI is just linear seconds from Jan 1 1970 <dsmith>Nope. But it's good for making time stamped measurements <old>is there a roadmap for guile somewhere? <rlb>old: I imagine wingo and civodul have various relevant plans, but I don't know of anything more formal atm, offhand. <old>rlb: I see. I wish things were less opaque in some way <minima>haugh: oh, that's cool re the SRFI browser shortcuts, thanks! <wingo>yeah sorry, guile is wonderful but kinda fits in between other things :/ <wingo>for me: my priority is replacing the gc with github.com/wingo/whippet. am not yet to the point of actually getting to guile yet <wingo>then the other big open things are rlb's utf8 work, and the spritely wasm-targetting work <wingo>i had some drafts at making guile produce better native code. but i am not sure how much that is important. it is, sometimes, but also compiler speed is important, and also some code doesn't need to be super-optimized. anyway it is hard to know. <wingo>the spritely work points towards some kind of whole-program compilation in guile. if we manage to compile all of guile, including the weird module system, to wasm, then that's a pretty interesting outcome <wingo>for guix, i think that replacing the gc is the highest-impact thing we can do. maybe speeding up the baseline compiler also. but speed of compiled code appears to be sufficient <minima>is there any facility in guile to handle what i think are clojure-like dictionaries, of the form `(#key value #another-key another-value)'? <minima>i suppose i can use hash-tables for this, but then that wouldn't serialise to file as nicely/easily, if i understand it correctly <minima>oh sorry, i meant to say `(:key value :other-key other-value)' :) <rlb>minima: there's no built-in external format iirc but there are various options for data structures more similar to clj's. i.e. pfds, fash, etc. I used pfds in lokke at first, but then switched to wingo's fash. (Though the persistent vector implementation is custom.). <rlb>minima: but you're not going to have similar semantics without doing some of the things I did in lokke, i.e. you'll may well need goops or similar to support more generic operations (type-wise). <minima>hey rlb, i was looking at lokke now! that looks very interesting, thanks for that <wingo>what should i do with fash btw? needs a rename of course, but i dunno where it should go <rlb>wingo: well I'd be fine with having it in guile proper :P One less dep for me :) <rlb>But seems like it could have a repo somewhere and we could collect various fixes/improvements (I have a few that might be useful). <rlb>No strong opinion though. I'd be OK hosting it with lokke's org on codeberg (or other) if that were preferable, though it's obviously completely independent. <wingo>rlb: i think it has proven some utility and its bugs are not too many though i don't doubt they exist so i would be ok with it being in guile <rlb>i.e. I'm happy to help, and not sure what you or others would prefer, arrangement-wise. <wingo>the problem is of course naming and documentation :) <rlb>If you decide what you'd like I can help with that (eventually). <wingo>need a good narrative for how it fits in with other things <rlb>I *do* think that it'd be great to have a good (enough) set of persistent data structures in guile itself, so that's where I'd lean, but I would say that, having spent a lot of time in clj for a while. <wingo>like it might replace some things (vhashes). might complement others. orthogonal to some. and where do we put it in terms of what we recommend to people <rlb>The main thing lokke really needs from it is a delete operator. Right now I just cheat, horrifyingly. <rlb>(magic is-deleted value) <rlb>It's for clj's "sissoc" fwiw. <wingo>i miss clojure's protocols in many ways :P a nice way to avoid the proliferation of names <rlb>wingo: I *have* tried to do some of the clj work in a lower scm-friendly way/layer, i.e. so more agnostic/configurable, so if we ever want some of that... <rlb>In terms of recommendations, my perspective is clearly tinted by my clj work, so I'd like to seee fairly flexible map, set, vector types, even if we need them to be based on less flexible, ore scheme-like in a bottom-level module for those who'd prefer no polymorphism. <rlb>I collapse on goops in there :) <rlb>i.e. completely critical. <rlb>That's how I did more or less all of it wrt general operations, when necessary like conj, merge, assoc, dissoc, etc. Anything that needs polymorphism is generic. <wingo>i feel like #lang would resolve many of our tensions. like it could be that guile-as-it-is remains a fine language for some tasks but also in many cases you would like a different vocabulary in which to solve problems (e.g. clojure) <rlb>I'd also love to see a built-in edn reader/writer :) Added that too, and has a guile-friently base layer where you tell it how to convert types. Not saying it's *great*, but maybe a start. <rlb>That's some of the more obviously scheme-friendly bits. <rlb>The persistent vector there is very much a scheme module, i.e. lokke-vector-length, etc. <rlb>But the vector in the parent dir is *not* :) <wingo>was your persistent vector faster, or did it have a more appropriate interface? <rlb>I had no idea fector existed when I started :) <rlb>But if fectors perform reasonably closely, then "why C", so worth considering later. <rlb>I'd love to see a slightly tightened up edn spec/parser (with maybe built-in support for "byte vectors") be handy everywhere I care about :) <rlb>Oh, and the atom in there is a (hopefully not broken) implementation of clj atoms in a scm/guile friendly way. Though one thing I really need at some point is thread pools. <rlb>A bunch of the other stuff that's not in scm/ could likely be ported to be scheme friendly without too much work, but those are the bits where I worked at it more. <rlb>wingo: one thing that'd be nice lokke compilation wise is support for "applicable types", etc. Because clj requires say (:some-key map) and to work. <rlb>Right not I do something pervasive and no real idea what it costs, i.e. at the tree-il level everything gets a trampoline, so (foo bar) becomes ((invoke foo) bar), and then invoke can be specialized for keywords, etc. <wingo>i think it's doable, but hard to make fast. basically you end up dispatching to some procedure when the callee isn't a "normal" procedure <rlb>Well, if what I'm doing is just about as fast, then maybe leave it alone, unless we need it otherwise. <wingo>you want calls to lexically-bound lambdas to be visible to the compiler. is a pretty big thing <wingo>so, it may be worth it to still lean on lambdas and direct application but also some sort of fallback apply function that probably gets overridden by goops when goops is loaded <rlb>ACTION has no idea yet :) <rlb>I'd also like to see at least a basic JSON parser in guile -- perhaps of much more general interest. I wrote one that's very straightforward, and also customizable like the edn parser, that we'd be welcome to, but that was before I noticed guile-json, so we'd I'm sure want to decide. I suppose it could be that we'd only want a more primitive one in guile, and the external one could be more full features (i.e. mine definitely doesn't <rlb>intend to handle streaming/events, etc.). <rlb>s/decide/consider that too/ (haven't looked myself yet) <rlb>i.e. it's *really* handy to just "import json" and read/write the flood of simple json that crops up all the time. <rlb>Hey, if that one's acceptable, let's go with it -- mine's been used by exactly 0 people in production :) <rlb>But happy to provide mine and help fix it if say that one's "too fancy" for the core or something. <wingo>basically for me, making 0 mistakes (via never including anything in guile) is worse than mostly solving peoples' problems ;) <rlb>Oh, and how do you feel about optional at least support for pcre regexps if/when we have utf-8? <wingo>well you know the core aesthetic, it's pretty minimal, but the documentation has to tell a coherent narrative <wingo>i don't know! regexp engines are gnarly. i guess you would link libpcre in that case? <rlb>Personally, I picked pcre for lokke's required #"regex" regexps, because I wanted something fast and *standard* -- i.e. seemed like our current support dpeends on "whatever the platform does", and that's hard to write solid code for. <wingo>i think that's probably not the best for guile itself but also the current status is garbage <rlb>Current status of which? <wingo>i am a bit tainted by working in the js world where they have very fast, standardized regexps <wingo>current status == ice-9 match <rlb>Right, in the end that's all I care about -- i.e. fast and standard, even if just "standard and almost always available" in guile. <rlb>I don't *care* about pcre2, but after a survey, it seemed like one of the best current choices... <wingo>ideally i would want something we could include at build-time instead of dynamically linking. dunno what civodul thinks tho <rlb>(and I suppose many are likely familiar with it via perl and the other things that use it) <rlb>You mean pull the source into guile, or just statically link, or...? <wingo>alternately if there were a scheme-only solution that would be best ;) dunno if it would perform well tho <rlb>On, and lokke's support is a mess, don't look at that -- mostly because pcre2 doesn't do utf-32 :) <rlb>sorry, latin-1 I meant. <rlb>I'd be surprised if in the medium run, we'd have a fast enough scheme-only implementation, but I'd love to be proven wrong :) <wingo>i mean, the macro expander can compile a regexp into scheme code, and then you rely on the scheme compiler to dtrt... dunno <antipode>wingo,rlb: We already have ‘applicable types’, though. <sneek>antipode, you have 1 message! <sneek>antipode, dsmith says: Thanks <wingo>fwiw the regexp engines in js are c++ that jit-compile regexps to native code <rlb>I'd be inclined to go with an optimized/sold UTF-8 lib, even if we had to require it, and just treat it as a required external dep. Can always adopt it later (plus or minus licensing) if the upstream has trouble. <wingo>antipode: is limited fwiw. and yes, i implemented it :) <rlb>antipode: right, and thanks, but yeah (and I forget the details), iirc it won't quite do what I needed. <wingo>rlb: yeah unistring appears a bit orphaned. dunno what to do about that <rlb>wingo: well, for any number of simpler operations, we can fairly easily handle it ourselves, or just steal its code. <rlb>But yeah, for harder things... <rlb>I did in fact reimplement some bits in the utf-8 branch... <wingo>right, applicable structs are just for structs; you can make the argument that (1 v) should mean something if v is an indexable sort of thing <rlb>But am happy to change any/all of it. <antipode>Is the idea that _any_ code, including Scheme, can do (#:some-keyword-argument 'argument1 'argument2), or would it be sufficient if this were limited to lokke? <rlb>wingo: clj doesn't actually do *that* at least. <rlb>antipode: just lokke for me for now :) <rlb>antipode: and it's only a handful of special cases iirc that really matter, but I'm not sure exactly what clj/jvm does underneath. If it uses a jvm interface/protocol, then it could be more customizable, but not sure we care, since, e.g. that probably wouldn't work in clojurescript, so it's unlikely to be "standard". <rlb>ACTION tries to remember what, if anything other than (:key map) is standard... <rlb>wingo: but back to the data structures, I'd love to see at least something for set/map/vector, and of course I've now been spoiled by more generic set/map/vector :) <rlb>But some of that asks potentially harder semantic questions, i.e. key order (sorted-set, sorted-map), equality, etc. and clj I believe leans pretty heavily on the fact that jvm objects have a hashCode. <rlb>short-circuiting many costs when provided. <rlb>also, various things are only well defined if everything involved is persistent/immutable (but I'm fine with that) <wingo>for me (fwiw, pinch of salt, etc etc): something that has no C and whose documentation fits into the manual in some coherent kind of way is an easy sell. documentation is crucial. with c is hard! possible if necessary tho. <antipode>If it's just for lokke, I think you could just do the ‘tree-il trampoline/dispatch’ thing in the lokke->tree-il compiler. Sure it's a performance hit, but it would only impact Lokke code, and from what I'm reading, it's necessary for a good/correct Lokke implementat. OTOH it's insufficient for '(scheme-map :some-lokke-applicable [...]))' <rlb>Yeah, I wasn't expecting say lokke's vectors to be likely :) <rlb>antipode: right that's what I do. <wingo>ACTION vanishes into the zzzz <rlb>Or rather the ((invoke orig-car) ...) is what I do, which is infinitely flexible (well as much as goops is). <wingo>one day someone will implement the apply-generic protocol :) <antipode>I think the biggest problem is interlingual interactions, because what's applicable from Lokke's perspective isn't the same as what is applicable to. <rlb>Oh, I also wrote up some of the standard uuid bits (b/c end requires them). Might be nice to have in the core (it's small), but not as interesting to me as json. <rlb>antipode: fwiw lokke tacks very close to guile, i.e. there's intentionally very little deviation wherever feasible. <antipode>Though for that interlingual you could simply have do (define (convert lokke-applicable) (lambda arguments (lokke-apply lokkke-applicable arguments))) and tell Lokke users to use that when crossing Lokke->scheme where appropriate. <rlb>e.g. clj namespaces (ns) *are* guile modules, clj functions can be called directly from guile and vice-versa, etc. <antipode>rlb: IIUC, ‘applicable stuff’ strictly larger than ‘clj functions’? <rlb>I was quite impressed by how much I didn't have to do -- very solid support for guile's both theory and practice right now, IMO. <antipode>Because IIUC, keywords are applicable in CLj, but they aren't in Scheme. <rlb>Right, but the scheme side doesn't have to care about that, because you can't write it, and the clj side hides the rewriting under the covers -- anything you could access from the scheme side will just be a function/method/literal/etc. you can use. <rlb>i.e. once clj compilation is finished, you just have a guile module with some exports. <rlb>wingo: if you're not completely zzz yet -- anything other than fixups of the commit messages that you think you might like to see wrt the parallel testing changes? <antipode>Unless there's some type information going on, I don't think you can completely hide and automate the rewriting. I mean, sometimes you are sending keywords to a Scheme procedure as keywords, but other times, its to pass an applicable (which needs to be converted to a procedure)? <antipode>Unless the position of the keyword is special (like in (E/Common)Lisp), I suppose. <rlb>So lokke rewrites clj (foo ...) as ((invoke foo) ...) during compilation, and the default specialization of invoke is just identity, and so it'll take "anything", and only act on things that have further specialization like keywords. <rlb>I'd show you where it happens, but I think that might just be more frightening than illuminating :) <rlb>(Though be happy to go find it if you did want to see it anyway.) <antipode>I was instead thinking of doing (scheme-procedure :lokke-keyword). <antipode>Is that kept as-is, or is it rewritten to (scheme-procedure (lambda arguments [invoke that lokke keyword]))? <rlb>It's rewritten to ((invoke scheme-procedure) :lokke-keyword), but (invoke <proc>) is defined as identity, so it just works as if it hadn't been rewritten. <antipode>It sounded like this keyword-as-procedure thing only happens when the keyword is in the ‘first’ position, not as an argument, but I wasn't sure. <rlb>Right, in clj keywords act as a function that looks themselves up in any map-like first argument. <rlb>And it's just this case that's an issue. In all other cases, we can use goops "normally". <rlb>i.e. this is the complex case because goops can't specialize on the function-position itself. <antipode>So that would imply (scheme-map :lokke-keyword (list something-map-like)) will result in a type error in Clojure (because can't invoke keywords), whereas (scheme-map-but-written-in-clojure :lokke-keyword (list something-map-like)) will work fine in Clojure (because Clojure semantics). <antipode>(Assuming that keyword objects are self-quoting in Clojure) <rlb>Oh, sure, none of this works from the scheme side with types normal guile code can't understand. But it *can* work from the clj side if we define suitable goops specializations, i.e. we could define dissoc for guile hash tables. <rlb>ACTION can't recall if he did, but suspect's he didn't. <rlb>i.e. in your example, that would become (*if* it were clj code): ((invoke scheme-map) :lokke-keyword ...) <rlb>and that would work if and only if invoke had been defined in the current module/namespace for scheme-maps (whatever those are) <antipode>So the rewriting isn't fully transparant, as the Lokke code should do scheme-map-but-written-in-clojure (lambda (o) (:lokke-keyword o)) (list something-map-like)) instead to make things work. <rlb>I'm not sure I follow, but depending on what you mean, it's definitely not a goal to have clojure-syntax-like stuff happen from the scheme side. <rlb>If it matters, the rewriting actually happens at the tree-il level, i.e. the code above is just psuedo code meant to give the general impression, but it's roughly accurate. <rlb>i.e. (:keyword ANYTHING ...) should work fine as long as someone's defined (and we have) an invoke specialization for all the relevant ANYTHING types. <antipode>I'm not talking about :keyword anything. <antipode>I'm talking about (lets-invoke-this-scheme-procedure-from-clojure :anything anything), where (define (lets-invoke-... proc anything) (proc anything)) <antipode>In Clojure, keywords and functions are applicable. But if a keyword is passed to a Scheme procedure with the intention to be used as something applicable, it needs to be converted to a procedure/function/.. that is applicable from Scheme's POV. <antipode>So, Lokke could automatically convert keyword arguments, but the problem with that is that sometimes a keyword is just a keyword, instead of something that is supposed to be applied. <rlb>Oh, ok, right, that's not a goal atm. <rlb>i.e. the scheme procedure would just have to know to look for keywords and do something unusual (for a scheme program). <antipode>And hence, Lokke can't do the rewriting fully transparant -- it has to limit the rewriting to the (:keyword-in-beginning arg ...). <antipode>Instead of the Scheme procedure doing something unusual, I think it more likely that the Lokke-using Clojure programmer will instead ‘rewrite’ the :keyword to (lambda (arg ...) (invoke :keyword arg ...)) manually. <rlb>OK, I'm still not sure I understand that, but maybe it's because I'm thinking of clj-specific keyword semantics being fully transparent from the clj side. i.e. if you say (:key ...) in scheme code, it'll work, and it from scheme you pass a keyword to clj code that does that, that'll work too. <rlb>And that's all I'd intended for now. <rlb>sorry "if you say (:key ...) in *clj* code, it'll work" <rlb>"and if from scheme" <rlb>i.e. only clj (compiled) code knows about the clj-specific semantics. <mwette>I'm looking forward to the time when the utf8 patch makes it in. I was exceted about the speed-up I saw. <minima>sorry is there any magic syntax to avoid mentioning the same variable multiple times? `(format #t "~a ~a ~a" foo foo foo)' <RhodiumToad>the ~:* skips backwards by 1 argument, you can use e.g. ~2* to skip 2 forward, ~2:* to skip 2 back, ~1@* to go to the second arg, etc. <ekaitz>btw is there any good tutorial on using `format`? I have a pretty crazy usecase and I need some assistance <ekaitz>i'm trying to print tabular data <RhodiumToad>I don't know of a tutorial other than the reference doc <janneke>ekaitz: not sure exactly what you need, but gash-utils implements ls <ekaitz>janneke: that's exactly what I need haha <old>sneek: later tell wingo (regarding Guile roadmap) that maybe there is a way to improve external contributions if you and civodul have more urgent priorities? <old>sneek: later tell wingo for example, having a third maintainers perhaps? <rlb>wingo: regarding the "current status" wrt regexps, guessing you referred to (ice-9 match), just as an slightly indirect comparison? (i.e. it's not regexps) <daviid>mark h. weaver did ask to get back as a maintainer - that, if accepted, would be awesome - and i hope it happens, some day ... <old>janneke: sure. I would love that. <old>However, perhaps there are more fit peoples than me for this (Scheme wise) <old>and a little training <wingo>rlb: if i said ice-9 match wrt regexps it was a misspeak <sneek>wingo, old says: (regarding Guile roadmap) that maybe there is a way to improve external contributions if you and civodul have more urgent priorities? <sneek>wingo, old says: for example, having a third maintainers perhaps? <rlb>Ahh, ok, thanks -- wondered after my brain caught up :) <wingo>old: fwiw i think of maintainer as a more formal role -- there is a lot that can be done just as a committer <wingo>if some committer ends up making most of the commits and merges then they should probably be maintainer <wingo>but being committer is first step fwiw <rlb>wingo: other than (presumably) commit message fixes, did you already notice other changes you might like to see to the parallel test patches? <wingo>rlb: i gave it something more than a cursory glance and less than a deep look :) lgtm. use your best judgment about how to proceed <wingo>no other comments other than let's do it :) <rlb>OK, then I assume we want the per-file bits in the commit messages. I'll add that, and look at the whole thing more seriously again myself. After that, if I don't see any further changes I'd like to make, how should I proceed -- update the branch for another look, repost with the changes, just merge it, or...? <rlb>(...and that small export issue I posted was revealed by some of the stuff I was doing in lokke. It's not urgent.) <rlb>One other thing I remembered I wanted to ask you about wrt the utf-8 branch -- you may not have seen, but earlier I tried to implement some srfi-13 bits on the scheme side (in the module file), but that fails, even after i tried a few things to get it to work (i.e. by actually using the module, in boot-9, etc.). If you know how to get that to work, and/or thing it'd be interesting, then I'd be happy to try again. Not critical, but I <rlb>imagined it'd be preferable to do work in scheme all else equal. <rlb>(Oh, and to do that ^ I of course created a module/srfi/srfi-13.scm, etc. for the scheme side. Right now, we just initialize the C code from C, and never use the module.) <rlb>But also not critical - got along fine without it :) <old>wingo: Is there a list of committers? <old>wingo: I though that only you and civodul were reviewing patches sent on bug-guile@gnu.org <RhodiumToad>daviid: I think I mentioned this before (some while back), did you see it? <RhodiumToad>WARNING: (g-golf): `disconnect' imported from both (g-golf hl-api gobject) and (g-golf hl-api signal) <daviid>RhodiumToad: if you did, it skip my attention, is this when you import a typelib? <RhodiumToad>this is when I use (disconnect) to disconnect a signal <daviid>RhodiumToad: do you have a snipset i can save here, i searched as i thought i had one, that you posted, but i can't find it, nor in the log ... that would help - as minimal as possible, tx <daviid>sure, take your time, i am on other things as well ... <RhodiumToad>ah. it only happens when running an already compiled module, I think <daviid>i didn't change anything releated to disconnect though ... probably something else is going on ... <RhodiumToad>I pulled the devel branch and tried again, no change <RhodiumToad>and doing (pk disconnect) show it as a generic, not an extended-generic <daviid>RhodiumToad: right, i would have thought so (answering 'nothing changed) <daviid>it is a generic, not an extended generic - but let me think a little about this <daviid>make a fake change in the example, so it compiles ... <wingo>just found a fun bug in the jit. <wingo>if a comparison op like eq-constant? can't address its stack operand directly because it doesn't fit in the space provided, the assembler transparently inserts some pushes and pops/drops around the instruction <wingo>but the jit wants comparison ops to be fused with their branches <wingo>i.e. each instruction has a wide and narrow variant, and there is a prefix opcode indicating whether the inst is wide or narrow. that way we don't have this problem <civodul>so it’s a performance bug, not a semantics bug, right?