Re: unique identifiers as a separate library
a...@spamcop.net wrote:
G'day all.
Quoting Sebastian Fischer s...@informatik.uni-kiel.de:
I have wrapped up (a tiny subset of) GHC's uniques into the package
`uniqueid` and put it on Hackage:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uniqueid
First off, thanks for this.
The main difference is due to my fear of depending on the foreign
function `genSymZh` which I replaced by a global counting IORef.
Why not depend on this instead?
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/value-supply
Looking at the code for this, I'm somewhat suspicious that it actually
works with GHC:
-- The extra argument to ``gen'' is passed because without
-- it Hugs spots that the recursive calls are the same but does
-- not know that unsafePerformIO is unsafe.
where gen _ r = Node { supplyValue = unsafePerformIO (genSym r),
supplyLeft = gen False r,
supplyRight = gen True r }
even if that extra Bool argument is enough to fool Hugs, I wouldn't count
on it being enough to fool GHC -O2! You probably want to use
unsafeInterleaveIO like we do in GHC's UniqSupply library.
Also, I'd replace the MVar with an IORef and use atomicModifyIORef for speed.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unique identifiers as a separate library
Isaac Dupree wrote: Sebastian Fischer wrote: On Dec 17, 2008, at 10:54 AM, Sebastian Fischer wrote: Would it be possible to put everything concerned with unique identifiers in GHC into a separate package on Hackage? I have wrapped up (a tiny subset of) GHC's uniques into the package `uniqueid` and put it on Hackage: thanks! The main difference is due to my fear of depending on the foreign function `genSymZh` which I replaced by a global counting IORef. which is its own risk. maybe you should NOINLINE it? Potential code criticisms / suggestions for it as a library: Unboxed: so it only works on GHC, even though others have unsafe IO too. In theory, strictness annotations should be able to achieve the same efficiency. Char is supposed to represent a Unicode character -- but this code behaves oddly: For 64-bit Int#, it does so. For 32-bit Int#, it assumes Char is within the first 8 bits (ASCII and a little more). If Int# (or Int) can be 30-bit (like Haskell98 permission), its correctness suffers even worse. Is it really even a necessary part of the design? The only way you provide to extract it or depend on its value is indirectly via the Show instance. Its presence there is, in any case, at the cost of max. 2^24 (16 million) IDs before problems happen, whereas billions is still not a great limit but at least is somewhat larger. (applications that are long-running or deal with huge amounts of data could be affected) unsafeDupableInterleaveIO: this Dupable was safe for GHC to use because GHC is single-threaded. Is it safe in a library setting? It would be safe if the genSym was atomic - so I recommend using atomicModifyIORef. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
Uwe Hollerbach wrote: Hello Barney all, I've been following your messages with some interest, as I too have been trying to build a more-modern ghc on my G3 iMac running 10.3.9. I started with an existing 6.6.1 build, and tried to build 6.8.3; I'm finally at the point where I have something to report, although I'm not sure if it's a success or a failure report... :-/ I applied your patch to package.conf.in (approximately; the relevant section wasn't quite identical), edited rts/Linker.c to add #define LC_SEGMENT_64 LC_SEGMENT, and hacked up a wrapper script around ar to always ranlib the library being processed; you had mentioned patching cabal, but I decided the wrapper around ar was easier... a hack, but what the hell. After that, configure make ran to completion without errors (although it took a couple of days, since I had all the extralibs). Success! ... or is it? I installed the new compiler into /usr/local, then tested it by trying ghc -v. Alas, no joy! It died with some dynamic-link error which I've approximately reproduced here: lupus:~/ghc-6.8.3% ghc-6.8.3 -v dyld: relocation error (external relocation for symbol _pthread_mutex_unlock in ghc-6.8.3 relocation entry 0 displacement too large)Trace/BPT trap Failure! ... or is it? I'd guess that the size of the binary has caused some kind of overflow of a short relocation field. Any experts in MacOS linking around? You might want to try the testsuite with stage1 and see whether the failure shows up anywhere else. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
please test: cabal install now less eager to reinstall core packages
Claus, Simon, You'll recall the cabal-install problem you noticed recently where it decides it wants to re-install some core library like array or containers or whatever. I'd appreciate it if you could test the darcs version of cabal-install and see if it is behaving better now. It was choosing to re-install packages when the way it had chosen to configure the available version of the package (ie what exact dependencies it'd picked) did not exactly match those of the installed package. I've changed things so that it now picks the installed version when the additional constraints it adds (direct and indirect dependencies) do not conflict with the existing constraints. This means it'll pick the installed instance in many more cases and when it does not that there is a more legitimate reason. It still may have been possible to use the installed version if we had known that information much earlier and made different choices at an earlier stage. I've not yet added support for user supplied install constraints but I plan to shortly (eg --constraint='array installed'). Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
