July 2014 - ghc-tickets

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 10 Jul '14

10 Jul '14

#7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by jstolarek): I have made some progress on this one today. I'm able to compile {{{ test :: Arrow a => a i i test = proc n -> do returnA -< n }}} using the new desugaring, which was not possible earlier. But I'm still stuck on this: {{{ test :: Arrow a => a i i test = proc n -> do returnA -< n returnA -< n }}} ie. desugaring of `thenA` although now I have gathered more information. With my new implementation the code above desugars to: {{{ (>>>) @ i @ (i, ()) @ i (arr @ i @ (i, ()) (\ (n :: i) -> (n, ()))) (thenA @ arrow @ i @ (GHC.Prim.Any *) @ (GHC.Prim.Any *) @ i $dArrow_auX ((>>>) @ (i, ()) @ i @ i (arr @ (i, ()) @ i (\ (ds2 :: (i, ())) -> case ds2 of _ { (ds4, ds5) -> ds4 })) (Control.Arrow.returnA @ arrow @ i $dArrow_auX)) ((>>>) @ (i, ()) @ i @ i (arr @ (i, ()) @ i (\ (ds2 :: (i, ())) -> case ds2 of _ { (ds4, ds5) -> ds4 })) (Control.Arrow.returnA @ arrow @ i $dArrow_auX))) }}} This looks correct except for the two `(GHC.Prim.Any *)` type parameters to `thenA`. One corresponds to the type of the stack, the other to result of first command (`b` in the type signature `a (e,s) b -> a (e,s) c -> a (e,s) c`). `thenA` should be polymorphic in these, but it seems that during typechecking I need to instantiate `s` and `b` to concrete values. I noticed that desugaring of `cmd` stored in the `BodyStmt` always passes `()` as the type of the stack. If this is correct then there's only the problem of what to do with `b`. Help needed here becuase I have no idea how to figure out the type of `b` from within `tcArrDoStmt`. Ross, I also tried to implement desugaring of `bind`. When generating the desugared Core for `cmd 'bind' \ p -> do { ss }` I have problem with the `\p ->` part. So, given the desugared `do { ss }`, `cmd` and the `bind` operator how should the generated command lambda look like? I'm still at a loss to undestand how to explicitly manipulate the stack from within Core. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #284: RPM doesn't support --prefix
by GHC 10 Jul '14

10 Jul '14

#284: RPM doesn't support --prefix -------------------------------------+------------------------------------ Reporter: skaller | Owner: juhp Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Build System | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ydewit): This is what I see with {{{otool -L}}}: {{{ /t/g/l/g/array-0.5.0.0 ❯❯❯ otool -L libHSarray-0.5.0.0-ghc7.9.20140709.dylib libHSarray-0.5.0.0-ghc7.9.20140709.dylib: @rpath/libHSarray-0.5.0.0-ghc7.9.20140709.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/local/lib/libgmp.10.dylib (compatibility version 13.0.0, current version 13.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) @rpath/libHSbase-4.7.1.0-ghc7.9.20140709.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSinteger-gmp-0.5.1.0-ghc7.9.20140709.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSghc-prim-0.3.1.0-ghc7.9.20140709.dylib (compatibility version 0.0.0, current version 0.0.0) }}} My understanding is that {{{@rpath}}}, which seems to be a feature added in 10.5, means this dylib can be relocated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/284#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9291: Best Muscle building supplement
by GHC 10 Jul '14

10 Jul '14

#9291: Best Muscle building supplement ------------------------------------+------------------------------------- Reporter: herbertlawrence | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: Horsepower XXL | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A improvement passim up the ablaze up see you afterwards alright why potshots it may become bacteria hey it's Kyle Leon here I fabricated the abbreviate presentation for you because I wish to betrayal the three biggest bodybuilding Liza mistakes there in actuality authoritative it impossible for you to anatomy apparent muscle quickly and are amenable for what you ‘relooking the aforementioned anniversary afterwards week you will be abashed but you will learn the accuracy about what is captivation you back from accepting the angular beef you deserve and by the end of this presentation you also apprentice in actuality how to breach through your muscle-building Pluto and you'll be on your way to packing on slabs ripped angular muscle without any fat now that sounds great but if you're annihilation like me [http://slioswim.com/ Horsepower XXL] you're going to wish quick safe and permanent results without accepting to await on things like dangerous steroids pills powders potions or even crazy hours in the gym I'm going to accord you the band-aid that will do just that I'm traveling to accord you the band-aid that abandoned use that accustomed me to overcome my genetics lose my top academy appellation the lanky Leo and become a supplement sponsored athlete by packing on and befitting 21pounds a in actuality muscle in just over a week's afterwards advertise aft this band-aid has landed me on magazine covers a supplement sponsorship and as ultimately afflicted my action that’s why I'm administration this admonition with you today I want to accord you. http://slioswim.com/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9291> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #284: RPM doesn't support --prefix
by GHC 10 Jul '14

10 Jul '14

#284: RPM doesn't support --prefix -------------------------------------+------------------------------------ Reporter: skaller | Owner: juhp Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Build System | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): I don't think relocating is quite that simple. Eg On OS X, dylibs can't use relative paths (last I checked), so relocating dylibs requires an invocation of the install-name-tool to fixup the paths! (my recollection could be totally wrong mind you) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/284#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #284: RPM doesn't support --prefix
by GHC 10 Jul '14

10 Jul '14

#284: RPM doesn't support --prefix -------------------------------------+------------------------------------ Reporter: skaller | Owner: juhp Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Build System | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ydewit): * cc: ydewit@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/284#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #284: RPM doesn't support --prefix
by GHC 10 Jul '14

10 Jul '14

#284: RPM doesn't support --prefix -------------------------------------+------------------------------------ Reporter: skaller | Owner: juhp Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Build System | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ydewit): There seems to be two areas that need to be fixed to support relocatable installs: the shell wrappers and the .conf files. Both of these set of files have absolute paths. Regarding the shell wrappers (e.g. $GHC_HOME/bin/{ghc,ghc- pkg,ghci,runghc,runhaskell}), we could simply use a slightly different scheme. For instance, an alternative for the ghc wrapper: {{{ #!/bin/sh GHC_HOME=$( cd $(dirname $0)/.. ; pwd ) exedir="${GHC_HOME}/lib/ghc-7.8.2/bin" exeprog="ghc-stage2" executablename="$exedir/$exeprog" datadir="${GHC_HOME}/lib" bindir="${GHC_HOME}/bin" topdir="${GHC_HOME}" executablename="$exedir/ghc" exec "$executablename" -B"$topdir" ${1+"$@"} }}} The critical piece is {{{ GHC_HOME=$( cd $(dirname $0)/.. ; pwd ) }}} since it needs to work for all supported platforms. Other than that, it is pretty straight-forward. I see that there is support for a {{{RelocatableBuild}}} variable in config.mk, but it is turned on only on Windows: {{{ # On Windows we normally want to make a relocatable bindist, to we # ignore flags like libdir ifeq "$(Windows_Host)" "YES" RelocatableBuild = YES else RelocatableBuild = NO endif }}} So it seems that we have two different layouts: one for Windows and one for everything else: {{{ exec_prefix = ${prefix} bindir = ${exec_prefix}/bin datadir = ${datarootdir} libdir = ${exec_prefix}/lib includedir = ${prefix}/include mandir = ${datarootdir}/man docdir = ${datarootdir}/doc/${PACKAGE_TARNAME} $(eval $(call set_default,docdir,$${datarootdir}/doc/ghc)) htmldir = ${docdir} dvidir = ${docdir} pdfdir = ${docdir} psdir = ${docdir} $(eval $(call set_default,htmldir,$${docdir})) $(eval $(call set_default,dvidir,$${docdir})) $(eval $(call set_default,pdfdir,$${docdir})) $(eval $(call set_default,psdir,$${docdir})) ifeq "$(RelocatableBuild)" "YES" # Hack: our directory layouts tend to be different on Windows, so # hack around configure's bogus assumptions here. datarootdir = $(prefix) datadir = $(prefix)/lib libdir = $(prefix)/lib docdir = $(prefix)/doc htmldir = $(docdir) dvidir = $(docdir) pdfdir = $(docdir) psdir = $(docdir) ghclibdir = $(libdir) ghcdocdir = $(datarootdir)/doc else # Unix: override libdir and datadir to put ghc-specific stuff in # a subdirectory with the version number included. # # datadir is set to libdir here as GHC needs package.conf and unlit # to be in the same place (and things like ghc-pkg need to agree on # where package.conf is, so we just set it globally). # ghclibdir = $(libdir)/$(CrossCompilePrefix)ghc-$(ProjectVersion) ghcdocdir = $(datarootdir)/doc/ghc endif ghclibexecdir = $(ghclibdir) topdir = $(ghclibdir) ghcheaderdir = $(ghclibdir)/include }}} Why two layouts? I also see that the non-windows layout is accounting for cross compilation, which is doesn't seem supported in the Windows layout. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/284#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9290: The job a whole tight will be
by GHC 10 Jul '14

10 Jul '14

#9290: The job a whole tight will be ------------------------------------+------------------------------------- Reporter: herbertlawrence | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: Horsepower XXL | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- You really have a great and rebuilding you know by you think I think there I'd get there I think character is an American as apple pie we live in a society today you got it and he in reality shows Madonna is making out with Britney Spears randy is a candle and hit you worried about steroids kids like you got to you made playing video games the current tampering [http://slioswim.com/ Horsepower XXL] that more influence in my opinion this can lead to ever be in Barry Bonds hit a homerun if there's a big difference between him taking them you don't need Paralympics a couple years as opposed to have grown man looking to perform better and better level in sports and we're thrilled maker known as I mean he’s the poster boy hysterical think the modem we heard it look at me like I did came I conquered a kickass that more biography says he was born in with 15 16 hey he won at the University nineteen-years-old 19 get to see what it looks like when hews 19 you think it was God given to next time you think that maybe people to performance-enhancing white people idolize these guys went into rock band body blow the movies on whether at all when you get to meet them and mandate a webcam a good day never at her what they appear to be thing I do you think in public like this got the middle finger on the table like this never look at the end what you get what you think and what they want you to see everybody idolized Schwarzenegger going up everybody put my hand want to lightweights in the end up. http://slioswim.com/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9290> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv)
by GHC 10 Jul '14

10 Jul '14

#9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------------------+------------------------------- Reporter: jberthold | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- A patch in GHC-7.7 modified the "thread stop status" encoding, so the current ghc-events (version 0.4.2.0 from 2012) produces wrong stop reasons when reading an eventlog written by GHC-7.8.2. The GHC patch is http://git.haskell.org/ghc.git/commit/70e20631742e516c6a11c3c112fbd5b4a08c1… The MVarRead block reason was added in the middle, shifting all following block reason codes one up. The error can be observed when a thread blocks on a black hole during a program run. Attached is a small test program which produces this situation, and two event logs for the same program run with the same arguments and RTS parameters. The program's two threads evaluate the same data, the parent thread typically blocks on a blackhole created by a forked child thread. Note the sequence around user event "child": The log written by GHC-7.6.3 correctly shows blocking on a black hole, while the log written by GHC-7.8.2 claims the main thread blocks "on I/O read". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

Re: [GHC] #7103: Compiler panic, when loading wxc in GHCi
by GHC 09 Jul '14

09 Jul '14

#7103: Compiler panic, when loading wxc in GHCi -------------------------------+------------------------------------ Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: GHCi | Version: 7.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+------------------------------------ Changes (by Henk-Jan): * cc: hvr (added) Comment: The problem still exists with GHC 7.8.2, compiled with DYNAMIC_GHC_PROGRAMS=YES. This is tested on Windows 8.1 (64-bit) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7103#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4218: System.Random is way too lazy
by GHC 08 Jul '14

08 Jul '14

#4218: System.Random is way too lazy ---------------------------------+----------------------------------------- Reporter: EyalLotem | Owner: rrnewton Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: | Version: 6.12.3 libraries/random | Keywords: random stack overflow Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: None/Unknown | Related Tickets: Test Case: | Blocking: | ---------------------------------+----------------------------------------- Changes (by thomie): * cc: rrnewton (added) * difficulty: => Unknown * component: Compiler => libraries/random * milestone: 7.6.2 => 7.10.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4218#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0