Re: [GHC] #1314: System.FilePath is documented but missing

[GHC]

#1314: System.FilePath is documented but missing
-+--
Reporter:  guest |Owner: 
Type:  bug   |   Status:  closed 
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.6.1  
Severity:  normal|   Resolution:  invalid
Keywords:|   Difficulty:  Unknown
  Os:  Unknown   | Testcase: 
Architecture:  Unknown   |  
-+--
Changes (by guest):

  * resolution:  => invalid
  * status:  new => closed

Comment:

 Whoops, sorry. I was looking at the online doc at haskell.org. The doc
 that ships with ghc tells the truth.

-- 
Ticket URL: 
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] #1314: System.FilePath is documented but missing

[GHC]

#1314: System.FilePath is documented but missing
---+
  Reporter:  guest |  Owner: 
  Type:  bug   | Status:  new
  Priority:  normal|  Milestone: 
 Component:  Compiler  |Version:  6.6.1  
  Severity:  normal|   Keywords: 
Difficulty:  Unknown   | Os:  Unknown
  Testcase:|   Architecture:  Unknown
---+
It seems like it's been defunct for years, no? Is there a replacement, and
 could the documentation be updated?

 For us newbies it's incredibly frustrating to have the doc out of date
 like this.

-- 
Ticket URL: 
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 6.6 panic from Data.Binary.Builder? reproducible on linux and mac os/x

[S. Alexander Jacobson]

Thinking about it further, I like the convention that the target of runhaskell 
MUST be Main.main.  It simplifies a lot of assumptions about intent.  It means 
that if I put a module named Main in HAppS/HTTP/FileServer, searchpath doesn't 
have to do anything special to figure out what it should do.


   sp runhaskell --sp HAppS.HTTP.FileServer --http-port=7000

Will download everything required at start serving files out of the current 
directory on port 7000 no fuss and no muss.  I withdraw the complaint and the 
bug report.


Note: In the next version of searchpath I hope to get rid of the --sp and have 
it just know that if it doesn't see the module on the path, it should download 
it.


-Alex-

On Mon, 30 Apr 2007, Simon Marlow wrote:


S. Alexander Jacobson wrote:
I've since modified sp to add a main-is which prevents the panic and 
replaces it with a complaint about Main e.g.


  runghc -i.haskell_cache/http_searchpath.org-default.map.cache -main-is 
HAppS.Protocols.HTTP.FileServer.main 
.haskell_cache/http_searchpath.org-default.map.cache/HAppS/Protocols/HTTP/FileServer.hs 
--http-port=7000


  :1:211:
Failed to load interface for `Main':
  Use -v to see a list of the files searched for.


runghc expects to run Main.main, I'm afraid it doesn't pay any attention to 
the -main-is flag (this flag is just passed along to GHC).  We do have a 
:main command that runghc really ought to use, but unfortunately it's not 
quite that simple.  I'll create a ticket, thanks for the bug report.


Instead of runghc, as a workaround you could use ghc -e directly.

Cheers,
Simon



___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1312: runghc doesn't respect -main-is

[GHC]

#1312: runghc doesn't respect -main-is
-+--
Reporter:  simonmar  |Owner: 
Type:  bug   |   Status:  new
Priority:  normal|Milestone:  6.8
   Component:  Compiler  |  Version:  6.6.1  
Severity:  minor |   Resolution: 
Keywords:|   Difficulty:  Easy (1 hr)
  Os:  Unknown   | Testcase: 
Architecture:  Multiple  |  
-+--
Comment (by Isaac Dupree):

 I've seen things like
 {{{
 ghc -e 'let
foo = bar
 in
   do
baz foo
putStrLn "ha ha"
 ' | some other shell command
 }}}
 ... how about allowing multiple `-e expr` arguments, which are done in
 sequence? At present it appears that GHC just evaluates the last one of
 those when given multiple (e.g. try `ghc -e 'putStrLn "1"' -e 'putStrLn
 "2"'`), which doesn't make much sense.

-- 
Ticket URL: 
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] #1313: HEAD gives warnings about code that it generates itself

[GHC]

#1313: HEAD gives warnings about code that it generates itself
--+-
  Reporter:  igloo|  Owner:  simonpj
  Type:  bug  | Status:  new
  Priority:  normal   |  Milestone:  6.8
 Component:  Compiler (Type checker)  |Version:  6.7
  Severity:  normal   |   Keywords: 
Difficulty:  Unknown  | Os:  Unknown
  Testcase:   |   Architecture:  Unknown
