IRC channel logs


back to list of logs

***karlosz_ is now known as karlosz
***chris is now known as Guest1739
***Guest1739 is now known as chrislck
***karlosz_ is now known as karlosz
<chrislck>sneek: botsnack
<stis>My double's implementation
<stis>Huge speedup of writing doubles is possible
<ArneBab>wow …
<chrislck>sneek: stis
<sneek>stis is a wizard
<stis>duplicate but I rearrange the blog so this link is for printing doubles
<stis>This little trick is insane, a nice 40X speedup
<stis>for almost ascii strings to utf8
<stis>Hmm we should be able to do something similar to the write function, needs more work though. That's my next goal
<stis>the difference there is that one quote and escape stuff
<nckx>Oh wow, mcneato.
<stis>writing a string of acii non quoted symbols = 200X faster then guiles implementation
<stis>for large strings that is
***mfiano_ is now known as mfiano
<taw10>I'm trying to use an exception handler to automatically get a backtrace when something goes wrong. However, it seems that calling (backtrace) gives only: system/repl/debug.scm:72:40: In procedure string->number: Wrong type argument in position 1 (expecting string): #f
<taw10>I made this simple test case to demonstrate: - it's based on call-with-backtrace from ... Did I misunderstand something?
<taw10>The "real" context with the same symptoms is here:
<stis>(getenv "COLUMNS")
<stis>what does that give you?
<stis>taw10: ^^
<taw10>$1 = "116"
<taw10>.. running the same Guile version in the terminal where I just tested
<stis>the line that was reported as error is (string->number (getenv "COLUMNS"))
<stis>Probaly we should hava a fallback if COLUMND returns false, it looks like you lost the env variables when running the test
<stis>or that there is no terminal info associated to the execution of the guile program
<stis>you can force it by using (setenv "COLUMNS" "116") and see if you can make it work without crashing
<taw10>That doesn't seem to help
<stis>maybe start-stack is making things go wild
<taw10>I had the same problem before I added that (when it was my own code as in the second line, rather than the mostly-from-the-Guile-docs test case)
<taw10>I tried hacking the terminal-width routine to just return 100, and now it seems to get into an infinite loop after "Backtrace:". I wonder if I just messed up something in my Guile installation
<stis>I will see what I get on my computer
<taw10>I'm trying a clean installation of the latest Guile Git version in a container as well. I feel like I remember it working in the past, maybe with a different version or a non-broken installation. I wouldn't have committed the exception handler code to my project without at least a basic test
<stis>if I run it via load from the interpreter in a terminal it works quite well!
<stis>do you run it via emacs?
<taw10>I'm running "guile exception-test.scm"
<stis>yeah I saw that sorry for the noise
<taw10>You're right, it works for me as well with (load "exception-test.scm") ... !
<stis>yeah when running it as a program as you do I can verify that the crash happens
<taw10>Which Guile version do you have? 3.0.7 here, just about to test with latest Git
<stis>adding (setenv "COLUMNS" "100") as the first line fixes the issue! Looks like a bug in the guile execition modell where env viriables are not transported in the fork
<taw10>Whoops, you're right! I was editing the wrong file before :$
<stis>Will you file a bug report?
<stis>sneek: bugs
<sneek>I could be wrong, but bugs is Send reports to, and see bug reports at
<taw10>Of course. I'll make sure it still happens with the latest version first
<stis>shoudl be, i'm very close to head
<taw10>Thanks! I would've suspected Guile itself earlier, but "It's Never The Compiler"
<taw10>When you say "not transported in the fork", which fork are you referring to?
<stis>It is possible two bugs, one that we do not check if the COLUMN has a value and the second one is that I expect the execution of a program to inherrit the environment variables
<stis>well a process does not loose any env variables willy nilly, so most likely it has to do with creatng a new process and not transfer the env virables
<stis>where this happens I do not know, and maybe it is by design. Also I think that usually when this code is executed, you have a terminal and a shell and nor running a script.
<stis>from the shell everything works
<stis>e.g. the repl
<taw10>Indeed, testing just the getenv part gives different results in different cases: