Re: change location of user's package directory
Albert Y. C. Lai wrote On 13-07-25 03:14 PM, harry wrote: How can I change the location that ghc and ghc-pkg use for the user's package directory? I'm running GHC in a very restricted environment where I don't have access to $HOME, but I can use specific subdirectories. Cannot. But you have another option. GHC and cabal-install support further package databases than global and user. To initialize: mkdir /joy (or other ways to make /joy exist and be empty) ghc-pkg --package-db=/joy recache Note: two hyphens, -- not - To cabal-install: cabal --package-db=/joy --prefix=/delight install acme-dont Note: you must provide a custom --prefix. The default is $HOME/.cabal which is exactly what you can't use. To ghc-pkg: ghc-pkg --global --package-db=/joy list ghc-pkg --package-db=/joy unregister acme-dont However, beware of http://ghc.haskell.org/trac/ghc/ticket/5442 To ghc or ghci: ghc -package-db=/joy Note: one hyphen: - not -- (Don't you love to memorize random conventions.) (In older versions of GHC, it was even better: cabal --package-db=/joy ghc-pkg --package-conf=/joy ghc -package-conf=/joy Don't you love to memorize random conventions.) Read the full story in GHC User's Guide section 4.9 Packages. It comes with GHC on your hard disk. $ ghc-pkg check --package-db=~/cabal ghc-pkg: ~/cabal: openFile: does not exist (No such file or directory) $ ls ~/cabal package.cache -- View this message in context: http://haskell.1045720.n5.nabble.com/change-location-of-user-s-package-directory-tp5733451p5733512.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: change location of user's package directory
harry wrote $ ghc-pkg check --package-db=~/cabal ghc-pkg: ~/cabal: openFile: does not exist (No such file or directory) $ ls ~/cabal package.cache Ah, the ~ seems to have been tripping it up. Thank you. -- View this message in context: http://haskell.1045720.n5.nabble.com/change-location-of-user-s-package-directory-tp5733451p5733514.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
throwTo semantics
The documentation for throwTo says: throwTo does not return until the exception has been raised in the target thread. The calling thread can thus be certain that the target thread has received the exception. This is a useful property to know when dealing with race conditions: eg. if there are two threads that can kill each other, it is guaranteed that only one of the threads will get to kill the other. I don't see how the last sentense follows. I understood it so that the implication throwTo has returned = exception has been delivered is true, but not the reverse. If my understanding is correct, then both exceptions could be delivered without any of throwTos returning. Or is it true that throwTo has returned = exception has been delivered ? Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: change location of user's package directory
On Sun, Jul 28, 2013 at 5:35 AM, harry volderm...@hotmail.com wrote: $ ghc-pkg check --package-db=~/cabal ghc-pkg: ~/cabal: openFile: does not exist (No such file or directory) $ ls ~/cabal package.cache Yet another reason to avoid ~... it's (a) only expanded by the shell, and (b) not reliably expanded even by the shell if it's not the very start of a word (as here where it is after =). Use $HOME instead. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: throwTo semantics
Roman Cheplyaka wrote: The documentation for throwTo says: throwTo does not return until the exception has been raised in the target thread. The calling thread can thus be certain that the target thread has received the exception. This is a useful property to know when dealing with race conditions: eg. if there are two threads that can kill each other, it is guaranteed that only one of the threads will get to kill the other. I don't see how the last sentense follows. I agree that it does not follow logically, at least I don't see how. It is an additional guarantee that the implementation provides. I understood it so that the implication throwTo has returned = exception has been delivered is true, but not the reverse. If my understanding is correct, then both exceptions could be delivered without any of throwTos returning. Or is it true that throwTo has returned = exception has been delivered Yes, that's true, in the sense that if and only if the exception has been delivered, the thread is ready to run (i.e., not blocked), to continue right after the throwTo. The implication from left to right does not mean that the thread ever gets a chance to run again. The program may terminate, or the thread may receive another exception in the meantime. The latter can be prevented by masking exceptions. I hope that makes sense. Bertram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: cascading type errors in ghc
Giving good type error messages is tricky! You get different behaviour for literals because 0 has type (forall a. Num a = a), whereas you declared x1 to have type Int. GHC could have additionally said Can't find an instance for Num Bool, but it suppresses such errors if there are more serious ones at hand. Hence the difference you observed. Previous GHCs would often bale out altogether if they tried to unify Int with Bool, and recover at some outer point. That's good for not getting lots of errors, but it might suppress genuinely separate errors. Nowadays we gather all the unsolved constraints without an exception-style bale-out, which probably accounts for you seeing more errors. The good news is that error generation is all in one module TcErrors.lhs, so it's easy to adjust these things. For example, given a nearby bunch of errors, you could suppress all but one. I don't know whether that would on balance make things better or not. But it's certainly easy to experiment (if you build yourself a GHC). Simon | -Original Message- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] | On Behalf Of Evan Laforge | Sent: 27 July 2013 20:36 | To: GHC users | Subject: cascading type errors in ghc | | I frequently see one logical mistake turn into many type errors in | ghc. Of course in general one logical mistake to a human and a type | checker can be completely different things, so that's not surprising. | The thing is, I feel like I started seeing more with the upgrade to | ghc 7.6 (or was it 7.4?) a while back, which I guess coincides with a | big typechecker overhaul. So I tracked down a specific example, | though I haven't checked if this gives different results in older | ghcs: | | complicated :: Bool - Int - (Double - Double) | - Int - Char - Int - Char - () | complicated _ _ _ _ _ _ _ = () | | t0 = complicated 0 id x1 y1 x1 y1 | where | x1 :: Int | x1 = 0 | y1 :: Char | y1 = 'a' | | In this case, the call to complicated is missing the initial Bool. In | ghci the above gives 5 separate type errors, for the 2nd, 3rd, 4th, | 5th, and 6th arguments. The curious thing is, if I replace x1 and y1 | with their values: | | t0 = complicated 0 id 0 'a' 0 'a' | | I'm now down to only 3 type errors, for 2nd, 4th, and 6th args. | | So I'm just curious: what's the difference between the where-bound | stuff and literals? Also, why don't I get an error that 0 isn't a | Bool? Or I suppose, that there's no instance Integral Bool? | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: throwTo semantics
* Bertram Felgenhauer bertram.felgenha...@googlemail.com [2013-07-28 17:57:04+0200] Roman Cheplyaka wrote: The documentation for throwTo says: throwTo does not return until the exception has been raised in the target thread. The calling thread can thus be certain that the target thread has received the exception. This is a useful property to know when dealing with race conditions: eg. if there are two threads that can kill each other, it is guaranteed that only one of the threads will get to kill the other. I don't see how the last sentense follows. I agree that it does not follow logically, at least I don't see how. It is an additional guarantee that the implementation provides. I understood it so that the implication throwTo has returned = exception has been delivered is true, but not the reverse. If my understanding is correct, then both exceptions could be delivered without any of throwTos returning. Or is it true that throwTo has returned = exception has been delivered Yes, that's true, in the sense that if and only if the exception has been delivered, the thread is ready to run (i.e., not blocked), to continue right after the throwTo. The implication from left to right does not mean that the thread ever gets a chance to run again. The program may terminate, or the thread may receive another exception in the meantime. The latter can be prevented by masking exceptions. I hope that makes sense. Thanks Bertram, this makes perfect sense. I wonder if the docs should be updated to clarify this? Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Liberalising IncoherentInstances
Simon Peyton-Jones simonpj at microsoft.com writes:
I've realised that GHC's -XIncoherentInstances flag is,
I think, over-conservative.
Hi Simon, by coincidence I've just come across a very similar issue with
overlapping instances and FunDeps (following-up some discussion with Oleg,
MartinS, EdwardK).
Starting with:
class C a b | a - b where foo :: a - b
instance C [a] [a] where foo = id
t1 = foo a -- t1 :: [Char] - [Char]
I then added:
instance C [Char] [Char] where foo = id
-- more specific!
t2 = foo a -- t2 :: C [a] [a] = [a] - [a]
-- more polymorphic!
My (probably subjective) experience is that somewhere around 2006 when
Type Families started appearing, there were some subtle changes around
overlaps. TF's seemed to be very pre-occupied with supporting 'coincident'
(or confluent) _partial_ overlap.
(By partial overlap I mean: some substitutions match both instances, some
only one, some only t'other. This seems to be the root of the issue with
Joachim's post on ghc-devs.)
Partial overlaps are always going to be awkward for IncoherentInstances.
With Type Families, you can always check that the result is confluent. But
for class instances there's no such algebraic/semantic check possible.
It's easy to avoid partial overlaps: just define an instance for the mgu
of the overlap; then both of the less-specific instances totally overlap
it.
With the benefit of hindsight, I would have banned partial overlaps. IMO
we could then validate class instance 'eagerly' at point of declaration
(as Hugs does), rather than paying the penalty later with hazy/lazy
instance selection woes.
I strenuously try to avoid needing IncoherentInstances. I've no objection
to your proposed liberalise a bit.
Incidentally, I think it'd be an improvement to localise the
Overlapping/Incoherent flags to particular
instance declarations, via pragmas, something like
instance C [a] where
{-# ALLOW_OVERLAP #-}
op x =
Similarly {-# ALLOW_INCOHERENT #-}. Having -XOverlappingInstances for
the whole module is a bit crude.,
and might be missed when looking at an instance. How valuable would
this be?
+1
I strongly support localising these flags. Very seldom do I want
Overlapping for every class in a module, and I'd rather the compiler told
me if I inadvertently did overlap an instance.
Better still, can we do {-# DISALLOW_PARTIAL #-} ?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
