Bytecode overflow

[seagle0128]

In recent versions, this error is showed while installing.

e.g.

doom-Iosvkem-theme.el:200:6:Error: Bytecode overflow
doom-one-theme.el:155:5:Error: Bytecode overflow

[ema2159]

Yes, Henrik is working on it. It's the compiler unable to manage the doom def theme function. Given this just happens during compile time it's not that big of a problem, but it we're working on it

[seagle0128]

Thank you for updating!

[bandali0]

Just chiming in to say that I bumped into the same problem today while packaging emacs-doom-themes for Guix, which does indeed do byte-compiling. So I'd very much appreciate a fix for this :)

[alphapapa]

After this is fixed, I'd love to see a write-up of what caused it and how it was fixed! :)

[jupart]

Is there another way to install this package? I'm unable to install.

[hlissner]

@seagle0128 Does increasing gc-cons-threshold and/or max-lisp-eval-depth stave off these errors?

[seagle0128]

@hlissner No, it doesn't work for me.

[hlissner]

I've disabled byte-compilation of theme files in 9cd6872. Which resolves this issue. This is a temporary fix while I work on https://github.com/hlissner/emacs-doom-themer; which will eventually replace this package's API for themes (and properly address this).

When I first wrote doom-themes my elisp-fu was weak. Performance and sane code be damned, I did what worked to make it easier for me to write multiple themes off a common base, but with some syntax sugar in the mix. What worked was a gratuitously iterative, accumulative and recursing monstrosity that threw space efficiency out the window to attempt to find Waldo between the cracks of parentheses. It did not find him. Most of that work is done at compile-time to spare users its inefficiencies at runtime/startup. In their stead, the byte-compiler got to suffer it, and suffer it did til it could take no more. They say you can still hear it crying "bytecode overflow" on dreary, windy days.

Anyhow, I'll leave this thread open until that is done. I'll keep you posted.

[alphapapa]

@hlissner Looking forward to your progress! Emacs could really use a better way to define themes. Wow us with your Elisp-fu mastery. :)

[hrehfeld]

I'm still getting similar errors on installing via melpa on non-doom-emacs:

In toplevel form:
doom-plain-dark-theme.el:153:5:Error: Bytecode overflow

In toplevel form:
doom-plain-theme.el:153:5:Error: Bytecode overflow

In doom-themes--neotree-no-fringes:
doom-themes-ext-neotree.el:173:23:Warning: reference to free variable
    ‘neo-global--window’

In doom-themes--neotree-setup:
doom-themes-ext-neotree.el:179:53:Warning: assignment to free variable
    ‘hl-line-sticky-flag’

In doom-themes-neotree-insert-dir:
doom-themes-ext-neotree.el:288:19:Warning: reference to free variable
    ‘neo-vc-integration’
doom-themes-ext-neotree.el:311:28:Warning: reference to free variable
    ‘neotree-dir-button-keymap’

In doom-themes-neotree-insert-file:
doom-themes-ext-neotree.el:318:17:Warning: reference to free variable
    ‘neo-vc-integration’
doom-themes-ext-neotree.el:342:28:Warning: reference to free variable
    ‘neotree-file-button-keymap’
doom-themes-ext-neotree.el:355:9:Warning: assignment to free variable
    ‘neo-vc-integration’

In end of data:
doom-themes-ext-neotree.el:374:1:Warning: the following functions are not
    known to be defined: all-the-icons-dir-is-submodule,
    all-the-icons-octicon, all-the-icons-octicon-family,
    all-the-icons-icon-for-file, all-the-icons-fileicon,
    neo-path--file-short-name, neo-vc-for-node,
    neo-buffer--insert-fold-symbol, neo-buffer--node-list-set,
    neo-buffer--newline-and-begin, neo-global--select-window,
    neo-buffer--insert-file-entry, neo-buffer--insert-dir-entry,
    neo-buffer--insert-root-entry