<jcowan>nly: I just looked through the manual: impressive for a WiP. Is there going to be a published Guile interface too, so that Guile programmers can use it without stuffing things through the C API? <str1ngs>jcowan: emacsy can be used from guile without needed the C API <nly>jcowan: Emacsy already can do a lot without using C. I think you might be asking about the event loop, let me see <str1ngs>you just need a loop with emacsy-tick IIRC the right procedure name <str1ngs>from what a gleamed when reading the C source. it simply exposes some C functions to make life easier for a C program. the C functions wrap scheme code. <nly>this is much better than i could say <nly>everything you need should be in (emacsy core) module <str1ngs>actually (emacsy emacsy) exports everyting. <str1ngs>emacsy is well designed. expect for the stack. lets not talk about that lol <str1ngs>nice thank you. I just had a chance to look at it <jcowan>str1ngs: You mean it eats Scheme stack? <str1ngs>jcowan: nothing like that, just it uses a stack library for buffers ***catonano_ is now known as catonano
<jcowan>I may write a ring-buffer library at some point, but not right away ***lavaflow_ is now known as lavaflow
*spk121 is revisiting some of my 10yo Guile code. Strange to read... <str1ngs>jcowan: we are looking to see if we can improve on the custom one emacsy is using. <str1ngs>jcowan: I think nly was looking at using a srfi if possible <ArneBab>spk121: how your coding style changed would be a very interesting blog post, I think. <manumanumanu>wingo, civodul: regarding srfi-171, I doubt I will have any time to hack on it during the christmas holidays. What is the policy on when to include srfis? I will miss 3.0 (I have probably missed any feature window if there is such a thing). Does srfi-171 have to wait for 3.2? I also have a bunch of non-portable transducers that were not included in the srfi. Should those go in (srfi srfi-171 gnu) if I were to <lloda>manumanumanu: I think a new srfi could go in 3.1 since it's not an incompatible change <lloda>oh I mean it could go in at any time <manumanumanu>lloda: I read through some old NEWS and the extended let-form was included in a 2.2.x release. <manumanumanu>Anyway, I will probably finish it by the end of january. <lloda>also srfi-71 was introduced in 2.2.5 <roptat>it's more like "get a canonical url/uri" actually <manumanumanu>hmmm... srfi-171 binds intermediate values where let-values does not <lloda>wdym let-values doesn't bind? <lloda>isn't that what let is about? <manumanumanu>lloda: they both expand to lambdas with call-with-values. srfi-71 expands to code using extra temporary variables <manumanumanu>probably. Maybe it is needed to handle some of the (values ...) semantics <manumanumanu>I should compare the assembler though to see if the code is any different. <lloda>I'm a fan of srfi-71, I don't use -11 or -8 anymore in fact <lloda>I didn't realize that there is already an (ice-9 string-fun) module in Guile :O <lloda>I thought chrislck yesterday was talking about creating it <lloda>it's all undocumented it seems! <lloda>I think it's no problem to add string-replace-substring in there <manumanumanu>lloda: so, most examples I have thrown at it produces similr ,opt code, and when the code ,opt prodeces isn't "optimal" it still produces similarly fast assembler. <lloda>it's a big help with long let* chains tbh <lloda>well, it's just neater looking <manumanumanu>The beauty of having to add a let-values in-between a chain of let* is questionable :D :D <lloda>you'd use let*-values for the whole chain and then it would be full of redundant parens :-/ <lloda>I'll send that patch to the list later today <manumanumanu>One could benchmark it against the srfi-13 implementation. <roptat>oh well, I read the RFC and implemented what I needed :) <ArneBab>manumanumanu: nowadays I mostly use define and avoid let* ***ng0_ is now known as ng0
<jcowan>I mostly use top-level define and do my own lambda-lifting <manumanumanu>ArneBab: well, if you want it to run fast on 2.2, there is some overhead using define. Porting pvector from racket actually showed that the overhead was quite substantial.