- Glasgow-haskell-users

RE: FFI - closure, __stginit
by Simon Marlow 29 Jul '02

29 Jul '02

> I'm just trying the ffi - importing some Haskell function > into C. I've got a > module "HelloWorld" with an exported function "add". And I got this > "undefined reference" error while linking: > > undefined reference to `HelloWorld_zdfadd_closure' > > Can anybody please help me, what's wrong here? > > A second problem is the __stginit... function. I've defined > void __stginit_HelloWorld (void) {} > with an empty body. Is this o.k.? Or should I make ghc to > generate it for me > somehow? It sounds like you're not linking the Haskell module into the binary. The compiled Haskell code should provide both HelloWorld_zdfadd_closure and __stginit_HelloWorld. Cheers, Simon

1 0

FFI - closure, __stginit
by Ondrej Rypacek 29 Jul '02

29 Jul '02

Hi, I'm just trying the ffi - importing some Haskell function into C. I've got a module "HelloWorld" with an exported function "add". And I got this "undefined reference" error while linking: undefined reference to `HelloWorld_zdfadd_closure' Can anybody please help me, what's wrong here? A second problem is the __stginit... function. I've defined void __stginit_HelloWorld (void) {} with an empty body. Is this o.k.? Or should I make ghc to generate it for me somehow? Thanks a lot, Ondra

1 0

RE: suggestion regarding :browse
by Simon Peyton-Jones 29 Jul '02

29 Jul '02

| :browse Some.Long.Module.Name | | but not | | :browse N | | which would be really nice :P | | if this could make its way into 5.04.1, that would be wonderful It turns out that the impl isn't structured with a separate modulename->modulename mapping so it would not be simple to implement. For example, what if two modules whose top level scopes you have open use the same abbreviation for a different module. Yes, we could arrange to emit an ambiguous-ref message, but it's all work. So I'm not enthusiastic, I'm afraid. Simon

1 0

Module Set
by Christian Maeder 28 Jul '02

28 Jul '02

Hi, I think the module Set lacks at least a (partial) function minimum :: forall a. (Ord a) => Set a -> a because "setToList" is the only (though sufficient) function to access the elements of a list. Will "minimum = head . setToList" be correct or do I need to sort the list? I was considering using sorted lists directly, but I thought the functions `elem` and `union` are not as efficient as they could be (under the assumption that the input lists are sorted). Surely balanced trees will be better for large sets. Besides the minimum, also the maximum or the simultaneous splitting of a set into its minimum and the remaining set would be useful (for recursions). Cheers Christian

2 5

RE: Problems dealing with GHC incompatibilities
by Simon Marlow 26 Jul '02

26 Jul '02

> What version of GHC do you use at Microsoft? Do you have a > last-not-broken version > which you use for developing GHC or what? If there is a > last-not-broken version it would > be good to have access to it. We generally have 'ghc' pointing to the latest stable release (i.e. now it points to 5.04), and I usually install a snapshot whenever we make one. We don't develop day-to-day using snapshots, because switching over existing builds is a little annoying. > For quite a long time I ran an automated system which > compiled GHC every night from > CVS (using the previous version) and installed it on our > system if the compile completed. This > actually worked quite well, though I stopped doing it because > the compilation system got > more complicated, I had problems doing it on Sparc/Solaris, > and it was too much trouble. > If the compile finished it was unusual for the compiler > itself to be hopelessly broken; > to be on the safe side you could check it was able to compile > Happy and Haddock. Something > like this might be good. Of course it would have to be made > very clear that such snapshot > releases were for evaluation only, and that only the official > releases were to be relied on. Our nightly builds run a 3-stage bootstrap and then the whole test suite, so you usually have a pretty good idea by the end whether the compiler is a good 'un or not. You can checkout the scripts we use for the nightly builds from CVS: just 'cvs co nightly'. Setting up your own build using these scripts is fairly painless; Malcolm Wallace did it recently for Sparc to bolster our Sparc support a bit. Cheers, Simon

