From karel.gardas at centrum.cz Fri Aug 1 09:19:20 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Fri, 01 Aug 2014 11:19:20 +0200 Subject: Cross compiling for Cortex A9 In-Reply-To: <4FC55335-526F-4007-BD0E-C8620DED6653@proclivis.com> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> <53C394AE.4020303@centrum.cz> <67CEBBAE-CC1F-47CC-9A21-AA94C4A25149@proclivis.com> <53C4015D.9060009@centrum.cz> <4FC55335-526F-4007-BD0E-C8620DED6653@proclivis.com> Message-ID: <53DB5B98.5040500@centrum.cz> OK, so you do have ghc-stage1 which is a cross-compiler. Now, what does ghc-stage1 --info tell you? Aha, you hacked configure, hmm. I don't think this is needed especially if you use proper CFLAGS. Karel On 07/25/14 06:00 AM, Michael Jones wrote: > I have some progress, and a problem. First, note I am using the 7.8.3 > tar ball, for this discussion here. > > If you read through, you will see a request for help at the end. It > looks like the cross compilation is trying to build stage2 when it > shouldn?t. > > In order to get the resulting stage1 cross compiler to have: > > ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], > armABI = HARD}") > > I hacked this: > > AC_DEFUN([GET_ARM_ISA], > [ > changequote(, )dnl > ARM_ISA=ARMv7 > ARM_ISA_EXT="[VFPv3,NEON]" > changequote([, ])dnl > [ARM_ABI="HARD"] > ]) > > Now, my gcc cross compiler does not default to ARMv7. To compile for my > Cortex A, I add these options: > > -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon > -mtune=cortex-a9 > > So I need to make sure that when building the libraries with stage1, it > passes the correct options. To do that: > > AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], > [ > AC_MSG_CHECKING([Setting up $2, $3, $4 and $5]) > ? > arm-poky-*) > $2="$$2 -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon > -mtune=cortex-a9" > ;; > > > Which results in a stage1 compiler with: > > ,("C compiler flags"," -march=armv7-a -mthumb-interwork -mfloat-abi=hard > -mfpu=neon -mtune=cortex-a9 -fno-stack-protector?) > > As the build proceeds, all calls to stage1 are completing. Then, the > build gets to this point: > > "inplace/bin/mkdirhier" compiler/stage2/build//. > "rm" -f compiler/stage2/build/Config.hs > Creating compiler/stage2/build/Config.hs ... > done. > > And I assume this means it is trying to build stage2. Correct me if I am > wrong. > > Eventually I get a build failure like this: > > gcc -E -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -march=armv7-a > -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 > -fno-stack-protector -Icompiler/. -Icompiler/parser -Icompiler/utils > -Icompiler/../rts/dist/build -Icompiler/stage2 -DGHCI > -I'/home/mike/ghc-7.8.3/libraries/process/include' > -I'/home/mike/ghc-7.8.3/libraries/directory/include' > -I'/home/mike/ghc-7.8.3/libraries/unix/include' > -I'/home/mike/ghc-7.8.3/libraries/time/include' > -I'/home/mike/ghc-7.8.3/libraries/containers/include' > -I'/home/mike/ghc-7.8.3/libraries/bytestring/include' > -I'/home/mike/ghc-7.8.3/libraries/base/include' > -I'/home/mike/ghc-7.8.3/rts/dist/build' > -I'/home/mike/ghc-7.8.3/includes' > -I'/home/mike/ghc-7.8.3/includes/dist-derivedconstants/header' -MM -x c > compiler/parser/cutils.c -MF compiler/stage2/build/.depend-v.c_asm.bit > gcc: error: unrecognized command line option ?-mthumb-interwork? > gcc: error: unrecognized command line option ?-mfloat-abi=hard? > gcc: error: unrecognized command line option ?-mfpu=neon? > make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1 > make: *** [all] Error 2 > > It is applying the -march? arguments to the local gcc. I am guessing > that compiling for stage2 is using the local gcc because stage2 is only > built when not making a cross compiler. > > Now, in build.mk I have: > > BuildFlavour = quick-cross > > Which is supposed to prevent stage2 compilation. > > Something is wrong. Either I need to stop stage2 compilation, if that is > what this is really doing, or prevent gcc from using the extra > arguments. But I see no reason to run gcc. Seems like that would only be > used at stage0 if at all. > > Mike > > On Jul 14, 2014, at 10:12 AM, Karel Gardas > wrote: > >> On 07/14/14 04:58 PM, Michael Jones wrote: >>> Karel, >>> >>> Thanks. This helps. >>> >>> If I understand, you have Linux running on a Panda, and on that Panda >>> system you have gcc, and you compile GHC on the Panda itself, rather >>> than build a cross compiler. I can see the advantage of building this >>> way. >> >> Correct! >> >>> As far as cross compilers, I have a reason for trying to build a >>> cross compiler, other than the ability to keep the image of the >>> target small. That is, eventually, I want to be able to compile for >>> an RTOS and/or bare iron system. I decided that learning to cross >>> compile for Linux first would be a good approach. Learn the build >>> system on something known to work. So I probably will not give up on >>> that. >> >> That is right, in future I'd also like to give a try to port GHC to >> some free RTOS and for this I'd need to use cross-compiling anyway, so >> I'll be on the same boat... >> >>> I got a book on Autoconfig. I?ll just have to dig a level deeper into >>> the whole build system. Mainly it means learning the M4 system. I >>> have never used it. >>> >>> Below are the defines from the command you suggested. Thanks for >>> that, got me over an ignorance hump. At least this define, >>> __ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study >>> the macros until I figure out what controls the gcc options passed to >>> the gcc cross compiler. I guess my question is what actually controls >>> this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt = >>> [VFPv3,NEON], armABI = HARD}?)? >>> >>> Are these controlled by the defines below, or are they controlled by >>> passing gcc arguments to the gcc compiler when the Haskell compiler >>> calls gcc? >> >> Basically speaking all those are controlled by platform gcc. That >> means if you pass the right option to your cross-compiling gcc you >> should also get the same result, so for example if you use: >> >> gcc -mfloat-abi=hard -march=armv7-a -mfpu=vfpv3-d16 >> >> you should get the same settings like me. >> >> But anyway, please note that ABI you set to your cross-compiler *have >> to* match the ABI provided by the target RTOS/OS! I hope that's clear. :-) >> >> Cheers, >> Karel > From mike at proclivis.com Fri Aug 1 21:23:09 2014 From: mike at proclivis.com (Michael Jones) Date: Fri, 1 Aug 2014 15:23:09 -0600 Subject: Cross compiling for Cortex A9 In-Reply-To: <53DB5B98.5040500@centrum.cz> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> <53C394AE.4020303@centrum.cz> <67CEBBAE-CC1F-47CC-9A21-AA94C4A25149@proclivis.com> <53C4015D.9060009@centrum.cz> <4FC55335-526F-4007-BD0E-C8620DED6653@proclivis.com> <53DB5B98.5040500@centrum.cz> Message-ID: Karel, On CFLAGS.. When the cross compiler is compiled, does it use gcc, or is gcc only used to compile libraries with the stage-1 compiler? Because if gcc is used for both, I would need different flags for each, and I don't know how to make that happen. Mike Sent from my iPad > On Aug 1, 2014, at 3:19 AM, Karel Gardas wrote: > > > OK, so you do have ghc-stage1 which is a cross-compiler. Now, what does ghc-stage1 --info tell you? > > Aha, you hacked configure, hmm. I don't think this is needed especially if you use proper CFLAGS. > > Karel > >> On 07/25/14 06:00 AM, Michael Jones wrote: >> I have some progress, and a problem. First, note I am using the 7.8.3 >> tar ball, for this discussion here. >> >> If you read through, you will see a request for help at the end. It >> looks like the cross compilation is trying to build stage2 when it >> shouldn?t. >> >> In order to get the resulting stage1 cross compiler to have: >> >> ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], >> armABI = HARD}") >> >> I hacked this: >> >> AC_DEFUN([GET_ARM_ISA], >> [ >> changequote(, )dnl >> ARM_ISA=ARMv7 >> ARM_ISA_EXT="[VFPv3,NEON]" >> changequote([, ])dnl >> [ARM_ABI="HARD"] >> ]) >> >> Now, my gcc cross compiler does not default to ARMv7. To compile for my >> Cortex A, I add these options: >> >> -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon >> -mtune=cortex-a9 >> >> So I need to make sure that when building the libraries with stage1, it >> passes the correct options. To do that: >> >> AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], >> [ >> AC_MSG_CHECKING([Setting up $2, $3, $4 and $5]) >> ? >> arm-poky-*) >> $2="$$2 -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon >> -mtune=cortex-a9" >> ;; >> >> >> Which results in a stage1 compiler with: >> >> ,("C compiler flags"," -march=armv7-a -mthumb-interwork -mfloat-abi=hard >> -mfpu=neon -mtune=cortex-a9 -fno-stack-protector?) >> >> As the build proceeds, all calls to stage1 are completing. Then, the >> build gets to this point: >> >> "inplace/bin/mkdirhier" compiler/stage2/build//. >> "rm" -f compiler/stage2/build/Config.hs >> Creating compiler/stage2/build/Config.hs ... >> done. >> >> And I assume this means it is trying to build stage2. Correct me if I am >> wrong. >> >> Eventually I get a build failure like this: >> >> gcc -E -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -march=armv7-a >> -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 >> -fno-stack-protector -Icompiler/. -Icompiler/parser -Icompiler/utils >> -Icompiler/../rts/dist/build -Icompiler/stage2 -DGHCI >> -I'/home/mike/ghc-7.8.3/libraries/process/include' >> -I'/home/mike/ghc-7.8.3/libraries/directory/include' >> -I'/home/mike/ghc-7.8.3/libraries/unix/include' >> -I'/home/mike/ghc-7.8.3/libraries/time/include' >> -I'/home/mike/ghc-7.8.3/libraries/containers/include' >> -I'/home/mike/ghc-7.8.3/libraries/bytestring/include' >> -I'/home/mike/ghc-7.8.3/libraries/base/include' >> -I'/home/mike/ghc-7.8.3/rts/dist/build' >> -I'/home/mike/ghc-7.8.3/includes' >> -I'/home/mike/ghc-7.8.3/includes/dist-derivedconstants/header' -MM -x c >> compiler/parser/cutils.c -MF compiler/stage2/build/.depend-v.c_asm.bit >> gcc: error: unrecognized command line option ?-mthumb-interwork? >> gcc: error: unrecognized command line option ?-mfloat-abi=hard? >> gcc: error: unrecognized command line option ?-mfpu=neon? >> make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1 >> make: *** [all] Error 2 >> >> It is applying the -march? arguments to the local gcc. I am guessing >> that compiling for stage2 is using the local gcc because stage2 is only >> built when not making a cross compiler. >> >> Now, in build.mk I have: >> >> BuildFlavour = quick-cross >> >> Which is supposed to prevent stage2 compilation. >> >> Something is wrong. Either I need to stop stage2 compilation, if that is >> what this is really doing, or prevent gcc from using the extra >> arguments. But I see no reason to run gcc. Seems like that would only be >> used at stage0 if at all. >> >> Mike >> >> On Jul 14, 2014, at 10:12 AM, Karel Gardas > > wrote: >> >>>> On 07/14/14 04:58 PM, Michael Jones wrote: >>>> Karel, >>>> >>>> Thanks. This helps. >>>> >>>> If I understand, you have Linux running on a Panda, and on that Panda >>>> system you have gcc, and you compile GHC on the Panda itself, rather >>>> than build a cross compiler. I can see the advantage of building this >>>> way. >>> >>> Correct! >>> >>>> As far as cross compilers, I have a reason for trying to build a >>>> cross compiler, other than the ability to keep the image of the >>>> target small. That is, eventually, I want to be able to compile for >>>> an RTOS and/or bare iron system. I decided that learning to cross >>>> compile for Linux first would be a good approach. Learn the build >>>> system on something known to work. So I probably will not give up on >>>> that. >>> >>> That is right, in future I'd also like to give a try to port GHC to >>> some free RTOS and for this I'd need to use cross-compiling anyway, so >>> I'll be on the same boat... >>> >>>> I got a book on Autoconfig. I?ll just have to dig a level deeper into >>>> the whole build system. Mainly it means learning the M4 system. I >>>> have never used it. >>>> >>>> Below are the defines from the command you suggested. Thanks for >>>> that, got me over an ignorance hump. At least this define, >>>> __ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study >>>> the macros until I figure out what controls the gcc options passed to >>>> the gcc cross compiler. I guess my question is what actually controls >>>> this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt = >>>> [VFPv3,NEON], armABI = HARD}?)? >>>> >>>> Are these controlled by the defines below, or are they controlled by >>>> passing gcc arguments to the gcc compiler when the Haskell compiler >>>> calls gcc? >>> >>> Basically speaking all those are controlled by platform gcc. That >>> means if you pass the right option to your cross-compiling gcc you >>> should also get the same result, so for example if you use: >>> >>> gcc -mfloat-abi=hard -march=armv7-a -mfpu=vfpv3-d16 >>> >>> you should get the same settings like me. >>> >>> But anyway, please note that ABI you set to your cross-compiler *have >>> to* match the ABI provided by the target RTOS/OS! I hope that's clear. :-) >>> >>> Cheers, >>> Karel > From d at davidterei.com Sat Aug 2 00:30:50 2014 From: d at davidterei.com (David Terei) Date: Fri, 1 Aug 2014 17:30:50 -0700 Subject: Overlapping and incoherent instances In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: This is great! It's nice to see something finer grain. We'd of course like to bring Safe Haskell into the picture though! Our concern with the new design as it stands is the OVERLAPS flag. We'd prefer it to be eliminated in favor of requiring developers specify both OVERLAPPABLE and OVERLAPS if that truly is their intention. # Why? ## Long Version https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell/NewOverlappingInstances#NewOverlappingInstances--a.k.aInstanceSpecificPragmas ## Short Version (kind-of) The security implications of OVERLAPPABLE vs. OVERLAPPING are fairly different. Remember, in Safe Haskell we apply a policy of only allowing instances from a module M compiled with `-XSafe` to overlap other instances from module M. If it overlaps (and is the most specific overlap) instances from modules other than M then we don't allow this to succeed. This is done to ensure that untrusted code compiled with `-XSafe` can't alter the behavior of existing code, some of which may be part of the TCB and security critical. Brining the new finer grained pragmas into the story we get the following: * OVERLAPPABLE is the programmer communicating that they can be overlapped, an open instance if you will. We want to relax the above restriction and allow instances from `-XSafe` modules to overlap instances from their own module AND instances declared OVERLAPPABLE that reside in any module. * OVERLAPPING is the programming simply declaring they may overlap less specific instances. We want to keep the above restriction for these instances. That is, a instance I1 from a `-XSafe` module M won't be able to overlap as the most specific instance, a instance I2 from another module if I2 is marked as OVERLAPPING. This distinction enables new encodings in Safe Haskell by allowing security library authors to distinguish how untrusted code can overlap their instances. In some way giving them open vs closed instances. This distinction is subtle and important. Having a pragma OVERLAPS that implies both glosses over this and will encourage developers to use this without much thought. ## Safe Inference We can also safely infer a module that only has OVERLAPPABLE instances as safe, while ones that contain OVERLAPPING or OVERLAPS instances must be regarded as unsafe since there is a difference in semantics of these pragmas under Safe vs Unsafe. So we also have an advantage if developers are more specific about what they want, than just defaulting to OVERLAPS. Cheers, David On 29 July 2014 02:11, Simon Peyton Jones wrote: > Friends > > One of GHC?s more widely-used features is overlapping (and sometimes > incoherent) instances. The user-manual documentation is here. > > The use of overlapping/incoherent instances is controlled by LANGUAGE > pragmas: OverlappingInstances and IncoherentInstances respectively. > > However the overlap/incoherent-ness is a property of the *instance > declaration* itself, and has been for a long time. Using LANGUAGE > OverlappingInstances simply sets the ?I am an overlapping instance? flag for > every instance declaration in that module. > > This is a Big Hammer. It give no clue about *which* particular instances > the programmer is expecting to be overlapped, nor which are doing the > overlapping. It brutally applies to every instance in the module. > Moreover, when looking at an instance declaration, there is no nearby clue > that it might be overlapped. The clue might be in the command line that > compiles that module! > > Iavor has recently implemented per-instance-declaration pragmas, so you can > say > > instance {-# OVERLAPPABLE #-} Show a => Show [a] where ? > > instance {-# OVERLAPPING #-} Show [Char] where ? > > This is much more precise (it affects only those specific instances) and it > is much clearer (you see it when you see the instance declaration). > > This new feature will be in GHC 7.10 and I?m sure you will be happy about > that. But I propose also to deprecate the LANGUAGE pragmas > OverlappingInstances and IncoherentInstances, as way to encourage everyone > to use the new feature instead of the old big hammer. The old LANGUAGE > pragmas will continue to work, of course, for at least another complete > release cycle. We could make that two cycles if it was helpful. > > However, if you want deprecation-free libraries, it will entail a wave of > library updates. > > This email is just to warn you, and to let you yell if you think this is a > bad idea. It would actually not be difficult to retain the old LANGUAGE > pragmas indefinitely ? it just seems wrong not to actively push authors in > the right direction. > > These deprecations of course popped up in the test suite, so I?ve been > replacing them with per-instance pragmas there too. Interestingly in some > cases, when looking for which instances needed the pragmas, I found?none. So > OverlappingInstances was entirely unnecessary. Maybe library authors will > find that too! > > Simon > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From mike at proclivis.com Sat Aug 2 02:02:28 2014 From: mike at proclivis.com (Michael Jones) Date: Fri, 1 Aug 2014 20:02:28 -0600 Subject: Cross compiling for Cortex A9 In-Reply-To: References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> <53C394AE.4020303@centrum.cz> <67CEBBAE-CC1F-47CC-9A21-AA94C4A25149@proclivis.com> <53C4015D.9060009@centrum.cz> <4FC55335-526F-4007-BD0E-C8620DED6653@proclivis.com> <53DB5B98.5040500@centrum.cz> Message-ID: <54DA8C80-0FC5-426B-889C-5C14BC24551C@proclivis.com> Karel, I think I proved that make dies early if CFLAGS has these options. The local gcc does not support ARM related flags. I am trying to build the tool chain with ?with-arch= and ?with-tune== so that it defaults to my target. This will bypass any GHC build issues. Mike On Aug 1, 2014, at 3:23 PM, Michael Jones wrote: > Karel, > > On CFLAGS.. > > When the cross compiler is compiled, does it use gcc, or is gcc only used to compile libraries with the stage-1 compiler? > > Because if gcc is used for both, I would need different flags for each, and I don't know how to make that happen. > > Mike > > Sent from my iPad > >> On Aug 1, 2014, at 3:19 AM, Karel Gardas wrote: >> >> >> OK, so you do have ghc-stage1 which is a cross-compiler. Now, what does ghc-stage1 --info tell you? >> >> Aha, you hacked configure, hmm. I don't think this is needed especially if you use proper CFLAGS. >> >> Karel >> >>> On 07/25/14 06:00 AM, Michael Jones wrote: >>> I have some progress, and a problem. First, note I am using the 7.8.3 >>> tar ball, for this discussion here. >>> >>> If you read through, you will see a request for help at the end. It >>> looks like the cross compilation is trying to build stage2 when it >>> shouldn?t. >>> >>> In order to get the resulting stage1 cross compiler to have: >>> >>> ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], >>> armABI = HARD}") >>> >>> I hacked this: >>> >>> AC_DEFUN([GET_ARM_ISA], >>> [ >>> changequote(, )dnl >>> ARM_ISA=ARMv7 >>> ARM_ISA_EXT="[VFPv3,NEON]" >>> changequote([, ])dnl >>> [ARM_ABI="HARD"] >>> ]) >>> >>> Now, my gcc cross compiler does not default to ARMv7. To compile for my >>> Cortex A, I add these options: >>> >>> -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon >>> -mtune=cortex-a9 >>> >>> So I need to make sure that when building the libraries with stage1, it >>> passes the correct options. To do that: >>> >>> AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], >>> [ >>> AC_MSG_CHECKING([Setting up $2, $3, $4 and $5]) >>> ? >>> arm-poky-*) >>> $2="$$2 -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon >>> -mtune=cortex-a9" >>> ;; >>> >>> >>> Which results in a stage1 compiler with: >>> >>> ,("C compiler flags"," -march=armv7-a -mthumb-interwork -mfloat-abi=hard >>> -mfpu=neon -mtune=cortex-a9 -fno-stack-protector?) >>> >>> As the build proceeds, all calls to stage1 are completing. Then, the >>> build gets to this point: >>> >>> "inplace/bin/mkdirhier" compiler/stage2/build//. >>> "rm" -f compiler/stage2/build/Config.hs >>> Creating compiler/stage2/build/Config.hs ... >>> done. >>> >>> And I assume this means it is trying to build stage2. Correct me if I am >>> wrong. >>> >>> Eventually I get a build failure like this: >>> >>> gcc -E -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -march=armv7-a >>> -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 >>> -fno-stack-protector -Icompiler/. -Icompiler/parser -Icompiler/utils >>> -Icompiler/../rts/dist/build -Icompiler/stage2 -DGHCI >>> -I'/home/mike/ghc-7.8.3/libraries/process/include' >>> -I'/home/mike/ghc-7.8.3/libraries/directory/include' >>> -I'/home/mike/ghc-7.8.3/libraries/unix/include' >>> -I'/home/mike/ghc-7.8.3/libraries/time/include' >>> -I'/home/mike/ghc-7.8.3/libraries/containers/include' >>> -I'/home/mike/ghc-7.8.3/libraries/bytestring/include' >>> -I'/home/mike/ghc-7.8.3/libraries/base/include' >>> -I'/home/mike/ghc-7.8.3/rts/dist/build' >>> -I'/home/mike/ghc-7.8.3/includes' >>> -I'/home/mike/ghc-7.8.3/includes/dist-derivedconstants/header' -MM -x c >>> compiler/parser/cutils.c -MF compiler/stage2/build/.depend-v.c_asm.bit >>> gcc: error: unrecognized command line option ?-mthumb-interwork? >>> gcc: error: unrecognized command line option ?-mfloat-abi=hard? >>> gcc: error: unrecognized command line option ?-mfpu=neon? >>> make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1 >>> make: *** [all] Error 2 >>> >>> It is applying the -march? arguments to the local gcc. I am guessing >>> that compiling for stage2 is using the local gcc because stage2 is only >>> built when not making a cross compiler. >>> >>> Now, in build.mk I have: >>> >>> BuildFlavour = quick-cross >>> >>> Which is supposed to prevent stage2 compilation. >>> >>> Something is wrong. Either I need to stop stage2 compilation, if that is >>> what this is really doing, or prevent gcc from using the extra >>> arguments. But I see no reason to run gcc. Seems like that would only be >>> used at stage0 if at all. >>> >>> Mike >>> >>> On Jul 14, 2014, at 10:12 AM, Karel Gardas >> > wrote: >>> >>>>> On 07/14/14 04:58 PM, Michael Jones wrote: >>>>> Karel, >>>>> >>>>> Thanks. This helps. >>>>> >>>>> If I understand, you have Linux running on a Panda, and on that Panda >>>>> system you have gcc, and you compile GHC on the Panda itself, rather >>>>> than build a cross compiler. I can see the advantage of building this >>>>> way. >>>> >>>> Correct! >>>> >>>>> As far as cross compilers, I have a reason for trying to build a >>>>> cross compiler, other than the ability to keep the image of the >>>>> target small. That is, eventually, I want to be able to compile for >>>>> an RTOS and/or bare iron system. I decided that learning to cross >>>>> compile for Linux first would be a good approach. Learn the build >>>>> system on something known to work. So I probably will not give up on >>>>> that. >>>> >>>> That is right, in future I'd also like to give a try to port GHC to >>>> some free RTOS and for this I'd need to use cross-compiling anyway, so >>>> I'll be on the same boat... >>>> >>>>> I got a book on Autoconfig. I?ll just have to dig a level deeper into >>>>> the whole build system. Mainly it means learning the M4 system. I >>>>> have never used it. >>>>> >>>>> Below are the defines from the command you suggested. Thanks for >>>>> that, got me over an ignorance hump. At least this define, >>>>> __ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study >>>>> the macros until I figure out what controls the gcc options passed to >>>>> the gcc cross compiler. I guess my question is what actually controls >>>>> this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt = >>>>> [VFPv3,NEON], armABI = HARD}?)? >>>>> >>>>> Are these controlled by the defines below, or are they controlled by >>>>> passing gcc arguments to the gcc compiler when the Haskell compiler >>>>> calls gcc? >>>> >>>> Basically speaking all those are controlled by platform gcc. That >>>> means if you pass the right option to your cross-compiling gcc you >>>> should also get the same result, so for example if you use: >>>> >>>> gcc -mfloat-abi=hard -march=armv7-a -mfpu=vfpv3-d16 >>>> >>>> you should get the same settings like me. >>>> >>>> But anyway, please note that ABI you set to your cross-compiler *have >>>> to* match the ABI provided by the target RTOS/OS! I hope that's clear. :-) >>>> >>>> Cheers, >>>> Karel >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From mike at proclivis.com Sat Aug 2 05:04:10 2014 From: mike at proclivis.com (Michael Jones) Date: Fri, 1 Aug 2014 23:04:10 -0600 Subject: Cross compiling for Cortex A9 In-Reply-To: <54DA8C80-0FC5-426B-889C-5C14BC24551C@proclivis.com> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> <53C394AE.4020303@centrum.cz> <67CEBBAE-CC1F-47CC-9A21-AA94C4A25149@proclivis.com> <53C4015D.9060009@centrum.cz> <4FC55335-526F-4007-BD0E-C8620DED6653@proclivis.com> <53DB5B98.5040500@centrum.cz> <54DA8C80-0FC5-426B-889C-5C14BC24551C@proclivis.com> Message-ID: <1E342657-2166-40C2-93AF-2C231B353ADC@proclivis.com> Karel, I was able to get GHC to compile by rebuilding the gcc cross compiler using ?with-arch= and ?with-tune= However, it is not a satisfactory solution, because if a gcc toolchain uses multilibs, adding those options does not make sense. In the case of the Yocto toolchain, it does not use multilibs, so I can get away with it. I?ll test the compiler tomorrow and see how things go. Here is the GHC info after building: [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","arm-poky-linux-gnueabi-gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("Haskell CPP command","arm-poky-linux-gnueabi-gcc") ,("Haskell CPP flags","-E -undef -traditional ") ,("ld command","/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}") ,("target word size","4") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","/usr/bin/llc") ,("LLVM opt command","/usr/bin/opt") ,("Project version","7.8.3") ,("Booter version","7.6.3") ,("Stage","1") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","arm-poky-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l ") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/home/mike/ghc-7.8.3/inplace/lib") ,("Global Package DB","/home/mike/ghc-7.8.3/inplace/lib/package.conf.d") ] On Aug 1, 2014, at 8:02 PM, Michael Jones wrote: > Karel, > > I think I proved that make dies early if CFLAGS has these options. The local gcc does not support ARM related flags. > > I am trying to build the tool chain with ?with-arch= and ?with-tune== so that it defaults to my target. This will bypass any GHC build issues. > > Mike > > On Aug 1, 2014, at 3:23 PM, Michael Jones wrote: > >> Karel, >> >> On CFLAGS.. >> >> When the cross compiler is compiled, does it use gcc, or is gcc only used to compile libraries with the stage-1 compiler? >> >> Because if gcc is used for both, I would need different flags for each, and I don't know how to make that happen. >> >> Mike >> >> Sent from my iPad >> >>> On Aug 1, 2014, at 3:19 AM, Karel Gardas wrote: >>> >>> >>> OK, so you do have ghc-stage1 which is a cross-compiler. Now, what does ghc-stage1 --info tell you? >>> >>> Aha, you hacked configure, hmm. I don't think this is needed especially if you use proper CFLAGS. >>> >>> Karel >>> >>>> On 07/25/14 06:00 AM, Michael Jones wrote: >>>> I have some progress, and a problem. First, note I am using the 7.8.3 >>>> tar ball, for this discussion here. >>>> >>>> If you read through, you will see a request for help at the end. It >>>> looks like the cross compilation is trying to build stage2 when it >>>> shouldn?t. >>>> >>>> In order to get the resulting stage1 cross compiler to have: >>>> >>>> ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], >>>> armABI = HARD}") >>>> >>>> I hacked this: >>>> >>>> AC_DEFUN([GET_ARM_ISA], >>>> [ >>>> changequote(, )dnl >>>> ARM_ISA=ARMv7 >>>> ARM_ISA_EXT="[VFPv3,NEON]" >>>> changequote([, ])dnl >>>> [ARM_ABI="HARD"] >>>> ]) >>>> >>>> Now, my gcc cross compiler does not default to ARMv7. To compile for my >>>> Cortex A, I add these options: >>>> >>>> -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon >>>> -mtune=cortex-a9 >>>> >>>> So I need to make sure that when building the libraries with stage1, it >>>> passes the correct options. To do that: >>>> >>>> AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], >>>> [ >>>> AC_MSG_CHECKING([Setting up $2, $3, $4 and $5]) >>>> ? >>>> arm-poky-*) >>>> $2="$$2 -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon >>>> -mtune=cortex-a9" >>>> ;; >>>> >>>> >>>> Which results in a stage1 compiler with: >>>> >>>> ,("C compiler flags"," -march=armv7-a -mthumb-interwork -mfloat-abi=hard >>>> -mfpu=neon -mtune=cortex-a9 -fno-stack-protector?) >>>> >>>> As the build proceeds, all calls to stage1 are completing. Then, the >>>> build gets to this point: >>>> >>>> "inplace/bin/mkdirhier" compiler/stage2/build//. >>>> "rm" -f compiler/stage2/build/Config.hs >>>> Creating compiler/stage2/build/Config.hs ... >>>> done. >>>> >>>> And I assume this means it is trying to build stage2. Correct me if I am >>>> wrong. >>>> >>>> Eventually I get a build failure like this: >>>> >>>> gcc -E -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -march=armv7-a >>>> -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 >>>> -fno-stack-protector -Icompiler/. -Icompiler/parser -Icompiler/utils >>>> -Icompiler/../rts/dist/build -Icompiler/stage2 -DGHCI >>>> -I'/home/mike/ghc-7.8.3/libraries/process/include' >>>> -I'/home/mike/ghc-7.8.3/libraries/directory/include' >>>> -I'/home/mike/ghc-7.8.3/libraries/unix/include' >>>> -I'/home/mike/ghc-7.8.3/libraries/time/include' >>>> -I'/home/mike/ghc-7.8.3/libraries/containers/include' >>>> -I'/home/mike/ghc-7.8.3/libraries/bytestring/include' >>>> -I'/home/mike/ghc-7.8.3/libraries/base/include' >>>> -I'/home/mike/ghc-7.8.3/rts/dist/build' >>>> -I'/home/mike/ghc-7.8.3/includes' >>>> -I'/home/mike/ghc-7.8.3/includes/dist-derivedconstants/header' -MM -x c >>>> compiler/parser/cutils.c -MF compiler/stage2/build/.depend-v.c_asm.bit >>>> gcc: error: unrecognized command line option ?-mthumb-interwork? >>>> gcc: error: unrecognized command line option ?-mfloat-abi=hard? >>>> gcc: error: unrecognized command line option ?-mfpu=neon? >>>> make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1 >>>> make: *** [all] Error 2 >>>> >>>> It is applying the -march? arguments to the local gcc. I am guessing >>>> that compiling for stage2 is using the local gcc because stage2 is only >>>> built when not making a cross compiler. >>>> >>>> Now, in build.mk I have: >>>> >>>> BuildFlavour = quick-cross >>>> >>>> Which is supposed to prevent stage2 compilation. >>>> >>>> Something is wrong. Either I need to stop stage2 compilation, if that is >>>> what this is really doing, or prevent gcc from using the extra >>>> arguments. But I see no reason to run gcc. Seems like that would only be >>>> used at stage0 if at all. >>>> >>>> Mike >>>> >>>> On Jul 14, 2014, at 10:12 AM, Karel Gardas >>> > wrote: >>>> >>>>>> On 07/14/14 04:58 PM, Michael Jones wrote: >>>>>> Karel, >>>>>> >>>>>> Thanks. This helps. >>>>>> >>>>>> If I understand, you have Linux running on a Panda, and on that Panda >>>>>> system you have gcc, and you compile GHC on the Panda itself, rather >>>>>> than build a cross compiler. I can see the advantage of building this >>>>>> way. >>>>> >>>>> Correct! >>>>> >>>>>> As far as cross compilers, I have a reason for trying to build a >>>>>> cross compiler, other than the ability to keep the image of the >>>>>> target small. That is, eventually, I want to be able to compile for >>>>>> an RTOS and/or bare iron system. I decided that learning to cross >>>>>> compile for Linux first would be a good approach. Learn the build >>>>>> system on something known to work. So I probably will not give up on >>>>>> that. >>>>> >>>>> That is right, in future I'd also like to give a try to port GHC to >>>>> some free RTOS and for this I'd need to use cross-compiling anyway, so >>>>> I'll be on the same boat... >>>>> >>>>>> I got a book on Autoconfig. I?ll just have to dig a level deeper into >>>>>> the whole build system. Mainly it means learning the M4 system. I >>>>>> have never used it. >>>>>> >>>>>> Below are the defines from the command you suggested. Thanks for >>>>>> that, got me over an ignorance hump. At least this define, >>>>>> __ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study >>>>>> the macros until I figure out what controls the gcc options passed to >>>>>> the gcc cross compiler. I guess my question is what actually controls >>>>>> this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt = >>>>>> [VFPv3,NEON], armABI = HARD}?)? >>>>>> >>>>>> Are these controlled by the defines below, or are they controlled by >>>>>> passing gcc arguments to the gcc compiler when the Haskell compiler >>>>>> calls gcc? >>>>> >>>>> Basically speaking all those are controlled by platform gcc. That >>>>> means if you pass the right option to your cross-compiling gcc you >>>>> should also get the same result, so for example if you use: >>>>> >>>>> gcc -mfloat-abi=hard -march=armv7-a -mfpu=vfpv3-d16 >>>>> >>>>> you should get the same settings like me. >>>>> >>>>> But anyway, please note that ABI you set to your cross-compiler *have >>>>> to* match the ABI provided by the target RTOS/OS! I hope that's clear. :-) >>>>> >>>>> Cheers, >>>>> Karel >>> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From karel.gardas at centrum.cz Sat Aug 2 17:15:08 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sat, 02 Aug 2014 19:15:08 +0200 Subject: Cross compiling for Cortex A9 In-Reply-To: <54DA8C80-0FC5-426B-889C-5C14BC24551C@proclivis.com> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> <53C394AE.4020303@centrum.cz> <67CEBBAE-CC1F-47CC-9A21-AA94C4A25149@proclivis.com> <53C4015D.9060009@centrum.cz> <4FC55335-526F-4007-BD0E-C8620DED6653@proclivis.com> <53DB5B98.5040500@centrum.cz> <54DA8C80-0FC5-426B-889C-5C14BC24551C@proclivis.com> Message-ID: <53DD1C9C.5080608@centrum.cz> IIRC, CFLAGS should be needed only for configure which should detect your architecture well and generate appropriate settings file. GHC itself should not use them IIRC. If you need something special, then you can use mk/build.mk But I'm not expert for cross-compiling GHC, nor for cross-compiling using GHC which is the reason why I recommended native compilation especially since this is possible and the least problematic way to go... Karel On 08/ 2/14 04:02 AM, Michael Jones wrote: > Karel, > > I think I proved that make dies early if CFLAGS has these options. The local gcc does not support ARM related flags. > > I am trying to build the tool chain with ?with-arch= and ?with-tune== so that it defaults to my target. This will bypass any GHC build issues. > > Mike > > On Aug 1, 2014, at 3:23 PM, Michael Jones wrote: > >> Karel, >> >> On CFLAGS.. >> >> When the cross compiler is compiled, does it use gcc, or is gcc only used to compile libraries with the stage-1 compiler? >> >> Because if gcc is used for both, I would need different flags for each, and I don't know how to make that happen. >> >> Mike >> >> Sent from my iPad >> >>> On Aug 1, 2014, at 3:19 AM, Karel Gardas wrote: >>> >>> >>> OK, so you do have ghc-stage1 which is a cross-compiler. Now, what does ghc-stage1 --info tell you? >>> >>> Aha, you hacked configure, hmm. I don't think this is needed especially if you use proper CFLAGS. >>> >>> Karel >>> >>>> On 07/25/14 06:00 AM, Michael Jones wrote: >>>> I have some progress, and a problem. First, note I am using the 7.8.3 >>>> tar ball, for this discussion here. >>>> >>>> If you read through, you will see a request for help at the end. It >>>> looks like the cross compilation is trying to build stage2 when it >>>> shouldn?t. >>>> >>>> In order to get the resulting stage1 cross compiler to have: >>>> >>>> ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], >>>> armABI = HARD}") >>>> >>>> I hacked this: >>>> >>>> AC_DEFUN([GET_ARM_ISA], >>>> [ >>>> changequote(, )dnl >>>> ARM_ISA=ARMv7 >>>> ARM_ISA_EXT="[VFPv3,NEON]" >>>> changequote([, ])dnl >>>> [ARM_ABI="HARD"] >>>> ]) >>>> >>>> Now, my gcc cross compiler does not default to ARMv7. To compile for my >>>> Cortex A, I add these options: >>>> >>>> -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon >>>> -mtune=cortex-a9 >>>> >>>> So I need to make sure that when building the libraries with stage1, it >>>> passes the correct options. To do that: >>>> >>>> AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], >>>> [ >>>> AC_MSG_CHECKING([Setting up $2, $3, $4 and $5]) >>>> ? >>>> arm-poky-*) >>>> $2="$$2 -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon >>>> -mtune=cortex-a9" >>>> ;; >>>> >>>> >>>> Which results in a stage1 compiler with: >>>> >>>> ,("C compiler flags"," -march=armv7-a -mthumb-interwork -mfloat-abi=hard >>>> -mfpu=neon -mtune=cortex-a9 -fno-stack-protector?) >>>> >>>> As the build proceeds, all calls to stage1 are completing. Then, the >>>> build gets to this point: >>>> >>>> "inplace/bin/mkdirhier" compiler/stage2/build//. >>>> "rm" -f compiler/stage2/build/Config.hs >>>> Creating compiler/stage2/build/Config.hs ... >>>> done. >>>> >>>> And I assume this means it is trying to build stage2. Correct me if I am >>>> wrong. >>>> >>>> Eventually I get a build failure like this: >>>> >>>> gcc -E -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -march=armv7-a >>>> -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 >>>> -fno-stack-protector -Icompiler/. -Icompiler/parser -Icompiler/utils >>>> -Icompiler/../rts/dist/build -Icompiler/stage2 -DGHCI >>>> -I'/home/mike/ghc-7.8.3/libraries/process/include' >>>> -I'/home/mike/ghc-7.8.3/libraries/directory/include' >>>> -I'/home/mike/ghc-7.8.3/libraries/unix/include' >>>> -I'/home/mike/ghc-7.8.3/libraries/time/include' >>>> -I'/home/mike/ghc-7.8.3/libraries/containers/include' >>>> -I'/home/mike/ghc-7.8.3/libraries/bytestring/include' >>>> -I'/home/mike/ghc-7.8.3/libraries/base/include' >>>> -I'/home/mike/ghc-7.8.3/rts/dist/build' >>>> -I'/home/mike/ghc-7.8.3/includes' >>>> -I'/home/mike/ghc-7.8.3/includes/dist-derivedconstants/header' -MM -x c >>>> compiler/parser/cutils.c -MF compiler/stage2/build/.depend-v.c_asm.bit >>>> gcc: error: unrecognized command line option ?-mthumb-interwork? >>>> gcc: error: unrecognized command line option ?-mfloat-abi=hard? >>>> gcc: error: unrecognized command line option ?-mfpu=neon? >>>> make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1 >>>> make: *** [all] Error 2 >>>> >>>> It is applying the -march? arguments to the local gcc. I am guessing >>>> that compiling for stage2 is using the local gcc because stage2 is only >>>> built when not making a cross compiler. >>>> >>>> Now, in build.mk I have: >>>> >>>> BuildFlavour = quick-cross >>>> >>>> Which is supposed to prevent stage2 compilation. >>>> >>>> Something is wrong. Either I need to stop stage2 compilation, if that is >>>> what this is really doing, or prevent gcc from using the extra >>>> arguments. But I see no reason to run gcc. Seems like that would only be >>>> used at stage0 if at all. >>>> >>>> Mike >>>> >>>> On Jul 14, 2014, at 10:12 AM, Karel Gardas>>> > wrote: >>>> >>>>>> On 07/14/14 04:58 PM, Michael Jones wrote: >>>>>> Karel, >>>>>> >>>>>> Thanks. This helps. >>>>>> >>>>>> If I understand, you have Linux running on a Panda, and on that Panda >>>>>> system you have gcc, and you compile GHC on the Panda itself, rather >>>>>> than build a cross compiler. I can see the advantage of building this >>>>>> way. >>>>> >>>>> Correct! >>>>> >>>>>> As far as cross compilers, I have a reason for trying to build a >>>>>> cross compiler, other than the ability to keep the image of the >>>>>> target small. That is, eventually, I want to be able to compile for >>>>>> an RTOS and/or bare iron system. I decided that learning to cross >>>>>> compile for Linux first would be a good approach. Learn the build >>>>>> system on something known to work. So I probably will not give up on >>>>>> that. >>>>> >>>>> That is right, in future I'd also like to give a try to port GHC to >>>>> some free RTOS and for this I'd need to use cross-compiling anyway, so >>>>> I'll be on the same boat... >>>>> >>>>>> I got a book on Autoconfig. I?ll just have to dig a level deeper into >>>>>> the whole build system. Mainly it means learning the M4 system. I >>>>>> have never used it. >>>>>> >>>>>> Below are the defines from the command you suggested. Thanks for >>>>>> that, got me over an ignorance hump. At least this define, >>>>>> __ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study >>>>>> the macros until I figure out what controls the gcc options passed to >>>>>> the gcc cross compiler. I guess my question is what actually controls >>>>>> this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt = >>>>>> [VFPv3,NEON], armABI = HARD}?)? >>>>>> >>>>>> Are these controlled by the defines below, or are they controlled by >>>>>> passing gcc arguments to the gcc compiler when the Haskell compiler >>>>>> calls gcc? >>>>> >>>>> Basically speaking all those are controlled by platform gcc. That >>>>> means if you pass the right option to your cross-compiling gcc you >>>>> should also get the same result, so for example if you use: >>>>> >>>>> gcc -mfloat-abi=hard -march=armv7-a -mfpu=vfpv3-d16 >>>>> >>>>> you should get the same settings like me. >>>>> >>>>> But anyway, please note that ABI you set to your cross-compiler *have >>>>> to* match the ABI provided by the target RTOS/OS! I hope that's clear. :-) >>>>> >>>>> Cheers, >>>>> Karel >>> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > From karel.gardas at centrum.cz Sat Aug 2 18:07:33 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sat, 02 Aug 2014 20:07:33 +0200 Subject: Cross compiling for Cortex A9 In-Reply-To: <1E342657-2166-40C2-93AF-2C231B353ADC@proclivis.com> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> <53C394AE.4020303@centrum.cz> <67CEBBAE-CC1F-47CC-9A21-AA94C4A25149@proclivis.com> <53C4015D.9060009@centrum.cz> <4FC55335-526F-4007-BD0E-C8620DED6653@proclivis.com> <53DB5B98.5040500@centrum.cz> <54DA8C80-0FC5-426B-889C-5C14BC24551C@proclivis.com> <1E342657-2166-40C2-93AF-2C231B353ADC@proclivis.com> Message-ID: <53DD28E5.9030906@centrum.cz> On 08/ 2/14 07:04 AM, Michael Jones wrote: > ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}") > ,("target word size","4") this looks good, but I hope you got it on clean tree, i.e. without your configure hack... Karel From haskell at benmachine.co.uk Sat Aug 2 20:54:57 2014 From: haskell at benmachine.co.uk (Ben Millwood) Date: Sat, 2 Aug 2014 21:54:57 +0100 Subject: Overlapping and incoherent instances In-Reply-To: <20140802195157.GB119560@srcf.ucam.org> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF2208260F@DB3PRD3001MB020.064d.mgd.msft.net> <20140802152714.GA119560@srcf.ucam.org> <20140802195157.GB119560@srcf.ucam.org> Message-ID: <20140802205457.GA157265@srcf.ucam.org> On Sat, Aug 02, 2014 at 08:51:57PM +0100, Ben Millwood wrote: >On Sat, Aug 02, 2014 at 04:27:14PM +0100, Ben Millwood wrote: >>On Thu, Jul 31, 2014 at 07:20:31AM +0000, Simon Peyton Jones wrote: >>>My main motivation was to signal the proposed deprecation of the global per-module flag -XoverlappingInstances. Happily people generally seem fine with this. It is, after all, precisely what deprecations are for ("the old thing still works for now, but it won't do so for ever, and you should change as soon as is convenient"). >> >>Here's one concern I have with the deprecation of >>-XOverlappingInstances: I don't like overlapping instances, I find >>them confusing and weird and prefer to use code that doesn't >>include them, because they violate my expectations about how type >>classes work. When there is a single LANGUAGE pragma, that's a >>simple, easily-checkable signpost of "this code uses techniques >>that Ben doesn't understand". When it is all controlled by pragmas >>I basically have to check every instance declaration individually. >> >>On a largely unrelated note, here's another thing I don't >>understand: when is OVERLAPPABLE at one instance declaration >>preferable to using only OVERLAPPING at the instance declarations >>that overlap it? In the latter model, as long as none of the >>instances I write have pragmas, I can be sure none of them overlap. >>In the former model, any instance I write for an existing typeclass >>might overlap another instance, even if I don't want it to. Do we >>have any specific use cases in mind for OVERLAPPABLE? >>_______________________________________________ >>Libraries mailing list >>Libraries at haskell.org >>http://www.haskell.org/mailman/listinfo/libraries > >When I originally sent this mail I wasn't subscribed to the GHC >lists, so I went and fixed that and am now resending. Good grief, and then I sent from the wrong address. Sorry for the noise. >Addendum: I was surprised by the behaviour of overlapping instances >when I went and looked closer at it. > > {-# LANGUAGE FlexibleInstances #-} > module M where > class C a where f :: a -> a > instance C a where f x = x > instance C Int where f x = x + 1 > >I suspect many people have the intuition that NoOverlappingInstances >should forbid the above, but in fact OverlappingInstances or no only >controls instance *resolution*. I imagine you all already knew this >but I did not until I carefully reread things. > >As someone who dislikes overlapping type class instances, I am >finding them harder to avoid than I at first thought :( From mike at proclivis.com Sat Aug 2 22:04:25 2014 From: mike at proclivis.com (Michael Jones) Date: Sat, 2 Aug 2014 16:04:25 -0600 Subject: Cross compiling for Cortex A9 In-Reply-To: <53DD28E5.9030906@centrum.cz> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> <53C394AE.4020303@centrum.cz> <67CEBBAE-CC1F-47CC-9A21-AA94C4A25149@proclivis.com> <53C4015D.9060009@centrum.cz> <4FC55335-526F-4007-BD0E-C8620DED6653@proclivis.com> <53DB5B98.5040500@centrum.cz> <54DA8C80-0FC5-426B-889C-5C14BC24551C@proclivis.com> <1E342657-2166-40C2-93AF-2C231B353ADC@proclivis.com> <53DD28E5.9030906@centrum.cz> Message-ID: Karel, My configure hack is now limited to two hacks on GHC 7.8.3. The vendor ?pokey", and the ARM settings that make the target architecture correct. I also enabled profiling in build.mk. So pretty clean. No compiler options. GHC compiles clean. I am getting a stack overflow during execution of the hello world applicaiton. I compiled like: arm-poky-linux-gnueabi-ghc -static -debug -auto-all -caf-all -prof Main.hs I ran on the target like: ./Main +RTS -Ds -Di -Db -DS -Dt -Da 2>log I attached a log. Search for overflow. created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 126 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 126 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 125 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 124 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 123 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 122 blocks free block list [7]: free block list [8]: new task (taskCount: 1) cap 0: created thread 1 new bound thread (1) cap 0: schedule() cap 0: running thread 1 (ThreadRunGHC) stg_ap_v_ret... PAP/1(0x5ba25a, 0x5a3670) stg_ap_0_ret... base:GHC.MVar.MVar(0x76c020d4) stg_ap_v_ret... (0xa964, CAF:main) stg_ap_v_ret... PAP/1(0x5bce1a, 0x76c02160) stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c021a9, 0x76c0219a) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c023be) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) stg_ap_0_ret... base:GHC.IO.Encoding.Types.TextEncoding(0x5aadd0, 0x76c026c5, 0x76c02665) stg_ap_v_ret... (0x59458, CAF) stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c029a1, 0x76c02992) stg_ap_0_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_0_ret... base:GHC.IO.Encoding.Types.TextEncoding(0x5aadd0, 0x76c02aa1, 0x76c02a41) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c02b40) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023ad, 0x76c02ba8) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02389, 0x76c02c10) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02365, 0x76c02c78) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02341, 0x76c02ce0) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c0231d, 0x76c02d48) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022f9, 0x76c02db0) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022d5, 0x76c02e18) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022b1, 0x76c02e80) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c0228d, 0x76c02ee8) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02269, 0x76c02f50) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02245, 0x76c02fb8) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02221, 0x76c0502c) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c021fd, 0x76c05094) stg_ap_0_ret... ghc-prim:GHC.Types.[]() stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02b14) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02b7c) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02be4) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02c4c) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02cb4) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02d1c) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02d84) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02dec) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02e54) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02ebc) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02f24) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02f8c) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05000) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05068) stg_ap_0_ret... ghc-prim:GHC.Types.[]() stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) cap 0: thread 1 stopped (stack overflow) On Aug 2, 2014, at 12:07 PM, Karel Gardas wrote: > On 08/ 2/14 07:04 AM, Michael Jones wrote: > >> ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}") >> ,("target word size","4") > > this looks good, but I hope you got it on clean tree, i.e. without your configure hack... > > Karel From mike at proclivis.com Mon Aug 4 14:23:35 2014 From: mike at proclivis.com (Michael Jones) Date: Mon, 4 Aug 2014 08:23:35 -0600 Subject: Cross compiling for Cortex A9 In-Reply-To: References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> <53C394AE.4020303@centrum.cz> <67CEBBAE-CC1F-47CC-9A21-AA94C4A25149@proclivis.com> <53C4015D.9060009@centrum.cz> <4FC55335-526F-4007-BD0E-C8620DED6653@proclivis.com> <53DB5B98.5040500@centrum.cz> <54DA8C80-0FC5-426B-889C-5C14BC24551C@proclivis.com> <1E342657-2166-40C2-93AF-2C231B353ADC@proclivis.com> <53DD28E5.9030906@centrum.cz> Message-ID: To be complete, there is an old link on compiling for arm, and it recommends this build process: $ chmod ugo+rx build-ghc-arm.sh Edit build-ghc-arm.sh to fix EOF $ ./build-ghc-arm.sh -j4 $ make test $ sudo make install $ arm-poky-linux-gnueabi-ghc --info This way of building produces the same result as below. So I am guessing that problems that this fixed moons ago no longer exist, or produce different problems that are masked. What will help me, not knowing the RTS, is if anyone can recognize the failure pattern and give me some hints where in the code the problem might be. That way I can add some logging specifically related to the problem to get more data, and limit my study of the RTS code to a specific set of files. My other thought is if there is some test code that might help reveal the problem. Something that if it runs, and the log is clean, perhaps eliminates possible problems. The RTS is able to write a log via stdio, so that could be exploited to run test code that can log information. But the hello world fails to write to stdio. So perhaps the problem occurs in the start up phase where the thread is created and things go wrong before hello world is executed. This would suggest any test code would have to be run within the RTS itself. Is there some way to enable some ASSERTIONS within RTS that would help narrow down the problem? Also, is there any way to compile up something small to run the RTS without any Haskell libraries, etc, so and debug it with a C/C++ debugger? I am able to debug other C/C++ programs on the target device, so if I had a C/C++ program, code, etc, I could run and debug it. Mike On Aug 2, 2014, at 4:04 PM, Michael Jones wrote: > Karel, > > My configure hack is now limited to two hacks on GHC 7.8.3. The vendor ?pokey", and the ARM settings that make the target architecture correct. I also enabled profiling in build.mk. So pretty clean. No compiler options. GHC compiles clean. > > I am getting a stack overflow during execution of the hello world applicaiton. I compiled like: > > arm-poky-linux-gnueabi-ghc -static -debug -auto-all -caf-all -prof Main.hs > > I ran on the target like: > > ./Main +RTS -Ds -Di -Db -DS -Dt -Da 2>log > > I attached a log. Search for overflow. > > created capset 0 of type 2 > created capset 1 of type 3 > cap 0: initialised > assigned cap 0 to capset 0 > assigned cap 0 to capset 1 > free block list [0]: > free block list [1]: > free block list [2]: > free block list [3]: > free block list [4]: > free block list [5]: > free block list [6]: > group at 0x76c82000, length 126 blocks > free block list [7]: > free block list [8]: > free block list [0]: > free block list [1]: > free block list [2]: > free block list [3]: > free block list [4]: > free block list [5]: > free block list [6]: > group at 0x76c82000, length 126 blocks > free block list [7]: > free block list [8]: > free block list [0]: > free block list [1]: > free block list [2]: > free block list [3]: > free block list [4]: > free block list [5]: > free block list [6]: > group at 0x76c82000, length 125 blocks > free block list [7]: > free block list [8]: > free block list [0]: > free block list [1]: > free block list [2]: > free block list [3]: > free block list [4]: > free block list [5]: > free block list [6]: > group at 0x76c82000, length 124 blocks > free block list [7]: > free block list [8]: > free block list [0]: > free block list [1]: > free block list [2]: > free block list [3]: > free block list [4]: > free block list [5]: > free block list [6]: > group at 0x76c82000, length 123 blocks > free block list [7]: > free block list [8]: > free block list [0]: > free block list [1]: > free block list [2]: > free block list [3]: > free block list [4]: > free block list [5]: > free block list [6]: > group at 0x76c82000, length 122 blocks > free block list [7]: > free block list [8]: > new task (taskCount: 1) > cap 0: created thread 1 > new bound thread (1) > cap 0: schedule() > cap 0: running thread 1 (ThreadRunGHC) > stg_ap_v_ret... PAP/1(0x5ba25a, 0x5a3670) > stg_ap_0_ret... base:GHC.MVar.MVar(0x76c020d4) > stg_ap_v_ret... (0xa964, CAF:main) > stg_ap_v_ret... PAP/1(0x5bce1a, 0x76c02160) > stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c021a9, 0x76c0219a) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c023be) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > stg_ap_0_ret... base:GHC.IO.Encoding.Types.TextEncoding(0x5aadd0, 0x76c026c5, 0x76c02665) > stg_ap_v_ret... (0x59458, CAF) > stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c029a1, 0x76c02992) > stg_ap_0_ret... FUN/1(0x59088, CAF, 0x76c02980) > stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) > stg_ap_0_ret... base:GHC.IO.Encoding.Types.TextEncoding(0x5aadd0, 0x76c02aa1, 0x76c02a41) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c02b40) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023ad, 0x76c02ba8) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02389, 0x76c02c10) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02365, 0x76c02c78) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02341, 0x76c02ce0) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c0231d, 0x76c02d48) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022f9, 0x76c02db0) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022d5, 0x76c02e18) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022b1, 0x76c02e80) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c0228d, 0x76c02ee8) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02269, 0x76c02f50) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02245, 0x76c02fb8) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02221, 0x76c0502c) > stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c021fd, 0x76c05094) > stg_ap_0_ret... ghc-prim:GHC.Types.[]() > stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02b14) > stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02b7c) > stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02be4) > stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02c4c) > stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02cb4) > stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02d1c) > stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02d84) > stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02dec) > stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02e54) > stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02ebc) > stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02f24) > stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02f8c) > stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05000) > stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05068) > stg_ap_0_ret... ghc-prim:GHC.Types.[]() > stg_ap_v_ret... IND_STATIC(0x76c0360c) > stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) > stg_ap_v_ret... IND_STATIC(0x76c0360c) > stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) > stg_ap_v_ret... IND_STATIC(0x76c0360c) > stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) > stg_ap_v_ret... IND_STATIC(0x76c0360c) > stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) > stg_ap_v_ret... IND_STATIC(0x76c0360c) > stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) > stg_ap_v_ret... IND_STATIC(0x76c0360c) > stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) > cap 0: thread 1 stopped (stack overflow) > On Aug 2, 2014, at 12:07 PM, Karel Gardas wrote: > >> On 08/ 2/14 07:04 AM, Michael Jones wrote: >> >>> ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}") >>> ,("target word size","4") >> >> this looks good, but I hope you got it on clean tree, i.e. without your configure hack... >> >> Karel > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From mike at proclivis.com Tue Aug 5 14:23:48 2014 From: mike at proclivis.com (Michael Jones) Date: Tue, 5 Aug 2014 08:23:48 -0600 Subject: Cross compiling for Cortex A9 In-Reply-To: References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> <53C394AE.4020303@centrum.cz> <67CEBBAE-CC1F-47CC-9A21-AA94C4A25149@proclivis.com> <53C4015D.9060009@centrum.cz> <4FC55335-526F-4007-BD0E-C8620DED6653@proclivis.com> <53DB5B98.5040500@centrum.cz> <54DA8C80-0FC5-426B-889C-5C14BC24551C@proclivis.com> <1E342657-2166-40C2-93AF-2C231B353ADC@proclivis.com> <53DD28E5.9030906@centrum.cz> Message-ID: I ran the same program on my dev linux and compared it to see if there were clues. On my dev box (Ubuntu) here are some snippets of the log (working app) new task (taskCount: 1) cap 0: created thread 1 new bound thread (1) cap 0: schedule() cap 0: running thread 1 (ThreadRunGHC) New weak pointer at 0x7f7788704050 stg_ap_0_ret... base:GHC.MVar.MVar(0x7f7788704148) stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x7f7788704281, 0x7f7788704272) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x7f7788704421, 0x7f778870440a) New weak pointer at 0x7f7788706188 stg_ap_0_ret... base:GHC.IO.Handle.Types.FileHandle(0x6d4080, 0x7f77887060b0) And on the failing embedded target: new task (taskCount: 1) cap 0: created thread 1 new bound thread (1) cap 0: schedule() cap 0: running thread 1 (ThreadRunGHC) New weak pointer at 0x76c02038 stg_ap_0_ret... base:GHC.MVar.MVar(0x76c020d4) stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c021a9, 0x76c0219a) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c023be) stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c029a1, 0x76c02992) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05068) stg_ap_0_ret... ghc-prim:GHC.Types.[]() stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) cap 0: thread 1 stopped (stack overflow) A couple of things are different in the failing target. First, the thread yields, and then is allowed to run, whereas on Ubuntu it just runs to completion. Second, there is a second set of primitive calls: stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c029a1, 0x76c02992) stg_ap_0_ret... ghc-prim:GHC.Types.[]() cap 0: thread 1 stopped (stack overflow) And this is followed by the stack overflow. These two calls are not present when run on Ubuntu. The original source is: module Main where main::IO() main = putStr "Hello world!? As a reminder, the difference is: Working: Standard GHC on Ubuntu Failing: Cross compiled for Cortex A and run on Wandboard with Yocto Linux Do these extra two calls give any clues to the cause of the stack flow? The other thing to note, is the working version eventually gets to various IO calls. These are never reached in the failing version. So it seems to be choking in the type system code before it gets to IO. Is there a test program that could be run that might narrow down the problem? Mike On Aug 4, 2014, at 8:23 AM, Michael Jones wrote: > To be complete, there is an old link on compiling for arm, and it recommends this build process: > > $ chmod ugo+rx build-ghc-arm.sh > Edit build-ghc-arm.sh to fix EOF > $ ./build-ghc-arm.sh -j4 > $ make test > $ sudo make install > $ arm-poky-linux-gnueabi-ghc --info > > This way of building produces the same result as below. So I am guessing that problems that this fixed moons ago no longer exist, or produce different problems that are masked. > > What will help me, not knowing the RTS, is if anyone can recognize the failure pattern and give me some hints where in the code the problem might be. That way I can add some logging specifically related to the problem to get more data, and limit my study of the RTS code to a specific set of files. > > My other thought is if there is some test code that might help reveal the problem. Something that if it runs, and the log is clean, perhaps eliminates possible problems. The RTS is able to write a log via stdio, so that could be exploited to run test code that can log information. But the hello world fails to write to stdio. So perhaps the problem occurs in the start up phase where the thread is created and things go wrong before hello world is executed. This would suggest any test code would have to be run within the RTS itself. Is there some way to enable some ASSERTIONS within RTS that would help narrow down the problem? > > Also, is there any way to compile up something small to run the RTS without any Haskell libraries, etc, so and debug it with a C/C++ debugger? I am able to debug other C/C++ programs on the target device, so if I had a C/C++ program, code, etc, I could run and debug it. > > Mike > > > On Aug 2, 2014, at 4:04 PM, Michael Jones wrote: > >> Karel, >> >> My configure hack is now limited to two hacks on GHC 7.8.3. The vendor ?pokey", and the ARM settings that make the target architecture correct. I also enabled profiling in build.mk. So pretty clean. No compiler options. GHC compiles clean. >> >> I am getting a stack overflow during execution of the hello world applicaiton. I compiled like: >> >> arm-poky-linux-gnueabi-ghc -static -debug -auto-all -caf-all -prof Main.hs >> >> I ran on the target like: >> >> ./Main +RTS -Ds -Di -Db -DS -Dt -Da 2>log >> >> I attached a log. Search for overflow. >> >> created capset 0 of type 2 >> created capset 1 of type 3 >> cap 0: initialised >> assigned cap 0 to capset 0 >> assigned cap 0 to capset 1 >> free block list [0]: >> free block list [1]: >> free block list [2]: >> free block list [3]: >> free block list [4]: >> free block list [5]: >> free block list [6]: >> group at 0x76c82000, length 126 blocks >> free block list [7]: >> free block list [8]: >> free block list [0]: >> free block list [1]: >> free block list [2]: >> free block list [3]: >> free block list [4]: >> free block list [5]: >> free block list [6]: >> group at 0x76c82000, length 126 blocks >> free block list [7]: >> free block list [8]: >> free block list [0]: >> free block list [1]: >> free block list [2]: >> free block list [3]: >> free block list [4]: >> free block list [5]: >> free block list [6]: >> group at 0x76c82000, length 125 blocks >> free block list [7]: >> free block list [8]: >> free block list [0]: >> free block list [1]: >> free block list [2]: >> free block list [3]: >> free block list [4]: >> free block list [5]: >> free block list [6]: >> group at 0x76c82000, length 124 blocks >> free block list [7]: >> free block list [8]: >> free block list [0]: >> free block list [1]: >> free block list [2]: >> free block list [3]: >> free block list [4]: >> free block list [5]: >> free block list [6]: >> group at 0x76c82000, length 123 blocks >> free block list [7]: >> free block list [8]: >> free block list [0]: >> free block list [1]: >> free block list [2]: >> free block list [3]: >> free block list [4]: >> free block list [5]: >> free block list [6]: >> group at 0x76c82000, length 122 blocks >> free block list [7]: >> free block list [8]: >> new task (taskCount: 1) >> cap 0: created thread 1 >> new bound thread (1) >> cap 0: schedule() >> cap 0: running thread 1 (ThreadRunGHC) >> stg_ap_v_ret... PAP/1(0x5ba25a, 0x5a3670) >> stg_ap_0_ret... base:GHC.MVar.MVar(0x76c020d4) >> stg_ap_v_ret... (0xa964, CAF:main) >> stg_ap_v_ret... PAP/1(0x5bce1a, 0x76c02160) >> stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c021a9, 0x76c0219a) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c023be) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> stg_ap_0_ret... base:GHC.IO.Encoding.Types.TextEncoding(0x5aadd0, 0x76c026c5, 0x76c02665) >> stg_ap_v_ret... (0x59458, CAF) >> stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c029a1, 0x76c02992) >> stg_ap_0_ret... FUN/1(0x59088, CAF, 0x76c02980) >> stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) >> stg_ap_0_ret... base:GHC.IO.Encoding.Types.TextEncoding(0x5aadd0, 0x76c02aa1, 0x76c02a41) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c02b40) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023ad, 0x76c02ba8) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02389, 0x76c02c10) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02365, 0x76c02c78) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02341, 0x76c02ce0) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c0231d, 0x76c02d48) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022f9, 0x76c02db0) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022d5, 0x76c02e18) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022b1, 0x76c02e80) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c0228d, 0x76c02ee8) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02269, 0x76c02f50) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02245, 0x76c02fb8) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02221, 0x76c0502c) >> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c021fd, 0x76c05094) >> stg_ap_0_ret... ghc-prim:GHC.Types.[]() >> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02b14) >> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02b7c) >> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02be4) >> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02c4c) >> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02cb4) >> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02d1c) >> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02d84) >> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02dec) >> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02e54) >> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02ebc) >> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02f24) >> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02f8c) >> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05000) >> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05068) >> stg_ap_0_ret... ghc-prim:GHC.Types.[]() >> stg_ap_v_ret... IND_STATIC(0x76c0360c) >> stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) >> stg_ap_v_ret... IND_STATIC(0x76c0360c) >> stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) >> stg_ap_v_ret... IND_STATIC(0x76c0360c) >> stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) >> stg_ap_v_ret... IND_STATIC(0x76c0360c) >> stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) >> stg_ap_v_ret... IND_STATIC(0x76c0360c) >> stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) >> stg_ap_v_ret... IND_STATIC(0x76c0360c) >> stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) >> cap 0: thread 1 stopped (stack overflow) >> On Aug 2, 2014, at 12:07 PM, Karel Gardas wrote: >> >>> On 08/ 2/14 07:04 AM, Michael Jones wrote: >>> >>>> ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}") >>>> ,("target word size","4") >>> >>> this looks good, but I hope you got it on clean tree, i.e. without your configure hack... >>> >>> Karel >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From verteiler at volker-wysk.de Tue Aug 5 16:41:05 2014 From: verteiler at volker-wysk.de (Volker Wysk) Date: Tue, 05 Aug 2014 18:41:05 +0200 Subject: Old code broken by new Typeable class Message-ID: <2650082.EBpa3z9bMv@debian> Hi! I've been working with GHC-4.6.3, and updating to GHC-4.8.3 breaks my code, because the Typeable class has been changed. The compiler produces this message: --------- src/HsShellScript/ProcErr.chs:2294:4: ?typeOf? is not a (visible) method of class ?Typeable? --------- I want to define System.Posix.Process.ProcessStatus to be an instance of Typeable, so I can throw and catch it as an exception. ProcessStatus isn't typeable by default. Is it still possible to make ProcessStatus a member of Typeable? How? Obviously, you can't accomplish it by deriving Typeable, because the definition can't be changed any longer. This is the spot in question: ---------- import System.Posix.Process import Data.Typeable {- data ProcessStatus = Exited ExitCode / | Terminated Signal/ / | Stopped Signal/ deriving (Eq, Ord, Show) -} instance Typeable ProcessStatus where typeOf = const tyCon_ProcessStatus tyCon_ProcessStatus = mkTyConApp (mkTyCon3 "hsshellscript" "HsShellScript.ProcErr" "Posix.ProcessStatus") [] instance Exception ProcessStatus ---------- Thanks, V.W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Aug 5 16:46:23 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 5 Aug 2014 12:46:23 -0400 Subject: Old code broken by new Typeable class In-Reply-To: <2650082.EBpa3z9bMv@debian> References: <2650082.EBpa3z9bMv@debian> Message-ID: i assume 7.6 and 7.8, if we're talking GHC rather than GCC :) in 7.8 you can't define userland typeable instances, you need only write deriving (Typeable) and you're all set. add some CPP to select the instances suitable On Tue, Aug 5, 2014 at 12:41 PM, Volker Wysk wrote: > Hi! > > I've been working with GHC-4.6.3, and updating to GHC-4.8.3 breaks my > code, > > because the Typeable class has been changed. The compiler produces this > > message: > > --------- > > src/HsShellScript/ProcErr.chs:2294:4: > > ?typeOf? is not a (visible) method of class ?Typeable? > > --------- > > I want to define System.Posix.Process.ProcessStatus to be an instance of > > Typeable, so I can throw and catch it as an exception. ProcessStatus isn't > > typeable by default. > > Is it still possible to make ProcessStatus a member of Typeable? How? > > Obviously, you can't accomplish it by deriving Typeable, because the > definition > > can't be changed any longer. > > This is the spot in question: > > ---------- > > import System.Posix.Process > > import Data.Typeable > > {- > > data ProcessStatus = Exited ExitCode > > | Terminated Signal > > | Stopped Signal > > deriving (Eq, Ord, Show) > > -} > > instance Typeable ProcessStatus where > > typeOf = const tyCon_ProcessStatus > > tyCon_ProcessStatus = mkTyConApp (mkTyCon3 "hsshellscript" > > "HsShellScript.ProcErr" > > "Posix.ProcessStatus") [] > > instance Exception ProcessStatus > > ---------- > > Thanks, > > V.W. > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Aug 5 16:49:29 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 5 Aug 2014 12:49:29 -0400 Subject: Old code broken by new Typeable class In-Reply-To: References: <2650082.EBpa3z9bMv@debian> Message-ID: more concretely #if defined(__GLASGOW_HASKELL__) && ( __GLASGOW_HASKELL__ >= 707) --- do the deriving version here #else --- your current stuff #endif On Tue, Aug 5, 2014 at 12:46 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > i assume 7.6 and 7.8, if we're talking GHC rather than GCC :) > > in 7.8 you can't define userland typeable instances, you need only write > deriving (Typeable) and you're all set. > add some CPP to select the instances suitable > > > On Tue, Aug 5, 2014 at 12:41 PM, Volker Wysk > wrote: > >> Hi! >> >> I've been working with GHC-4.6.3, and updating to GHC-4.8.3 breaks my >> code, >> >> because the Typeable class has been changed. The compiler produces this >> >> message: >> >> --------- >> >> src/HsShellScript/ProcErr.chs:2294:4: >> >> ?typeOf? is not a (visible) method of class ?Typeable? >> >> --------- >> >> I want to define System.Posix.Process.ProcessStatus to be an instance of >> >> Typeable, so I can throw and catch it as an exception. ProcessStatus >> isn't >> >> typeable by default. >> >> Is it still possible to make ProcessStatus a member of Typeable? How? >> >> Obviously, you can't accomplish it by deriving Typeable, because the >> definition >> >> can't be changed any longer. >> >> This is the spot in question: >> >> ---------- >> >> import System.Posix.Process >> >> import Data.Typeable >> >> {- >> >> data ProcessStatus = Exited ExitCode >> >> | Terminated Signal >> >> | Stopped Signal >> >> deriving (Eq, Ord, Show) >> >> -} >> >> instance Typeable ProcessStatus where >> >> typeOf = const tyCon_ProcessStatus >> >> tyCon_ProcessStatus = mkTyConApp (mkTyCon3 "hsshellscript" >> >> "HsShellScript.ProcErr" >> >> "Posix.ProcessStatus") [] >> >> instance Exception ProcessStatus >> >> ---------- >> >> Thanks, >> >> V.W. >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Tue Aug 5 17:04:56 2014 From: vogt.adam at gmail.com (adam vogt) Date: Tue, 5 Aug 2014 13:04:56 -0400 Subject: Old code broken by new Typeable class In-Reply-To: References: <2650082.EBpa3z9bMv@debian> Message-ID: Hi Volker, You can use this extension: http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#stand-alone-deriving to write that orphan Typeable instance for most ghcs (probably 6.10 is the earliest). It might be worth pushing for a Typeable instance to be added to the unix package (here: http://hackage.haskell.org/package/unix-2.7.0.1/docs/System-Posix-Process.html#t:ProcessStatus, with Carter's code): somebody else might define the same orphan instance too, which will break programs that end up seeing both instances. Regards, Adam On Tue, Aug 5, 2014 at 12:49 PM, Carter Schonwald wrote: > more concretely > #if defined(__GLASGOW_HASKELL__) && ( __GLASGOW_HASKELL__ >= 707) > --- do the deriving version here > #else > --- your current stuff > #endif > > > On Tue, Aug 5, 2014 at 12:46 PM, Carter Schonwald > wrote: >> >> i assume 7.6 and 7.8, if we're talking GHC rather than GCC :) >> >> in 7.8 you can't define userland typeable instances, you need only write >> deriving (Typeable) and you're all set. >> add some CPP to select the instances suitable >> >> >> On Tue, Aug 5, 2014 at 12:41 PM, Volker Wysk >> wrote: >>> >>> Hi! >>> >>> I've been working with GHC-4.6.3, and updating to GHC-4.8.3 breaks my >>> code, >>> >>> because the Typeable class has been changed. The compiler produces this >>> >>> message: >>> >>> --------- >>> >>> src/HsShellScript/ProcErr.chs:2294:4: >>> >>> ?typeOf? is not a (visible) method of class ?Typeable? >>> >>> --------- >>> >>> I want to define System.Posix.Process.ProcessStatus to be an instance of >>> >>> Typeable, so I can throw and catch it as an exception. ProcessStatus >>> isn't >>> >>> typeable by default. >>> >>> Is it still possible to make ProcessStatus a member of Typeable? How? >>> >>> Obviously, you can't accomplish it by deriving Typeable, because the >>> definition >>> >>> can't be changed any longer. >>> >>> This is the spot in question: >>> >>> ---------- >>> >>> import System.Posix.Process >>> >>> import Data.Typeable >>> >>> {- >>> >>> data ProcessStatus = Exited ExitCode >>> >>> | Terminated Signal >>> >>> | Stopped Signal >>> >>> deriving (Eq, Ord, Show) >>> >>> -} >>> >>> instance Typeable ProcessStatus where >>> >>> typeOf = const tyCon_ProcessStatus >>> >>> tyCon_ProcessStatus = mkTyConApp (mkTyCon3 "hsshellscript" >>> >>> "HsShellScript.ProcErr" >>> >>> "Posix.ProcessStatus") [] >>> >>> instance Exception ProcessStatus >>> >>> ---------- >>> >>> Thanks, >>> >>> V.W. >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From verteiler at volker-wysk.de Tue Aug 5 17:47:42 2014 From: verteiler at volker-wysk.de (Volker Wysk) Date: Tue, 05 Aug 2014 19:47:42 +0200 Subject: Old code broken by new Typeable class In-Reply-To: References: <2650082.EBpa3z9bMv@debian> Message-ID: <4549377.G6a3rSn4ka@debian> Am Dienstag, 5. August 2014, 12:46:23 schrieb Carter Schonwald: > i assume 7.6 and 7.8, if we're talking GHC rather than GCC :) > > in 7.8 you can't define userland typeable instances, you need only write > deriving (Typeable) and you're all set. > add some CPP to select the instances suitable So you need to be able to change the definition of the data type, in order to add deriving (Typeable). It's not possible to add a Typeable instance declaration later. When you can't change the definition, you're out of luck. Okay, V.W. From verteiler at volker-wysk.de Tue Aug 5 17:51:07 2014 From: verteiler at volker-wysk.de (Volker Wysk) Date: Tue, 05 Aug 2014 19:51:07 +0200 Subject: Old code broken by new Typeable class In-Reply-To: References: <2650082.EBpa3z9bMv@debian> Message-ID: <4198102.pbhypUMQBr@debian> Am Dienstag, 5. August 2014, 12:49:29 schrieb Carter Schonwald: > more concretely > #if defined(__GLASGOW_HASKELL__) && ( __GLASGOW_HASKELL__ >= 707) > --- do the deriving version here I can't do a deriving version, because ProcessStatus is part of the GHC libraries (System.Posix.Process). Its definition can't be changed. > #else > --- your current stuff > #endif Cheers, V.W. From allbery.b at gmail.com Tue Aug 5 17:59:26 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 5 Aug 2014 13:59:26 -0400 Subject: Old code broken by new Typeable class In-Reply-To: <4549377.G6a3rSn4ka@debian> References: <2650082.EBpa3z9bMv@debian> <4549377.G6a3rSn4ka@debian> Message-ID: On Tue, Aug 5, 2014 at 1:47 PM, Volker Wysk wrote: > Am Dienstag, 5. August 2014, 12:46:23 schrieb Carter Schonwald: > > i assume 7.6 and 7.8, if we're talking GHC rather than GCC :) > > > > in 7.8 you can't define userland typeable instances, you need only write > > deriving (Typeable) and you're all set. > > add some CPP to select the instances suitable > > So you need to be able to change the definition of the data type, in order > to > add deriving (Typeable). It's not possible to add a Typeable instance > declaration later. > Are you sure? There is a standalone deriving syntax. deriving instance Typeable ProcessStatus http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#stand-alone-deriving -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Aug 5 18:03:01 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 5 Aug 2014 14:03:01 -0400 Subject: Old code broken by new Typeable class In-Reply-To: References: <2650082.EBpa3z9bMv@debian> <4549377.G6a3rSn4ka@debian> Message-ID: thats what i meant. I meant you can't WRITE the body of a typeable in 7.8, you can derive though On Tue, Aug 5, 2014 at 1:59 PM, Brandon Allbery wrote: > On Tue, Aug 5, 2014 at 1:47 PM, Volker Wysk > wrote: > >> Am Dienstag, 5. August 2014, 12:46:23 schrieb Carter Schonwald: >> > i assume 7.6 and 7.8, if we're talking GHC rather than GCC :) >> > >> > in 7.8 you can't define userland typeable instances, you need only write >> > deriving (Typeable) and you're all set. >> > add some CPP to select the instances suitable >> >> So you need to be able to change the definition of the data type, in >> order to >> add deriving (Typeable). It's not possible to add a Typeable instance >> declaration later. >> > > Are you sure? There is a standalone deriving syntax. > > deriving instance Typeable ProcessStatus > > > http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#stand-alone-deriving > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From verteiler at volker-wysk.de Tue Aug 5 18:33:15 2014 From: verteiler at volker-wysk.de (Volker Wysk) Date: Tue, 05 Aug 2014 20:33:15 +0200 Subject: Old code broken by new Typeable class In-Reply-To: References: <2650082.EBpa3z9bMv@debian> <4549377.G6a3rSn4ka@debian> Message-ID: <3082453.WePp7yeNyI@debian> Am Dienstag, 5. August 2014, 13:59:26 schrieb Brandon Allbery: > On Tue, Aug 5, 2014 at 1:47 PM, Volker Wysk > > So you need to be able to change the definition of the data type, in order > > to > > add deriving (Typeable). It's not possible to add a Typeable instance > > declaration later. > > Are you sure? There is a standalone deriving syntax. > > deriving instance Typeable ProcessStatus Yes, that's the solution. You need these options for GHC: -XStandaloneDeriving -XDeriveDataTypeable Thanks, and Bye, V.W. From ekmett at gmail.com Tue Aug 5 19:29:21 2014 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 5 Aug 2014 15:29:21 -0400 Subject: Old code broken by new Typeable class In-Reply-To: <4549377.G6a3rSn4ka@debian> References: <2650082.EBpa3z9bMv@debian> <4549377.G6a3rSn4ka@debian> Message-ID: If you can't change the definition you can use the syntax Bj?rn Bringert added back in 2006 or so for StandaloneDeriving. Just turn on {-# LANGUAGE StandaloneDeriving, DeriveDataTypeable #-} and then you can use deriving instance Typeable Foo -Edward On Tue, Aug 5, 2014 at 1:47 PM, Volker Wysk wrote: > Am Dienstag, 5. August 2014, 12:46:23 schrieb Carter Schonwald: > > i assume 7.6 and 7.8, if we're talking GHC rather than GCC :) > > > > in 7.8 you can't define userland typeable instances, you need only write > > deriving (Typeable) and you're all set. > > add some CPP to select the instances suitable > > So you need to be able to change the definition of the data type, in order > to > add deriving (Typeable). It's not possible to add a Typeable instance > declaration later. > > When you can't change the definition, you're out of luck. > > Okay, > V.W. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Aug 5 21:05:28 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 5 Aug 2014 21:05:28 +0000 Subject: Overlapping and incoherent instances In-Reply-To: <20140802205457.GA157265@srcf.ucam.org> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF2208260F@DB3PRD3001MB020.064d.mgd.msft.net> <20140802152714.GA119560@srcf.ucam.org> <20140802195157.GB119560@srcf.ucam.org> <20140802205457.GA157265@srcf.ucam.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF220981A1@DB3PRD3001MB020.064d.mgd.msft.net> | >>Here's one concern I have with the deprecation of | >>-XOverlappingInstances: I don't like overlapping instances, I find | >>them confusing and weird and prefer to use code that doesn't | >>include them, because they violate my expectations about how type | >>classes work. When there is a single LANGUAGE pragma, that's a | >>simple, easily-checkable signpost of "this code uses techniques | >>that Ben doesn't understand". When it is all controlled by pragmas | >>I basically have to check every instance declaration individually. I see your point. Though you could just grep for OVERLAP! I suppose that -XOverlappingInstances could mean "silently honour OVERLAPPABLE/OVERLAPPING pragmas", while lacking it would mean "honour OVERLAPPABLE/OVERLAPPING pragmas, but emit noisy warnings" or even "don't honour them and warn". But that is different to the behaviour today, so we'd need a new LANGUAGE pragma. Perhaps -XHonourOverlappingInstances or something. My sense is that the extra faff is not worth it. | >>On a largely unrelated note, here's another thing I don't | >>understand: when is OVERLAPPABLE at one instance declaration | >>preferable to using only OVERLAPPING at the instance declarations | >>that overlap it? It's a user decision. GHC allows - OVERLAPPABLE at the instance that is being overlapped, or - OVERLAPPING at the instance that is doing the overlapping, or - both Another possible choice would be to require both. One or t'other wouldn't do. But the current choice (with the LANGUAGE pragmas -XOverlappingInstances) is the either/or choice, and I had no user pressure to change that. There *is* user pressure for the either/or semantics, so that you can *later* add an un-anticipated OVERLAPPING instance. | > {-# LANGUAGE FlexibleInstances #-} | > module M where | > class C a where f :: a -> a | > instance C a where f x = x | > instance C Int where f x = x + 1 | > | >I suspect many people have the intuition that NoOverlappingInstances | >should forbid the above, but in fact OverlappingInstances or no only | >controls instance *resolution*. I imagine you all already knew this | >but I did not until I carefully reread things. It's pretty clearly stated in the manual, but I'd be delighted to add a paragraph or two, or an example, if you can draft something and say where a good place for it would be (ie where you'd have looked). Thanks Simon From cheater00 at gmail.com Wed Aug 6 14:18:04 2014 From: cheater00 at gmail.com (cheater00 .) Date: Wed, 6 Aug 2014 16:18:04 +0200 Subject: cabal repl failing silently on missing exposed-modules Message-ID: Hi, I have just spent some time trying to figure out why all of a sudden "cabal repl" silently exits without an error message. What helped was to take a project that could launch the repl and compare the cabal files to my new project. It turns out the exposed-modules entry was missing. I was wondering whether this behaviour was intentional, as I don't recollect this happening before, but I don't have older systems to test this on. The reason I wanted to run a repl without editing exposed modules was to test some dependencies I pulled in to the sandbox with cabal install. The package in question didn't have any code of its own yet. In this case I would just expect ghci to load with the Prelude. Thanks! From alois.cochard at gmail.com Wed Aug 6 17:53:36 2014 From: alois.cochard at gmail.com (Alois Cochard) Date: Wed, 6 Aug 2014 18:53:36 +0100 Subject: cabal repl failing silently on missing exposed-modules In-Reply-To: References: Message-ID: Hi, I'm not sure if that relate to this problem so please ignore me if not. I had to spend quite a lot of time understanding what the issue had, when as you I had forget to add an entry for `exposed-modules` and trying to build... Basically I had an error saying that a symbol was missing or something like that (can remember the exact message), but every time I have that issue it take me a while to realise I have forget the entry... I think it's not a type error, it's kind of a linking error maybe that's why the repl fail silently. Anyway, I was wondering if it would be possible to give a more helpful error message in such case. Cheers On 6 August 2014 15:18, cheater00 . wrote: > Hi, > I have just spent some time trying to figure out why all of a sudden > "cabal repl" silently exits without an error message. What helped was > to take a project that could launch the repl and compare the cabal > files to my new project. It turns out the exposed-modules entry was > missing. I was wondering whether this behaviour was intentional, as I > don't recollect this happening before, but I don't have older systems > to test this on. > > The reason I wanted to run a repl without editing exposed modules was > to test some dependencies I pulled in to the sandbox with cabal > install. The package in question didn't have any code of its own yet. > In this case I would just expect ghci to load with the Prelude. > > Thanks! > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheater00 at gmail.com Wed Aug 6 21:29:35 2014 From: cheater00 at gmail.com (cheater00 .) Date: Wed, 6 Aug 2014 23:29:35 +0200 Subject: cabal repl failing silently on missing exposed-modules In-Reply-To: References: Message-ID: The simplest thing to fix your case might be to emit an error when a library is built with no exposed-modules (why would you build it otherwise?) On Wed, Aug 6, 2014 at 7:53 PM, Alois Cochard wrote: > Hi, > > I'm not sure if that relate to this problem so please ignore me if not. > > I had to spend quite a lot of time understanding what the issue had, when as > you I had forget to add an entry for `exposed-modules` and trying to > build... > Basically I had an error saying that a symbol was missing or something like > that (can remember the exact message), but every time I have that issue it > take me a while to realise I have forget the entry... > > I think it's not a type error, it's kind of a linking error maybe that's why > the repl fail silently. > > Anyway, I was wondering if it would be possible to give a more helpful error > message in such case. > > Cheers > > > > > On 6 August 2014 15:18, cheater00 . wrote: >> >> Hi, >> I have just spent some time trying to figure out why all of a sudden >> "cabal repl" silently exits without an error message. What helped was >> to take a project that could launch the repl and compare the cabal >> files to my new project. It turns out the exposed-modules entry was >> missing. I was wondering whether this behaviour was intentional, as I >> don't recollect this happening before, but I don't have older systems >> to test this on. >> >> The reason I wanted to run a repl without editing exposed modules was >> to test some dependencies I pulled in to the sandbox with cabal >> install. The package in question didn't have any code of its own yet. >> In this case I would just expect ghci to load with the Prelude. >> >> Thanks! >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > -- > ?\ois > http://twitter.com/aloiscochard > http://github.com/aloiscochard From cheater00 at gmail.com Wed Aug 6 21:31:31 2014 From: cheater00 at gmail.com (cheater00 .) Date: Wed, 6 Aug 2014 23:31:31 +0200 Subject: cabal repl failing silently on missing exposed-modules In-Reply-To: References: Message-ID: In the last email I meant that I don't see a reason to build a library without exposed-modules, sorry! On Wed, Aug 6, 2014 at 11:29 PM, cheater00 . wrote: > The simplest thing to fix your case might be to emit an error when a > library is built with no exposed-modules (why would you build it > otherwise?) > > On Wed, Aug 6, 2014 at 7:53 PM, Alois Cochard wrote: >> Hi, >> >> I'm not sure if that relate to this problem so please ignore me if not. >> >> I had to spend quite a lot of time understanding what the issue had, when as >> you I had forget to add an entry for `exposed-modules` and trying to >> build... >> Basically I had an error saying that a symbol was missing or something like >> that (can remember the exact message), but every time I have that issue it >> take me a while to realise I have forget the entry... >> >> I think it's not a type error, it's kind of a linking error maybe that's why >> the repl fail silently. >> >> Anyway, I was wondering if it would be possible to give a more helpful error >> message in such case. >> >> Cheers >> >> >> >> >> On 6 August 2014 15:18, cheater00 . wrote: >>> >>> Hi, >>> I have just spent some time trying to figure out why all of a sudden >>> "cabal repl" silently exits without an error message. What helped was >>> to take a project that could launch the repl and compare the cabal >>> files to my new project. It turns out the exposed-modules entry was >>> missing. I was wondering whether this behaviour was intentional, as I >>> don't recollect this happening before, but I don't have older systems >>> to test this on. >>> >>> The reason I wanted to run a repl without editing exposed modules was >>> to test some dependencies I pulled in to the sandbox with cabal >>> install. The package in question didn't have any code of its own yet. >>> In this case I would just expect ghci to load with the Prelude. >>> >>> Thanks! >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> >> >> >> -- >> ?\ois >> http://twitter.com/aloiscochard >> http://github.com/aloiscochard From alois.cochard at gmail.com Wed Aug 6 21:34:13 2014 From: alois.cochard at gmail.com (Alois Cochard) Date: Wed, 6 Aug 2014 22:34:13 +0100 Subject: cabal repl failing silently on missing exposed-modules In-Reply-To: References: Message-ID: Because it's actually not with a library but when building an executable, sorry I should have specified that. On 6 August 2014 22:31, cheater00 . wrote: > In the last email I meant that I don't see a reason to build a library > without exposed-modules, sorry! > > On Wed, Aug 6, 2014 at 11:29 PM, cheater00 . wrote: > > The simplest thing to fix your case might be to emit an error when a > > library is built with no exposed-modules (why would you build it > > otherwise?) > > > > On Wed, Aug 6, 2014 at 7:53 PM, Alois Cochard > wrote: > >> Hi, > >> > >> I'm not sure if that relate to this problem so please ignore me if not. > >> > >> I had to spend quite a lot of time understanding what the issue had, > when as > >> you I had forget to add an entry for `exposed-modules` and trying to > >> build... > >> Basically I had an error saying that a symbol was missing or something > like > >> that (can remember the exact message), but every time I have that issue > it > >> take me a while to realise I have forget the entry... > >> > >> I think it's not a type error, it's kind of a linking error maybe > that's why > >> the repl fail silently. > >> > >> Anyway, I was wondering if it would be possible to give a more helpful > error > >> message in such case. > >> > >> Cheers > >> > >> > >> > >> > >> On 6 August 2014 15:18, cheater00 . wrote: > >>> > >>> Hi, > >>> I have just spent some time trying to figure out why all of a sudden > >>> "cabal repl" silently exits without an error message. What helped was > >>> to take a project that could launch the repl and compare the cabal > >>> files to my new project. It turns out the exposed-modules entry was > >>> missing. I was wondering whether this behaviour was intentional, as I > >>> don't recollect this happening before, but I don't have older systems > >>> to test this on. > >>> > >>> The reason I wanted to run a repl without editing exposed modules was > >>> to test some dependencies I pulled in to the sandbox with cabal > >>> install. The package in question didn't have any code of its own yet. > >>> In this case I would just expect ghci to load with the Prelude. > >>> > >>> Thanks! > >>> _______________________________________________ > >>> Glasgow-haskell-users mailing list > >>> Glasgow-haskell-users at haskell.org > >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >> > >> > >> > >> > >> -- > >> ?\ois > >> http://twitter.com/aloiscochard > >> http://github.com/aloiscochard > -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From singpolyma at singpolyma.net Thu Aug 7 14:47:21 2014 From: singpolyma at singpolyma.net (Stephen Paul Weber) Date: Thu, 7 Aug 2014 09:47:21 -0500 Subject: Overlapping and incoherent instances In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF220981A1@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF2208260F@DB3PRD3001MB020.064d.mgd.msft.net> <20140802152714.GA119560@srcf.ucam.org> <20140802195157.GB119560@srcf.ucam.org> <20140802205457.GA157265@srcf.ucam.org> <618BE556AADD624C9C918AA5D5911BEF220981A1@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <20140807144721.GB2003@singpolyma-liberty> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >I suppose that -XOverlappingInstances could mean "silently honour >OVERLAPPABLE/OVERLAPPING pragmas", while lacking it would mean "honour >OVERLAPPABLE/OVERLAPPING pragmas, but emit noisy warnings" or even "don't >honour them and warn". > >But that is different to the behaviour today, so we'd need a new LANGUAGE >pragma. Perhaps -XHonourOverlappingInstances or something. This would be a reasonable alternative to the keyword-based solution. At least for now. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJT45F5AAoJENEcKRHOUZzewwwQALUiK60sbIC6j5nbXHPCeau8 bN80pmhUL11lAyI7OCSQyV8S9AU7ikgaUPyKwk/cx/TtKQGLwghWFZlRCoCRrplk dmGsSCw2LN4GElHL22EcyELPcx74lknz3tmQuZg4oAUXm1h2w8774L3iHOE4Ompg 9gYzuOo8Ii3oHJ6fjIL0DwGWp92F8NrTPeQmziBOPHAgQYVFO8QMncXcOGtdIZUb PQr0szr9HLkcwKSrYoxvvZBqEj6AM0xj+KhX87NEnQ08EaY6FO/Dhm4mi7X/A5Ca khwsjwId0qR6C4vs7QyYnaK3yiUFlZMUlXdUhpRG3wWFHseb3m9tX2a2ewE30jPl TgnoU5NYphijMWXpc3p06D5Zj0lT6L++Y3Ez8CS+0QpBPG9c0CJnLqXFQ5CNbl+9 Ryzpg7ltg5vhtq7BLwcz+V87lzc4KYm/tyqEVvxN59W6XLuLLe4tW6NL9vLDl9Rg /3vMRYKZBa+0we7jAi/wYbdks7g+9sqpiLqke5m73a5F2j/TTl4BrkIj2vG0KrP+ G9eJC1aieUbfPXXwXWSJh8binJNp//qWs7rILDsx4r0o1QR245uT5WzwkwapXmE8 ZYuXsVcc1/mS1ZneOP6zn0QOlRcUJ0A5dFxQg69hsXpD+MM226r/57P3eI9XhLRN W+DNBoXbr9mp8eNGjl6O =CFkA -----END PGP SIGNATURE----- From bertram.felgenhauer at googlemail.com Thu Aug 7 15:24:53 2014 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Thu, 7 Aug 2014 17:24:53 +0200 Subject: Overlapping and incoherent instances In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF220981A1@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF2208260F@DB3PRD3001MB020.064d.mgd.msft.net> <20140802152714.GA119560@srcf.ucam.org> <20140802195157.GB119560@srcf.ucam.org> <20140802205457.GA157265@srcf.ucam.org> <618BE556AADD624C9C918AA5D5911BEF220981A1@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <20140807152453.GA3611@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Simon Peyton Jones wrote: > | >>On a largely unrelated note, here's another thing I don't > | >>understand: when is OVERLAPPABLE at one instance declaration > | >>preferable to using only OVERLAPPING at the instance declarations > | >>that overlap it? > > It's a user decision. GHC allows > - OVERLAPPABLE at the instance that is being overlapped, or > - OVERLAPPING at the instance that is doing the overlapping, or > - both I'm curious how this affects simplification of contexts. If I have class Foo a instance Foo a => Foo [a] then GHC will simplify foo :: Foo [a] => a -> () to foo :: Foo a => a -> () Would this be prevented by declaring the Foo [a] instance as overlappable? In other words, does OVERLAPPABLE instruct the type checker to expect overlapping instances even if none of them are visible? Cheers, Bertram From simonpj at microsoft.com Thu Aug 7 20:46:43 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 7 Aug 2014 20:46:43 +0000 Subject: Overlapping and incoherent instances In-Reply-To: <20140807152453.GA3611@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF2208260F@DB3PRD3001MB020.064d.mgd.msft.net> <20140802152714.GA119560@srcf.ucam.org> <20140802195157.GB119560@srcf.ucam.org> <20140802205457.GA157265@srcf.ucam.org> <618BE556AADD624C9C918AA5D5911BEF220981A1@DB3PRD3001MB020.064d.mgd.msft.net> <20140807152453.GA3611@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: <618BE556AADD624C9C918AA5D5911BEF22198CDC@DBXPRD3001MB024.064d.mgd.msft.net> | overlappable? In other words, does OVERLAPPABLE instruct the | type checker to expect overlapping instances even if none of | them are visible? No, not at the moment. Suppose we have class C a where op :: a -> String instance {-# OVERLAPPABLE #-} C a => C [a] where op x = "[a]" instance {-# OVERLAPPING #-} C [Int] where op x = "[Int]" foo :: C a => a -> String foo x = op [x] ++ "urk" Then we (rightly) get an overlapping instance error when we try to solve the (C [a]) constraint arising from op [a] in foo's RHS. But if we omit the type signature for foo, then GHC will (as before) not simplify the (C [a]) constraint, for the same reason, but because it's unsolved GHC will abstract over it to give the inferred type foo :: C [a] => a -> String But this only happens if the overlapping instance is visible here. If the C [Int] instance is in some other module, then GHC will infer foo :: C a => a -> String. Your point is that if the C [a] instance is marked OVERLAPPABLE, perhaps GHC should decline to simplify it, on the grounds that a more specific instance might appear. But then the (C [a]) instance would never, ever be used! (On the grounds that it might be overlapped by some as-yet-unseen instance. So I don't think this would work. In any case, if the current behaviour doesn't seem precisely defined by the user manual, could you suggest some words that would make it clearer? Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of Bertram Felgenhauer | Sent: 07 August 2014 16:25 | To: glasgow-haskell-users at haskell.org | Subject: Re: Overlapping and incoherent instances | | Simon Peyton Jones wrote: | > | >>On a largely unrelated note, here's another thing I don't | > | >>understand: when is OVERLAPPABLE at one instance declaration | > | >>preferable to using only OVERLAPPING at the instance declarations | > | >>that overlap it? | > | > It's a user decision. GHC allows | > - OVERLAPPABLE at the instance that is being overlapped, or | > - OVERLAPPING at the instance that is doing the overlapping, or | > - both | | I'm curious how this affects simplification of contexts. If I have | | class Foo a | instance Foo a => Foo [a] | | then GHC will simplify | | foo :: Foo [a] => a -> () | | to | | foo :: Foo a => a -> () | | Would this be prevented by declaring the Foo [a] instance as | overlappable? In other words, does OVERLAPPABLE instruct the | type checker to expect overlapping instances even if none of | them are visible? | | Cheers, | | Bertram | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ezyang at mit.edu Fri Aug 8 12:08:35 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 08 Aug 2014 13:08:35 +0100 Subject: cabal repl failing silently on missing exposed-modules In-Reply-To: References: Message-ID: <1407499692-sup-5283@sabre> If you haven't already, go file a bug on https://github.com/haskell/cabal/issues Edward Excerpts from cheater00 .'s message of 2014-08-06 15:18:04 +0100: > Hi, > I have just spent some time trying to figure out why all of a sudden > "cabal repl" silently exits without an error message. What helped was > to take a project that could launch the repl and compare the cabal > files to my new project. It turns out the exposed-modules entry was > missing. I was wondering whether this behaviour was intentional, as I > don't recollect this happening before, but I don't have older systems > to test this on. > > The reason I wanted to run a repl without editing exposed modules was > to test some dependencies I pulled in to the sandbox with cabal > install. The package in question didn't have any code of its own yet. > In this case I would just expect ghci to load with the Prelude. > > Thanks! From iavor.diatchki at gmail.com Sun Aug 10 20:12:04 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun, 10 Aug 2014 13:12:04 -0700 Subject: Overlapping and incoherent and intentionally omitted instances In-Reply-To: <53E77F54.5010007@henning-thielemann.de> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53D76989.2070808@nh2.me> <87lhrcbijz.fsf@gnu.org> <53E77F54.5010007@henning-thielemann.de> Message-ID: Hello, Such a pragma sounds useful, and is very much like the "fails" instance from the "Instance chains" paper. You may also be interested in ticket #9334 (https://ghc.haskell.org/trac/ghc/ticket/9334), which proposes an alternative to overlapping instances, and I just updated it to point to #7775. -Iavor On Sun, Aug 10, 2014 at 7:19 AM, Henning Thielemann < schlepptop at henning-thielemann.de> wrote: > Am 29.07.2014 um 12:02 schrieb Johan Tibell: > > P.S. For e.g. INLINABLE we require that you mention the function name >> next to the pragma (which means that you can e.g. put the pragma after >> the declaration). What's the rationale to not require >> >> {-# OVERLAPPING Show [Char] #-} >> >> here? Perhaps it's too annoying to have to repeat the types? >> > > Once I proposed a pragma for documenting intentionally unimplemented > instances. In this case there is no instance you can write a pragma in > front of. Your OVERLAPPING syntax would be conform with the one of > NOINSTANCE: > > https://ghc.haskell.org/trac/ghc/ticket/7775 > > Maybe NOINSTANCE can be reconsidered in the course of the introduction of > the OVERLAP pragma? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From twanvl at gmail.com Mon Aug 11 15:36:51 2014 From: twanvl at gmail.com (Twan van Laarhoven) Date: Mon, 11 Aug 2014 17:36:51 +0200 Subject: Overlapping and incoherent instances In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <53E8E313.6020300@gmail.com> To me, perhaps naively, IncoherentInstances is way more scary than OverlappingInstances. What behavior do these new pragmas have? In particular, will it be an error if there is no single most specific instance? And can the user decide whether it is an error? Twan On 29/07/14 11:11, Simon Peyton Jones wrote: > Friends > > One of GHC?s more widely-used features is overlapping (and sometimes incoherent) > instances. The user-manual documentation is here > . > > The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas: > OverlappingInstances and IncoherentInstances respectively. > > However the overlap/incoherent-ness is a property of the **instance > declaration** itself, and has been for a long time. Using LANGUAGE > OverlappingInstances simply sets the ?I am an overlapping instance? flag for > every instance declaration in that module. > > This is a Big Hammer. It give no clue about **which** particular instances the > programmer is expecting to be overlapped, nor which are doing the > overlapping. It brutally applies to every instance in the module. Moreover, > when looking at an instance declaration, there is no nearby clue that it might > be overlapped. The clue might be in the command line that compiles that module! > > Iavor has recently implemented per-instance-declaration pragmas, so you can say > > instance {-# OVERLAPPABLE #-} Show a => Show [a] where ? > > instance {-# OVERLAPPING #-} Show [Char] where ? > > This is much more precise (it affects only those specific instances) and it is > much clearer (you see it when you see the instance declaration). > > This new feature will be in GHC 7.10 and I?m sure you will be happy about that. > *But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and > IncoherentInstances*, as way to encourage everyone to use the new feature > instead of the old big hammer. The old LANGUAGE pragmas will continue to work, > of course, for at least another complete release cycle. We could make that two > cycles if it was helpful. > > However, if you want deprecation-free libraries, it will entail a wave of > library updates. > > This email is just to warn you, and to let you yell if you think this is a bad > idea. It would actually not be difficult to retain the old LANGUAGE pragmas > indefinitely ? it just seems wrong not to actively push authors in the right > direction. > > These deprecations of course popped up in the test suite, so I?ve been replacing > them with per-instance pragmas there too. Interestingly in some cases, when > looking for which instances needed the pragmas, I found?none. So > OverlappingInstances was entirely unnecessary. Maybe library authors will find > that too! > > Simon > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From dan.doel at gmail.com Mon Aug 11 19:35:42 2014 From: dan.doel at gmail.com (Dan Doel) Date: Mon, 11 Aug 2014 15:35:42 -0400 Subject: Overlapping and incoherent instances In-Reply-To: <53E8E313.6020300@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53E8E313.6020300@gmail.com> Message-ID: On Mon, Aug 11, 2014 at 11:36 AM, Twan van Laarhoven wrote: > To me, perhaps naively, IncoherentInstances is way more scary than > OverlappingInstances. > ?It might be a bit naive. Most things that incoherent instances would allow are allowed with overlapping instances so long as you partition your code into two modules. So unless such a partitioning is impossible, overlapping instances are almost as scary as incoherent instances (unless the module separation somehow makes it less scary). And actually, with the way GHC handles instances, you can get more incoherent behavior than incoherent instances allow without enabling any extensions, just using modules: module A where class Foo a where foo :: a module B where import A instance F? ?oo Int where foo = 5 bar :: Int ; bar = foo module C where import A instance Foo Int where foo = 6 baz :: Int ; baz = foo module D where import B import C quux = bar + baz -- 11? ? -- ? Dan? -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Tue Aug 12 01:27:46 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 11 Aug 2014 18:27:46 -0700 Subject: Overlapping and incoherent instances In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53E8E313.6020300@gmail.com> Message-ID: Hello, this is clearly a bug in GHC: where `B` and `C` are imported, there should have been an error, saying that there is a duplicate instance of `Foo Int`. If there is no ticket for this already, could you please add one? -Iavor On Mon, Aug 11, 2014 at 12:35 PM, Dan Doel wrote: > On Mon, Aug 11, 2014 at 11:36 AM, Twan van Laarhoven > wrote: > >> To me, perhaps naively, IncoherentInstances is way more scary than >> OverlappingInstances. >> > > ?It might be a bit naive. Most things that incoherent instances would > allow are allowed with overlapping instances so long as you partition your > code into two modules. So unless such a partitioning is impossible, > overlapping instances are almost as scary as incoherent instances (unless > the module separation somehow makes it less scary). > > And actually, with the way GHC handles instances, you can get more > incoherent behavior than incoherent instances allow without enabling any > extensions, just using modules: > > module A where > class Foo a where foo :: a > > module B where > import A > instance F? > ?oo Int where foo = 5 > bar :: Int ; bar = foo > > module C where > import A > instance Foo Int where foo = 6 > baz :: Int ; baz = foo > > module D where > import B > import C > > quux = bar + baz -- 11? > ? > > -- > ? Dan? > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Tue Aug 12 01:33:48 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 11 Aug 2014 21:33:48 -0400 Subject: Overlapping and incoherent instances In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53E8E313.6020300@gmail.com> Message-ID: <60E3C12B-2BEF-462F-A438-802FFB1636CE@cis.upenn.edu> This has been reported: https://ghc.haskell.org/trac/ghc/ticket/8338 But it's really not clear what the solution is! Richard On Aug 11, 2014, at 9:27 PM, Iavor Diatchki wrote: > Hello, > > this is clearly a bug in GHC: where `B` and `C` are imported, there should have been an error, saying that there is a duplicate instance of `Foo Int`. If there is no ticket for this already, could you please add one? > > -Iavor > > > > > > > On Mon, Aug 11, 2014 at 12:35 PM, Dan Doel wrote: > On Mon, Aug 11, 2014 at 11:36 AM, Twan van Laarhoven wrote: > To me, perhaps naively, IncoherentInstances is way more scary than OverlappingInstances. > > ?It might be a bit naive. Most things that incoherent instances would allow are allowed with overlapping instances so long as you partition your code into two modules. So unless such a partitioning is impossible, overlapping instances are almost as scary as incoherent instances (unless the module separation somehow makes it less scary). > > And actually, with the way GHC handles instances, you can get more incoherent behavior than incoherent instances allow without enabling any extensions, just using modules: > > module A where > class Foo a where foo :: a > > module B where > import A > instance F??oo Int where foo = 5 > bar :: Int ; bar = foo > > module C where > import A > instance Foo Int where foo = 6 > baz :: Int ; baz = foo > > module D where > import B > import C > > quux = bar + baz -- 11?? > > -- ? Dan? > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at proclivis.com Wed Aug 13 04:44:17 2014 From: mike at proclivis.com (Michael Jones) Date: Tue, 12 Aug 2014 22:44:17 -0600 Subject: Odd FFI behavior Message-ID: I have some strange behavior with GHC 7.6.3 on Ubuntu 14 TLS when using FFI and I am looking for some ideas on what could be going on. Fundamentally, adding wait calls (delays coded in the C) changes the behavior of the C, in that returned status codes have proper values when there are delays, and return errors when there are no delays. But these same calls result in proper behavior on the Aardvark?s serial bus, return proper data, etc. Only the status get?s messed up. The module calls a thin custom C layer over the Aaardvark C layer, which dynamically loads a dll and makes calls into it. The thin layer just makes the use of c2hs eaiser. It is always possible there is some kind of memory issue, but there is no pattern to the mishap. It is random. Adding delays just changes probabilities of bad status. I made a C version of my application calling the same custom C layer, and there are no problems. This sort of indicates the problem is with the FFI. Because the failures are not general in that they target one particular value, and seem to be affected by time, it makes me wonder if there is some subtle Haskell run time issue. Like, could the garbage collector be interacting with things? Does anyone have an idea what kind of things to look for? Mike DLL loader static void *_loadFunction (const char *name, int *result) { static DLL_HANDLE handle = 0; void * function = 0; /* Load the shared library if necessary */ if (handle == 0) { u32 (*version) (void); u16 sw_version; u16 api_version_req; _setSearchPath(); handle = dlopen(SO_NAME, RTLD_LAZY); if (handle == 0) { #if API_DEBUG fprintf(stderr, "Unable to load %s\n", SO_NAME); fprintf(stderr, "%s\n", dlerror()); #endif *result = API_UNABLE_TO_LOAD_LIBRARY; return 0; } version = (void *)dlsym(handle, "c_version"); if (version == 0) { #if API_DEBUG fprintf(stderr, "Unable to bind c_version() in %s\n", SO_NAME); fprintf(stderr, "%s\n", dlerror()); #endif handle = 0; *result = API_INCOMPATIBLE_LIBRARY; return 0; } sw_version = (u16)((version() >> 0) & 0xffff); api_version_req = (u16)((version() >> 16) & 0xffff); if (sw_version < API_REQ_SW_VERSION || API_HEADER_VERSION < api_version_req) { #if API_DEBUG fprintf(stderr, "\nIncompatible versions:\n"); fprintf(stderr, " Header version = v%d.%02d ", (API_HEADER_VERSION >> 8) & 0xff, API_HEADER_VERSION & 0xff); if (sw_version < API_REQ_SW_VERSION) fprintf(stderr, "(requires library >= %d.%02d)\n", (API_REQ_SW_VERSION >> 8) & 0xff, API_REQ_SW_VERSION & 0xff); else fprintf(stderr, "(library version OK)\n"); fprintf(stderr, " Library version = v%d.%02d ", (sw_version >> 8) & 0xff, (sw_version >> 0) & 0xff); if (API_HEADER_VERSION < api_version_req) fprintf(stderr, "(requires header >= %d.%02d)\n", (api_version_req >> 8) & 0xff, (api_version_req >> 0) & 0xff); else fprintf(stderr, "(header version OK)\n"); #endif handle = 0; *result = API_INCOMPATIBLE_LIBRARY; return 0; } } /* Bind the requested function in the shared library */ function = (void *)dlsym(handle, name); *result = function ? API_OK : API_UNABLE_TO_LOAD_FUNCTION; return function; } From donn at avvanta.com Wed Aug 13 05:04:59 2014 From: donn at avvanta.com (Donn Cave) Date: Tue, 12 Aug 2014 22:04:59 -0700 (PDT) Subject: Odd FFI behavior In-Reply-To: References: Message-ID: <20140813050459.1CB13276C42@mail.avvanta.com> ... > Because the failures are not general in that they target one > particular value, and seem to be affected by time, it makes me > wonder if there is some subtle Haskell run time issue. Like, > could the garbage collector be interacting with things? > > Does anyone have an idea what kind of things to look for? Sure - not that I have worked out in any detail how this would do what you're seeing, but it's easy to do and often enough works. Compile with RTS options enabled and invoke with RTS option -V0. That will disable the runtime internal timer, which uses signals. The flood of signals from this source can interrupt functions that aren't really designed to deal with that, because in a more normal context they don't have to. Donn From mike at proclivis.com Wed Aug 13 15:12:35 2014 From: mike at proclivis.com (Michael Jones) Date: Wed, 13 Aug 2014 09:12:35 -0600 Subject: Odd FFI behavior In-Reply-To: <20140813050459.1CB13276C42@mail.avvanta.com> References: <20140813050459.1CB13276C42@mail.avvanta.com> Message-ID: Donn, Thanks, this solved the problem. I would like to know more about what the signals are doing, and what am I giving up by disabling them? My hope is I can then go back to the dll expert and ask why this is causing their library a problem and try to see if they can solve the problem from their end, etc. Mike On Aug 12, 2014, at 11:04 PM, Donn Cave wrote: > ... >> Because the failures are not general in that they target one >> particular value, and seem to be affected by time, it makes me >> wonder if there is some subtle Haskell run time issue. Like, >> could the garbage collector be interacting with things? >> >> Does anyone have an idea what kind of things to look for? > > Sure - not that I have worked out in any detail how this would > do what you're seeing, but it's easy to do and often enough > works. > > Compile with RTS options enabled and invoke with RTS option -V0. > > That will disable the runtime internal timer, which uses signals. > The flood of signals from this source can interrupt functions > that aren't really designed to deal with that, because in a more > normal context they don't have to. > > Donn From donn at avvanta.com Wed Aug 13 15:56:59 2014 From: donn at avvanta.com (Donn Cave) Date: Wed, 13 Aug 2014 08:56:59 -0700 (PDT) Subject: Odd FFI behavior In-Reply-To: References: Message-ID: <20140813155659.B06FE276C48@mail.avvanta.com> [ ... re -V0 ] > Thanks, this solved the problem. > > I would like to know more about what the signals are doing, and > what am I giving up by disabling them? > > My hope is I can then go back to the dll expert and ask why this > is causing their library a problem and try to see if they can > solve the problem from their end, etc. I'm disgracefully ignorant about that. When I've been forced to run this way, it doesn't seem to do any very obvious immediate harm to the application at all, but I could be missing long term effects. The problem with the library might be easy to fix, and in principle it's sure worth looking into - while the GHC runtime delivers signals on an exceptionally massive scale, there are plenty of normal UNIX applications that use signals, maybe timers just like this for example, and it's easy to set up a similar test environment using setitimer(2) to provide the signal bombardment. (I believe GHC actually uses SIGVTALRM rather than SIGALRM, but don't think it will make any difference.) But realistically, in the end sometimes we can't get a fix for it, so it's interesting to know how -V0 works out as a work-around. I hope you will keep us posted. Donn From mike at proclivis.com Thu Aug 14 12:32:13 2014 From: mike at proclivis.com (Michael Jones) Date: Thu, 14 Aug 2014 06:32:13 -0600 Subject: Odd FFI behavior In-Reply-To: <20140813155659.B06FE276C48@mail.avvanta.com> References: <20140813155659.B06FE276C48@mail.avvanta.com> Message-ID: <7256D141-71B4-4661-8FC4-3D42F4DE69EF@proclivis.com> Donn, I was able to duplicate my problem in C using SIGVTALRM. Can someone explain the impact of using -V0 ? What does it do to performance, etc? Mike Sent from my iPad > On Aug 13, 2014, at 9:56 AM, Donn Cave wrote: > > [ ... re -V0 ] >> Thanks, this solved the problem. >> >> I would like to know more about what the signals are doing, and >> what am I giving up by disabling them? >> >> My hope is I can then go back to the dll expert and ask why this >> is causing their library a problem and try to see if they can >> solve the problem from their end, etc. > > I'm disgracefully ignorant about that. When I've been forced to > run this way, it doesn't seem to do any very obvious immediate > harm to the application at all, but I could be missing long term > effects. > > The problem with the library might be easy to fix, and in principle > it's sure worth looking into - while the GHC runtime delivers signals > on an exceptionally massive scale, there are plenty of normal UNIX > applications that use signals, maybe timers just like this for example, > and it's easy to set up a similar test environment using setitimer(2) > to provide the signal bombardment. (I believe GHC actually uses > SIGVTALRM rather than SIGALRM, but don't think it will make any > difference.) > > But realistically, in the end sometimes we can't get a fix for it, > so it's interesting to know how -V0 works out as a work-around. > I hope you will keep us posted. > > Donn From choener at tbi.univie.ac.at Thu Aug 14 15:54:12 2014 From: choener at tbi.univie.ac.at (Christian =?iso-8859-1?Q?H=F6ner?= zu Siederdissen) Date: Thu, 14 Aug 2014 17:54:12 +0200 Subject: 'import ccall unsafe' and parallelism Message-ID: <20140814155412.GA14915@workstation> Greetings everybody, I happen to be a bit confused with regards to unsafe foreign imports and parallelism. Assume the following C function: foreign import ccall unsafe "cfun" cfun :: CInt -> IO () Now, cfun does some work: go xs = unsafePerformIO $ do forM_ xs $ cfun return $ somethingUnhealthy And I'd like to parallelize this: parMap rdeepseq go [costly,costly] However, due to the way ghc handles unsafe imports, namely block everything else whenever 'cfun' is called, I happen to have only one active 'go'. Lets assume 'cfun' is cheap and would suffer from 'ccall safe' more than I'd be willing to pay. Is there any fix possible? Viele Gruesse, Christian PS: The real problem happens to use a bunch of different judy arrays, each of which lives in its on thread; 300 judy arrays, 300 threads, each up to 20 million inserts. But I think the basic problem can be reduced to "how to parallelize 'ccall unsafe's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From johan.tibell at gmail.com Thu Aug 14 16:00:16 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 14 Aug 2014 18:00:16 +0200 Subject: 'import ccall unsafe' and parallelism In-Reply-To: <20140814155412.GA14915@workstation> References: <20140814155412.GA14915@workstation> Message-ID: Hi! On Thu, Aug 14, 2014 at 5:54 PM, Christian H?ner zu Siederdissen < choener at tbi.univie.ac.at> wrote: > > However, due to the way ghc handles unsafe imports, namely block > everything else whenever 'cfun' is called, I happen to have only one > active 'go'. Lets assume 'cfun' is cheap and would suffer from 'ccall > safe' more than I'd be willing to pay. > Calls to unsafe functions do not block everything! Other Haskell threads can continue running on other capabilities (make sure you run your program with +RTS -N). However, make sure that the C function itself never blocks, or it might deadlock your program. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Aug 14 16:12:00 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 14 Aug 2014 12:12:00 -0400 Subject: 'import ccall unsafe' and parallelism In-Reply-To: <20140814155412.GA14915@workstation> References: <20140814155412.GA14915@workstation> Message-ID: On Thu, Aug 14, 2014 at 11:54 AM, Christian H?ner zu Siederdissen < choener at tbi.univie.ac.at> wrote: > go xs = unsafePerformIO $ do > forM_ xs $ cfun > return $ somethingUnhealthy > I wonder if this is your real problem. `unsafePerformIO` does some extra locking; the FFI specifies a function `unsafeLocalState`, which in GHC is `unsafeDupablePerformIO` which skips the extra locking. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From donn at avvanta.com Thu Aug 14 16:21:11 2014 From: donn at avvanta.com (Donn Cave) Date: Thu, 14 Aug 2014 09:21:11 -0700 (PDT) Subject: 'import ccall unsafe' and parallelism In-Reply-To: References: Message-ID: <20140814162111.96E15F396D@mail.avvanta.com> I'm no judge of what's true about safe and unsafe, but this account of the system has at least to my ear the ring of authenticity: http://blog.melding-monads.com/2011/10/24/concurrency-and-foreign-functions-in-the-glasgow-haskell-compiler/ The FFI section is short and readable. With respect to whether "unsafe" does or does not block other threads, I can never penetrate the verbiage about capabilities to know for sure what to expect in practice, but when I checked, in practice, "unsafe" blocks other threads. I use "safe" to avoid this. Donn From carter.schonwald at gmail.com Thu Aug 14 16:26:58 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 14 Aug 2014 12:26:58 -0400 Subject: 'import ccall unsafe' and parallelism In-Reply-To: <20140814162111.96E15F396D@mail.avvanta.com> References: <20140814162111.96E15F396D@mail.avvanta.com> Message-ID: if your computation in the C call takes more than 400 nano seconds, the overhead of the safe ffi convention is less onerous and you should do that when applicable. an alternative is so use forkOn to setup a worker thread on various GHC capabilities, and have them in parallel work on different chunks of the list. that way you're pausing ALL the capabilities (which again, you should only use the unsafe ffi convention for computations that take <= 10 microseconds if you want things to be well behaved) On Thu, Aug 14, 2014 at 12:21 PM, Donn Cave wrote: > I'm no judge of what's true about safe and unsafe, but this account of > the system has at least to my ear the ring of authenticity: > > > http://blog.melding-monads.com/2011/10/24/concurrency-and-foreign-functions-in-the-glasgow-haskell-compiler/ > > The FFI section is short and readable. > > With respect to whether "unsafe" does or does not block other threads, > I can never penetrate the verbiage about capabilities to know for sure > what to expect in practice, but when I checked, in practice, "unsafe" > blocks other threads. I use "safe" to avoid this. > > Donn > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Thu Aug 14 16:32:40 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 14 Aug 2014 17:32:40 +0100 Subject: 'import ccall unsafe' and parallelism In-Reply-To: References: <20140814155412.GA14915@workstation> Message-ID: <1408033939-sup-7225@sabre> I have to agree with Brandon's diagnosis: unsafePerformIO will take out a lock, which is likely why you are seeing no parallelism. Edward Excerpts from Brandon Allbery's message of 2014-08-14 17:12:00 +0100: > On Thu, Aug 14, 2014 at 11:54 AM, Christian H?ner zu Siederdissen < > choener at tbi.univie.ac.at> wrote: > > > go xs = unsafePerformIO $ do > > forM_ xs $ cfun > > return $ somethingUnhealthy > > > > I wonder if this is your real problem. `unsafePerformIO` does some extra > locking; the FFI specifies a function `unsafeLocalState`, which in GHC is > `unsafeDupablePerformIO` which skips the extra locking. > From choener at tbi.univie.ac.at Thu Aug 14 17:20:38 2014 From: choener at tbi.univie.ac.at (Christian =?iso-8859-1?Q?H=F6ner?= zu Siederdissen) Date: Thu, 14 Aug 2014 19:20:38 +0200 Subject: 'import ccall unsafe' and parallelism In-Reply-To: <20140814162111.96E15F396D@mail.avvanta.com> Message-ID: <20140814172038.GA22510@workstation> Thanks, I've played around some more and finally more than one capability is active. And indeed, unsafe calls don't block everything. I /had/ actually read that but when I saw the system spending basically only 100% cpu time, I'd thought to ask. One problem with this program seems to be that the different tasks are of vastly different sizes. Inputs range from ~ 7x10^1 to ~ 3x10^7 elements inducing waits with the larger problem sizes. We'll keep the program single-threaded for now as this also keeps memory consumption at only 25 gbyte instead of the more impressive 70 gbyte in multi-threaded mode ;-) Viele Gruesse, Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From carter.schonwald at gmail.com Thu Aug 14 21:10:22 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 14 Aug 2014 17:10:22 -0400 Subject: 'import ccall unsafe' and parallelism In-Reply-To: <20140814172038.GA22510@workstation> References: <20140814162111.96E15F396D@mail.avvanta.com> <20140814172038.GA22510@workstation> Message-ID: have a smart wrapper around you ffi call, and if when you think the ffi call will take more than 1 microsecond, ALWAYS use the safe ffi call, i do something like this in an FFI i wrote, it works great On Thu, Aug 14, 2014 at 1:20 PM, Christian H?ner zu Siederdissen < choener at tbi.univie.ac.at> wrote: > Thanks, > > I've played around some more and finally more than one capability is > active. And indeed, unsafe calls don't block everything. I /had/ > actually read that but when I saw the system spending basically only > 100% cpu time, I'd thought to ask. > > One problem with this program seems to be that the different tasks are > of vastly different sizes. Inputs range from ~ 7x10^1 to ~ 3x10^7 > elements inducing waits with the larger problem sizes. > > We'll keep the program single-threaded for now as this also keeps memory > consumption at only 25 gbyte instead of the more impressive 70 gbyte in > multi-threaded mode ;-) > > Viele Gruesse, > Christian > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From choener at tbi.univie.ac.at Thu Aug 14 21:38:37 2014 From: choener at tbi.univie.ac.at (Christian =?iso-8859-1?Q?H=F6ner?= zu Siederdissen) Date: Thu, 14 Aug 2014 23:38:37 +0200 Subject: 'import ccall unsafe' and parallelism In-Reply-To: References: <20140814162111.96E15F396D@mail.avvanta.com> <20140814172038.GA22510@workstation> Message-ID: <20140814213836.GA4015@workstation> That's actually a great idea, especially since the safe variants of the calls are already in place. * Carter Schonwald [14.08.2014 23:10]: > have a smart wrapper around you ffi call, and if when you think the ffi > call will take more than 1 microsecond, ALWAYS use the safe ffi call, > i do something like this in an FFI i wrote, it works great > > On Thu, Aug 14, 2014 at 1:20 PM, Christian HAP:ner zu Siederdissen > wrote: > > Thanks, > > I've played around some more and finally more than one capability is > active. And indeed, unsafe calls don't block everything. I /had/ > actually read that but when I saw the system spending basically only > 100% cpu time, I'd thought to ask. > > One problem with this program seems to be that the different tasks are > of vastly different sizes. Inputs range from ~ 7x10^1 to ~ 3x10^7 > elements inducing waits with the larger problem sizes. > > We'll keep the program single-threaded for now as this also keeps memory > consumption at only 25 gbyte instead of the more impressive 70 gbyte in > multi-threaded mode ;-) > > Viele Gruesse, > Christian > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From carter.schonwald at gmail.com Thu Aug 14 21:50:52 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 14 Aug 2014 17:50:52 -0400 Subject: 'import ccall unsafe' and parallelism In-Reply-To: <20140814213836.GA4015@workstation> References: <20140814162111.96E15F396D@mail.avvanta.com> <20140814172038.GA22510@workstation> <20140814213836.GA4015@workstation> Message-ID: glad I could help, https://github.com/wellposed/hblas/blob/master/src/Numerical/HBLAS/BLAS/Internal.hs#L146 is an example of the "choose to do the safe vs unsafe ffi call" trick in the case of blas / lapack routines, i can always estimate how long a compute job will take as a function of its inputs, and i use that estimate to decide which ffi strategy to use (ie i use unsafe ffi on < 10 microsecond computations so that the overhead doesn't dominate the compute time on tiny inputs) On Thu, Aug 14, 2014 at 5:38 PM, Christian H?ner zu Siederdissen < choener at tbi.univie.ac.at> wrote: > That's actually a great idea, especially since the safe variants of the > calls are already in place. > > * Carter Schonwald [14.08.2014 23:10]: > > have a smart wrapper around you ffi call, and if when you think the > ffi > > call will take more than 1 microsecond, ALWAYS use the safe ffi call, > > i do something like this in an FFI i wrote, it works great > > > > On Thu, Aug 14, 2014 at 1:20 PM, Christian HAP:ner zu Siederdissen > > wrote: > > > > Thanks, > > > > I've played around some more and finally more than one capability is > > active. And indeed, unsafe calls don't block everything. I /had/ > > actually read that but when I saw the system spending basically only > > 100% cpu time, I'd thought to ask. > > > > One problem with this program seems to be that the different tasks > are > > of vastly different sizes. Inputs range from ~ 7x10^1 to ~ 3x10^7 > > elements inducing waits with the larger problem sizes. > > > > We'll keep the program single-threaded for now as this also keeps > memory > > consumption at only 25 gbyte instead of the more impressive 70 > gbyte in > > multi-threaded mode ;-) > > > > Viele Gruesse, > > Christian > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g9ks157k at acme.softbase.org Fri Aug 15 20:04:29 2014 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri, 15 Aug 2014 23:04:29 +0300 Subject: Are safe coercions safe in the sense of Safe Haskell? Message-ID: <1408133069.19601.5.camel@idefix> Hi, I would expect the function coerce :: Coercible a b => a -> b to be safe in the sense of Safe Haskell. However, the Data.Coerce module is marked ?Unsafe?. The coerce function is also available via GHC.Exts and GHC.Prim. The former module is marked ?Unsafe?, but the latter is (surprisingly) marked ?Safe-Inferred?. What are the reasons behind this? All the best, Wolfgang From g9ks157k at acme.softbase.org Fri Aug 15 20:10:39 2014 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri, 15 Aug 2014 23:10:39 +0300 Subject: Rules for class methods and Safe Haskell Message-ID: <1408133439.19601.10.camel@idefix> Hi, the module Control.Arrow declares a set of rules for the Arrow class. It is marked ?Trustworthy?, probably to allow these rules to actually fire. Now these rules are only correct for class instances that actually satisfy the arrow laws. If the author of another module defines an instance of Arrow that does not respect the laws, this other module could still be considered ?Safe? by GHC, although the rules from Control.Arrow are bogus now. Is this considered a problem? All the best, Wolfgang From merijn at inconsistent.nl Fri Aug 15 22:40:34 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Fri, 15 Aug 2014 15:40:34 -0700 Subject: Revival: PROPOSAL: Literate haskell and module file names In-Reply-To: References: Message-ID: Ola! I raised this proposal earlier this year and got to busy to follow up, this week I was suddenly reminded and decided to reraise this. To summarise the discussion up until this point: There was no real opposition to the general idea, the only real objection to the original proposal was that ?Foo.lhs.md? and ?Foo.md.lhs? would collide with the naming scheme used by JHC on case insensitive filesystems. Alternative proposal raised during the discussion: "Foo+md.lhs", "Foo.lhs+md? and ?Foo.md+lhs?. According to MS documentation and testing the + should not be an issue on windows, the + doesn?t collide with any other haskell compiler (at least, not any I?m aware off) and since the report doesn?t specify any module name resolution mechanism, it does not conflict with the report either. My personal preferences goes to either ?.lhs+md? or ?.md+lhs?, since GHC currently tries every alternative in turn, I propose to just extend this list to look for any file whose extension is ?.lhs+*? or ?.*+lhs?. Are there any objections to this? If not, I?m just going to produce a patch + ticket as there were no real objections to the proposal last time. Cheers, Merijn On 16 Mar 2014, at 05:56 , Merijn Verstraaten wrote: > Ola! > > I didn't know what the most appropriate venue for this proposal was so I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right venue I welcome advice where to take this proposal. > > Currently the report does not specify the mapping between filenames and module names (this is an issue in itself, it essentially makes writing haskell code that's interoperable between compilers impossible, as you can't know what directory layout each compiler expects). I believe that a minimal specification *should* go into the report (hence, haskell-prime). However, this is a separate issue from this proposal, so please start a new thread rather than sidetracking this one :) > > The report only mentions that "by convention" .hs extensions imply normal haskell and .lhs literate haskell (Section 10.4). In the absence of guidance from the report GHC's convention of mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that exists. In general this standard is nice enough, but the mapping of literate haskell is a bit inconvenient, it leaves it completelyl ambiguous what the non-haskell content of said file is, which is annoying for tool authors. > > Pandoc has adopted the policy of checking for further file extensions for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets interpreted as being reStructured Text with literate haskell and .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps filenames like this to the module names Foo.rst and Foo.md, breaking anything that wants to import the module Foo. > > I would like to propose allowing an optional extra extension in the pandoc style for literate haskell files, mapping Foo.rst.lhs to module name Foo. This is a backwards compatible change as there is no way for Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs would map to module name "Foo.rst" but module name "Foo.rst" maps to filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst is lowercase and module names have to start with an uppercase letter. > > Pros: > - Tool authors can more easily determine non-haskell content of literate haskell files > - Currently valid module names will not break > - Report doesn't specify behaviour, so GHC can do whatever it likes > > Cons: > - Someone has to implement it > - ?? > > Discussion: 4 weeks > > Cheers, > Merijn > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From eir at cis.upenn.edu Fri Aug 15 23:40:01 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 15 Aug 2014 19:40:01 -0400 Subject: Are safe coercions safe in the sense of Safe Haskell? In-Reply-To: <1408133069.19601.5.camel@idefix> References: <1408133069.19601.5.camel@idefix> Message-ID: <28EB32BE-D64C-422E-A4A0-19E459C22584@cis.upenn.edu> See https://ghc.haskell.org/trac/ghc/ticket/8745 and https://ghc.haskell.org/trac/ghc/ticket/8827 which discuss this problem at length. The short answer: It's conceivable that a role-unaware library author would have abstraction expectations that are defeated through the use of `coerce`. I would strongly welcome a proposal for how to make `coerce`, and hence GeneralizedNewtypeDeriving, to be considered Safe for 7.10. Richard On Aug 15, 2014, at 4:04 PM, Wolfgang Jeltsch wrote: > Hi, > > I would expect the function > > coerce :: Coercible a b => a -> b > > to be safe in the sense of Safe Haskell. However, the Data.Coerce module > is marked ?Unsafe?. The coerce function is also available via GHC.Exts > and GHC.Prim. The former module is marked ?Unsafe?, but the latter is > (surprisingly) marked ?Safe-Inferred?. > > What are the reasons behind this? > > All the best, > Wolfgang > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From p.k.f.holzenspies at utwente.nl Sat Aug 16 13:51:08 2014 From: p.k.f.holzenspies at utwente.nl (p.k.f.holzenspies at utwente.nl) Date: Sat, 16 Aug 2014 13:51:08 +0000 Subject: Revival: PROPOSAL: Literate haskell and module file names In-Reply-To: References: , Message-ID: <37030b7f674d4804b551a9c57753d586@EXMBX31.ad.utwente.nl> Dear Merijn, Do you even need a separate extension or filename convention for this? Can't you just call it lhs and expand the definition thereof to include markdown? (I suggested something similar before, but objections were raised that having too good and too broad an unlitter might lead to the bit-rot of the flag to employ external unlitters. I didn't quite understand that objection, but didn't pursue it) Regards, Philip ________________________________________ Van: Glasgow-haskell-users namens Merijn Verstraaten Verzonden: zaterdag 16 augustus 2014 00:40 Aan: haskell-prime at haskell.org; glasgow-haskell-users at haskell.org Onderwerp: Revival: PROPOSAL: Literate haskell and module file names Ola! I raised this proposal earlier this year and got to busy to follow up, this week I was suddenly reminded and decided to reraise this. To summarise the discussion up until this point: There was no real opposition to the general idea, the only real objection to the original proposal was that ?Foo.lhs.md? and ?Foo.md.lhs? would collide with the naming scheme used by JHC on case insensitive filesystems. Alternative proposal raised during the discussion: "Foo+md.lhs", "Foo.lhs+md? and ?Foo.md+lhs?. According to MS documentation and testing the + should not be an issue on windows, the + doesn?t collide with any other haskell compiler (at least, not any I?m aware off) and since the report doesn?t specify any module name resolution mechanism, it does not conflict with the report either. My personal preferences goes to either ?.lhs+md? or ?.md+lhs?, since GHC currently tries every alternative in turn, I propose to just extend this list to look for any file whose extension is ?.lhs+*? or ?.*+lhs?. Are there any objections to this? If not, I?m just going to produce a patch + ticket as there were no real objections to the proposal last time. Cheers, Merijn On 16 Mar 2014, at 05:56 , Merijn Verstraaten wrote: > Ola! > > I didn't know what the most appropriate venue for this proposal was so I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right venue I welcome advice where to take this proposal. > > Currently the report does not specify the mapping between filenames and module names (this is an issue in itself, it essentially makes writing haskell code that's interoperable between compilers impossible, as you can't know what directory layout each compiler expects). I believe that a minimal specification *should* go into the report (hence, haskell-prime). However, this is a separate issue from this proposal, so please start a new thread rather than sidetracking this one :) > > The report only mentions that "by convention" .hs extensions imply normal haskell and .lhs literate haskell (Section 10.4). In the absence of guidance from the report GHC's convention of mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that exists. In general this standard is nice enough, but the mapping of literate haskell is a bit inconvenient, it leaves it completelyl ambiguous what the non-haskell content of said file is, which is annoying for tool authors. > > Pandoc has adopted the policy of checking for further file extensions for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets interpreted as being reStructured Text with literate haskell and .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps filenames like this to the module names Foo.rst and Foo.md, breaking anything that wants to import the module Foo. > > I would like to propose allowing an optional extra extension in the pandoc style for literate haskell files, mapping Foo.rst.lhs to module name Foo. This is a backwards compatible change as there is no way for Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs would map to module name "Foo.rst" but module name "Foo.rst" maps to filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst is lowercase and module names have to start with an uppercase letter. > > Pros: > - Tool authors can more easily determine non-haskell content of literate haskell files > - Currently valid module names will not break > - Report doesn't specify behaviour, so GHC can do whatever it likes > > Cons: > - Someone has to implement it > - ?? > > Discussion: 4 weeks > > Cheers, > Merijn > From merijn at inconsistent.nl Sat Aug 16 21:05:55 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Sat, 16 Aug 2014 14:05:55 -0700 Subject: Revival: PROPOSAL: Literate haskell and module file names In-Reply-To: <37030b7f674d4804b551a9c57753d586@EXMBX31.ad.utwente.nl> References: , <37030b7f674d4804b551a9c57753d586@EXMBX31.ad.utwente.nl> Message-ID: <7DB6F353-D3E5-4A44-9B73-2EAA2BEE9A89@inconsistent.nl> Hey Philip, This proposal is not because *GHC* needs to know anything about markdown/rST, in fact, GHC is already perfectly happy to take a literate haskell files that?s written in markdown, since it just strips the non-haskell bits and only compiles the haskell code. The problem is OTHER tools. For example, I have literate haskell files for my blog posts, how does my blog software know whether my lhs file is markdown, rST, TeX, or what not? I can just name my files using anyway I want (like ?Foo.md.lhs?) to have these tools detect the format, but then GHC will no longer compile my files. This is the problem I?m trying to solve with this proposal, once we settle on some extension format like this, it?s trivial to patch (for example) pandoc to use this to detect which contents are in the file. Cheers, Merijn On 16 Aug 2014, at 06:51 , p.k.f.holzenspies at utwente.nl wrote: > Dear Merijn, > > Do you even need a separate extension or filename convention for this? Can't you just call it lhs and expand the definition thereof to include markdown? (I suggested something similar before, but objections were raised that having too good and too broad an unlitter might lead to the bit-rot of the flag to employ external unlitters. I didn't quite understand that objection, but didn't pursue it) > > Regards, > Philip > > > ________________________________________ > Van: Glasgow-haskell-users namens Merijn Verstraaten > Verzonden: zaterdag 16 augustus 2014 00:40 > Aan: haskell-prime at haskell.org; glasgow-haskell-users at haskell.org > Onderwerp: Revival: PROPOSAL: Literate haskell and module file names > > Ola! > > I raised this proposal earlier this year and got to busy to follow up, this week I was suddenly reminded and decided to reraise this. To summarise the discussion up until this point: > > There was no real opposition to the general idea, the only real objection to the original proposal was that ?Foo.lhs.md? and ?Foo.md.lhs? would collide with the naming scheme used by JHC on case insensitive filesystems. Alternative proposal raised during the discussion: "Foo+md.lhs", "Foo.lhs+md? and ?Foo.md+lhs?. > > According to MS documentation and testing the + should not be an issue on windows, the + doesn?t collide with any other haskell compiler (at least, not any I?m aware off) and since the report doesn?t specify any module name resolution mechanism, it does not conflict with the report either. > > My personal preferences goes to either ?.lhs+md? or ?.md+lhs?, since GHC currently tries every alternative in turn, I propose to just extend this list to look for any file whose extension is ?.lhs+*? or ?.*+lhs?. > > Are there any objections to this? If not, I?m just going to produce a patch + ticket as there were no real objections to the proposal last time. > > Cheers, > Merijn > > On 16 Mar 2014, at 05:56 , Merijn Verstraaten wrote: >> Ola! >> >> I didn't know what the most appropriate venue for this proposal was so I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right venue I welcome advice where to take this proposal. >> >> Currently the report does not specify the mapping between filenames and module names (this is an issue in itself, it essentially makes writing haskell code that's interoperable between compilers impossible, as you can't know what directory layout each compiler expects). I believe that a minimal specification *should* go into the report (hence, haskell-prime). However, this is a separate issue from this proposal, so please start a new thread rather than sidetracking this one :) >> >> The report only mentions that "by convention" .hs extensions imply normal haskell and .lhs literate haskell (Section 10.4). In the absence of guidance from the report GHC's convention of mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that exists. In general this standard is nice enough, but the mapping of literate haskell is a bit inconvenient, it leaves it completelyl ambiguous what the non-haskell content of said file is, which is annoying for tool authors. >> >> Pandoc has adopted the policy of checking for further file extensions for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets interpreted as being reStructured Text with literate haskell and .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps filenames like this to the module names Foo.rst and Foo.md, breaking anything that wants to import the module Foo. >> >> I would like to propose allowing an optional extra extension in the pandoc style for literate haskell files, mapping Foo.rst.lhs to module name Foo. This is a backwards compatible change as there is no way for Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs would map to module name "Foo.rst" but module name "Foo.rst" maps to filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst is lowercase and module names have to start with an uppercase letter. >> >> Pros: >> - Tool authors can more easily determine non-haskell content of literate haskell files >> - Currently valid module names will not break >> - Report doesn't specify behaviour, so GHC can do whatever it likes >> >> Cons: >> - Someone has to implement it >> - ?? >> >> Discussion: 4 weeks >> >> Cheers, >> Merijn >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From carter.schonwald at gmail.com Sat Aug 16 21:23:58 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 16 Aug 2014 17:23:58 -0400 Subject: Revival: PROPOSAL: Literate haskell and module file names In-Reply-To: <7DB6F353-D3E5-4A44-9B73-2EAA2BEE9A89@inconsistent.nl> References: <37030b7f674d4804b551a9c57753d586@EXMBX31.ad.utwente.nl> <7DB6F353-D3E5-4A44-9B73-2EAA2BEE9A89@inconsistent.nl> Message-ID: i personally think the .format+lhs pattern/convention is a good one, and prevents any misinterpretations that current plague literate tools + willl be treated as an unknown format rather than eagerly as .format or .lhs On Sat, Aug 16, 2014 at 5:05 PM, Merijn Verstraaten wrote: > Hey Philip, > > This proposal is not because *GHC* needs to know anything about > markdown/rST, in fact, GHC is already perfectly happy to take a literate > haskell files that?s written in markdown, since it just strips the > non-haskell bits and only compiles the haskell code. > > The problem is OTHER tools. For example, I have literate haskell files for > my blog posts, how does my blog software know whether my lhs file is > markdown, rST, TeX, or what not? I can just name my files using anyway I > want (like ?Foo.md.lhs?) to have these tools detect the format, but then > GHC will no longer compile my files. > > This is the problem I?m trying to solve with this proposal, once we settle > on some extension format like this, it?s trivial to patch (for example) > pandoc to use this to detect which contents are in the file. > > Cheers, > Merijn > > > On 16 Aug 2014, at 06:51 , p.k.f.holzenspies at utwente.nl wrote: > > Dear Merijn, > > > > Do you even need a separate extension or filename convention for this? > Can't you just call it lhs and expand the definition thereof to include > markdown? (I suggested something similar before, but objections were raised > that having too good and too broad an unlitter might lead to the bit-rot of > the flag to employ external unlitters. I didn't quite understand that > objection, but didn't pursue it) > > > > Regards, > > Philip > > > > > > ________________________________________ > > Van: Glasgow-haskell-users > namens Merijn Verstraaten > > Verzonden: zaterdag 16 augustus 2014 00:40 > > Aan: haskell-prime at haskell.org; glasgow-haskell-users at haskell.org > > Onderwerp: Revival: PROPOSAL: Literate haskell and module file names > > > > Ola! > > > > I raised this proposal earlier this year and got to busy to follow up, > this week I was suddenly reminded and decided to reraise this. To summarise > the discussion up until this point: > > > > There was no real opposition to the general idea, the only real > objection to the original proposal was that ?Foo.lhs.md? and ?Foo.md.lhs? > would collide with the naming scheme used by JHC on case insensitive > filesystems. Alternative proposal raised during the discussion: > "Foo+md.lhs", "Foo.lhs+md? and ?Foo.md+lhs?. > > > > According to MS documentation and testing the + should not be an issue > on windows, the + doesn?t collide with any other haskell compiler (at > least, not any I?m aware off) and since the report doesn?t specify any > module name resolution mechanism, it does not conflict with the report > either. > > > > My personal preferences goes to either ?.lhs+md? or ?.md+lhs?, since GHC > currently tries every alternative in turn, I propose to just extend this > list to look for any file whose extension is ?.lhs+*? or ?.*+lhs?. > > > > Are there any objections to this? If not, I?m just going to produce a > patch + ticket as there were no real objections to the proposal last time. > > > > Cheers, > > Merijn > > > > On 16 Mar 2014, at 05:56 , Merijn Verstraaten > wrote: > >> Ola! > >> > >> I didn't know what the most appropriate venue for this proposal was so > I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the > right venue I welcome advice where to take this proposal. > >> > >> Currently the report does not specify the mapping between filenames and > module names (this is an issue in itself, it essentially makes writing > haskell code that's interoperable between compilers impossible, as you > can't know what directory layout each compiler expects). I believe that a > minimal specification *should* go into the report (hence, haskell-prime). > However, this is a separate issue from this proposal, so please start a new > thread rather than sidetracking this one :) > >> > >> The report only mentions that "by convention" .hs extensions imply > normal haskell and .lhs literate haskell (Section 10.4). In the absence of > guidance from the report GHC's convention of mapping module Foo.Bar.Baz to > Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that > exists. In general this standard is nice enough, but the mapping of > literate haskell is a bit inconvenient, it leaves it completelyl ambiguous > what the non-haskell content of said file is, which is annoying for tool > authors. > >> > >> Pandoc has adopted the policy of checking for further file extensions > for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs > gets interpreted as being reStructured Text with literate haskell and > .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps > filenames like this to the module names Foo.rst and Foo.md, breaking > anything that wants to import the module Foo. > >> > >> I would like to propose allowing an optional extra extension in the > pandoc style for literate haskell files, mapping Foo.rst.lhs to module name > Foo. This is a backwards compatible change as there is no way for > Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs > would map to module name "Foo.rst" but module name "Foo.rst" maps to > filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst > is lowercase and module names have to start with an uppercase letter. > >> > >> Pros: > >> - Tool authors can more easily determine non-haskell content of > literate haskell files > >> - Currently valid module names will not break > >> - Report doesn't specify behaviour, so GHC can do whatever it likes > >> > >> Cons: > >> - Someone has to implement it > >> - ?? > >> > >> Discussion: 4 weeks > >> > >> Cheers, > >> Merijn > >> > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g9ks157k at acme.softbase.org Sat Aug 16 22:06:51 2014 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Sun, 17 Aug 2014 01:06:51 +0300 Subject: Are safe coercions safe in the sense of Safe Haskell? In-Reply-To: <28EB32BE-D64C-422E-A4A0-19E459C22584@cis.upenn.edu> References: <1408133069.19601.5.camel@idefix> <28EB32BE-D64C-422E-A4A0-19E459C22584@cis.upenn.edu> Message-ID: <1408226811.19601.13.camel@idefix> Hi, thank you for these links. Still, it is interesting that also in GHC 7.8 you can have a coerce that is considered ?Safe?, although the discussions on Trac concluded that this should not be the case. You can just import coerce via GHC.Prim, which is ?Safe-Inferred?. All the best, Wolfgang Am Freitag, den 15.08.2014, 19:40 -0400 schrieb Richard Eisenberg: > See https://ghc.haskell.org/trac/ghc/ticket/8745 and https://ghc.haskell.org/trac/ghc/ticket/8827 which discuss this problem at length. > > The short answer: It's conceivable that a role-unaware library author would have abstraction expectations that are defeated through the use of `coerce`. > > I would strongly welcome a proposal for how to make `coerce`, and hence GeneralizedNewtypeDeriving, to be considered Safe for 7.10. > > Richard > > On Aug 15, 2014, at 4:04 PM, Wolfgang Jeltsch wrote: > > > Hi, > > > > I would expect the function > > > > coerce :: Coercible a b => a -> b > > > > to be safe in the sense of Safe Haskell. However, the Data.Coerce module > > is marked ?Unsafe?. The coerce function is also available via GHC.Exts > > and GHC.Prim. The former module is marked ?Unsafe?, but the latter is > > (surprisingly) marked ?Safe-Inferred?. > > > > What are the reasons behind this? > > > > All the best, > > Wolfgang > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > From eir at cis.upenn.edu Sun Aug 17 15:26:45 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 17 Aug 2014 11:26:45 -0400 Subject: Are safe coercions safe in the sense of Safe Haskell? In-Reply-To: <1408226811.19601.13.camel@idefix> References: <1408133069.19601.5.camel@idefix> <28EB32BE-D64C-422E-A4A0-19E459C22584@cis.upenn.edu> <1408226811.19601.13.camel@idefix> Message-ID: <6F814A43-E589-4677-A1BA-55004ED65001@cis.upenn.edu> Have you tried doing this? If so, `coerce` is the least of our problems: `unsafeCoerce#` is much worse! When I just tried, GHC told me that I couldn't import GHC.Prim into a module with -XSafe enabled. So, this seems to be a documentation bug (the Haddock description of GHC.Prim indeed says "Safe Inferred"), but not a "real" bug. Let me know if you see otherwise! Thanks, Richard On Aug 16, 2014, at 6:06 PM, Wolfgang Jeltsch wrote: > Hi, > > thank you for these links. > > Still, it is interesting that also in GHC 7.8 you can have a coerce that > is considered ?Safe?, although the discussions on Trac concluded that > this should not be the case. You can just import coerce via GHC.Prim, > which is ?Safe-Inferred?. > > All the best, > Wolfgang > > Am Freitag, den 15.08.2014, 19:40 -0400 schrieb Richard Eisenberg: >> See https://ghc.haskell.org/trac/ghc/ticket/8745 and https://ghc.haskell.org/trac/ghc/ticket/8827 which discuss this problem at length. >> >> The short answer: It's conceivable that a role-unaware library author would have abstraction expectations that are defeated through the use of `coerce`. >> >> I would strongly welcome a proposal for how to make `coerce`, and hence GeneralizedNewtypeDeriving, to be considered Safe for 7.10. >> >> Richard >> >> On Aug 15, 2014, at 4:04 PM, Wolfgang Jeltsch wrote: >> >>> Hi, >>> >>> I would expect the function >>> >>> coerce :: Coercible a b => a -> b >>> >>> to be safe in the sense of Safe Haskell. However, the Data.Coerce module >>> is marked ?Unsafe?. The coerce function is also available via GHC.Exts >>> and GHC.Prim. The former module is marked ?Unsafe?, but the latter is >>> (surprisingly) marked ?Safe-Inferred?. >>> >>> What are the reasons behind this? >>> >>> All the best, >>> Wolfgang >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From g9ks157k at acme.softbase.org Sun Aug 17 20:54:56 2014 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Sun, 17 Aug 2014 23:54:56 +0300 Subject: Are safe coercions safe in the sense of Safe Haskell? In-Reply-To: <6F814A43-E589-4677-A1BA-55004ED65001@cis.upenn.edu> References: <1408133069.19601.5.camel@idefix> <28EB32BE-D64C-422E-A4A0-19E459C22584@cis.upenn.edu> <1408226811.19601.13.camel@idefix> <6F814A43-E589-4677-A1BA-55004ED65001@cis.upenn.edu> Message-ID: <1408308896.19601.34.camel@idefix> Hi, the GHC 7.8.2 installation on my machine refuses to import GHC.Prim if Safe is enabled. The locally generated documentation still claims that GHC.Prim is Safe-Inferred, though. So this seems to be indeed a documentation bug. All the best, Wolfgang Am Sonntag, den 17.08.2014, 11:26 -0400 schrieb Richard Eisenberg: > Have you tried doing this? If so, `coerce` is the least of our > problems: `unsafeCoerce#` is much worse! When I just tried, GHC told > me that I couldn't import GHC.Prim into a module with -XSafe enabled. > > So, this seems to be a documentation bug (the Haddock description of > GHC.Prim indeed says "Safe Inferred"), but not a "real" bug. > > Let me know if you see otherwise! > > Thanks, > Richard > > On Aug 16, 2014, at 6:06 PM, Wolfgang Jeltsch wrote: > > > Hi, > > > > thank you for these links. > > > > Still, it is interesting that also in GHC 7.8 you can have a coerce that > > is considered ?Safe?, although the discussions on Trac concluded that > > this should not be the case. You can just import coerce via GHC.Prim, > > which is ?Safe-Inferred?. > > > > All the best, > > Wolfgang > > > > Am Freitag, den 15.08.2014, 19:40 -0400 schrieb Richard Eisenberg: > >> See https://ghc.haskell.org/trac/ghc/ticket/8745 and https://ghc.haskell.org/trac/ghc/ticket/8827 which discuss this problem at length. > >> > >> The short answer: It's conceivable that a role-unaware library author would have abstraction expectations that are defeated through the use of `coerce`. > >> > >> I would strongly welcome a proposal for how to make `coerce`, and hence GeneralizedNewtypeDeriving, to be considered Safe for 7.10. > >> > >> Richard > >> > >> On Aug 15, 2014, at 4:04 PM, Wolfgang Jeltsch wrote: > >> > >>> Hi, > >>> > >>> I would expect the function > >>> > >>> coerce :: Coercible a b => a -> b > >>> > >>> to be safe in the sense of Safe Haskell. However, the Data.Coerce module > >>> is marked ?Unsafe?. The coerce function is also available via GHC.Exts > >>> and GHC.Prim. The former module is marked ?Unsafe?, but the latter is > >>> (surprisingly) marked ?Safe-Inferred?. > >>> > >>> What are the reasons behind this? > >>> > >>> All the best, > >>> Wolfgang > >>> > >>> _______________________________________________ > >>> Glasgow-haskell-users mailing list > >>> Glasgow-haskell-users at haskell.org > >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >>> > >> > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > From acrisciu at gmail.com Thu Aug 21 12:26:54 2014 From: acrisciu at gmail.com (Adrian Victor Crisciu) Date: Thu, 21 Aug 2014 15:26:54 +0300 Subject: hmatrix-0.16.0.4 installation problem Message-ID: Hi, I tried to upgrade from hmatrix 0.15.2.1 to hmatrix-0.16.0.4 and both cabal install and cabal configure complained about missing blas and lapack libraries. However, I do have those libraries installed, and I passed their locations through --extra-include-dirs and --extra-lib-dirs with no results. I use cabal 1.20.0.3, ghc 7.8.2 and gcc 4.4.4 on a Slackware-13.1 64-bit linux box. Any idea of what is going wrong (and how to correct it?) Thanks, Adrian-Victor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Thu Aug 21 13:15:17 2014 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 21 Aug 2014 16:15:17 +0300 Subject: hmatrix-0.16.0.4 installation problem In-Reply-To: References: Message-ID: On Thu, Aug 21, 2014 at 3:26 PM, Adrian Victor Crisciu wrote: > Hi, > > I tried to upgrade from hmatrix 0.15.2.1 to hmatrix-0.16.0.4 and both > cabal install and cabal configure complained about missing blas and lapack > libraries. However, I do have those libraries installed, and I passed their > locations through --extra-include-dirs and --extra-lib-dirs with no results. > > I use cabal 1.20.0.3, ghc 7.8.2 and gcc 4.4.4 on a Slackware-13.1 64-bit > linux box. > > Any idea of what is going wrong (and how to correct it?) > > Thanks, > Adrian-Victor. > > > A report like this is much easier to answer if it includes the actual command you ran and its output. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From acrisciu at gmail.com Thu Aug 21 13:22:58 2014 From: acrisciu at gmail.com (Adrian Victor Crisciu) Date: Thu, 21 Aug 2014 16:22:58 +0300 Subject: hmatrix-0.16.0.4 installation problem In-Reply-To: References: Message-ID: Sorry! This is the the failed cabal install command and its output: The blas (libcblas.so) and lapack (both liblapack.a and liblapack.so) are in /usr/local/lib64, so they can be easily found. And the configure script for other software did found them. cabal install --enable-documentation hmatrix Resolving dependencies... Configuring hmatrix-0.16.0.4... cabal: Missing dependencies on foreign libraries: * Missing C libraries: blas, lapack This problem can usually be solved by installing the system packages that provide these libraries (you may need the "-dev" versions). If the libraries are already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are. Failed to install hmatrix-0.16.0.4 cabal: Error: some packages failed to install: hmatrix-0.16.0.4 failed during the configure step. The exception was: ExitFailure 1 Adrian-Victor -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Thu Aug 21 13:29:55 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 21 Aug 2014 14:29:55 +0100 Subject: hmatrix-0.16.0.4 installation problem In-Reply-To: References: Message-ID: <1408627703-sup-1459@sabre> Hello Adrian, Are the header files for blas and lapack on your system? (I'm not sure what the configure script for other software was checking for.) Edward Excerpts from Adrian Victor Crisciu's message of 2014-08-21 14:22:58 +0100: > Sorry! > > This is the the failed cabal install command and its output: The blas > (libcblas.so) and lapack (both liblapack.a and liblapack.so) are in > /usr/local/lib64, so they can be easily found. And the configure script for > other software did found them. > > cabal install --enable-documentation hmatrix > > Resolving dependencies... > Configuring hmatrix-0.16.0.4... > cabal: Missing dependencies on foreign libraries: > * Missing C libraries: blas, lapack > This problem can usually be solved by installing the system packages that > provide these libraries (you may need the "-dev" versions). If the libraries > are already installed but in a non-standard location then you can use the > flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are. > Failed to install hmatrix-0.16.0.4 > cabal: Error: some packages failed to install: > hmatrix-0.16.0.4 failed during the configure step. The exception was: > ExitFailure 1 > > Adrian-Victor From acrisciu at gmail.com Thu Aug 21 13:34:25 2014 From: acrisciu at gmail.com (Adrian Victor Crisciu) Date: Thu, 21 Aug 2014 16:34:25 +0300 Subject: hmatrix-0.16.0.4 installation problem In-Reply-To: <1408627703-sup-1459@sabre> References: <1408627703-sup-1459@sabre> Message-ID: Hi, Yes, they are in /usr/local/include. Moreover, /usr/local/lib64 is a symbolic link to /usr/local/lib (as may system is a 64-bit anyway), so the libraries should be found regardless of the path they are searched on. I have atlas-3.3.8 and lapack-3.4.0. Are newer versions required? Thanks! Adrian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Aug 21 22:38:39 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 21 Aug 2014 18:38:39 -0400 Subject: hmatrix-0.16.0.4 installation problem In-Reply-To: References: <1408627703-sup-1459@sabre> Message-ID: You need to pass cabal the extra includes and extra lib dirs flags with the explicit paths to the lib and include folders that have your blas and lapack. The logic in hmatrix can only check stadard paths. On Thursday, August 21, 2014, Adrian Victor Crisciu wrote: > Hi, > > Yes, they are in /usr/local/include. Moreover, /usr/local/lib64 is a > symbolic link to /usr/local/lib (as may system is a 64-bit anyway), so the > libraries should be found regardless of the path they are searched on. > > I have atlas-3.3.8 and lapack-3.4.0. Are newer versions required? > > Thanks! > Adrian. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From acrisciu at gmail.com Fri Aug 22 09:55:00 2014 From: acrisciu at gmail.com (Adrian Victor Crisciu) Date: Fri, 22 Aug 2014 12:55:00 +0300 Subject: hmatrix-0.16.0.4 installation problem In-Reply-To: References: <1408627703-sup-1459@sabre> Message-ID: I tried the following command line: cabal install --enable-documentation --extra-include-dirs=/usr;local/include --extra-lib-dirs=/usr/local/lib hmatrix and got the following: Resolving dependencies... Configuring hmatrix-0.16.0.4... cabal: Missing dependencies on foreign libraries: * Missing C libraries: blas, lapack This problem can usually be solved by installing the system packages that provide these libraries (you may need the "-dev" versions). If the libraries are already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are. Failed to install hmatrix-0.16.0.4 cabal: Error: some packages failed to install: hmatrix-0.16.0.4 failed during the configure step. The exception was: ExitFailure 1 As I said before, the libraries for blas and lapack ARE in /usr/local/lib and the header files ARE in /usr/local/include. Is it possible for hmatrix to look for another version of atlas/blas and lapack? I have installed atlas-3.3.8 and lapack-3.4.0 Adrian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Aug 22 14:34:20 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 22 Aug 2014 10:34:20 -0400 Subject: hmatrix-0.16.0.4 installation problem In-Reply-To: References: <1408627703-sup-1459@sabre> Message-ID: What Linux distro? If you're on an unusual distro You might just need to patch the build process to look up the right names. Also have you contacted the hmatrix maintainer to ask him for help. HMATRIX does have an issue tracker on github etc On Friday, August 22, 2014, Adrian Victor Crisciu wrote: > I tried the following command line: > > cabal install --enable-documentation > --extra-include-dirs=/usr;local/include --extra-lib-dirs=/usr/local/lib > hmatrix > > and got the following: > > Resolving dependencies... > Configuring hmatrix-0.16.0.4... > cabal: Missing dependencies on foreign libraries: > * Missing C libraries: blas, lapack > This problem can usually be solved by installing the system packages that > provide these libraries (you may need the "-dev" versions). If the > libraries > are already installed but in a non-standard location then you can use the > flags --extra-include-dirs= and --extra-lib-dirs= to specify where they > are. > Failed to install hmatrix-0.16.0.4 > cabal: Error: some packages failed to install: > hmatrix-0.16.0.4 failed during the configure step. The exception was: > ExitFailure 1 > > As I said before, the libraries for blas and lapack ARE in /usr/local/lib > and the header files ARE in /usr/local/include. > > Is it possible for hmatrix to look for another version of atlas/blas and > lapack? I have installed atlas-3.3.8 and lapack-3.4.0 > > Adrian. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri Aug 22 14:38:16 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 22 Aug 2014 15:38:16 +0100 Subject: hmatrix-0.16.0.4 installation problem In-Reply-To: References: <1408627703-sup-1459@sabre> Message-ID: <1408718281-sup-333@sabre> Excerpts from Adrian Victor Crisciu's message of 2014-08-22 10:55:00 +0100: > I tried the following command line: > > cabal install --enable-documentation > --extra-include-dirs=/usr;local/include --extra-lib-dirs=/usr/local/lib > hmatrix Is that semicolon a typo? Edward From allbery.b at gmail.com Fri Aug 22 15:02:34 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 22 Aug 2014 11:02:34 -0400 Subject: hmatrix-0.16.0.4 installation problem In-Reply-To: <1408718281-sup-333@sabre> References: <1408627703-sup-1459@sabre> <1408718281-sup-333@sabre> Message-ID: On Fri, Aug 22, 2014 at 10:38 AM, Edward Z. Yang wrote: > > cabal install --enable-documentation > > --extra-include-dirs=/usr;local/include --extra-lib-dirs=/usr/local/lib > > hmatrix > > Is that semicolon a typo? It kinda has to be, they'd have gotten rather more interesting errors otherwise. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From merijn at inconsistent.nl Sat Aug 23 07:06:01 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Sat, 23 Aug 2014 00:06:01 -0700 Subject: Revival: PROPOSAL: Literate haskell and module file names In-Reply-To: References: <37030b7f674d4804b551a9c57753d586@EXMBX31.ad.utwente.nl> <7DB6F353-D3E5-4A44-9B73-2EAA2BEE9A89@inconsistent.nl> Message-ID: Right, given the lack of disagreement and past support for this I will implement whichever variant is simplest to implement/strikes my fancy and put a patch up on Trac. Cheers, Merijn On 16 Aug 2014, at 14:23 , Carter Schonwald wrote: > i personally think the .format+lhs pattern/convention is a good one, and prevents any misinterpretations that current plague literate tools + willl be treated as an unknown format rather than eagerly as .format or .lhs > > > On Sat, Aug 16, 2014 at 5:05 PM, Merijn Verstraaten wrote: > Hey Philip, > > This proposal is not because *GHC* needs to know anything about markdown/rST, in fact, GHC is already perfectly happy to take a literate haskell files that?s written in markdown, since it just strips the non-haskell bits and only compiles the haskell code. > > The problem is OTHER tools. For example, I have literate haskell files for my blog posts, how does my blog software know whether my lhs file is markdown, rST, TeX, or what not? I can just name my files using anyway I want (like ?Foo.md.lhs?) to have these tools detect the format, but then GHC will no longer compile my files. > > This is the problem I?m trying to solve with this proposal, once we settle on some extension format like this, it?s trivial to patch (for example) pandoc to use this to detect which contents are in the file. > > Cheers, > Merijn > > > On 16 Aug 2014, at 06:51 , p.k.f.holzenspies at utwente.nl wrote: > > Dear Merijn, > > > > Do you even need a separate extension or filename convention for this? Can't you just call it lhs and expand the definition thereof to include markdown? (I suggested something similar before, but objections were raised that having too good and too broad an unlitter might lead to the bit-rot of the flag to employ external unlitters. I didn't quite understand that objection, but didn't pursue it) > > > > Regards, > > Philip > > > > > > ________________________________________ > > Van: Glasgow-haskell-users namens Merijn Verstraaten > > Verzonden: zaterdag 16 augustus 2014 00:40 > > Aan: haskell-prime at haskell.org; glasgow-haskell-users at haskell.org > > Onderwerp: Revival: PROPOSAL: Literate haskell and module file names > > > > Ola! > > > > I raised this proposal earlier this year and got to busy to follow up, this week I was suddenly reminded and decided to reraise this. To summarise the discussion up until this point: > > > > There was no real opposition to the general idea, the only real objection to the original proposal was that ?Foo.lhs.md? and ?Foo.md.lhs? would collide with the naming scheme used by JHC on case insensitive filesystems. Alternative proposal raised during the discussion: "Foo+md.lhs", "Foo.lhs+md? and ?Foo.md+lhs?. > > > > According to MS documentation and testing the + should not be an issue on windows, the + doesn?t collide with any other haskell compiler (at least, not any I?m aware off) and since the report doesn?t specify any module name resolution mechanism, it does not conflict with the report either. > > > > My personal preferences goes to either ?.lhs+md? or ?.md+lhs?, since GHC currently tries every alternative in turn, I propose to just extend this list to look for any file whose extension is ?.lhs+*? or ?.*+lhs?. > > > > Are there any objections to this? If not, I?m just going to produce a patch + ticket as there were no real objections to the proposal last time. > > > > Cheers, > > Merijn > > > > On 16 Mar 2014, at 05:56 , Merijn Verstraaten wrote: > >> Ola! > >> > >> I didn't know what the most appropriate venue for this proposal was so I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right venue I welcome advice where to take this proposal. > >> > >> Currently the report does not specify the mapping between filenames and module names (this is an issue in itself, it essentially makes writing haskell code that's interoperable between compilers impossible, as you can't know what directory layout each compiler expects). I believe that a minimal specification *should* go into the report (hence, haskell-prime). However, this is a separate issue from this proposal, so please start a new thread rather than sidetracking this one :) > >> > >> The report only mentions that "by convention" .hs extensions imply normal haskell and .lhs literate haskell (Section 10.4). In the absence of guidance from the report GHC's convention of mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that exists. In general this standard is nice enough, but the mapping of literate haskell is a bit inconvenient, it leaves it completelyl ambiguous what the non-haskell content of said file is, which is annoying for tool authors. > >> > >> Pandoc has adopted the policy of checking for further file extensions for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets interpreted as being reStructured Text with literate haskell and .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps filenames like this to the module names Foo.rst and Foo.md, breaking anything that wants to import the module Foo. > >> > >> I would like to propose allowing an optional extra extension in the pandoc style for literate haskell files, mapping Foo.rst.lhs to module name Foo. This is a backwards compatible change as there is no way for Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs would map to module name "Foo.rst" but module name "Foo.rst" maps to filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst is lowercase and module names have to start with an uppercase letter. > >> > >> Pros: > >> - Tool authors can more easily determine non-haskell content of literate haskell files > >> - Currently valid module names will not break > >> - Report doesn't specify behaviour, so GHC can do whatever it likes > >> > >> Cons: > >> - Someone has to implement it > >> - ?? > >> > >> Discussion: 4 weeks > >> > >> Cheers, > >> Merijn > >> > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From acrisciu at gmail.com Sat Aug 23 22:45:48 2014 From: acrisciu at gmail.com (Adrian Victor Crisciu) Date: Sun, 24 Aug 2014 01:45:48 +0300 Subject: hmatrix Message-ID: After 3 days of frustrating trials and errors, I managed to install the new hmatrix package on Slackware 13.1. I post this message in case anyone else hits the same problem, as the process requires some alteration of the standard build process of ATLAS, LAPACK, hmatrix and hmatrix-gsl. The following steps assume that LAPACK is built against an optimized ATLAS library. 1.) By default, ATLAS builds only static libraries. However, hmatrix needs shared objects, so ATLAS should be configured with the --share option and, after the build is complete, the commands "make shared" and/ore "make ptshared" need to be issued in BUILDDIR/lib 2.) LAPACK also buils by default only static libraries and, for the same reason as above, we need position independent conde in ALL the objects in liblapack. In order to do this we need to 2.1.) Add -fPIC to OPTS, NOOPT and LOADOPT in LAPACKROOT/make.inc 2.2.) Change the BLASLIB macro in the same file to point to the optimized tatlas (os satlas) library 2.3.) Add the target liblapack.so to SRC/Makefile: ../liblapack.so: $(ALLOBJ) gfortran -shared -W1 -o $@ $(ALLOBJ) (This step is a corected version of http://theoryno3.blogspot.ro/2010/12/compiling-lapack-as-shared-library-in.html ) 3.) Change the extra-libraries line in hmatrix.cabal to read: extra-libraries: tatlas lapack 4.) Change the extra-library line in hmatrix-gsl to read: extra-libraries: gslcblas gsl Again, this procedure worked for may Slackware 13.1 linux box, but I think it will work on any decent linux machine. Thanks everyone for your time and useful comments! Adrian Victor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Sun Aug 24 23:10:22 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 25 Aug 2014 00:10:22 +0100 Subject: hmatrix In-Reply-To: References: Message-ID: <1408921782-sup-6208@sabre> Hello Adrian, This sounds like a definite bug in Cabal, in that it should report accordingly if it is looking for both static and dynamic versions of the library, and only finds the static one. Can you file a bug report? Thanks, Edward Excerpts from Adrian Victor Crisciu's message of 2014-08-23 23:45:48 +0100: > After 3 days of frustrating trials and errors, I managed to install the new > hmatrix package on Slackware 13.1. I post this message in case anyone else > hits the same problem, as the process requires some alteration of the > standard build process of ATLAS, LAPACK, hmatrix and hmatrix-gsl. The > following steps assume that LAPACK is built against an optimized ATLAS > library. > > 1.) By default, ATLAS builds only static libraries. However, hmatrix needs > shared objects, so ATLAS should be configured with the --share option and, > after the build is complete, the commands "make shared" and/ore "make > ptshared" need to be issued in BUILDDIR/lib > > 2.) LAPACK also buils by default only static libraries and, for the same > reason as above, we need position independent conde in ALL the objects in > liblapack. In order to do this we need to > 2.1.) Add -fPIC to OPTS, NOOPT and LOADOPT in LAPACKROOT/make.inc > 2.2.) Change the BLASLIB macro in the same file to point to the > optimized tatlas (os satlas) library > 2.3.) Add the target liblapack.so to SRC/Makefile: > ../liblapack.so: $(ALLOBJ) > gfortran -shared -W1 -o $@ $(ALLOBJ) > (This step is a corected version of > http://theoryno3.blogspot.ro/2010/12/compiling-lapack-as-shared-library-in.html > ) > > 3.) Change the extra-libraries line in hmatrix.cabal to read: > extra-libraries: tatlas lapack > > 4.) Change the extra-library line in hmatrix-gsl to read: > extra-libraries: gslcblas gsl > > Again, this procedure worked for may Slackware 13.1 linux box, but I think > it will work on any decent linux machine. > > Thanks everyone for your time and useful comments! > Adrian Victor. From michael at snoyman.com Mon Aug 25 10:25:47 2014 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 25 Aug 2014 13:25:47 +0300 Subject: Document for review: evaluation order and state tokens Message-ID: As part of trac ticket 9390[1], Simon PJ recommended that we try to get a document written that clarifies some of the issues regarding evaluation order, and get it included in the GHC wiki. After a few iterations with review from Simon, I've got a first "publicly consumable" version available at: https://www.fpcomplete.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens I'd appreciate any feedback on this document before I add it to the wiki. Michael [1] https://ghc.haskell.org/trac/ghc/ticket/9390 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bertram.felgenhauer at googlemail.com Mon Aug 25 18:37:57 2014 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Mon, 25 Aug 2014 20:37:57 +0200 Subject: Document for review: evaluation order and state tokens In-Reply-To: References: Message-ID: <20140825183757.GA649@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Dear Michael, Michael Snoyman wrote: > As part of trac ticket 9390[1], Simon PJ recommended that we try to get a > document written that clarifies some of the issues regarding evaluation > order, and get it included in the GHC wiki. After a few iterations with > review from Simon, I've got a first "publicly consumable" version available > at: > > https://www.fpcomplete.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens Thanks for writing this, it looks very useful. > I'd appreciate any feedback on this document before I add it to the wiki. [on unsafeDupablePerformIO] | And when the first thread completes the action, it may terminate the | execution of the other thread. I think it's worthwhile to stress that "bracket" does not help, because evaluation of the thunk in the other thread simply stops, without throwing an exception. Could you add something about unsafePerformIO inside STM? The upshot is that you get the behaviour of unsafeDupablePerformIO, except for the parallelism: When an STM transaction is interrupted to be retried, its evaluation simply stops. This is a known bug which causes real problems with FFI bindings, see https://ghc.haskell.org/trac/ghc/ticket/2401 http://www.haskell.org/pipermail/haskell-cafe/2014-February/112555.html but it has been around for a long time. Cheers, Bertram From michael at snoyman.com Tue Aug 26 08:26:49 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 26 Aug 2014 11:26:49 +0300 Subject: Document for review: evaluation order and state tokens In-Reply-To: <20140825183757.GA649@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> References: <20140825183757.GA649@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: On Mon, Aug 25, 2014 at 9:37 PM, Bertram Felgenhauer < bertram.felgenhauer at googlemail.com> wrote: > Dear Michael, > > Michael Snoyman wrote: > > As part of trac ticket 9390[1], Simon PJ recommended that we try to get a > > document written that clarifies some of the issues regarding evaluation > > order, and get it included in the GHC wiki. After a few iterations with > > review from Simon, I've got a first "publicly consumable" version > available > > at: > > > > > https://www.fpcomplete.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens > > Thanks for writing this, it looks very useful. > > > I'd appreciate any feedback on this document before I add it to the wiki. > > [on unsafeDupablePerformIO] > | And when the first thread completes the action, it may terminate the > | execution of the other thread. > > I think it's worthwhile to stress that "bracket" does not help, because > evaluation of the thunk in the other thread simply stops, without > throwing an exception. > > > Could you add something about unsafePerformIO inside STM? The upshot is > that you get the behaviour of unsafeDupablePerformIO, except for the > parallelism: When an STM transaction is interrupted to be retried, its > evaluation simply stops. This is a known bug which causes real problems > with FFI bindings, see > > https://ghc.haskell.org/trac/ghc/ticket/2401 > http://www.haskell.org/pipermail/haskell-cafe/2014-February/112555.html > > but it has been around for a long time. > > Cheers, > > Bertram > Thanks for the feedback, I've added information on both of these points to the document (STM in its own section at the bottom, as I couldn't find a good place where it fit with the existing flow). Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: