diff options
| author | Sacha Chua <sacha@sachachua.com> | 2021-12-04 21:05:14 -0500 | 
|---|---|---|
| committer | Sacha Chua <sacha@sachachua.com> | 2021-12-04 21:05:14 -0500 | 
| commit | 76bd2482a4d8ca5ff192915cba7b9893c9a968a7 (patch) | |
| tree | 087a687249f066f5b0e81f89741e3f92a943c8bf /2021/talks/native.md | |
| parent | dc3a0b09cc0c9b7c09709008ddb4f6c12f38a6f8 (diff) | |
| download | emacsconf-wiki-76bd2482a4d8ca5ff192915cba7b9893c9a968a7.tar.xz emacsconf-wiki-76bd2482a4d8ca5ff192915cba7b9893c9a968a7.zip | |
Video tweaks, removed slashes too
Diffstat (limited to '2021/talks/native.md')
| -rw-r--r-- | 2021/talks/native.md | 16 | 
1 files changed, 8 insertions, 8 deletions
| diff --git a/2021/talks/native.md b/2021/talks/native.md index b35b6e7c..2916c9f5 100644 --- a/2021/talks/native.md +++ b/2021/talks/native.md @@ -34,11 +34,11 @@ Format: 40 minutes  Pad: --   Q1: Why do you say that Elisp is \*nearly\* a general purpose -    programming lang? What\'s missing? (and btw, huge thanks for your +-   Q1: Why do you say that Elisp is *nearly* a general purpose +    programming lang? What's missing? (and btw, huge thanks for your      work!)      -   A: --   Q2: Is this the \"rudiments\" that the garbage collector talk was +-   Q2: Is this the "rudiments" that the garbage collector talk was      discussing yesterday? Feel free to ignore this n00b question.       -   A:  -   Q3:Is the idea to enventually develop Emacs itself in ELisp (c.f.  @@ -60,7 +60,7 @@ Pad:      written in C? Could/should some of the existing C code be converted      without significant performance loss?      -   A: --   Q7: What\'s the risk of (setq native-comp-speed 3)? +-   Q7: What's the risk of (setq native-comp-speed 3)?      -   A: Not sigificant risks.  Some side effects might include:          needing to recompile a whole file or compilation unit when          redefining a function, otherwise the old function definition @@ -69,7 +69,7 @@ Pad:      runtime introspectability, changeability/redefinability, etc?      -   A:  -   Q9: Is there a benefit in setting native-comp-compiler-options to  -    \"-mtune=native -march=\<cpu\>\"? +    "-mtune=native -march=<cpu>"?      -   A: Not at the moment.  Maybe in the future if, e.g. libgccjit is          enhanced further.  -   Q10: You mentioned native-comp coming in emacs 28, will this be the @@ -79,7 +79,7 @@ Pad:  -   Q11: Could we avoid libgccjit.so? Or consider using another jit lib      (e.g. dynasm used by luajit) et al to gain better optimization      -   A: libgccjit is more for AoT compilation, more in-depth -        optimization, which JITters don\'t typically do, so they aren\'t +        optimization, which JITters don't typically do, so they aren't          really equivalent.  -   Q12: How much of emacs C code base could be translated to      emacs-lisp? What is the minimum C code base necessary?  (seems @@ -104,13 +104,13 @@ Pad:          interesting, though.  There may be some possibilities, e.g. with          regard to some similarities between Rust and some CL          implementations. --   Q16: Why not implement Emacs Lisp in Guile and use Guile\'s +-   Q16: Why not implement Emacs Lisp in Guile and use Guile's      compiler?      -   A: (not Andrea answering) This has already been tried and done,          lookup Guilemacs, e.g. on EmacsWiki.          -   A: I think they meant to implement Elisp in Guile, and not              to replace Elisp with Scheme -            -   Yes, that\'s already been done.  Guile can already run +            -   Yes, that's already been done.  Guile can already run                  some subset of Elisp.  Look it up.  :)  BBB: | 
