IRC channel 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

<sneek>:)

<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>Okay.

<dsmith>!uptime

<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: https://www.emacswiki.org/emacs/GuileEmacs

<civodul>CPUs became faster in the meantime :-)

<rekado>an actual (and preventable) source of slowness was that modules were not pre-compiled

IRC channel logs

2023-05-02.log