IRC channel logs


back to list of logs

<ecraven>rgherdt: hey ;)
<ecraven>do you have a minute?
<rgherdt>hi! sure
<ecraven>I'd like to merge your PR, however you've put some guile-specific things in common, that should be in specific, I think ;)
<ecraven>is it ok if I just make these changes, instead of bouncing it back to you?
<ecraven>also, thank you *very* much for working on guile here, I'm getting back into guix, and this will prove very helpful!
<rgherdt>ecraven: you're welcome! Thank you for putting up the basis, so that I could expand it so easily :)
<rgherdt>I started experimenting with improving the support for chicken too, let's see how far I can get
<rgherdt>and for Guile I would like to find a way to get breakpoints working
<ecraven>since I now have guix, it'll be easier to just test out new Schemes...
<ecraven>also, I need to move away from github ;D
<rgherdt>the only thing I miss in codeberg is CI, but they are working on it. And for my small projects it's not a big deal
<rgherdt>ecraven: I realized my connection dropped before, and my answer wasn't send. Sure you can change the code :) Do you mean the intersperse stuff?
<ecraven>yea, but maybe I'll just keep it, it doesn't hurt ;)
<ecraven>hm.. a few schemes missing from guix, maybe after re-learning how to write derivations I can add them
<rgherdt>I thought it could be useful for other implementations, and it's used by the build-multi-value procedure (sorry, couldn't come up with a better name :))
<ecraven>that's fine, it can always be renamed later
<ArneBab>ecraven: great to hear that you’re on Guix now! You may want to look into the --tune option if you want to get maximum speed from your hardware.
<ArneBab>(though I added this to too many packages and had to undo it again :-) )
<ecraven>ArneBab: still "on Arch", but playing around with guix again
<spk121>OK, for (unthreaded, non-JIT, non-LTO) Guile on Windows, I'm pretty happy with this tree: Passes all tests except timezone and some file permissions. Does ubuntu, cygwin, msys, and the mingw variants: 32-bit and 64-bit.
<spk121>Hopefully I can socialize some of this before 3.0.10, but, it is a lot
<dalepsmith>Wow. Great work spk121 !
<dalepsmith>It's a sucky task, but ultimately will really help Guile's adoption
<dthompson>spk121: nice! that would be a great foundation to get into main so threads, JIT, etc. can be fixed incrementally.
<spk121>dthompson: yeah, JIT is close to working. but I can't figure out why it messes up some setjmp/longjmp. I also don't know why threading and GC don't work well together. You can build with both and run for a while, but eventually it aborts or hangs.
<rlb>Hmm, when I added some code to be able to explicitly mark some bytevectors immutable (scm_i_c_..._set_mutable), for use when handing utf-8 content and indexes back to the scheme side, the assembler crashed when something ends up passing the (singleton?) empty bytevector as the bytevector-copy! target, with a copy length of 0.
<rlb>For now I just hacked around it by adjusting bytevector-copy! to only insist the target be mutable if the length is positive, but wondered what we think is proper there.
<rlb>wingo: do you think we might want to keep the internal null termination of all string buffers as a safety backstop against runaway traversals from either internal or external code, or do we want to be strict? (I'm not sure what I think yet, but I have removed the one documented internal barrier we had.)