IRC channel logs
2023-07-14.log
back to list of logs
<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>Hopefully I can socialize some of this before 3.0.10, but, it is a lot <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.)