2 1

RE: Problems dealing with GHC incompatibilities
by Simon Marlow 26 Jul '02

26 Jul '02

> So my suggestion is that > (1) The GHC team continue to issue snapshot releases as often > as possible (I don't know why they > don't make the automatic builds generate them every night). We could, and in fact the nightly build system has support for publishing the resulting source & binary bundles. One consideration, though, is that someone pulling down a snapshot will want a clue as to whether that snapshot is likely to be not completely broken, and without reading cvs-ghc(a)haskell.org. So we tend to pick snapshots at moments when we know things are in a reasonably stable state. > By the way, Simon M, how long can we rely on the hslibs > library structure? Because some time > I shall have to schedule time to move over to the new > structure, and I'm not looking forward to > it. Perhaps they'll go away in 6.00... how do people feel about that? The 5.04 release will continue to be supported up until the release of 6.00, which is likely to be at least 6 months (probably longer). Cheers, Simon

2 1

Problems dealing with GHC incompatibilities 2
by George Russell 26 Jul '02

26 Jul '02

Simon M wrote [snip] > If you don't want things to change, don't upgrade! [snip] A typical Microsoft response, if I may say so. : -) Admittedly we don't have the problem that the penalty for not upgrading GHC is that you expose your computer to every Bugtraq-reader on the Internet. All the same, you have to upgrade now and again, or cut yourself off from all bug fixes, improvements, and so on. Putting off unpleasant upgrades just makes the bit rot ten times harder to deal with when you do deal with it.

1 0

Problems dealing with GHC incompatibilities
by George Russell 26 Jul '02

26 Jul '02

I used to have a lot of trouble with UniForM / HTk every time there was a new GHC release, because we use a LOT of GHC extensions. Sometimes a GHC release wouldn't work at all and I had to submit a shopping list of bugs to the GHC Team, in the hope that they would issue a version X+0.01 which we could use. However I'm glad to say I had virtually no trouble with the upgrade to GHC5.04. I think this is partly because I tried out ghc5.03 several times before ghc5.04 was released, partly from the snapshot releases, and partly from the CVS version. I made sure the UniForM code worked with ghc5.03. Where I had real trouble I was able to complain loudly to the GHC team, and get them to fix the problem, in time for ghc5.04. For example, I think I had two problems with ghc-pkg, which Simon M was kind enough to fix. So my suggestion is that (1) The GHC team continue to issue snapshot releases as often as possible (I don't know why they don't make the automatic builds generate them every night). (2) If you are responsible for a lot of Glasgow Haskell code, you make sure it works not only with the latest official GHC release, but also try to keep it in step with the snapshot releases. We use the -cpp option and combinations like #if (__GLASGOW_HASKELL__ >= 503) -- new stuff #else -- old stuff #endif By the way, Simon M, how long can we rely on the hslibs library structure? Because some time I shall have to schedule time to move over to the new structure, and I'm not looking forward to it.

1 0

RE: re-evaluating CAFs in ghc
by Simon Marlow 26 Jul '02

26 Jul '02

> Is there any way to trick ghc into causing CAFs to > be re-evaluated upon each reference to them? (specifically > without adding arguments to it so that it is no longer a CAF). > > I know this sounds like a dodgy hack ... Apart from hacking the compiler to remove the update frame from CAFs (which isn't difficult), no. In GHCi you can cause CAFs to be thrown away after each evaluation by saying ':set +r'. Cheers, Simon

1 0

re-evaluating CAFs in ghc
by Bernard James POPE 26 Jul '02

26 Jul '02

Hi all, Is there any way to trick ghc into causing CAFs to be re-evaluated upon each reference to them? (specifically without adding arguments to it so that it is no longer a CAF). I know this sounds like a dodgy hack ... Cheers, Bernie.

1 0