IRC channel logs

<rlb>...regarding pr#25, since we already support XDG_CACHE_HOME, might make sense to just support XDG_CONFIG_HOME too, instead; although that might need to wait for 4.0 too.

<humm>why wait for 4.0? can add support for XDG_CONFIG_HOME now and drop support for ~/.guile in 4.0

<humm>if dropping support for ~/.guile is desired at all

<rlb>I think it'd be fine to add it in a non X/Y *if* we can do it without breaking existing sitautions, and then yeah, I don't know why we wouldn't just keep support for ~/.guile indefinitely, as long as it didn't interfere somehow.

<rlb>I just hadn't thought through the cases yet.

<rlb>(*carefully*)

<euouae>Hello

<ieure>Hi.

<old>rlb: I had a look at: https://debbugs.gnu.org/cgi-bin/bugreport.cgi?users=guile-devel%40gnu.org;bug=19581

<old>It seems that sleep and usleep are implemented using the select system call

<old>and the rest of time to sleep is returned from the timeval struct

<old>But: On Linux, select() modifies timeout to reflect the amount of time not slept; most other implementations do not do this.

<old>So I guess if you intend on fixing this bug for next release, maybe the sleep functions could be implemented with nanosleep(2)

<old>because I fear there is a wrong assumption here with the usage of the select(2) syscall that can result in weird behavior on some OS

<ArneBab>old: thank you for writing in the issue. Looks like a discussion is starting (and that we hopefully can merge soon)

<lxsameer>if you're using emacs, what mode are you using for guile? geiser?

<identity>lxsameer: i would imagine most use the built-in scheme-mode + geiser

<lxsameer>cheers

<Arsen>ACTION wonders how good that alternative to geiser that was talked about here is

<kestrelwx>emacs-arei.

<identity>Arsen: pretty good, but still raw

<Arsen>that one, yeah

<lxsameer>when defining a new language, should I do anything specific to force guile to use this new language for a scm file? I run guile like `guile -L $DIR --language='foo' somefile.scm`, I can confirm that my reader is getting executed but guile treats the file as a scheme source code

<lxsameer>nvm my reader is the problem

<dsmith>old, re sleep/select: Ya, linux does lots of things that are non-standard

<old>dsmith: it seems to me that Guile relis on this behavior for certain timeouts

<old>s/relis/relies

<old>since the timeval struct is not modified by the kernel in other OS, I suspect that the time left (if interrupted by signal) will be the same and thus it is possible that a guile program sleep for inifinity if it receives too much signal

<dsmith>I wonder what other non-linux systems do for that functionality

<dsmith>I've heard netbsd is a real stickler for adhering to standards without extras and extensions

<mwette>Is use of nanosleep an option?

<dsmith> https://man.netbsd.org/nanosleep.2

<dsmith>Yes, nanoslepp seems to be a portable option.

<dsmith>Uh. What about windows?

<rlb>lxsameer: scheme-mode + paredit here.

<rlb>old: thanks for looking in to it, though I wasn't planning anything there myself, specifically -- I just noticed it was something Ludovic seemed to want to fix in releases before now and tagged it. I also assumed from the discussion that it'd need a Y release.

<dsmith>sleep-inexact, anyone?

<old>mwette: yes nanosleep is the way

<old>dsmith: I can tell you that my sleep was indeed not exact yesterday. In fact, it was truncated to almost zero

<old>(my son is sick)

<dsmith>old, Ya, that can be rough

<dsmith>old, How old is your son?

<old>18 months

<dsmith>YEah, ok

<old>Visited a kindergarten on friday. Some other kids sneeze on him and now he's sick

<old>The worst part is just that he does not understand what's happening and there are not much that I can do to help

<old>oh well he just woke up. back at it (:

<euouae>Hello

IRC channel logs

2025-09-29.log