Robbert Haarman


Posted by inglorion
at 2014-02-02 14:56:41

If you are getting the error message "ValueError: bad marshal data (unknown type code)" while trying to import a Python module, it may be that the compiled version of the module (the .pyc file) is corrupt. There is an easy way to fix that: just delete the .pyc file.

For example, on my Linaro 13.09 system, I got this error whenever I ran any of the package management commands (aptitude et al.):

Traceback (most recent call last):
  File "/usr/bin/py3compile", line 34, in <module>
    from debpython.version import SUPPORTED, debsorted, vrepr, \
  File "/usr/share/python3/debpython/", line 26, in <module>
    from configparser import ConfigParser
  File "<frozen importlib._bootstrap>", line 1564, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1531, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 586, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1023, in load_module
  File "<frozen importlib._bootstrap>", line 1004, in load_module
  File "<frozen importlib._bootstrap>", line 562, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 854, in _load_module
  File "<frozen importlib._bootstrap>", line 968, in get_code
ValueError: bad marshal data (unknown type code)

I was able to fix this by doing:

sudo rm /usr/lib/python3.3/__pycache__/configparser.cpython-33.pyc

  • View this thread (0 comments)
Posted by inglorion
at 2014-01-22 19:09:23

Good article by Walter Bright about what it takes to create your own programming language and getting it adopted: So You Want To Write Your Own Language?

  • View this thread (1 comments)
Posted by inglorion
at 2014-01-07 05:09:55

Some of you may have noticed that my website has been down for an extended amount of time (over a week). What happened is that, while I was on vacation, the solid-state drive attached to the machine serving the site broke. Not having access to the files on the SSD, the machine was unable to serve the website, and I only got around to fixing the problem after I returned home.

I replaced the broken SSD with a new one, got everything back up and running, and started a backup job. Unfortunately, while running that backup job, the new SSD broke. I'm now serving the site from a different machine while I wait for a new hard disk to attach to the original server. This machine may have slightly older versions of some files, so I will have to do some work to get things up to the latest state, but I will wait until I have the replacement disk.

  • View this thread (0 comments)
Posted by inglorion
at 2013-12-01 22:50:52

I just released version 1.1.3 of the Voodoo Compiler. This release comes with the following bug fixes and improvements:

* Compatibility with Ruby 1.8, 1.9 and 2.0, tested with MRI/YARV and Rubinius.

* Labels that start in underscores now work.

* Programs that use symbols and then try to export or import them are now rejected.

The last change deserves some explanation. Previously, the Voodoo language definition imposed no constraints on the ordering of symbol use, import, and export. However, imported and exported symbols are treated differently from locally defined symbols at least on some platforms. In some cases, using a symbol without first importing it, and then later importing the symbol, would result in a program that compiles and links, but crashes or produces wrong results when run on some platforms. To avoid this rather nasty situation, I've updated the language definition to clarify that symbols that are imported or exported must be imported or exported before they are first used, and updated the Voodoo compiler to reject programs that do not obey this constraint.

  • View this thread (0 comments)
Posted by inglorion
at 2013-10-21 05:30:42

I just released version 1.1.2 of the Voodoo Compiler. This release comes with the following bug fixes and improvements:

* Fixed the allocation of space for local variables. Previously, let incantations inside blocks inside if incantations were not considered, which caused incorrect behavior when such let incantations were used.

* Fixed the computation of offsets for local variables on ARM. A bug in the way these offsets were computed caused incorrect behavior due to local variables being stored in the same memory locations as other values.

* Fixed the parser so that numbers after line continuation escapes are parsed as numbers, not symbols.

* Made the handling of undeclared symbols more consistent. voodooc now rejects code that uses symbols that have not been defined or imported with an error message. Previously, the behavior depended on whether or not the assembler accepted the generated code.

* make gem now configures the Voodoo Compiler with default assembler names, rather than using the configuration of the host system.

  • View this thread (0 comments)

View previous 5 threads

View next 5 threads