IRC channel logs

<old>I guess maybe he wants to get the GC Whippet in first?

<euouae>I'm writing a guile text editor, I was fiddling with the gap buffer concept and C extensions

<euouae>but I think I'll go for a pure Scheme string-rope implementation instead

<euouae>there doesn't seem to be a library for Guile for that, but there's one for CHICKEN

<ArneBab>old: I think that shows a deeper problem we have at the moment: merging code is our main bottleneck.

<euouae>I know Guile has a substring with CoW semantics

<euouae>but does it have a superstring with CoW semantics?

<euouae>i.e. string-append/concatenate that doesn't allocate an entire new string?

<euouae>Another question: What does it take to introduce a new SRFI to Guile? I'm thinking of SRFI 223 that has binary search.

<euouae>Ah SRFI 43 and SRFI 133 also do, but less general. My question still stands anyway

<apoorv569>are there any examples of hosting a site built with haunt using nginx or something?

<euouae>apoorv569: what do you want nginx to do? reverse proxy?

<euouae>(because haunt is its own web server)

<euouae>or do you want to just build the static HTML, sorry I misunderstood maybe

<apoorv569>so you just use haunt serve to host the site in production?

<euouae>No, I misspoke. I haven't used haunt, but I know of it. It provides `haunt build` so you can use that for production

<apoorv569>i thought its just a dev server for development.

<euouae>Right so you just use haunt build and it'll build the static HTML for you, what in particular are you in need of help with nginx?

<apoorv569>yes after i build thw site, im wondering how to host this.. as this is my first time using a static site generator in general.

<apoorv569>do i use nginx? if so, how?

<euouae>which distribution are you using

<apoorv569>gnu guix

<euouae>you use gnu guix on your VPS or your personal computer?

<apoorv569>personal computer.. vps is debian ATM but i will convert to guix there as well once i sort couple of things i need there.

<euouae>In general you'd use nginx-service-type, have you seen <https://guix.gnu.org/manual/en/html_node/Web-Services.html#NGINX>?

<apoorv569>yes im aware of the service.

<euouae>the root should point to your built directory

<apoorv569>i see.. that's it?

<euouae>For a static site it's pretty simple

<apoorv569>what about the assets and all? images, css etc..

<euouae>the `haunt build` should take care to place everything needed in the build directory

<euouae>then nginx will simply serve it upon request

<apoorv569>hmm.. i see. i will try this out in a VM..

<euouae>Do it on your Debian VPS first

<euouae> https://wiki.debian.org/Nginx

<apoorv569>if this is all that's needed then this is way easier then i was expecting.

<euouae>you can use guile/haunt there too

<apoorv569>yes, thank you.

<euouae>you're welcome!

<euouae>I guess string-append/shared and string-concatenate/shared might be the option

<old>ArneBab: there have been lots of discussions on that topic since I joined the community and nothing has moved since .. yeah

<identity>i notice that (and (eq? (+ 2 2) (+ 2 2)) (eq? (integer->char 50) (integer->char 50))), but the Guile docs explicitly mention that this is what ‘eqv?’ is for (“‘eqv?’ extends ‘eq?’ to look at the value of numbers and characters.”), am i missing something?

<euouae>Hello again

<euouae>ACTION is still working on a string rope implementation

<ekaitz>euouae: in guile or for guile?

<ekaitz>ACTION is interested on text editors

<euouae>ekaitz: me too, I'm writing a text editor in Guile

<euouae>I'm not sure what you mean by /in or for/

<ekaitz>euouae: we should talk then

<euouae>It's in GNU Guile, I am not writing it as a C extension

<ekaitz>i meant if you wanted to provide it in the Guile standard library or so

<ekaitz>or if you were writing it in Guile

<ekaitz>but I got my answer now

<euouae>oh I don't know if my implementation would be that good

<euouae>ekaitz: I'm trying to replicate parts of emacs in Guile, that is the ultimate goal, a Guile lisp emacs-y editor

