IRC channel logs

2021-11-05.log

back to list of logs

<RhodiumToad>file ports could be backed by special devices, pipes, or sockets
<RhodiumToad>all of which may be pollable (for devices it depends on the device)
<lispmacs[work]>hey, wait a second, stdin returns eof when data is not available...?
<lispmacs[work]>I wasn't expecting that
<lispmacs[work]>it makes sense, I guess
<lispmacs[work]>I wonder if special devices do that too
<lispmacs[work]>tty devices in particular
<lispmacs[work]>I just found out through experimentation that get-u8 will return eof object if data is not available, at least working with the default current-input-port
<RhodiumToad>in non-blocking mode?
<lispmacs[work]>RhodiumToad: I didn't set anything related to blocking, so far as I know, although I disabled guile port buffering
<RhodiumToad>by default it should block waiting for input if there is none
<lispmacs[work]>RhodiumToad: oh, wait, might be a logic bug in my code...
<lispmacs[work]>let me double check
<lispmacs[work]>ah, nevermind, I was not doing my branching correctly
<dsmith>Yeah, files (as in seekable things on a drive) are always "ready". Sockets and Serial ports (and other I/O device) might not be. Not until data arrives. Was really dissapointed when I found out about that.
<mfiano>Hello
<mfiano>It seems 3.0.7 or guile3 git HEAD no longer builds on machines with the latest release of the boehm gc library, due to it not including the gc_pthread_redirects header anymore.
<mfiano>I tried on Arch and void
<dsmith>:(
<mfiano>Yeah, unfortunate. I was going to take a break from Common Lisp to do some Scheme for a change for a particular project idea I had, but looks like I'll just use CL.
<sneek>dsmith: wb!!
<lampilelo>mfiano: 8.2.0 is a pre-release, kinda strange it's in arch already
<lampilelo>fwiw i sent a pull request to bdwgc, let's see what they have to say
<lloda>oh there's already a bug for the ash thing from yesterday
<lloda> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48150
<ft>Is there a reason scm_shell() doesn't return but calls exit()? A buddy of mine wants to embed guile in an application where he needs to do some cleanup after scm_shell(). Luckily, the function is pretty simple, so he could reimplement it and leave the exit() off. But I wonder why that is.
<RhodiumToad>good question
<lloda>i do the same, copy scm_shell without the exit
<lloda>don't know why it's like that either
<dsmith>How about this, to prevent calling it a second time?
<dsmith>It's main purpose is to implement the guile exe I think.
<RhodiumToad>ironically, the guile inner_main seems to think that it returns
<ft>Maybe. But I suppose that could be handled with a note in the documentation. Or if it's really important to prevent it at all costs, it could be prevented in C with some state. :)
<ft>RhodiumToad: The one in the documentation right? I was fooled by that as well. :)
<dsmith>The docs expclitly states that scm_shell doesn't return.
<RhodiumToad>ft: the one in the source, too
<ft>dsmith: Yes, but there is a code example that suggests you can do stuff after scm_shell().
<dsmith>I think the other guile init methods were added later to get around that.
<dsmith>Dunno.
<dsmith>Thost latest ash commits are not in gnu C style.
<dsmith>The guile devs are usually pretty picky about that.
<lloda>my bad
<lloda>fixed
<dsmith-work>Happy Friday, Guilers!!
<dadinn>RhodiumToad: regarding the issue with the password yesterday, thanks for suggesting using strace... figured the issue was that my opt-args parsing was wrong, and parsed the password as a boolead flag because (value #t) was missing from the option-spec
<dadinn>*boolean
<dadinn>So accidentally I set the password to "#t", then failed to unlock it with the expected one. Now it works with "passwd" by passing it "password\npassword", or by "chpasswd" by passing it "username:password".
<lampilelo>hours of debugging, that's funny
<dsmith-work>dadinn: Yey!
<dsmith-work>sneek: botsnack
<sneek>:)
<dsmith-work>!uptime
<sneek>I've been running for one day and 6 hours
<sneek>This system has been up 15 weeks, 2 days, 3 hours, 31 minutes
<dadinn>I am trying to use dynamic-wind, but not sure what to put in the in-guard. A noop (lambda ()) is invalid... should I just return a nil?
<dadinn>Is it bad that I don't do anything in the in-guard? What should I be doing there?
<lampilelo>i use (const #t)
<dadinn>lampilelo: sounds good!
<lampilelo>i don't really know what the convention is, maybe returning #<unspecified> with (if #f #f) is more appropriate
<lampilelo>but i also don't think it matters
<RhodiumToad>most common seems to be (lambda () #t)
<lilyp>I'm evil, because I use *unspecified* explicitly
<lilyp>but yeah, for stuff like dynamic-wind (const #t) is better than returning an unspecified value from your in-guard
***AndroidToad83 is now known as AndroidToad
***roptat is now known as Guest3449
***dongcarl3 is now known as dongcarl
***berndj-blackout is now known as berndj
<ajarara>because match patterns on record fields are positional, re-organizing the order of fields on the definition of the record isn't a good idea, right?
<lilyp>not unless you want to bump your major version quickly for semver clout
<ajarara>a pretty big incentive