--+-
The HEAD is now giving warnings about code that it generates itself, e.g.
 {{{
 module Q where

 data Foo = Bar Int
 }}}
 gives
 {{{
 $ ghc -fforce-recomp -Wall -fgenerics -c q.hs

 q.hs:4:5:
 Warning: Definition but no type signature for `Q.$gtoFoo'
  Inferred type: Q.$gtoFoo :: Int -> Foo

 q.hs:4:5:
 Warning: Definition but no type signature for `Q.$gfromFoo'
  Inferred type: Q.$gfromFoo :: Foo -> Int
 }}}
 I assume that this is since the change which added the inferred type to
 the
 warning, but I haven't confirmed that.

-- 
Ticket URL: 
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] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request

[GHC]

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature
request
-+--
Reporter:  Isaac Dupree  |Owner: 
Type:  bug   |   Status:  new
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.6.1  
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
  Os:  Unknown   | Testcase: 
Architecture:  Unknown   |  
-+--
Comment (by Isaac Dupree):

 I'm not seeing a way it would actually be useful for GADTs either, since
 you can't do anything with a general value of kind '#'.

 It would be nice to be able to do enumerations more cleanly than that
 numerical way, but... As far as I have been able to figure out, the
 advantage of using unboxed values is that the compiler enforces that you
 can't use them in a non-strict way, potentially making code more efficient
 (versus the compiler guessing what places to unbox data implicitly) (and
 having less strictness annotations in the source code, even where it is
 effectively strict [function arguments, data members, let-bound
 variables], which has its pros and cons).  The trouble with enumeration
 types is that they are boxed normally: a function can take a Bool thunk
 that, iff the function decides to evaluate it, will raise an exception.

 Being able to newtype for FastInt makes sense, though, for the same
 abstraction reason of all newtypes - of course with the odd property of it
 being unlifted and not type-equal to any of the standard unlifted types.

 (what if we could declare {{{data ( FastBool :: # ) = FastTrue |
 FastFalse}}}, or even allow different data sizes and it takes up an amount
 of space equal to any necessary tag plus the maximum member: {{{data (
 FastEither a b :: # ) = FastLeft a | FastRight !b {-members may or may not
 be strict-} }}}, {{{data ( FastTuple a b :: # ) = FastTuple a b {- would
 this be equivalent to (# #) ? -} }}} ? Probably at least some of that is a
 foolish idea... Let's performance-test GHC with/without using those
 unboxed, maybe)

-- 
Ticket URL: 
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] #1292: -Wall doesn't include all warnings

[GHC]

#1292: -Wall doesn't include all warnings
-+--
Reporter:  guest |Owner:  
Type:  bug   |   Status:  reopened
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  6.7 
Severity:  normal|   Resolution:  
Keywords:|   Difficulty:  Unknown 
  Os:  Unknown   | Testcase:  
Architecture:  Unknown   |  
-+--
Comment (by igloo):

 gcc, from which I assume we get the name `-Wall`, says in its info page:
 {{{
 The following `-W...' options are not implied by `-Wall'.  Some of
 them warn about constructions that users generally do not consider
 questionable, but which occasionally you might wish to check for;
 others warn about constructions that are necessary or hard to avoid in
 some cases, and there is no simple way to modify the code to suppress
 the warning.
 }}}
 While it is poorly named, I think that the above list plus `-fwarn-
 monomorphism-restriction` fall into the same category.

-- 
Ticket URL: 
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] #1312: runghc doesn't respect -main-is

[GHC]

#1312: runghc doesn't respect -main-is
--+-
  Reporter:  simonmar |  Owner:  
  Type:  bug  | Status:  new 
  Priority:  normal   |  Milestone:  6.8 
 Component:  Compiler |Version:  6.6.1   
  Severity:  minor|   Keywords:  
Difficulty:  Easy (1 hr)  | Os:  Unknown 
  Testcase:   |   Architecture:  Multiple
--+-
runghc always invokes `Main.main`, it doesn't pay any attention to a
 `-main-is` flag if there is one.  The right way to fix this is for
 `runghc` to invoke GHCi's `:main` command, but unfortunately then we'd
 need to pass multiple commands to `ghc -e`, because we also need to `:set
 prog`, for example.  So probably `ghc -e` should split the input
 expression into lines and execute each line as a separate
 statement/command.

-- 
Ticket URL: 
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 6.6 panic from Data.Binary.Builder? reproducible on linux and mac os/x

[Simon Marlow]

S. Alexander Jacobson wrote:
I've since modified sp to add a main-is which prevents the panic and 
replaces it with a complaint about Main e.g.


  runghc -i.haskell_cache/http_searchpath.org-default.map.cache -main-is 
HAppS.Protocols.HTTP.FileServer.main 
.haskell_cache/http_searchpath.org-default.map.cache/HAppS/Protocols/HTTP/FileServer.hs 
--http-port=7000


  :1:211:
Failed to load interface for `Main':
  Use -v to see a list of the files searched for.


runghc expects to run Main.main, I'm afraid it doesn't pay any attention to the 
-main-is flag (this flag is just passed along to GHC).  We do have a :main 
command that runghc really ought to use, but unfortunately it's not quite that 
simple.  I'll create a ticket, thanks for the bug report.


Instead of runghc, as a workaround you could use ghc -e directly.

Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: GHC 6.6 panic from Data.Binary.Builder? reproducible on linux and mac os/x

[Simon Marlow]

S. Alexander Jacobson wrote:

How to reproduce:

$ curl http://searchpath.org/searchpath/SearchPath.hs > SearchPath.hs
$ ghc --make SearchPath.hs -o sp
$ ./sp -f runghc --sp HAppS.Protocols.HTTP.FileServer --http-port=7000

searchpath will download all the needed modules and calls out to shell 
to run this:
  runghc -i.haskell_cache/http_searchpath.org-default.map.cache 
.haskell_cache/http_searchpath.org-default.map.cache/HAppS/Protocols/HTTP/FileServer.hs 
--http-port=7000


which produces the following error:

  ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for i386-apple-darwin):
  ByteCodeFFI.mkMarshalCode_wrk(x86) L_

  Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


This particular panic was fixed in 6.6.1.  It was a missing case in the handling 
of foreign imports by the byte-code compiler.


Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1307: Warning refers to code not in the source

[GHC]

#1307: Warning refers to code not in the source
-+--
Reporter:  guest |Owner: 
Type:  bug   |   Status:  new
Priority:  lowest|Milestone:  _|_
   Component:  Compiler  |  Version:  6.7
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
  Os:  Windows   | Testcase: 
Architecture:  Unknown   |  
-+--
Comment (by simonpj):

 There are three things going on here:

  * Whether a warning is generated at all for this particular program.  It
 should not be; and Ian says he can't reproduce it.  Perhpas a glitch?

  * How to report missing patterns.  Lennart, how would you like GHC to
 report "you have not covered the case where the head of the input list is
 '!' or '_'"?  In general, of course.  Maybe we should replace the
 `notElem` with "is not one of".

  * Another bad thing about the current report is that it exposes the
 representation of characters.  This is structural: the overlap checker
 first expands character patterns and only then checks for overlap.  It's
 easily fixed -- when someone re-engineers the overlap checker.

 Incidentally, there's a new paper out about overlap warnings "Warnings for
 pattern matching" by Luc Maranget, JFP 17(3), May 07.  All ready for
 someone to implement.

 Simon

-- 
Ticket URL: 
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] #1292: -Wall doesn't include all warnings

[GHC]

#1292: -Wall doesn't include all warnings
-+--
Reporter:  guest |Owner:  
Type:  bug   |   Status:  reopened
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  6.7 
Severity:  normal|   Resolution:  
Keywords:|   Difficulty:  Unknown 
  Os:  Unknown   | Testcase:  
Architecture:  Unknown   |  
-+--
Changes (by simonmar):

  * resolution:  invalid =>
  * summary:  -fwarn-monomorphism-restriction should be -Wmonomorphism-
  restriction => -Wall doesn't include all
  warnings
  * status:  closed => reopened

Comment:

 `-Wall` should enable all warnings, otherwise it's badly named.  So if we
 have `-fwarn-monomorphism-restriction` at all, it should be in `-Wall`,
 and possibly also in `-W`.  I personally think it's useful and we should
 have it, but it should not be enabled by default.

 If you use `-Wall -Werror`, you should expect your code to break whenever
 a new warning is added.  Perhaps we should emit a warning for this option
 combination :-)

 Incedentally, the following warnings are not in `-Wall` (I believe we
 should fix this):

  * `-fwarn-simple-patterns`
  * `-fwarn-tabs`
  * `-fwarn-incomplete-record-updates`

-- 
Ticket URL: 
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: ghci value printing

[Simon Marlow]

Frederik Eaton wrote:

Thanks.

Maybe -fno-print-bind-result belongs in "Interactive-mode options"
rather than "Misc compiler options"?:

http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id3132588


Thanks, I'll move it.

Simon
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1292: -fwarn-monomorphism-restriction should be -Wmonomorphism-restriction

[GHC]

#1292: -fwarn-monomorphism-restriction should be -Wmonomorphism-restriction
-+--
Reporter:  guest |Owner: 
Type:  bug   |   Status:  closed 
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.7
Severity:  normal|   Resolution:  invalid
Keywords:|   Difficulty:  Unknown
  Os:  Unknown   | Testcase: 
Architecture:  Unknown   |  
-+--
Comment (by simonpj):

 Let me observe that
  * Many newbie complaints are due to silent application of the MR
  * It can always be suppressed by adding a type signature

 Perhaps one could make a case to allowing silent MR for nested defns, like
 the one above.

 In any case, I don't feel strongly enough to reopen this.  For now it can
 stay off by default.

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs