Runtime bug in compiled program.

[HeinrichApfelmus]

I am able to compile reactive-banana by telling haste to compile all dependency source files at the same time.

However, the resulting program doesn't work and throws the JavaScript error

Uncaught TypeError: Cannot read property '1' of null 

Unfortunately, I have not been able to distill a minimal example. Reactive-banana uses several techniques that are not referentially transparent, like observable sharing and unsafePerformIO, so there might be some problems there, but I really can't tell. Also, I am using value recursion, but it appears that the instance MonadFix IO instance works fine haste, so that should be ok, but I don't understand the interactions.

I have checked that the code used for the haste version of reactive-banana compiles and works under GHC. In particular, my custom implementation of Data.HashMap is correct as far as I can tell.

To try out the full code, check out the repository

https://github.com/HeinrichApfelmus/reactive-banana/tree/0d933257f615271930395a8a8041d3063676f70b

and download the latest version of vault

https://github.com/HeinrichApfelmus/vault/tree/b944d14393f9bba67f3fdba7c29b9c72e2610f8e

into the parent directory, which should now contain two folders reactive-banana and vault. Then, do

 cd reactive-banana/haste
 make single

to compile the example program. The result can be viewed in the corresponding html file.

[HeinrichApfelmus]

I should provide the compilation output, at least.

https://raw.github.com/gist/3918731/00fb7d680478323131c0c8a457f908a5754043fe/CurrencyConverter.js

As you can see, the bug is somewhere in that second to last line...

[valderman]

I have three theories:

1. Interesting mismatch between libs for Haste and GHC. As Haste still shares base with vanilla GHC, there may be an interface mismatch between the libraries you're using with Haste and the ones installed for GHC. This is very unlikely if you compiled base yourself instead of using the precompiled libraries though.
2. Bug in MVar implementation. reactive-banana uses those, right? Should be easy to rule out since the implementation is extremely simple.
3. Bug in tail recursion optimization. This is the most likely one. Going to add a compiler flag to disable it entirely to make debugging easier.

Thanks for providing a test environment, that's going to make it way easier to track this issue down.

[HeinrichApfelmus]

1. I'm using GHC 7.4.1 while you're using GHC 7.4.2, so this may be a possibility. I can try to compile the base libraries, but how do I tell GHC to build in 32 bit mode?
2. Yep, reactive-banana uses MVars, but last I checked, your implementation seemed fine to me.
3. You tell me. :-)

Let me know if the test environment doesn't work for you, I can try to make it more pleasant. In particular, the Makefile should be able to clone the vault library automatically, but git seemed to get confused about cloning a project inside another project.

[valderman]

Unfortunately, it's not possible to get 64-bit GHC to build anything in 32-bit mode, as it assumes that the build and target architectures are the same. You can build the libraries in 64-bit mode; Integer and Int64 operations won't work, but most other functionality should be intact, at least enough to check whether the problem persists with matching libraries or not.

[valderman]

This is extremely likely to be another variant of #172 and #123, which has been fixed in head for a while. Reopen if this proves not to be the case.