<dje42>gdb+guile is testsuite clean. two dozen FIXMEs and it'll be about ready. <dje42>[this is just a first pass at functionality of course] <dje42>don't have one yet. gdb will have its own git repo soon. i might just put it there <gzg>Is there a log anywhere, to track what is left to do until 2.2 hits? Just generally curious. <ijp>gzg: wingo has been updating his TODO on guile-devel I think, but mark_weaver's current TODO is not online ;) <ijp>fuck off, you are not welcome here *gzg really needs to set up his Emacs config, so it'll open up guile-devel and guix-devel in a single frame at launch -- via gnus. <ijp>mark_weaver: you need to call him out though, or other people fall for it <ijp>gzg: habitual timewaster *gzg really needs to look into Emacs buffer, window, and frame management a lot more in-general though. :^U *nalaginrut is afraid of most people don't want to here Artanis anymore if gavino always like this... <gzg>nalaginrut: Packaged for guix yet? Stable release yet in-general? <mark_weaver>the best thing is to pretend he doesn't exist at all. then he will eventually get bored and leave. any mention of him will only encourage him. <nalaginrut>gzg: no, I'll release it carefully, at least after there's ORM and MVC <nalaginrut>anyway, the latest update is re-implement template with a regular lexer/parser *gzg is glad to see that there's a significant stack of software building on top of Guile. :^) <gzg>nalaginrut: License? I can't seem to find it referenced. <nalaginrut>yes, I forget it, but GPL was declared in any header of files *gzg needs to start checking there as soon as I don't see a dedicated file... but always seems to forget. :^/ <gzg>nalaginrut: It seems, in-terms of libraries, the rule of thumb is to more-often-than not go via the lgpl, from what I've seen. <nalaginrut>you're suggesting GPLv3? that's the current license in declaration, though missing a copying of it in TOPLEVEL *gzg is still confused if GPLv3 is really appropriate for his introductory text (that in-turn, he's writing to cement guile into his own head) -- but civodul made it sound like due to how Skribilo's written, it'd pretty much would have to be? <gzg>nalaginrut: Are you asking me, in terms of license? <nalaginrut>I have to understand GPLv3 carefully, since many of my friends have same question like me <nalaginrut>hack means dig then try to understand it here ;-P <ijp>gzg: most people choose their license for cultural reasons <gzg>Ah, do you mean you need to "hack away" at learning the license; Like you need to start working through it piece by piece? <gzg>ijp: Can you expand on that notion? <ijp>clojure and the eclipse license, haskell and the bsd, elisp and the gpl, python and the python license, perl and the artistic license,... <ijp>gzg: code tends to inherit the license of the language implementation, since it means you don't have to think about it <gzg>ijp: Ah, I thought you were speaking globally for a second. :^P <dsmith>nalaginrut, sneek has a fuzzy nick matcher. "seen" matches "sneek" unfortunately. <dsmith>ijp, How did you recognize him has gavino ? <ijp>partly his host, partly that he uses a small set of nicks <ijp>gavino, republican_devil, chaotic_good, and I think one more <taylanub>Hah, so sneek only reacts to "seen" because it fuzzy-matches "sneek" ? :P <wingo>there's still a fair number of things to squeeze out <wingo>the compile loop could be twice as fast i think <wingo>in the annotation i also show stack vm compilation <wingo>that's the ,time of the raw expression <wingo>there's a ,time of a compiled rtl thunk, then the stack vm code <wingo>anyway, looking forward to it <wingo>i finally did the right thing and broke down and computed precise liveness information instead of the bogus things i was doing earlier <dsmith-work>OR not? I was comparing 1.375221s real time with 0.013949s real time <wingo>primitive-eval is slower than compiled code, yes <wingo>those are the times for rtl-compiled eval and rtl compilation <wingo>2.436763s and 0.023601s are the stack VM eval and compiled times <wingo>so we are getting around 90% speedup for eval <wingo>and something similar for compiled code <wingo>whee, that fixed my vlist miscompile issue too... <wingo>just pushed some changes to master <wingo>bah, it bails contifying psyntax, boo :) <brendyn>davexunit: how awesome are we talking? <brendyn>Does it have the register VM doohickey yet? ***add^_` is now known as add^_
<mark_weaver>davexunit: fwiw, I do think it makes sense for alist->hash-table to give precedence to the leftmost one in the case of duplicate keys, but unless I'm mistaken, that's not what the current code does. <davexunit>mark_weaver: you're right. I wrote that it was leftmost, but what I meant to write was rightmost. <davexunit>mark_weaver: thanks for the really thorough review. <mark_weaver>the code should probably be changed to take the leftmost one though. <davexunit>thanks for noticing those tabs, I guess I should use whitespace mode to check for that in the future. <mark_weaver>because alist lookups always find the leftmost one, and a lot of code takes advantage of that fact, e.g. by "overwriting" an alist entry by merely consing a new pair to the front. <davexunit>ah that is a great reason to make it leftmost. I did not know about that before. <shanecelis>What's a good way to do a kind of emacsclient but for Guile? So a guileclient Suppose I'm running a REPL server. Do I just telnet into it, and send some expressions? <wingo>but the best way is to usegeiser <wingo>guile --listen then M-x connect-to-guile <mark_weaver>shanecelis: if it's okay to evaluate the expressions in a separate posix thread, then you can just use the (system repl server) stuff. <mark_weaver>shanecelis: if you want to instead run the expressions within an existing posix thread, e.g. within one of your coroutine-based green threads, then you might want to do something similar to what davexunit is doing with guile-2d. <shanecelis>Cool. All right. I think I see the way through. I'm using geiser with Emacs, which is nice. I just want a command where I can control part of the app from elsewhere. <mark_weaver>shanecelis: if you don't need a full REPL, then it gets a lot easier. <shanecelis>mark_weaver: Yeah, I kind of just want to be able to throw some expressions at it. <madsy>shanecelis: I'm doing something similar as well :) <madsy>shanecelis: I've embedded Guile in my game/demo framework and implemented functions for input- and graphics handling. I connect to it remotely with geiser <mark_weaver>if there's a socket that can accept arbitrary expressions to evaluate, then it better be a unix socket with tight perms. <shanecelis>mark_weaver: Yeah, planning on keeping it local. Perhaps a unix socket would be better. <madsy>Or just don't start a REPL server in the final version <mark_weaver>local TCP sockets are not safe. for example, web browsers can be manipulated into accessing them. <mark_weaver>wingo wrote something up about that on his blog, but it's far enough back that I'm having trouble finding it now. <mark_weaver>(can't think of the right search terms to use to find it) <mark_weaver>well, I guess it's a bit more limited than I thought.. but in any case, local TCP sockets are open to other users on the same machine. <stis>I notised that guile-eval uses list-ref, list-set!, can that be fixed by using vlists? <stis>e.g. do we know if these operators are limiting the speed of eval? <wingo>stis: those operators do limit the speed, but the fix is to use a 2-dimensional environment <wingo>anyway we can't do vlists in eval, because of bootstrapping issues <stis>well I got a vlist implementation in C ;-) But as you saye two dimensional is the king! <wingo>gah, i pushed a contification rewrite, and everything was fine; except that i think it's not contifying any more <wingo>hard to test these things... <wingo>i was comparing times from one machine to times on another, and they aren't the same of course *wingo done being a fool for today <wingo>mark_weaver: psyntax makes it through the optimizer, it seems, though it doesn't quite make it through cps->rtl <wingo>still some pre-module bootstrapping issues tho <wingo>i'm going to pick this up again in a few days <aleix>in guile-json i'm using a record to store parser state (like column and line). i did some test loading a 600kb json file, and it's *slow* moslty because of altering column and line in the record itself <aleix>i don't want to have a module column and line variables, as we could not have different parsers running <aleix>i could pass column and line to the functions <aleix>but it's kind of inconvenient...