<ekaitz>let me tell you a secret, many things in standard libraries aren't "that good"

<euouae>but for now I'm writing a mini-editor in ncurses

<ekaitz>oh very cool

<euouae>It's just going to have some basic functionality + extensible in Guile

<ekaitz>i started with a text editor written in chibi/guile (r7rs compatibility) but I dropped that and started to rewrite in C89

<ekaitz>I wrote a simple piece table

<ekaitz>and some goodies on top

<euouae>I only know of gap buffers and ropes, I havent looked into piece tables

<euouae>so your editor is unrelated to lisp?

<ekaitz>now it isn't but I wanted to make it as an editor for lisp

<ekaitz>now it's just a learning project for later

<euouae>I started with gap buffers, I was writing a Guile extension in C, you know what that is right?

<euouae>also how does your editor work with encodings?

<dthompson>if I were making a lisp-specific editor I would go the structural route rather than plain text

<euouae>What's the structural route?

<old>ACTION wonder why Guile does not expose a `get-internal-monotonic-time'

<ekaitz>euouae: I didn't make the encodings work yet

<ekaitz>ACTION is a little bit afk

<euouae>ekaitz: that's what I get for free from Guile by the way

<euouae>ekaitz: It's OK. If I have something cool to show you I'll send you a memo thorugh MEMOSERV. I work slowly with all the other responsibilities I have

<euouae>also feel free to send me your editor I might look at it

<old>ACTION wonder why time-monotonic in srfi-19 is using the TAI clock ..

<identity>TAI is almost monotonic if you disregard all the times when it is not

<old>correct me if I'm wrong, but polling monotonic clock is way faster than anything else

<old>but I guess that the overhead of calling C from Guile is an order of magnitude slower than the difference between polling any kind of clock so there's that

<euouae>Really?

<euouae>Can't you add it directly to the guile compiler/interpreter?

<old>if glibc expose a symbol I can add it to anything sure

<dthompson>euouae: https://clojure.org/guides/structural_editing

<euouae>dthompson: I am not sure how you'd make an editor like that

<euouae>there is structural editing on top of plain text usually

<old>identity: well apparently clock_gettime has become real fast now. all clocks seem to be in the 20 ns ballpark

<ekaitz>euouae: we can continue the chat via email if you like

<identity>you could store code as something more abstract and then pretty print it when writing it out, i think some obscure editors did/do that

<old>but that's on x86-64 with VDSO, don't know for the other archs

<ekaitz>dthompson: I started with a piece table exactly for this, i could make pieces that are exactly the forms in the file so the editing is fast

<euouae>ekaitz: I'll send you my e-mail in PM

<identity>‘Stop Writing Dead Programs’ by Jack Rusher has some neat stuff about “editing programs as something that is not text” closer to the end

<ekaitz>identity: i should rewatch that one

<rlb>identity: the eq? eqv? distinction just says that eqv? must "work right" for characters, etc. not that eq? must *never*. i.e. eq? is allowed to do whatever it wants with integers and chars.

<rlb>And on guile it just so happens that eq? "works" for some of them.

<rlb>old: reminded me of https://debbugs.gnu.org/76227 -- though I hadn't/haven't looked in to it.

<old>rlb: oh god that's worse than I though

<old>at least that function is also present in VDSO so not so bad

<old>but yeah, this is actually a pain. Looking at fibers time wheel, and I can see it's using internal real time

<old>when it should probably be using either TAI or monotonic

<old>oh well, time for little FFI

<rlb>Only semi-related - I wondered whether our jit arrangement can currently call C functions directly, and/or could we eventually (if we don't already) use it to construct (novel) ffi calls.

<euouae>rlb: not that I understand all the words there, but I wondered earlier if to avoid the "ffi overhead" one should modify the Guile interpreter/compiler directly

<rlb>...or maybe our existing ffi is already similar to that (not very familiar with it).

<rlb>Basically, I was speculating about being able to assemble new external calls "on demand", and didn't know if lightening already made that kind of thing plausible. (Just speculating.)

<ArneBab>old: in the savannah repository I had merge rights for simple things -- and looking at the number of news entries I wrote when rlb asked, I merged a lot more than I thought. I’d also vote for merging the lilypond fixes for Windows. That would also move towards making Guile more viable for local games.

<old>rlb: the FFI arangement is made in libffi IIRC. so event with JIT, I think we have to call libffi first, which then do the foreign CALL

<old>rlb: but maybe libffi has a function for "write the call to this buffer" and then we could inline this into the JIT code, avoiding a call to libffi

<ArneBab>sneek: later tell civodul: I’d like to ask again for merge permission on guile/guile on codeberg. I have push-permission on savannah (see https://savannah.gnu.org/project/memberlist.php?group=guile ) and we are blocked a lot by having too few people who review and merge code. My account on codeberg: https://codeberg.org/ArneBab

<sneek>Will do.

<ArneBab>sneek: botsnack

<sneek>:)

<euouae>rlb: old: do any of you have merge permissions in guile? because I want to fix the section on autotools for guile

<euouae>in the documentation

<euouae>but I don't want to commit my time to it unless I know there's interest for it

<old>euouae: I don't rlb does

<rlb>I do, but for now, I'm fairly conservative, generally only merging things I'm fairly confident in *and* have the time to handle "properly". In a lot of cases, until/unless I have a better idea what my purview should be, I'd want to defer until wingo or civodul can weigh in, even if it's just at a higher level.

<euouae>okay I will ask them

<rlb>And my impression is that they've been fairly swamped i general for a while now.

<euouae>well that's the problem then isnt 'it

<euouae>the project (guile) is too bottlenecked

<euouae>A bit of trust can go a long way if /some/ merging rights were relegated to others

<rlb>So for automake, for example, i'm not *really* knowledgeable, so if the changes were straightforward, sure, but if not, I might or might not have the time/energy to come up to speed enough to be comfortable reviewing/merging.

<rlb>But, I also look at it with respect to the "community" -- if for example other people reviewed it, and I could get a reasonable impression of their expertise in the domain, then I might become comfortable merging something based on that.

<euouae>yeah but I'm not committing time without knowing there's interest in that direction

<rlb>(Of course everyone, me included, has the time factor.)

<rlb>Understandble.

<euouae>I've spent weeks working on a musl libc patch only to realize the people maintaining musl don't even know how to review it

<euouae>and similar other experiences

<rlb>ouch

<old>musl is known to be terrible in every aspects

<rlb>ACTION has little experience

<rlb>(there)

<euouae>well it was just an example, I don't do anything above trivial without coordinating first nowadays

<rlb>My main focus for guile right now is just trying to help some wrt a 3.0.11 release -- think we're definitely closer.

<euouae>well let's fix some of the docs too? can we do that pretty please? lol

<euouae>anyway I'm not pushing you, I will message civodul and wingo

<kestrelwx>Hi! Would it make any sense for the 'eval-in-sandbox' to be able to take '#f' for time and/or memory if I don't want to impose such a limit? I guess the user can just pass inf as is anyway.

<kestrelwx>Or write one themself.

<identity>kestrelwx: you could just pass an unreasonably large limit that would definitely not be hit, if you really have to

<old>kestrelwx: just pass the age of the universe and you'll be fine

<kestrelwx>Right, that's what occured to me just now. I've been thinking about it couple months ago.

<rlb>As a (much simpler) example, this was recently submitted, and from a quick glance, it looks like it might be fine, but to be *sure* would take some time, and for the past few weeks, most of my guile related time has been tied up with other things (the various bugs, etc.): https://codeberg.org/guile/guile/pulls/12/commits/67cb80c1fd80e3b206a1abc38c2b02ae5c4bf47b

<rlb>So if someone waned to go double-check it (perhaps via a bit of git archaeology), and to become "sure" that we really did mean (when exceptions were changed) to publically change the documented api too (seems likely) then that'd be helpful wrt making it easier to merge. In lieu, of course, of wingo just popping up and saying "sure, that's right" :)

<euouae>yeah that's me

<rlb>Oh :)

<euouae>that account in codeberg ;p

<rlb>I think maybe I figured that out the other day and now wasn't sure.

<identity>surely 7.889238e13 seconds is plenty enough time for whatever code to run in a sandbox. unless you are sending it to the Andromeda Galaxy, i guess

<rlb>And perhaps that example is too simple, but in general, it's not just civodul and wingo that are "overcommitted" -- right now, we're fairly constrained in general wrt "review". i.e. even if they had more time right now, they probably couldn't and/or shouldn't be handling the majority of the review work, ideally.

<euouae>rlb: right now, I'm undercommitted in terms of doing anything aside from babysitting so I'd be happy to do /something/

<rlb>:)

<kestrelwx>identity: Well I was actually loading a scheme file and evaluating it inside the sandbox so it might just compile by that time, yeah. But that's on me, I think.

<rlb>euouae: regarding your earlier question about srfis -- I'm not the expert, but one key question for me for any given srfi would be "are we sure we want it", and *that*'s something I would really want to hear from wingo or civodul about.

<rlb>Other than that, if the reference implementation is reasonable, then it's "just work" -- see the recent merge of srfi-207, for example (hopefully I did that right (enough)).

<rlb>or SRFI-197 (which was simpler)

<euouae>oh yeah, thanks for SRFI-197, it's really nice

<euouae>cut (srfi-26) and chain are fun to use

<rlb>Oh, and I'm not promising (ought to be doing "another thing" right now :) ) but I might poke at your doc changes "later" if no one else does (and anyone could).

<euouae>cool!

<rlb>But as soon as civodul has time to help with a few bits, and unless something more important pops up, overall I'm inclined to proceed with 3.0.11 as one of our higher priorities.

<ArneBab>rlb: are you knowledgeable enough about the C side that I could file a PR with the lilypond-patch for you to review?

<ArneBab>sneek: later tell euouae: where I am reviewer, I appreciate it if contributors focus on trivial changes. That makes it much more likely that they cut their contributions into smaller steps that I can realistically review and merge within half an hour in an evening.

<sneek>Got it.

<rlb>Hah, I almost said something about that earlier, as an example of something I thought was important, but didn't think I'd feel comfortable with as the primary reviewer. If nothing else, I suspect I'd also want an opinion on the C-side type manipulations from Andy or Ludovic, e.g. wrt the ABI, etc. Though they may well be fine, whatever they are.

<rlb>But still probably a plausible step to have a pr we can keep rebased until we're satisfied?

<rlb>And wrt "smaller steps" -- strong general agreement. And a good bit of the work regarding the proposed utf-8 changes was repeated refactor/rebase to try to make the (long) series easier to follow.

<rlb>My other issue with respect to the lilypond patches is that I have *very* limited experience with respect to windows, and effectively none at all for 10+ years.

<rlb>(iirc)

<dsmith-work>Hey! Working I think

<dsmith-work>sneek, botsnack

<sneek>:)

<dsmith-work>There's a good bot

<rlb>ArneBab: I'd say overall, if it's not too much work relative to uncertainty, seems like a completely reasonable thing to raise a pr for, and we can go from there.

<rlb>old: was it you (someone here did) that mentioned some tool(s) for verifying ABI compatibility?

<rlb>If that's a thing, and if it's feasible, that sounds like something that'd be really nice to have in CI, or perhaps better yet, in "make check" depending on how it works.

<rlb>(Assuming it could lower the bar for becoming confident about change.)

<ArneBab>rlb: then I’ll create a PR.

<ArneBab>(may still need a few evenings till I get to file it)

IRC channel logs

2025-09-15.log