IRC channel logs

2019-12-20.log

back to list of logs

<nly>sneek later tell janneke Manuals are up https://www.nongnu.org/emacsy/manual/emacsy.html
<sneek>Okay.
<bandali>niice
<nly>:)
<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
<str1ngs>nly: nice work, thank you
<str1ngs>neeeding*
<nly>jcowan: Emacsy already can do a lot without using C. I think you might be asking about the event loop, let me see
<nly>heyyy :)
<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.
<str1ngs>see https://git.savannah.nongnu.org/cgit/emacsy.git/tree/emacsy/emacsy.c#n113. emacsy_tick is just a C helper for scheme emacsy-tick
<nly>this is much better than i could say
<nly>everything you need should be in (emacsy core) module
<nly>no c required
<str1ngs>actually (emacsy emacsy) exports everyting.
<str1ngs>IIRC
<nly>yep
<str1ngs>emacsy is well designed. expect for the stack. lets not talk about that lol
<str1ngs>except*
<nly>lol
<str1ngs>how is the release going nly?
<nly>it's done
<str1ngs>nice thank you. I just had a chance to look at it
<str1ngs>and tarballs! :)
<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>Ah
<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
<manumanumanu>judge some of them actually usable for mainstream use?
<manumanumanu>Happy friday, btw!
<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
<lloda>or .6, anyway
<roptat>hi! I'm looking for a way to compact a url, like "https://example.com/test/../foo" -> "https://example.com/foo". I've been looking at (web uri) but there's nothing obvious... I tried (uri->string (string->uri "https://example.com/test/../foo")) but that didn't work :)
<roptat>it's more like "get a canonical url/uri" actually
<manumanumanu>lloda: that was what I was referring to :D
<manumanumanu>hmmm... srfi-171 binds intermediate values where let-values does not
<manumanumanu>srfi-71
<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>where they are not necessary.
<lloda>oh
<lloda>an implementation artifact?
<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>hmm
<lloda>I'm a fan of srfi-71, I don't use -11 or -8 anymore in fact
<manumanumanu>oh! sorry
<lloda>why :D
<manumanumanu>the optimizer solves it.
<lloda>oh
<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
<lloda>I'll make a patch
<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.
<manumanumanu>I might start using it as well!
<lloda>it's a big help with long let* chains tbh
<lloda>well, it's just neater looking
<lloda> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=cf5b4a1db8ad4c1060f08f07113791dd34374266
<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 :-/
<manumanumanu>exactly.
<lloda>I'll send that patch to the list later today
<manumanumanu>is string-contains? based on KMP-search?
<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.
<dsmith-work>Happy Friday, Guilers!!