Anyone tried GuileEmacs with this version and noticed any differences?
IIRC there is still some unmerged elisp implementation code out there that improves certain things, but performance is still bad because things are not yet optimized.
GNU Guile 2.2.0
31–40 of 149 posts
Re: GNU Guile 2.2.0
#32For those excited about the "Guile's Elisp implementation" in this release. The last major Guile release was 6 years ago, and much of this GuileEmacs work is still highly WIP and from my searching on emacs-devel seems to have stalled in 2015 for lack of volunteers. Just because Guile implements Elisp the language doesn't mean there isn't a ton of work to be done on Emacs itself to swap out its native VM for Guile, an…
What's left to be done?
I'm not involved in Emacs/Guile/GuileEmacs development. I just searched emacs-devel / EmacsWiki before writing that comment.
Having said that it seems to be in a POC state, but is very slow and needs optimization. These two wiki pages provide a decent overview: https://www.emacswiki.org/emacs/GuileEmacs & https://www.emacswiki.org/emacs/GuileEmacsTodo
This "Preview: portable dumper," thread from November 2016 and spin-offs appear to be the most up-to-date emacs-devel discussion on the subject: https://lists.gnu.org/archive/html/emacs-devel/2016-11/threa...
The older October 2015 "In support of guile-emacs" thread seems to have been written after development mostly tapered out, discusses some work to be done, and is a call for more development (which seems to have gone unanswered): https://lists.gnu.org/archive/html/emacs-devel/2015-10/threa...
All the work on the Emacs integration appears to have been done by Robin Templeton in early 2015 with no commit since May 2015: http://git.hcoop.net/?p=bpt/emacs.git;a=shortlog
Re: GNU Guile 2.2.0
#33Why are those brackets there in the syntax? What's the need? It looks hard to read when the programs are bigger. Is there any super advantage to it?
This "problem" is not unique to Lisps. Quite often, when I look at a piece of code written in C++, especially when it uses lambda functions inside calls, I can't help asking myself why there are so many brackets (and whether a Lisp would be a better alternative to C++, syntax-wise). The syntax of the lambda itself in C++ is sort of funny: it requires to use all the bracket types at the same time! [](){}
But they're not interchangeable, so they give an person reading the code a strong hint whether it's a array index, function call/grouping, or a code block.
Re: GNU Guile 2.2.0
#34To try out Guile 2.2.0 easily from any GNU/Linux distro (from the full release notes): Bonus track! This release also contains a new experiment, a binary installation package for the x86_64 architecture. The GNU Guix project (https://guixsd.org/) has assembled a graph of package definitions (for example, GCC, glibc, Guile, and so on) and is able to build that graph in an entirely deterministic way starting from only…
Technical question: What are .lz files? Is this LZMA compression? If so, why not using the more popular .xz format?
Re: GNU Guile 2.2.0
#35Why are those brackets there in the syntax? What's the need? It looks hard to read when the programs are bigger. Is there any super advantage to it?
Why are people downvoting for asking a question?
Re: GNU Guile 2.2.0
#36To try out Guile 2.2.0 easily from any GNU/Linux distro (from the full release notes): Bonus track! This release also contains a new experiment, a binary installation package for the x86_64 architecture. The GNU Guix project (https://guixsd.org/) has assembled a graph of package definitions (for example, GCC, glibc, Guile, and so on) and is able to build that graph in an entirely deterministic way starting from only…
Technical question: What are .lz files? Is this LZMA compression? If so, why not using the more popular .xz format?
I'm not sure but probably because it produced a smaller file than xz.
Re: GNU Guile 2.2.0
#37For me this is the most exciting part: Complete Emacs-compatible Elisp implementation Thanks to the work of Robin Templeton, Guile's Elisp implementation is now fully Emacs-compatible, implementing all of Elisp's features and quirks in the same way as the editor we know and love. This means we can finally have a proper GuileEmacs!
Also exciting is the "Fibers" functionality for I/O as well as the updates to the vm instructions that will more naturally facilitate JIT compilation. Especially now that a 2.2 release has been cut, I wouldn't be surprised if JIT compilation makes it upstream soon:
https://lists.gnu.org/archive/html/guile-devel/2017-03/msg00...
Re: GNU Guile 2.2.0
#38Re: GNU Guile 2.2.0
#39Earlier quoted context omitted.
This "problem" is not unique to Lisps. Quite often, when I look at a piece of code written in C++, especially when it uses lambda functions inside calls, I can't help asking myself why there are so many brackets (and whether a Lisp would be a better alternative to C++, syntax-wise). The syntax of the lambda itself in C++ is sort of funny: it requires to use all the bracket types at the same time! [](){}
But they're not interchangeable, so they give an person reading the code a strong hint whether it's a array index, function call/grouping, or a code block.
Oh, that's yet another issue: in the context of the above example (which, incidentally, was not merely a list of all kinds of brackets) the meaning of the pair of square brackets is changed from 'array index' to 'lambda'.
Re: GNU Guile 2.2.0
#40Congrats to the Guile team. Remember -- Guile goes with everything.