IRC channel logs


back to list of logs

<ArneBab>johnjaye: the pain problem I saw in guile-emacs was that it did not have bytecode support, so startup was really slow.
<dsmith>sneek, botsnack
<dsmith>rekado, Did find/fix the month rollover bug in the logging? Seems to be working!
<dsmith>sneek, later tell danisanti Guile *used* to be able to save its image. Was called "unexec"
<sneek>Got it.
<dsmith>sneek later tell wingo oom
<sneek>I've been serving for 10 days
<sneek>This system has been up 4 weeks, 2 days, 4 hours, 29 minutes
<flatwhatson>re: lisp images, scheme48 supports them, it's used to bundle the core libs with the VM (ie. running scheme48 actually loads a default image) and applications can dump their own images
<flatwhatson>re: guile emacs, i think there is still latent interest in a schemey editor. one interesting alternative direction is edwin, which is an emacs clone (minus elisp) in scheme. i think it only works on MIT/GNU Scheme currently, but could be ported to other schemes with some effort
<dthompson>I don't think even the people that made edwin would want to give up emacs :)
<RhodiumToad>problem is that emacs represents a huge investment in elisp code
<dthompson>and yeah that's right, guile-emacs didn't have bytecode support, which is an example of a technical problem that could have been solved if the emacs folks liked the proof-of-concept and wanted to move in that direction.
<dthompson>guile-emacs was a very cool experiment. would have been cool if it resonated with the emacs community.
<flatwhatson>replacing emacs would probably not be the goal of an edwin port, obviously emacs+elisp is a behemoth
<flatwhatson>there's value in having a clean integrated editor+repl/runtime+gui even if it can't run gnus natively :)
<ArneBab>flatwhatson: I guess that it would need its own user experience vision — similar to nano differs from emacs and vim.
<flatwhatson>well there are great ideas for interactive programming environments both from history (genera, squeak) and modern times (jupyter, clerk)
<flatwhatson>i think drracket is somewhat in that direction too?
<lloda>imo guilemacs is very rescuable, but ofc that needs people
<Arsen>it'd be nice for guile to gain some of the features of the elisp compiler (namely libgccjit integration), so I imagime there could be mutual benefit to it
<lloda>guile already has a jit
<lloda>the progress in emacs has been great but ofc it makes guilemacs seem less interesting
<Arsen>sure, but libgccjit can make use of the gcc optimizers
<ArneBab>Arsen: Guile uses the lightening framework instead, trying to find the right balance for Guile code.
<mwette>last time I read up on guile-emacs I read that there was slowness, apparently due to the implementation of dynamic binding; this might be the ref:
<civodul>CPUs became faster in the meantime :-)
<rekado>an actual (and preventable) source of slowness was that modules were not pre-compiled