***karlosz_ is now known as karlosz
***chris is now known as Guest1739
***Guest1739 is now known as chrislck
***karlosz_ is now known as karlosz
<stis>My double's implementation <stis>Huge speedup of writing doubles is possible <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 <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 <stis>what does that give you? <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 <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? <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