Prolems with GHC/Desugar.jsmod

[RudolfVonKrugstein]

Hey,
When I try to compile a program in which I use arrow syntax, I get:

Compiling Main into .
Compiling JavaScript into .
Compiling Coroutine into .
Linking Pong.js
Linking Main.jsmod
Linking JavaScript.jsmod
Linking GHC/Tuple.jsmod
Linking Haste/Callback.jsmod
Linking Prelude.jsmod
Linking GHC/Base.jsmod
Linking GHC/IO.jsmod
Linking GHC/IO/Exception.jsmod
Linking Data/Typeable.jsmod
Linking Data/Maybe.jsmod
Linking GHC/Exception.jsmod
Linking GHC/Types.jsmod
Linking GHC/IO/Handle/Types.jsmod
Linking GHC/Show.jsmod
Linking GHC/IORef.jsmod
Linking Haste/DOM.jsmod
Linking GHC/STRef.jsmod
Linking Coroutine.jsmod
Linking GHC/Float.jsmod
Linking GHC/Err.jsmod
Linking GHC/Integer/Type.jsmod
Linking GHC/Real.jsmod
Linking GHC/Integer/Logarithms/Internals.jsmod
Linking GHC/Num.jsmod
Linking Control/Arrow.jsmod
Linking Control/Category.jsmod
Linking GHC/Desugar.jsmod
/home/ls/.haste/lib/GHC/Desugar.jsmod: openBinaryFile: does not exist (No such file or directory)

The file does indeed not exist.
I am node 100% sure, but I think the problem occurs when I use arrow syntax in my program.

[RudolfVonKrugstein]

Here is a small example source file:

{-# LANGUAGE Arrows #-}

module Main where

import Control.Arrow
import Haste
import Haste.Prim

type Document = JSAny

foreign import ccall "objWrite" write :: Document -> JSString -> IO ()
foreign import ccall "getDocument" getDocument :: IO Document

func :: Int -> Int
func = proc i -> do
  i' <- (+1) -< i
  returnA -< i'

main = do
  doc <- getDocument
  write doc . toJSStr . show . func $ 3

Compiler output:

Compiling Main into .
Linking Arrow.js
Linking Main.jsmod
Linking GHC/Base.jsmod
Linking GHC/IO.jsmod
Linking GHC/IO/Exception.jsmod
Linking Data/Typeable.jsmod
Linking Data/Maybe.jsmod
Linking GHC/Exception.jsmod
Linking GHC/Types.jsmod
Linking GHC/IO/Handle/Types.jsmod
Linking GHC/Show.jsmod
Linking Control/Arrow.jsmod
Linking Control/Category.jsmod
Linking GHC/Desugar.jsmod
/home/ls/.haste/lib/GHC/Desugar.jsmod: openBinaryFile: does not exist (No such file or directory)

[valderman]

This is indeed a bug, one caused by the way the base libraries are built. At present, buildlibs.sh handles that part manually and only the most common modules are included. I'm currently working on a way to integrate cabal with Haste and then just cabal install base and ditch buildlibs.sh, which will solve the problem nicely. I''ll also push an emergency fix for your issue on Sunday or Monday (I'm currently visiting relatives). If you want, you can (most likely) create an emergency fix for yourself by downloading the source for GHC 7.4.x, cd:ing to libraries/base and running hastec --libinstall -O2 Control.Arrows GHC.Desugar.

[RudolfVonKrugstein]

Thanks for the reply! When I do "hastec --libinstall -O2 Control.Arrow GHC.Desugar" I get:

GHC/Float.lhs:28:0:
     fatal error: ieee-flpt.h: No such file or directory
compilation terminated.

Mmh, can I prevent him from compiling? GHC/Float.lhs?
Otherwise, I will be patient :)

[RudolfVonKrugstein]

How do I in general install libraries? I am trying to use vector space, which fails with:

/home/ls/.haste/lib/Data/AdditiveGroup.jsmod: openBinaryFile: does not exist (No such file or directory)

So I am unpacking vector space, cd ing in its root and try:

hastec --libinstall -O2 Data.VectorSpace Data.AdditiveGroup.jsmod
target `Data.AdditiveGroup.jsmod' is not a module name or a source file

[valderman]

Apparently, GHC.Desugar isn't as friendly to stand-alone building as I imagined, it needs a bunch of special flags and a partial GHC build, it seems. I'm working on it.

As for installing modules in the general case, just drop the trailing .jsmod and use the module name, so your example would be hastec --libinstall -O2 Data.VectorSpace Data.AdditiveGroup. Also make sure that vanilla GHC can see those modules or you'll get compile errors.

[Ericson2314]

GHC/Float.lhs:28:0:
fatal error: ieee-flpt.h: No such file or directory
compilation terminated.

In case anybody else that stumble here is wondering, the problem causing that is that the implicit prelude import in Setup.hs causes GHC to also compile Prelude.hs, etc etc, as a dependency