[GHC] #7334: How different services like clinking sites can execute seo successfully?
#7334: How different services like clinking sites can execute seo successfully? --+- Reporter: seoservice5 | Owner: Type: bug | Status: new Priority: normal| Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- [[Image(https://lh6.googleusercontent.com/-trPE6yw5VZM/T327tkWKtNI/FlU/PR3SkWqyiko/s550/s10.jpg)]] For to learn about clicking services, you need to know a lot of things relevant to seo. As we know search engine optimisation service provider needs to do a lot of things for to highlight their site in google rank. For that to do, one of the important thing they usually does is PPC or pay per click. Yes, all we know that '''[http://mpmarketingsolutions.com SEO service]''' indicates whole facilitates of sites, as they can get up in Look for or by any indicates of common search. It is almost like a one stop remedy middle and without this no one can make his or her website well-known these days. As we can see days are getting aggressive and therefore the business is, you can not prevent such solutions of a common SEO organization. A good SEO company always keep port for PPC promotion. for PPC or Pay Per Simply simply click Marketing is a one of the best methods to produce qualified visitors for an online item or a services based organization. [[Image(https://lh3.googleusercontent.com/-VjaxKXGSpLQ/UHlWimVHWXI/LQk/_Hl69-y4eLY/s380 /seo-services-india-bikaner.jpg)]] Now we will enter in more deep. PPC promotion or pay-per-click promotion is a amazing accountable technique of promotion and promotion followed by on the web promoters. PPC promotion may often be known as as pay for place, or pay for overall efficiency. Not easy to decide, so far I can say. But if the product is the same, you can use single domain. Go for a good company to take help. From a good '''[http://mpmarketingsolutions.com seo services]''' provider you can really a get a numbers of service like link building, back linking and many other things. Besides you can get services like PPC or pay per click, email marketing, web design, social media marketing and many other things. In case of increasing online exposures of the websites and brands and also to attract customers there are no such ways to avoid a expert professional holder seo company. I think, it will work for you. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7334 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7335: Need for extra warning pragma for accidental pattern matching in do blocks
#7335: Need for extra warning pragma for accidental pattern matching in do
blocks
--+-
Reporter: duncan| Owner:
Type: feature request | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
There are a few functions (actually monadic actions) where it's almost
always an error to pattern match on the result, e.g.:
{{{
(x,y) - rpar $ ...-- this is wrong!
(x,y) - unsafeInterleaveIO $ ... -- this is also wrong!
}}}
We can help users by warning when they do this. To do this sensibly we
would need a new warning pragma.
Here's a suggestion:
{{{
{-# WARN_DO_PATTERNMATCH unsafeInterleaveIO
You don't want to use pattern matching directly on the
result of unsafeInterleaveIO because that will immediately
force the IO to be done, defeating the intention of lazily
deferring it. #-}
unsafeInterleaveIO :: IO a - IO a
unsafeInterleaveIO = ...
{-# WARN_DO_PATTERNMATCH rpar You don't want to use pattern
matching directly on the result of rpar because that will
immediately wait for the result to be evaluated, defeating
the intention of doing it in parallel. #-}
par :: Strategy a
par = ...
}}}
The warning message should probably suggest using a ~ lazy irrefutable
match. Perhaps that bit of the message should be generated rather than
taken from the string in the pragma, since it can provide the actual
pattern the user used, with the extra ~.
As far as I can tell, this is only needed in a 'do' context, not a pure
'case' context.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7335
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7336: Defined but not used is not detected for data types with instances
#7336: Defined but not used is not detected for data types with instances
--+-
Reporter: maeder| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
{{{
module Unused () where
data U = U deriving Show
}}}
does _not_ report
{{{
Unused.hs:3:6: Warning:
Defined but not used: type constructor or class `U'
Unused.hs:3:10: Warning: Defined but not used: data constructor `U'
}}}
This message is only displayed without deriving.
I know, instances are always exported, but these instances cannot be used.
Considering that all types may get Typeable instances, no unused warning
would ever be issued for data types.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7336
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7076: Crash with eager blackholing
#7076: Crash with eager blackholing ---+ Reporter: SimonMeier| Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Runtime System|Version: 7.4.2 Resolution: fixed | Keywords: eager blackholing Os: Unknown/Multiple | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: #6146 ---+ Comment(by SimonMeier): Thanks. I will reopen it if I encounter trouble in the upcoming tests. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7076#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7216: Compositional blocking on file descriptors
#7216: Compositional blocking on file descriptors -+-- Reporter: AndreasVoellmy| Owner: Type: feature request | Status: patch Priority: normal| Milestone: 7.8.1 Component: libraries/base| Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * milestone: = 7.8.1 Comment: This patch warns that the return values of `registerFd` and `unregisterFd_` are ignored. Is that correct? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7240: Stack trace truncated too much with indirect recursion
#7240: Stack trace truncated too much with indirect recursion -+-- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal| Milestone: 7.8.1 Component: Profiling | Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * milestone: = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7240#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7256: Missing dataCast1 and dataCast2 methods in Data.Data instances
#7256: Missing dataCast1 and dataCast2 methods in Data.Data instances -+-- Reporter: dreixel | Owner: dreixel Type: bug | Status: patch Priority: normal| Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * milestone: = 7.8.1 Comment: Replying to [comment:3 dreixel]: Shall I go ahead and push the patch? Probably worth asking on libraries@, to give people the chance to object. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7256#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7287: Primops in RULES generate warnings
#7287: Primops in RULES generate warnings +--- Reporter: rl | Owner: simonpj Type: bug| Status: merge Priority: normal | Milestone: 7.6.2 Component: Compiler |Version: 7.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Difficulty: Unknown Testcase: simplCore/should_compile/T7287 | Blockedby: Blocking: |Related: +--- Changes (by igloo): * milestone: = 7.6.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7287#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7321: Compiler hangs when reading interface file
#7321: Compiler hangs when reading interface file -+-- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal| Milestone: 7.6.2 Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: gadt/T7321 Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * milestone: = 7.6.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7321#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7312: panic! applytTypeToArgs with non-infix function type constructor
#7312: panic! applytTypeToArgs with non-infix function type constructor +--- Reporter: jwlato | Owner: simonpj Type: bug | Status: merge Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time crash Difficulty: Unknown |Testcase: typecheck/should_compile/T7312 Blockedby: |Blocking: Related: | +--- Changes (by igloo): * milestone: = 7.6.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7312#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7297: LLVM incorrectly hoisting loads
#7297: LLVM incorrectly hoisting loads -+-- Reporter: dterei| Owner: dterei Type: bug | Status: new Priority: normal| Milestone: 7.8.1 Component: Compiler (LLVM) | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Incorrect result at runtime Difficulty: Unknown |Testcase: 367_letnoescape Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * difficulty: = Unknown * milestone: = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7297#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7140: Allow type signature in export list
#7140: Allow type signature in export list
-+--
Reporter: drb226| Owner:
Type: feature request | Status: new
Priority: normal| Milestone:
Component: Compiler (Type checker) | Version:
Keywords: module export type signature | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related: 2526 1404 |
-+--
Changes (by igloo):
* difficulty: = Unknown
Old description:
In response to the new InstanceSigs extension in the 7.6.1 RC1,
waterlight on Reddit suggested the following:
While we're at it, why not also allow type signatures in export lists?
People tend to add them anyway as comments, just because it's useful
documentation. Checking for consistency would be nice.
The desired syntax, therefore, is something like this:
{{{
{-# LANGUAGE ExportSigs #-}
module Foo
( foo :: Bar - Baz
, Blah ( Blip :: a - Blah a
, Bloop :: Blah Int )
, Quux ( quux :: Quux q = a - q a
, qux :: Quux q = q (q ()) )
) where
...
}}}
where all of the type annotations here are optional, and can be '''no
less restrictive''' than the corresponding type signatures provided at
the definition site, if provided (whether that be in that file's own
code, or imported from another file).
This would have non-trivial interaction with -fno-warn-missing-
signatures, and consequently, with
[http://hackage.haskell.org/trac/ghc/ticket/2526 ticket #2526].
There may also be non-trivial interaction with GADTs, if we allow
exported constructors to be annotated with a type signature.
This idea was vaguely referenced by
[http://hackage.haskell.org/trac/ghc/ticket/1404 ticket #1404], to which
igloo responded:
Type sigs in export lists might be nice, as some people seem to like
giving them as comments which then get out of sync with the actual
types.
If we are to consider this sort of thing for Haskell', we should try it
out as a GHC extension first.
New description:
In response to the new InstanceSigs extension in the 7.6.1 RC1, waterlight
on Reddit suggested the following:
While we're at it, why not also allow type signatures in export lists?
People tend to add them anyway as comments, just because it's useful
documentation. Checking for consistency would be nice.
The desired syntax, therefore, is something like this:
{{{
{-# LANGUAGE ExportSigs #-}
module Foo
( foo :: Bar - Baz
, Blah ( Blip :: a - Blah a
, Bloop :: Blah Int )
, Quux ( quux :: Quux q = a - q a
, qux :: Quux q = q (q ()) )
) where
...
}}}
where all of the type annotations here are optional, and can be '''no less
restrictive''' than the corresponding type signatures provided at the
definition site, if provided (whether that be in that file's own code, or
imported from another file).
This would have non-trivial interaction with -fno-warn-missing-signatures,
and consequently, with #2526.
There may also be non-trivial interaction with GADTs, if we allow exported
constructors to be annotated with a type signature.
This idea was vaguely referenced by #1404, to which igloo responded:
Type sigs in export lists might be nice, as some people seem to like
giving them as comments which then get out of sync with the actual types.
If we are to consider this sort of thing for Haskell', we should try it
out as a GHC extension first.
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7140#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7140: Allow type signature in export list
#7140: Allow type signature in export list -+-- Reporter: drb226| Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.8.1 Component: Compiler (Type checker) | Version: Keywords: module export type signature | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related: 2526 1404 | -+-- Changes (by igloo): * milestone: = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7140#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7102: Type family instance overlap accepted in ghci
#7102: Type family instance overlap accepted in ghci
--+-
Reporter: exbb2| Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: GHCi |Version: 7.4.1
Resolution: wontfix | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: GHC accepts invalid program | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Changes (by igloo):
* status: new = closed
* difficulty: = Unknown
* resolution: = wontfix
Comment:
I'm inclined to say that this is not a bug. In a similar way to how ghci
lets you shadow variables:
{{{
Prelude let f = 'a'
Prelude let f = True
Prelude f
True
}}}
it is letting you shadow type family instances:
{{{
Prelude :set -XTypeFamilies
Prelude type family F x :: *
Prelude type instance F Int = Bool
Prelude type instance F Int = Char
Prelude :t undefined :: F Int
undefined :: F Int :: Char
}}}
I think that this makes sense: If you imagine that `F` is defined in some
other package, and you are developing the type on the RHS, then if this
were not possible then you'd have to restart ghci each time you alter the
type.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7102#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles
#7161: hSetNewlineMode and hSetEncoding can be performed on closed and
semi-closed
handles
-+--
Reporter: duncan| Owner:
Type: bug | Status: new
Priority: normal| Milestone: 7.8.1
Component: libraries/base| Version: 7.6.1-rc1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by igloo):
* difficulty: = Unknown
* milestone: = 7.8.1
Comment:
Can you give us a way to reproduce the segfault please? I tried:
{{{
module Main (main) where
import System.IO
main :: IO ()
main = do h - openFile tmp WriteMode
hPutStrLn h Test
hClose h
hSetEncoding h utf8
hSetEncoding h utf32
hSetEncoding h utf8
print h
}}}
{{{
$ ghc --make q
$ ./q
{handle: tmp}
}}}
but got no segfault.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7161#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7259: Eta expansion of products in System FC
#7259: Eta expansion of products in System FC
-+--
Reporter: simonpj | Owner: simonpj
Type: bug | Status: new
Priority: normal| Milestone: 7.8.1
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by diatchki):
I updated `GHC.TypeLits` to avoid using `Any` as a constructor, so now we
should be able to convert it to a type function.
In a previous e-mail I mentioned some sketchiness that occurs when using
`Any` (in either form) with empty kinds. Here is an example to illustrate
the issue:
{{{
data {-kind-} Empty
data T (a :: Empty) = C deriving Show
main = print C -- what is the type of C here?
}}}
The issue is that in `main`: constructor `C` is of type `T Any`, with
`Any` of kind `Empty`. However, kind `Empty` has no members, so what does
`Any` refer to?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7259#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7189: RTS Assertion Crash
#7189: RTS Assertion Crash ---+ Reporter: sseverance | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.2 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by sseverance): The log file is 34MB. Do you want me to upload it somewhere where it can be downloaded for would the last 256K be fine? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7189#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7219: Reinstate constant propagation in some form
#7219: Reinstate constant propagation in some form --+- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler |Version: 7.7 Resolution: fixed| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: I believe this is now fixed. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7219#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7189: RTS Assertion Crash
#7189: RTS Assertion Crash ---+ Reporter: sseverance | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.2 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by simonmar): Please upload it somewhere (is that 34MB compressed?). e.g. Dropbox is fine. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7189#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7216: Compositional blocking on file descriptors
#7216: Compositional blocking on file descriptors -+-- Reporter: AndreasVoellmy| Owner: Type: feature request | Status: patch Priority: normal| Milestone: 7.8.1 Component: libraries/base| Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by AndreasVoellmy): `threadWaitSTM` basically follows the template `threadWait`. `threadWait` also ignores the result of applications of unregisterFd_, so on this point it is no different than the code that is already in that module. Regarding the result of `registerFd`: `threadWait` uses the result of `registerFd` in only one place: it creates an empty `MVar`, registers a callback that fills it and waits on the `MVar` handling any exceptions thrown to the thread (it unregisters the callback on exception); unregistering is the only place the result of `registerFd` is used. `threadWaitSTM` does not block on an `MVar` (or anything else, that is the point of it), so it cannot use the result of `registerFd` in the same way. To accomplish the same thing on an exception (i.e. unregistering the callback) we should probably return the registration key in the result of `threadWaitSTM` so that the user can handle and unregister. This would require also re-exporting the unregistration function in `GHC.Event.Thread`, since it is currently exported from the non-exposed `GHC.Event.Manager` module. On the other hand, I don't really see why unregistering is necessary for correctness. It seems to me like unregistering is an optimization, since it keeps the callback table smaller. If this occurs and the registered file is ever ready, then the callback will fire and be unregistered. If the registered file is never ready, then the file will never be removed from the callback table, but this could happen with a file anyway even when no error occurs. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7216#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7337: GHC does not generate great code for bit-level rotation
#7337: GHC does not generate great code for bit-level rotation
--+-
Reporter: bos | Owner:
Type: feature request | Status: new
Priority: normal| Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
I'm working on some hashing functions at the moment, and I notice that GHC
generates an {{{or}}} and a pair of shifts for a rotate. The LLVM back end
is smart enough to recover the code's intent via strength reduction and
emit a single {{{rot}}} instruction, but the regular code generator emits
three instructions.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7337
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7189: RTS Assertion Crash
#7189: RTS Assertion Crash ---+ Reporter: sseverance | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.2 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by sseverance): 1.5 MB Gzipped. Here is the link: https://dl.dropbox.com/u/85043508/clean_err.log.gz -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7189#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7259: Eta expansion of products in System FC
#7259: Eta expansion of products in System FC -+-- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal| Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * cc: Conor.McBride@…, sweirich@… (added) Comment: Re the sketchiness, is your worry the following? * Even though the type `Empty` has no data constructors, there are terms with type `Empty`, namely diverging ones, such as `undefined :: Empty`. * But are there any '''types''' with '''kind''' `Empty`? You might think no since we don't have divergent type terms. But there is one, namely `(Any Empty)`. So, is that a problem? Adding Conor to the cc list. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7259#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7323: decoding GADTs gives internal error: stg_ap_v_ret
#7323: decoding GADTs gives internal error: stg_ap_v_ret ---+ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler| Version: 7.7 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: yes Blockedby: |Blocking: Related: | ---+ Changes (by igloo): * difficulty: = Unknown * milestone: = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7323#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7162: RULES that never fire (automatically)
#7162: RULES that never fire (automatically) -+-- Reporter: andygill | Owner: Type: feature request | Status: patch Priority: normal| Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * milestone: = 7.8.1 Comment: Thanks for the patch. We'll take a look. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7162#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7158: GHCi commands case insensitive
#7158: GHCi commands case insensitive -+-- Reporter: Oblosys | Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * difficulty: = Unknown * component: Compiler = GHCi * milestone: = 7.8.1 Comment: Seems reasonable to me. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7158#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7148: generalized newtype and type families is unsound
#7148: generalized newtype and type families is unsound +--- Reporter: carter | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.1-rc1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | +--- Changes (by igloo): * owner: = simonpj * component: Compiler = Compiler (Type checker) * milestone: = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7148#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7314: GHCi 64-bit OS X segfaults on interaction with C-libraries
#7314: GHCi 64-bit OS X segfaults on interaction with C-libraries
+---
Reporter: darchon | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.4.1 | Keywords: GHCi external library 64-bit
Os: MacOS X | Architecture: x86_64 (amd64)
Failure: GHCi crash | Testcase:
Blockedby: | Blocking:
Related: |
+---
Comment(by george.colpitts):
email thread mentions
{{{
My only problem is that I don't have OS X 10.8 installed on my machine.
I'm running OS X 10.6, and am not inclined to upgrade.
So providing feedback on the questions related to the bug report will be
hard and/or take some time.
}}}
I'm on 10.8 so I can answer any questions about the bug there. I think
this is an important bug to fix as I have also seen it wrt Yale Euterpea
project. A lot of courses teaching Haskell like to use graphics or audio
for their examples, problems etc. so I think this is an important bug to
fix.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7314#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7162: RULES that never fire (automatically)
#7162: RULES that never fire (automatically) -+-- Reporter: andygill | Owner: Type: feature request | Status: patch Priority: normal| Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by afarmer): I think Andy had originally hoped that this would make it into 7.6.2. Is that still possible? It's a very small change. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7162#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7162: RULES that never fire (automatically)
#7162: RULES that never fire (automatically) -+-- Reporter: andygill | Owner: Type: feature request | Status: patch Priority: normal| Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by igloo): We have a policy of not making interface changes in stable branches, sorry -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7162#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7314: GHCi 64-bit OS X segfaults on interaction with C-libraries
#7314: GHCi 64-bit OS X segfaults on interaction with C-libraries +--- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.1 | Keywords: GHCi external library 64-bit gloss Os: MacOS X | Architecture: x86_64 (amd64) Failure: GHCi crash | Testcase: Blockedby: | Blocking: Related: | +--- Changes (by george.colpitts): * keywords: GHCi external library 64-bit = GHCi external library 64-bit gloss -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7314#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7338: Duplicate type signature not reported
#7338: Duplicate type signature not reported
-+--
Reporter: evincarofautumn | Owner:
Type: bug | Status:
new
Priority: normal | Component:
Compiler
Version: 7.4.1| Keywords:
Os: MacOS X | Architecture:
x86
Failure: GHC accepts invalid program | Testcase:
Blockedby: | Blocking:
Related: http://hackage.haskell.org/trac/ghc/ticket/5589 |
-+--
Under 7.4.1, the following snippet compiles without error:
{{{
a, a :: Int
a = 0
}}}
It should issue the usual “duplicate type signature” diagnostic.
[http://hackage.haskell.org/trac/ghc/changeset/82cd019e0ccf9c097e54b80cc94401863ee98ecd
82cd019e] is probably relevant here.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7338
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7339: GHC fails to build from source on Alpha
#7339: GHC fails to build from source on Alpha -+-- Reporter: creemj | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1| Keywords: Os: Linux| Architecture: alpha Failure: Building GHC failed | Testcase: Blockedby: | Blocking: Related: | -+-- The ghc compiler (version 7.6.1-2 as packaged by Debian in the experimental distribution) fails to build from source on the Alpha architecture. The build failure is: echo 'bindir=/«PKGBUILDDIR»/inplace/bin' inplace/bin/ghc- stage2 echo 'topdir=/«PKGBUILDDIR»/inplace/lib' inplace/bin/ghc-stage2 echo 'pgmgcc=/usr/bin/gcc' inplace/bin/ghc-stage2 cat ghc/ghc.wrapperinplace/bin/ghc-stage2 chmod +x inplace/bin/ghc-stage2 HC [stage 2] utils/haddock/dist/build/Haddock/GhcUtils.o utils/haddock/src/Haddock/GhcUtils.hs:1:35: lexical error at character '\n' make[2]: *** [utils/haddock/dist/build/Haddock/GhcUtils.o] Error 1 The full build log is at: http://buildd.debian- ports.org/status/fetch.php?pkg=ghcarch=alphaver=7.6.1-2stamp=1349784016 The GHC compiler was bootstrapped with the 7.4.1 compiler. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7339 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7339: GHC fails to build from source on Alpha
#7339: GHC fails to build from source on Alpha -+-- Reporter: creemj | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1| Keywords: Os: Linux| Architecture: alpha Failure: Building GHC failed | Testcase: Blockedby: | Blocking: Related: | -+-- Changes (by creemj): * cc: mcree@… (added) Comment: Looking back at the old build logs for building ghc on Alpha I see that 7.4.1 successfully builds but 7.4.2 fails to build with the same reason as 7.6.2. Likely then to be some change between 7.4.1 and 7.4.2 that has caused this. I think I'll run a check that 7.4.1 still builds to verify that conclusion. FYI, the old build logs of GHC for the unofficial Debian Alpha port can be found at: http://buildd.debian-ports.org/status/logs.php?pkg=ghcarch=alpha -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7339#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
