June 2013 - Glasgow-haskell-users

Re-entrant TcRnIf
by p.k.f.holzenspies＠utwente.nl 13 Jun '13

13 Jun '13

Dear GHC-ers, The current API *seems* to assume that all different stages of the compiler pipeline are always passed successively (with the exception of the interleaving of the renamer and the type checker for the sake of Template Haskell), in other words, it is assumed all parsing has been done once we start renaming and that when we desugar the AST, we can through out all type checker state. I'm working on an interactive environment (different in many ways from ghci), in which I would like to incrementally parse a statement, rename it and type check it, after which I may chose to wash, rinse and repeat. This is somewhat problematic in the renamer (at least; this is how far I have come), at the very least with regards to the unique source and the provenance of things. What I'm hoping to do is to generalize the monads in the GHC API to some class, along these lines: class Generalizes m n where glift :: n a -> m a class (GhcMonad m, Generalizes m TcRnIf, Generalizes m CoreM, ...) => GHCAPI m What such a monad needs is to be able to evaluate some function in (for example) the renamer monad, extract the part of the renamer state that needs to persist and store that for whenever another renamer function is evaluated. One such thing would be the supply of unique names. I tried simply carrying over everything in the Env, except the env_top (HscEnv), but this broke things. Upon inspection of the TcGblEnv and TcLclEnv, this seems logical, considering they are dependent on the HscEnv (at least in terms of tcg_type_env_var, but there may be other dependencies I've not spotted). The thing that seems to bite me is the assumption that the top-level environment is assumed to be fixed [1]. In my scenario, this assumption does not hold. Concretely: 1) Do ways exist to carry over the part of the TcRnMonad state that is required to restart the renamer / type checker / etc later on? 2) If not, what parts of the Env, TcGblEnv and TcLclEnv should I copy over to the new state, assuming the HscEnv changed between consecutive runs? 3) Is there a particular reason why the front-end (of the front-end) is defined in an overloaded monad (GhcMonad) and the later bits all take concrete monads (TcRnIf etc.)? Regards, Philip [1] http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/TcRnMonad

2 2

Dona Eus�bia - Lista dos aprovados divulgada
by David Anderson 05 Jun '13

05 Jun '13

Dona Eusébia ANA CLARA DE MORAES HOLANDA, LORENNA DOS SANTOS SILVA, FRANCISCO JEFERSON GUERRA DA COSTA, PEDRO AMARANTE SILVA FILHO, JOÃO CARLOS MOREIRA DE CARVALHO, DANIEL AGUIAR DE SOUSA, MARIA ISABELA DE BRITO MORAIS, JARDEL SOUSA DA SILVA. SILVANA FERREIRA DE ARAÚJO, ARTHUR MAURICIO DE SOUZA RODRIGUES, LUCAS RAMOS DE LIMA, GLEYCIANNE M. DE CARVALHO, REBECCA ERONIDES NOJOSA ARRUDA. Caiapônia. Amontada AMANDA AZEVEDO DE CASTRO FROTA ARAGAO, LEONARDO ARAUJO DE SOUSA, FRANCISCA NAGIELE SILVA, PABLO RICHEL SOARES MENDES, JOÃO CARLOS MOREIRA DE CARVALHO, CLOVIS JOSE PINHEIRO PADILHA, MARIA DE LOURDES CORDEIRO, IZAEL DIAS DA SILVA. SANDRO NEVES DE SILVA, EMYLIA KAROLINE ARARUNA MACEDO, MAYALLE DE LIMA, JOSELÂNE DOS SANTOS FERREIRA, WANDERLEIYA CICERA SIQUEIRA. Cláudia. Antônio Prado de Minas ANA CLARA DE MORAES HOLANDA, LORENNA DOS SANTOS SILVA, FRANCISCO JEFERSON GUERRA DA COSTA, PEDRO AMARANTE SILVA FILHO, JOÃO CARLOS MOREIRA DE CARVALHO, DANIEL AGUIAR DE SOUSA, MARIA ISABELA DE BRITO MORAIS, JARDEL SOUSA DA SILVA. SILVANA FERREIRA DE ARAÚJO, ARTHUR MAURICIO DE SOUZA RODRIGUES, LUCAS RAMOS DE LIMA, GLEYCIANNE M. DE CARVALHO, REBECCA ERONIDES NOJOSA ARRUDA. Cláudia.

1 0

dialog box error during compile
by harry 02 Jun '13

02 Jun '13

(I posted the following to gmane.comp.lang.haskell.glasgow.bugs, but I think that might have been the wrong list.) I was recently having some trouble building a package through an IDE. When I tried it from the command line, GHC popped up the following dialogue box: ghc.exe - Entry Point Not Found The procedure entry point deflateSetHeader could not be located in the dynamic link library zlib1.dll. I fixed the error, but I hadn't seen it earlier because the IDE (EclpiseFP) only gave GHC a console, where the error wasn't written. Why wasn't it written to the error stream like any other error? Haskell Platform 2013.2 on Windows. The error occurred when building an application that uses gtk2hs.

1 0

Debugging GHCi
by Mateusz Kowalczyk 01 Jun '13

01 Jun '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, Nowadays I'm looking at Haddock and amongst other things, recent GHC is a must. Due to this, I now have 7.6.3 on my system as well as a build from yesterday (7.7.20130531), straight from git HEAD. Building Haddock with --enable-tests, I then try to run some hspec (or probably more appropriately, nanospec) tests. Simple stuff: > ghci src/Spec.hs > Prelude> :main Tests run as expected and everything is fine until about 2 seconds after main terminates: GHCi segfaults. As a means of checking whether this is a problem with GHCi, I ran the same commands with my 7.6.3 install and everything was fine - no segfault. This clearly points to something being wrong with GHCi. My question is, how would I even begin to investigate what's wrong? If I want to file a bug, I need to have more information, especially considering that someone I asked could not reproduce this. I have no experience with GHCis guts and I'm not sure how to progress. - -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRqnINAAoJEM1mucMq2pqXSbEQAIM9+czAgoyHJQ4LCI+eRMWP yM6pCxvQH5XLfSg6dD9UJASqsZ3kgaQcJsx77c1PCDXyU11hF5x3MygKOBKcqXoO fC/khWqp1ru17tOhJ9nfpCTFm6HUI9RGKRYBJhsrUkv1DzY6tw5kJuwFqf/9e9jF Om9wiqA1Sp0L1YEGnjcQ+ZB2/5gekPK4Il1iSWujrvo9JzGzJULXo94sxAXNa9P+ xuaSpTxKP1+6+zmuK1sSYgNNCP8b5yKXgwUjjI25s8MP6usXpvz5YRs760zMlpFl l9ZepNMiWgcL9dxWI3g8TFrm3jE5EVgIQ+/3ytEoRuetYU713Dj4DQSu5dZkxZku wdWuy/HVBOqpQf+fbMqlH4vW4Q4QIJbnU+qsRr6nNyoyEvGvuom4gXC18fHYqJST r03WD/UXlF4KTXD45flypeOnkRrcFiws76gdRqwiXpec0WxmYjEYGzbIARfQrU9V xWoykrTmVCbE8uG8FktXcjzirSAK5HAsy0sceurgPT8FDmSn9AFF03pOiW/A8Hli d8WrS5uuTWprzFFaUtpPbERWLOxieLNJrpXeeKKICVLF4VNzlrjw9regToYh2rTq tMaJgP61E8Vji2NhR1bk/TPPdOFtEB+cJnXDrn9Z6ICJlAmHXVCCQJA7KmsX5WGA NEqif1T5kIkHLc0FUmZl =nTqG -----END PGP SIGNATURE-----

1 0