IRC channel logs

2021-10-14.log

back to list of logs

<robin>ideally, guile-emacs would make it possible to write more of emacs *in* elisp, and then things like keymap support could be written in elisp and used from guile
<robin>lilyp, BLVs might actually be written in pure scheme using delimited continuations :D but that'll depend on performance and, i think, ensuring the scheme implementation can be used without capturing c stack frames (which iirc wasn't possible with delimited continuations last time i checked, ages ago)
<robin>or to be precise i did prototype them in pure scheme based on kiselyov et al's work on delimited dynamic binding (...over a decade ago, wow), but i've no idea what performance is like compared to emacs's BLVs
<RhodiumToad>how would that work?
<robin>RhodiumToad, how would what work? scheme-based BLVs in general or something mentioned earlier?
<RhodiumToad>using delimited continuations to do BLVs
<lilyp>robin: I wasn't trying to say that it's impossible to do BLVs in Guile. I simply said you can't have BLVs without Bs.
<lilyp>and Guile-Elisp != guile-emacs
<lilyp>Obviously the latter will depend on the former, but you could write the basic procedures that Emacs requires in C or Guile (possibly utilizing FFI somewhere) and do the rest in Elisp
<lilyp>In fact, I'd argue that there's some things you might want to implement in Tree-IL directly rather than going to any of the higher languages.
<robin>lilyp, oh, fair enough re: the B in BLVs (i don't know how widely-known the delimited dynamic binding research is, or whether guile's delimited continuations are widely used, even)
<RhodiumToad>you mean other than for error handling? :-)
*RhodiumToad has experimented with shift & reset, which required a certain amount of effort to understand
<lilyp>Well, I abuse prompts to do "cooperative" "multi"-"threading", does that count?
<robin>RhodiumToad, https://okmij.org/ftp/Computation/dynamic-binding.html is the background research, https://www.gnu.org/ghm/2011/paris/slides/bt-templeton-guile-emacs.pdf has a...terse sketch in scheme (i was informed about the talk the day before ;)), which one can play with directly i think although it'd take me a minute to remember how to use it
<lilyp>sheesh, ten years old
<robin>i'll see if i can dig up a better example (i know i wrote some test scripts at least, which are...somewhere amongst my archived files)
<robin>lilyp, of course it does :p
<robin>and i guess error handling is a relatively popular application
<robin>i think shift/reset in friends may have been relatively new in guile when i was writing this stuff
<robin>guile-emacs may seem to have taken an absurdly long time, but it was funded by GSoC summer internships, and i only worked on it for a little over a year...spread over five years, with a lot of time spent on rebasing and generally catching up with the last year's worth of emacs development each summer
<robin>it works, the next trick (beyond rebasing, reconciling the "new" thread and ffi support with guile's, etc.) is making it fast. correctness was always priority #1
<robin>lilyp, hmm, i hadn't considered hacking tree-il directly, but it's certainly worth considering
<robin>in tree-il*
<lilyp>Obviously, we need prompts to implement Emacs' cooperative multithreading :P
<robin>oh, right, i forgot emacs only had cooperative multithreading (although "correct programs should not rely on cooperative threading" -- (info "(elisp) Threads"))
<robin>RhodiumToad, https://paste.debian.net/1215326/ is a better example (actual implementation + simple tests)
<robin>of "context-local variables"
<robin>";; No MV handling because Elisp lacks MVs" -- not until someone finishes guile-cl and integrates it with elisp, at least ;)
<RhodiumToad>MVs?
<robin>multiple values
<RhodiumToad>ah right
<robin>(well, scheme has them too of course, they ought to be handled in any case since guile-emacs provides @/@@ for access to scheme modules)
<robin>btw you can see a limitation of the current implementation at the end of that paste -- it relies on eq? to detect when a fluid's been mutated within a context
<robin>and i don't have a good solution for make-variable-buffer-local yet
<robin>but otherwise it's fairly complete
<lilyp>robin: couldn't you use identifier syntax or something similar to make (make-variable-local 'y) → y is always (contex-ref (%current-context) 'y)?
<lilyp>well, one percent too many it seems
<RhodiumToad>I don't think that works because you don't know at compile time that it's buffer-local
<wingo>o/
<wingo>interesting article supporting our eventual-plan of moving to utf-8 strings https://swift.org/blog/utf8-string/
<wingo>cc rlb
<civodul>wingo: interesting!
<civodul>why they used UTF-16 in the first place is a mystery
<civodul>i mean, if you're going to do variable-size encoding, why not choose UTF-8?
<wingo>i think objc
<wingo>which probably has the same history as java, js etc with ucs-2 vs utf-16
<civodul>ah ok
<lampilelo>so up till now i've been using PKG_CHECK_MODULES to get the flags needed for guile, to make it easy on myself i wanted to use GUILE_FLAGS instead but now autoreconf throws me an error that build-aux/config.rpath doesn't exist. What am i missing?
<civodul>lampilelo: hi! GUILE_FLAGS is kinda deprecated, isn't it?
<lampilelo>is it? the manual doesn't say anything about that
<lampilelo>hmm... ok, i think my problem is somewhere else
<lampilelo>it pulls m4 macros from my older installation of guile
<civodul>ah
<chrislck>sneek: decepticons
<sneek>I could be wrong, but decepticons is the sworn enemy of autobots
<lampilelo>i set ACLOCAL_PATH and now it pulls the correct file, but it didn't really change anything, if GUILE_FLAGS is deprecated, what should i use?
<wingo>lampilelo: imo you should include guile.m4 in your acinclude.m4. that way you know you have a version of guile.m4 corresponding to the guile that your code is written for
<wingo>anyway that is what i do
<wingo>i.e. cat /path/to/guile.m4 >> ./acinclude.m4
<lampilelo>i'll take that into consideration but for now the main problem for me is GUILE_FLAGS complaining about nonexistant build-aux/config.rpath, i'm not overly familiar with autotools so i don't really know what that means and what should be done about it
<lloda>that's an autogen.sh output iirc
<lloda>it used to be in the guile source and i removed it
<lampilelo>i went back to my old ways of PKG_CHECK_MODULES(GUILE, [guile-3.0])
<lloda>ra-reshape ra k s ... -> rb
<lloda>my bad bad paste
<lloda>at least that's the first option listed in https://www.gnu.org/software/guile/manual/html_node/Autoconf-Macros.html
<lampilelo>lloda: so you say that config.rpath file needs to be provided by me if i want to use GUILE_FLAGS?
<lloda>you shouldn't need to, that isn't even an installed file, it's just part of the build process of Guile
<lloda>looks broken to me that GUILE_FLAGS requires it
<lampilelo>it's mentioned inside the definition of GUILE_FLAGS
<lloda>m4/lib-link.m4
<lloda>but config.rpath isn't installed, so how did that work when the file was part of the source? if it did
<rlb>wingo: thanks, I'll take a look. And I was just thinking about that again, though I don't know for sure if/when I'll resume my attempt. I'd gotten pretty far, but it also got complicated, and I got side-tracked :)
<lampilelo>omg because of scheme i constantly forget about ; in c
<rlb>Hmm, if their stride is what it sounds like, then they may have done exactly what I've been doing.
<dsmith-work>Hey Hi Howdy, Guilers
<tricon>dsmith-work: Howdy, howdy.
<dsmith-work>!uptime
<sneek>I've been running for 2 days
<sneek>This system has been up 12 weeks, 1 day, 2 hours, 31 minutes