IRC channel logs
2021-11-04.log
back to list of logs
<drakonis>guile definitely has loops through recursion i guess <qwitwa>Is there a better repl than the default? <drakonis>you need to have guile-readline and guile-colorized installed for that <drakonis>after that you need to configure your .guile file <drakonis>let me look up the config file that guix uses <drakonis>copy the contents of the next line minus quotes <drakonis>and remove the unicode characters for new lines <dsmith>And for even more guile interactive enjoyment, there is geiser. (If you can handle emacs) <qwitwa>I can handle emacs but I'd prefer to use vscode <qwitwa>Doesn't seem like there's a language server <qwitwa>where do I get guile-colorized from <qwitwa>and manually moved it into the right place whilst cringing heavily <qwitwa>so long as you're not on window, right? <flatwhatson>i haven't tried it, but WSL might be a reasonable option <qwitwa>Not if I'm shipping it inside a game <flatwhatson>that is cool, but yes, in that case WSL might not be an option <flatwhatson>you could possibly use guix from WSL to prepare the library paths, and then run them with the win32 guile instead of WSL guile <flatwhatson>that should work OK for anything that's purely scheme <chrislck>if guile-3 on WSL works well then it would be amazing <qwitwa>that sounds like such an awful package management bodge that it makes "fuck it, I'll rewrite akku in rust" look appealing <drakonis>is this for writing tooling for a game or for modding? <qwitwa>Personal project, been playing around with the sdl/opengl/imgui with the intended end goal of a roguelike <qwitwa>So content description, touching on modding <qwitwa>I do want to be able to handle logic <qwitwa>It's a personal project in the sense that I'm not being paid and am not under NDA <qwitwa>that doesn't mean not being able to ship a working windows version is acceptable if I get anywhere worthwhile with it <qwitwa>This seems like basic 101 stuff for the use-case I've seen guile advertised as <qwitwa>I did see that library earlier, thought it looked cool <qwitwa>I've worked on little love2d games before, seems like a similar interface <qwitwa>in the end a combination of lack of static types and lua idiosyncrasies made it a bit less fun than it should have been <qwitwa>and in this case there are some things I want to do that need easy direct opengl access <qwitwa>but type safety was a big motivation for choosing c++ <qwitwa>If the call out to an extension language explode then that's fine, that entity gets shown as an error texture or whatever but the underlying system is unaffected <lloda>In procedure bytevector-u32-native-set!: Argument 3 out of range: 4294967296 <lloda>Throw to key `numerical-overflow' with args `("ash" "Numerical overflow" #f #f)'. <lloda>i think we just need to be a lot more conservative throwing in there <dsmith>Those really would be some huge numbers! <lloda>i think it might be a 32/64 thing <lloda>like long_max etc are ok limits on 32, but def not on 64 <dsmith>IIUC, it would take about 2,305,843,009,213,693,952 bytes to represent (ash 1 (expt 2 64)) <dsmith>Yeah, I don't have quite that much ram. <lloda>i'm inclined to use INT32_MIN etc <lloda>(ash 1 (expt 2 30)) should fit in a GB or so but it takes such a long time, i doubt anyone would complain if it overflows <RhodiumToad>passwd doesn't read the password from stdin, in a correct implementation <dadinn>when i do it on the command line it indeed works like that, but for some reason my guile procedure is wrong, because when I try to login with the user, it complains that the password is incorrect <dadinn>i've had similar issues with cryptsetup luksFormat/luksOpen , there it was that I used write-line, and the newline counted into the passphrase :/ <RhodiumToad>if your OS supports passwd --stdin then you need to use that <dadinn>RhodiumToad: it's Debian, and I don't seem to have --stdin option <dadinn>RhodiumToad: `echo -e 'password\npassword' | passwd myuser` does work, and sets the password to 'password' :/ <dadinn>drakonis: you mean in the cryptsetup or the passwd case? <dadinn>I don't know where this echo password\npassword is coming from, I can't find any reference to it in the manuals <RhodiumToad>why would the passwd command read passwords from stdin? that's just nuts <RhodiumToad>dadinn: try adding another (newline output-port) after the second display <dadinn>RhodiumToad: doesn't seem to work. Tried this too: (format output-port "~A\n~A\n" password password) <RhodiumToad>did the password not get changed at all, or did it get changed to something else? <RhodiumToad>have you tried getting the hashed value that was set and verifying it? <dadinn>RhodiumToad: there is no error, but I am not able to log in with su, it throws an Authentication failure error <dadinn>RhodiumToad: I mean there is no error when I am running the guile code, but then I am not able to log in. I assume the password is set to something other than expected. <RhodiumToad>but using echo -e 'password\npassword' | passwd someuser on the _same_ user allows you to log in with su in the _same_ way? <RhodiumToad>use truss or strace or whatever to check that what got sent down the pipe was exactly what you expected <dadinn>No manual entry for strace or truss <dsmith-work>dadinn: You might not have strace/truss installed. (strace for Linux, truss for *bsd) <dadinn>RhodiumToad: strace confirms that 'password\npassword\n' gets written by "echo -o 'password\n\password'" <dadinn>RhodiumToad: interestingly the trace doesn't show any of that... I assume because the scripts forks and chroots halfway <RhodiumToad>see if there's an option to trace into child processes <dsmith-work>Ya, -f follows forks. -ff outputs each fork to a seprate file. <dadinn>RhodiumToad: the script has to be ran us root or with sudo <dsmith-work>> Programs that use the setuid bit do not have effective user ID privileges while being traced. <dadinn>RhodiumToad: running with -f I still don't see writing of the password anywhere. There are lots of EBADF bad file descriptor errors <dadinn> maybe I should try creating a small example script which only does this one thing, without forking and all the rest. <dadinn>not good, one extra argument missing <dadinn> ((ice-9 readline) #:select (readline)) <dadinn> ((ice-9 format) #:select (format)) <dadinn> ((ice-9 regex) #:prefix regex:) <dadinn> ((ice-9 rdelim) #:prefix rdelim:) <dadinn> ((ice-9 popen) #:prefix popen:)) <dadinn>(define* (set-password username #:optional password) <dadinn> (format #t "Setting password for user ~A..." username) <dadinn> (let ((output-port (popen:open-pipe* OPEN_WRITE "passwd" username))) <dadinn> (format output-port "~A\n~A\n" password password) <dadinn> (popen:close-pipe output-port)) <dadinn> (while (not (zero? (system* "passwd" username))) <dadinn> (rdelim:write-line "Passwords don't match! Please try again!")))) <dadinn> (set-password username password)) <dadinn> (rdelim:write-line "Wrong number of arguments!"))) <RhodiumToad>ok, and the password still didn't get correctly set? <dadinn>RhodiumToad: it still didn't work :/ <RhodiumToad>does (printf 'password'; printf '\n'; printf 'password'; printf '\n') | passwd someuser work in the shell? <dsmith-work>dadinn: Just curious, what/why are you attemtping to change passwords? <dadinn>dsmith-work: currently adding end-to-end testing using qemu, and was using (ice9 expect) to drive it, but it is becoming unmanageable, so I've added some unattended parameters to the scripts so that it doesn't need user interaction <dadinn>the issue is that the installation works, but then I am not able to log in once rebooted, because the password is not set up correctly <dadinn>btw it still doesn't work with the chpasswd version either. it works with the test script, but when I run the whole end-to-end test the login doesn't work again <dadinn>dsmith-work: Debian on ZFS root ;) <dadinn>dsmith-work: the next submodule I will add is going to be called guix-setup ;) <dadinn>dsmith-work: but I need to get the end-to-end tests working before I can start working on it. <dsmith-work>Well, from the man page, chpasswd seems like the right thing to use. <dadinn>lampilelo: I mean sets the password and then you can su to the user, and it accepts the password. Interestingly when I try to log in after reboot, it doesn't work :/ <lampilelo>that is strange, does it modify /etc/shadow? <dsmith-work>YEah, is it setting something in a chrooted environment instead of the real /etc/shadow ? <lispmacs[work]>hi, if I'm reading from and writing to the same device file, do I have to use one "rw" port for that, or can I have one "r" port and one "w" port? <lispmacs[work]>reasoning it through... so long as the device file supports multiple access, that shouldn't be a problem <dsmith>lispmacs[work]: Watch out for buffering <dsmith>lispmacs[work]: (force-output) to write the scheme port buffers to the fd. <lispmacs[work]>I'm reading through the Guile Reference section on Non-blocking I/O, and it seems that the choice is between blocking i/o, or non-blocking i/o that is very slow <lispmacs[work]>I'm a little confused... why isn't there just a way to poll a port to see if input is available? <lispmacs[work]> backed by files always poll as readable. For non-file ports, this <lispmacs[work]>logically, then, char-ready? would be useless unless using soft ports? <lispmacs[work]>well, it doesn't say what happens for file port not backed by files. That would be special devices, yes?