Errors while tangling file

[markgdawson]

When tangling the file with org mode and python 3.9.0 or 2.7.18 the table-layout-taphold block fails with:

Traceback (most recent call last):
  File "<stdin>", line 34, in <module>
  File "<stdin>", line 9, in main
TypeError: unhashable type: 'list'

Which results in a manna-harbour_miryoku.c file like:

#if defined MIRYOKU_ALPHAS_QWERTY
,
#elif defined MIRYOKU_ALPHAS_DVORAK
,
#elif defined MIRYOKU_ALPHAS_COLEMAK
,
#elif defined MIRYOKU_ALPHAS_COLEMAKDH
,
#elif defined MIRYOKU_ALPHAS_WORKMAN
,
#else
,
#endif
,
,

[markgdawson]

I'm not seeing this error today and I'm not sure why.

I expect there might have been an issue with my Emacs setup or my python installation.

I'll post here if I find any more information. In the meantime, I'm closing since this is now resolved for me.

[manna-harbour]

Let me know if it reappears. It's assuming python2 at the moment, but will be updated to work with both, or maybe require python3, at some point.

[markgdawson]

It seemed to be dict.fromkeys that was causing the error I was seeing. But if I removed that, there was an error happening in the map call further down.

But I'll keep an eye for it and see if it and let you know if I reproduce it.

[markgdawson]

Sorry for the ping pong on this issue, but I'm reopening with some more detail.

I'm seeing the error again. I've done this in a fresh version of GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0).

I've started emacs with emacs -q, and evaluated only the following lisp code:

(org-babel-do-load-languages
  'org-babel-load-languages
  '((emacs-lisp . nil)
    (python . t)
    (C . t)
    (makefile . t)))

(setq org-babel-python-command "python2")

(setq python-shell-interpreter "python2")

(setq org-confirm-babel-evaluate nil)

If I run M-& python2 --version I get 2.7.18. I get the same with M-x run-python.

Running M-x org-babel-tangle in the users/manna-harbour_miryoku/miryoku.org file buffer then gives the following in the *Org-Babel Error-Output* buffer:

Traceback (most recent call last):
  File "<stdin>", line 14, in <module>
  File "<stdin>", line 5, in main
TypeError: unhashable type: 'list'
Traceback (most recent call last):
  File "<stdin>", line 34, in <module>
  File "<stdin>", line 9, in main
TypeError: unhashable type: 'list'
Traceback (most recent call last):
  File "<stdin>", line 34, in <module>
  File "<stdin>", line 9, in main
TypeError: unhashable type: 'list'
Traceback (most recent call last):
  File "<stdin>", line 34, in <module>
  File "<stdin>", line 9, in main
TypeError: unhashable type: 'list'
Traceback (most recent call last):
  File "<stdin>", line 34, in <module>
  File "<stdin>", line 9, in main
TypeError: unhashable type: 'list'
Traceback (most recent call last):
  File "<stdin>", line 34, in <module>
  File "<stdin>", line 9, in main
TypeError: unhashable type: 'list'
Traceback (most recent call last):
  File "<stdin>", line 34, in <module>
  File "<stdin>", line 9, in main
TypeError: unhashable type: 'list'
Traceback (most recent call last):
  File "<stdin>", line 46, in <module>
  File "<stdin>", line 10, in main
TypeError: unhashable type: 'list'
Traceback (most recent call last):
  File "<stdin>", line 46, in <module>
  File "<stdin>", line 10, in main
TypeError: unhashable type: 'list'
Traceback (most recent call last):
  File "<stdin>", line 46, in <module>
  File "<stdin>", line 10, in main
TypeError: unhashable type: 'list'
Traceback (most recent call last):
  File "<stdin>", line 46, in <module>
  File "<stdin>", line 10, in main
TypeError: unhashable type: 'list'
Traceback (most recent call last):
  File "<stdin>", line 46, in <module>
  File "<stdin>", line 10, in main
TypeError: unhashable type: 'list'
Traceback (most recent call last):
  File "<stdin>", line 46, in <module>
  File "<stdin>", line 10, in main
TypeError: unhashable type: 'list'

[manna-harbour]

Thanks very much for the excellent report. I'll look into it soon.

[markgdawson]

On further investigation, it seems that the root of the issue is that my (newer?) version of org mode passes the mods_list variable as a table (a python list of lists) rather than a single list.

I believe that this is already fixed previously by @manna-harbour for new versions of org-mode in commit be1e9dd10 (in the branch origin/miryoku-layerlock-test). But the fix has not been applied in master.

Applying this fix causes the issue to go away. I've tested this in my case by applying the changes in be1e9dd10 to master and testing the changes after flashing onto a keyboard. This seems to work now.

I expect the fix in this form however would break support with older version of org mode. Maybe a conditional branch based on the shape of mods_list would allow support for both?

Something like (untested) might work:

# Make format consistent between versions of org-mode.
if(type([0]) == list):
  mods_list = mods_list[0]

mods_dict = dict.fromkeys(mods_list)

[obar]

I don't know the timeline of this issue and the changes in the miryoku branch, but the first python block table-layout-taphold does use mods_table and I get the following error when executing it:

Traceback (most recent call last):
  File "<stdin>", line 37, in <module>
  File "<stdin>", line 17, in main
TypeError: 'NoneType' object is not callable

I'm running Org 9.4 and Python 3.8.5:

#+begin_src python
    import sys
    return sys.version
#+end_src

#+RESULTS:
: 3.8.5 (default, Jan 27 2021, 15:41:15) 
: [GCC 9.3.0]

[obar]

Solved this issue here, will get a pull request ready. I also needed the patch from manna-harbour/qmk_firmware#12 to make it work.

[manna-harbour]

On further investigation, it seems that the root of the issue is that my (newer?) version of org mode passes the mods_list variable as a table (a python list of lists) rather than a single list.

I believe that this is already fixed previously by @manna-harbour for new versions of org-mode in commit be1e9dd (in the branch origin/miryoku-layerlock-test). But the fix has not been applied in master.

Applying this fix causes the issue to go away. I've tested this in my case by applying the changes in be1e9dd to master and testing the changes after flashing onto a keyboard. This seems to work now.

It seems you're using the old version in qmk master (https://github.com/qmk/qmk_firmware/blob/master/users/manna-harbour_miryoku/miryoku.org) rather than the main miryoku branch (https://github.com/manna-harbour/qmk_firmware/blob/miryoku/users/manna-harbour_miryoku/miryoku.org). That change was added to the main miryoku branch in manna-harbour/qmk_firmware@a718e73 but isn't in qmk master yet. In general, please use the main miryoku branch rather than the old version in qmk master.

Please let me know if there is still an issue when using the main miryoku branch.

I expect the fix in this form however would break support with older version of org mode. Maybe a conditional branch based on the shape of mods_list would allow support for both?

Something like (untested) might work:

# Make format consistent between versions of org-mode.
if(type([0]) == list):
  mods_list = mods_list[0]

mods_dict = dict.fromkeys(mods_list)

That's a nice idea, but the org version it was originally written in is very old, so it's probably not necessary now.

[obar]

The switch to zip in the python code (see manna-harbour/qmk_firmware#10) allows for the use of a newer Python version, which otherwise adds many commas as per the first post in this bug.

[manna-harbour]

@markgdawson With manna-harbour/qmk_firmware#10 merged it should work with python2 and python3. If you're still having issues please reopen and confirm your emacs / org / python versions and the current HEAD commit id. Thanks!