<zacts>I'm still waiting to hear back from the FreeBSD people. I'm totally ready to have this imported into FreeBSD soon. <mark_weaver>well, it's the weekend, and it hasn't been very long since redports went all green :) <zacts>I wonder if guilemacs is participating in GSoC this year. <mark_weaver>zacts: yes, it seems that it will be. I don't know if anything has been posted publicly yet though. <zacts>is Guile-* becoming a standard convention? <zacts>and which guile projects will be happening this year? <zacts>ah I see on News. Two guile related projects were accepted this year ***_zxq9_ is now known as zxq9
*zacts is giving emacs another try. (eventually I hope to get around to finishing customizing evil-mode the way I like) <zacts>but, I'm going to start again where I left of with that 'Scheme and the Art of Programming' book <zRecursive>zacts: IMHO, it is better to forget VIM temporarily when using emacs <zRecursive>After using emacs, i never want to use VIM again :) <mark_weaver>zacts: yeah, if you try to make emacs into vim, you'll lose most of the advantages of using emacs. <b4283>zRecursive: actually i still use vim occasionally for editing plain text config files' <mark_weaver>I used vim for many years as my primary editor, and I still use it sometimes for quick editing jobs, especially when root. <mark_weaver>but whatever your preferences, vim's support for lisp/scheme editing and interaction is extremely primitive compared with emacs. <b4283>especially with `sudo vim <FILE>' <didi>b4283: C-x C-f /sudo::/filename <b4283>didi: yeah, i know that, but still it's convenient to just use vim when working with file/dir, especially when you are already in terminal and have a long path <zRecursive>b4283: For me, emacs is always running. so emacs-client is enough <mark_weaver>for security reasons, I prefer to log in as root on a separate text-only VT, and to not allow my user-level session access to root or the root password. <mark_weaver>I consider 'sudo' to be a huge hole, because it basically allows any program running under my userid to have full root access for whatever the timeout period is while it won't ask for the password. <b4283>didi: yeah, i know all that, dired is my favorite <mark_weaver>I do use tramp quite extensively to access remote machines, though. <mark_weaver>and I basically live in emacs otherwise: shells in emacs, w3m for web browsing, docview to read pdfs, gnus for mail/news (although I intend to try switching to notmuch soon) <b4283>used gnus for a while back, later i feel that having to memorize all that keys and combinations is a torture <lloda`>wingo: just tried 63b9e8b03f6eb6c87bb8fff8efa34831a69b8952 make check, got exactly the same thing as last time. <wingo>lloda`: did it abort or was the error different? <wingo>and did test-out-of-memory pass for you? <wingo>are you on a 32-bit machine or a 64-bit machine? <lloda`>64-bit. test-out-of-memory did pass. It aborted. Here: <lloda`>PASS: test-pthread-create-secondary <lloda`>GC Warning: Failed to expand heap by 2797568 bytes <lloda`>GC Warning: Failed to expand heap by 2818048 bytes <lloda`>GC Warning: Failed to expand heap by 2842624 bytes <lloda`>GC Warning: Failed to expand heap by 2863104 bytes <lloda`>GC Warning: Failed to expand heap by 2883584 bytes <lloda`>GC Warning: Failed to expand heap by 2908160 bytes <lloda`>GC Warning: Failed to expand heap by 2928640 bytes <lloda`>GC Warning: Failed to expand heap by 2949120 bytes <lloda`>GC Warning: Failed to expand heap by 2973696 bytes <lloda`>GC Warning: Failed to expand heap by 2994176 bytes <lloda`>GC Warning: Failed to expand heap by 3014656 bytes <lloda`>GC Warning: Failed to expand heap by 3039232 bytes <lloda`>GC Warning: Failed to expand heap by 3059712 bytes <lloda`>GC Warning: Failed to expand heap by 3080192 bytes <lloda`>GC Warning: Failed to expand heap by 3104768 bytes <lloda`>GC Warning: Failed to expand heap by 3125248 bytes <lloda`>GC Warning: Failed to expand heap by 65536 bytes <lloda`>GC Warning: Out of Memory! Heap size: 8 MiB. Returning NULL! <lloda`>Warning: Unwind-only `out-of-memory' exception; skipping pre-unwind handler. <lloda`>/bin/bash: line 5: 20918 Segmentation fault (core dumped) top_srcdir="../../../src4" srcdir="../../../src4/test-suite/standalone" builddir="." CHARSETALIASDIR="/home/danielo/sys/guile-git/obj4/lib" GUILE_AUTO_COMPILE=0 "../../meta/uninstalled-env" ${dir}$tst <wingo>probably we should use a pastebin next time :) <wingo>can you run GUILE_AUTO_COMPILE=0 meta/gdb-uninstalled-guile test-suite/standalone/test-stack-overflow <wingo>and paste the backtrace somewhere? <Onslauth>I am looking at the code fro 2.0.11 and I noticed that this patch is not in it: <Onslauth>Has the problem been fixed in another area, or will that patch still be needed. <lloda`>wingo: sorry about the blob earlier <wingo>Onslauth: dunno what's going on with that, is there a corresponding mail on bug-guile? that's the best way to make sure something gets done <Onslauth>I will have to ask them if they sent to bug-guile <wingo>lloda`: so it worked for you that time <wingo>lloda`: if you run it again a few times it succeeds for you in gdb? <Onslauth>Ok, they say they never sent to bug-guile <wingo>Onslauth: yeah guile-devel is great for discussion but when you need to track a patch it's best to make sure there is a bug-guile thread <Onslauth>They didnt send because Mark replied with: "I pushed a fix to stable-2.0." <Onslauth>Anyway, just let us know what needs to be done if you would still like the patch. <lloda`>wingo: yes, it seems to work there every time <wingo>Onslauth: if mark fixed it then there is no issue then :) <Onslauth>So must we re-submit it or wait for Mark to find out if he fixed it somewhere else? <wingo>no i think then the problem is fixed with a different patch <wingo>if you see the problem again, please let us know <Onslauth>Ok, well let me wait for mark and find out. <didi>Browsing Guile's files, I see module/srfi/srfi-64. Is it not yet ready for use? <didi>Ah, my bad. I'm running 2.0.9 and I don't have it here. <didi>Hum, should I bug the maintainer to upgrade it? <didi>Does Guile tag the releases? <didi>wingo: Debian's package. <didi>wingo: It was a rhetoric question tho. ;^) <wingo>you can try that, sure -- i think he knows about it but whatever :) <didi>I'm not finding a tag for the release. So, if there isn't one, is it possible to know from which commit a release was made? <wingo>perhaps you were looking on master instead of stable-2.0? <didi>wingo: No, I'm looking at stable-2.0. Maybe magit is tricking me. Thank you, I'll dig into it. <Onslauth>mark_weaver - can you ping me when you get a second, thanks. <didi>wingo: Yeah, it was obviously my mistake. <wingo>Onslauth: if it's about that bug, then if mark said he fixed it, then it should be fixed -- no need to bother people :) <Onslauth>Yeah, but that bug bit us in production and was hard to track down. <Onslauth>I am just being cautious, measure twice cut once. <Onslauth>I would also like to see how it was fixed if not with the patch supplied. <mark_weaver>Here's the commit: 10454601e03a20cc121d06d8004f96bb2a3b6fb5 <saul>General question: Why is running byte code faster than normal evaluation? You are still interpreting the contents of memory, just in the latter case the memory is in the form of an abstract syntax tree. <saul>Is the benefit mainly owing to a reduction in page faults? <saul>Or is there some other factors to be considered? <mark_weaver>saul: the byte code is not simply a trivial transformation of the AST. there's a considerable amount of optimization that happens as well. also, there's far less GC heap allocation by the compiled code, i.e. the stack is used where possible. <mark_weaver>there are quite a few reasons why the byte code is faster beyond what I've written here. <madsy>string->utf8 converts a string to a bytevector. But the terminating '\\0' is missing. Is that by design? <mark_weaver>madsy: UTF-8 says nothing about NUL terminators. that's a C string thing. <mark_weaver>there are C level functions that will convert a SCM string to UTF-8 with terminator. <madsy>That's true. I just assumed null-terminating the string would be a reasonable thing to do as bytevectors are handy to use in C <madsy>I use bytevectors for any function argument which requires a pointer. <mark_weaver>well, if you want to do anything else with that bytevector, e.g. writing it to a file or concatenating it with other bytevectors, it's the wrong thing to do. <mark_weaver>madsy: if FFI usage, I think you want string->pointer <madsy>In OpenGL's case, it's difficult to know whether char* is a string, or a pointer to some byte data. So I have to use bytevectors even for strings. <madsy>I could fix up the functions manually, but that's a lot of work. By just using bytevectors for everything, I was able to generate 99% of the code <madsy>So currently in guile code I use string->utf8 once, and then copy the result into a final bytevector which has space enough for a null terminator <mark_weaver>maybe you should do (string-append str "\\0") before converting to a bytevector. <madsy>Oh.. okay. So '\\0' isn't ignored all together? <madsy>So if I have two in a string, one of them are copied over? <mark_weaver>no, NUL code points are preserved. We need to C hacks. <madsy>Sorry. I keep forgetting the functions use the string/bytevector length, not a terminator <madsy>So string->utf8 doesn't add a '\\0' because there is no '\\0 to copy over. Right? <mark_weaver>it would be *incorrect* to add a NUL code point where one didn't exist in the string. <mark_weaver>for Guile, NUL is just another Unicode code point (which are called 'characters' in modern Scheme/Guile). <civodul>madsy: maybe you want string->pointer? <madsy>civodul: No, I need a bytevector. <madsy>I'll try string-append- It's probably faster than the bytevector-copy! I do currently <ijp>saul: not having to recompute expensive macros every time you run can be a big win <saul>ijp, mark_weaver, thank you for your responses. <mark_weaver>civodul: would it be easy to add a 32-bit clang build of guile to hydra.nixos.org? If so, could you add it? It turns out we have problems that would have been discovered much earlier if we had that. <mark_weaver>(fyi, the issue is that we had code that assumed that scm_t_uint64 would always be 8-byte aligned, but in 32-bit clang that's not the case) <civodul>mark_weaver: done; if it doesn't show up within an hour, let me know <mark_weaver>wingo: thanks for the kind words. you're great too :) <mark_weaver>civodul: I don't think so. I haven't anything in the C standards that would mandate that a 64-bit integer is 64-bit aligned. <mark_weaver>heh, you mean the "indeed" wasn't in response to "you're great too" ? LOL :) <mark_weaver>the silliness of the birthday party here is spilling out onto channel, I guess :) <civodul>actually int64 is not in the SysV ABI ps386 <mark_weaver>even if it was, that would only help us on intel systems. <mark_weaver>unfortunately, even C99 has no portable way to specify alignment that I can find. We need C11 for that. <civodul>well there's no problem on 64-bit platforms, for instance, because the ABI specifies this <mark_weaver>ABIs are specific to a platform. we need a solution that's portable. <civodul>i'm just arguing in case we find it's a Clang issue ;-) <mark_weaver>if you search for SCM_ALIGNED in libguile/control.c, you'll find that it supports systems where SCM_ALIGNED is undefined by avoiding static allocation in that case. <mark_weaver>but maybe we should require that there be some way to specify static alignment, and just add a case for C11 to the definition of SCM_ALIGNED (that uses _Alignas) <mark_weaver>speaking of portability, I think we should consider requiring C99 as a baseline. we could remove a substantial amount of compatibility cruft and Guile-specific type names, #ifdefs, etc. <zacts`>mark_weaver: what's this about alignment? will it affect my FreeBSD patches? ***ijp is now known as logan5
***logan5 is now known as ijp
<joolean>I'm thinking about building a Guile client library for a client-server framework that's fairly event-oriented. That is to say, the client's role is mostly to listen for and dispatch messages it receives from the server to client-side handlers. <joolean>This seems like a natural fit for integration with a main loop of some sort in a client application <joolean>What are my options for that when it comes to Scheme? <joolean>I know guile-gnome exposes some of GLib's main loop stuff. <joolean>Is there a more Guile-y / Scheme-y way to go? <didi>joolean: I would try very hard to keep a REPL running along with the application. <joolean>Okay. Can you be a bit more specific? My intent is to provide this client library as reference code that works well for people doing mainstream application development in Guile (or using Guile in obvious ways from C, e.g.) <joolean>I guess I'm just asking, how do people do event handling in Guile these days? <mark_weaver>zacts: the alignment problem is what was fixed by the patch I gave you. <mark_weaver>it's just that the patch I gave you isn't quite portable enough as-is to go into guile git yet. <zacts>mark_weaver: ok, I would like to use the more portable patch once it's ready. <zacts>but for now, this one will suffice. <mark_weaver>zacts: yeah, the one you have should work for any gcc, clang, icc, or sun pro compiler, anyway. ***wingo_ is now known as wingo
<zacts>wingo: aren't you one of the early guile hackers? <taylanub>zacts: I don't know about wingo but I know that Guile is pretty much exactly as old as me. :P <taylanub>(Likely older than me by a couple months, I was born in December.) <zacts>I was scheduled for December, but I was a premie <wingo>zacts: actually no! one of the latter-day guile hackers <zacts>ah, I just think I remember reading about 'the history of guile/scheme' from a wingo somewhere. <ijp>in the beginning there was tcl, and rms saw it was not good <wingo>i did write an article but it was from the perspective of a contemporary historian :) <zacts>ijp: was tcl around before scheme? <zacts>anyway, /me reads his scheme book <mark_weaver>zacts: and the original SIOD upon which SCM was based, upon which Guile is based, came out about the same time Tcl appeared. <ijp>zacts: TECO is the Tape Editor and COrrector, which is the language the original emacs was written in <ijp>tcl is kinda like sh <ijp>zacts: originally it wasn't even interactive <cluck>nothing is as horrid as viml <zacts>I highly highly dislike viml. php is heaven in comparison. <zacts>By gosh! I think I'm getting a lisp in my voice from using emacs and guile! <zacts>I now sound like a snake. thanks a lot guys! :/ <zacts>wait no, I sound like a cool (guile) scheme hacker now. <zacts>I have a local scheme user group where I live. <zacts>I should introduce myself on the mailing list and check it out.