IRC channel logs

<rlb>Anyone know why we have libguile simpos and posix? I could imagine "boostrapping", but so far don't see that as relevant, and both came in the first git commit.

<rlb>Oh, are options.c options (like the reader options) just global right now? If so, that explains why they don't (and can't easily?) revert at the end of a module load the way I tend to think they should. (I hadn't delved before.)

<rlb>i.e. if I enable postfix keywords, curly-infix, r6rs hex escapes, or whatever within a module, I don't feel like that should affect other modules, or the parent module/envt.

<haugh>rlb, yes afaik all the reader stuff including hash extensions is global.

<graywolf>I wonder whether https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71262 has a chance of going anywhere

<polyex>some ppl say json should be universal config format because it's just javascript. but can't you say the same about guile because it's just an s-expr at the file format level?

<civodul>graywolf: sounds reasonable to me, although C.UTF-8 isn’t really “standard”

<civodul>in the context of Guix, you may like: https://issues.guix.gnu.org/67686

<civodul>coming soon! 🤞

<graywolf>That is what this was inspired about :) Since C.utf-8 will always be available, it should get auto-installed :)

<graywolf>not sure about "not standard", musl and glibc both support it, it "in practice good enough"(tm) ?

<graywolf>civodul: in context of Guix I am said that https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71257 is being ignored :/

<graywolf>I hoped it would get into this core-updates cycle

<graywolf>I am sad*

<dthompson>polyex: json is actually really bad as a config file format. I don't know why some people think it should be used in that context.

<dthompson>"raw" s-expressions (choose your flavor) are better in the sense that they support more data types and comments, but they're also limited in the sense that their just data.

<dthompson>the best config format of all is a full-featured programming language, like how emacs is configured in elisp.

<dthompson>so in that sense, yes, guile is an excellent configuration format... if the application it is configuring is written in guile.

<dthompson>s/their/they're/ a few messages back lol

<dthompson>too early in the morning for grammar

<singpolyma>Even if not written in guile you can call libguile to interpret the config

<dthompson>but why? that's a weird dependency to add to something that doesn't already use guile imo

<singpolyma>What would you use in that case? Lua?

<dthompson>I mean if you're making your application extensible then sure use guile

<dthompson>but like, just as a config file thing? seems odd

<civodul>graywolf: these are harsh words; i think the answer to this patch is not an obvious yes or no, that’s most likely the reason you haven’t seen any reaction

<civodul>the problem that motivated it is very real though, no question

<graywolf>Uff I am sorry if it came out wrong. I did not mean it in bad way, I should have chose better words.

<civodul>no worries, i understand the frustration all too well

<tohoyn>sneek: botsnack

<sneek>:)

<RavenJoad>dthompson: How hard do you think it would be to add Hugo-like shortcode support to guile-commonmark, so we could at least call Guile functions when generating the SXML for a haunt post?

<RavenJoad>That would solve our hacks for inserting HTML _we_ want.

<dthompson>RavenJoad: I don't know what "shortcode" is, but there's nothing stopping you from making a reader that does what that is

<RavenJoad>dthompson: Hugo's shortcodes are essentially formatted replacements. {{ do-something arg1 }} may turn into <span></span> at the end. I was thinking of something similar, but instead of templated HTML, it is a Scheme function that returns SXML.

<dthompson>RavenJoad: oh so it's just string templating. sure, just use scheme and generate sxml. that's what I do.

<dthompson>for my blog theme and stuff

IRC channel logs

2024-07-23.log