Re: Avoiding BlockedIndefinitelyOnSTM exceptions
Gabriel Is the underlying issue one of “scope” - STM variables have global scope, would a batter approach to be to create scope of such things and then some overall recovery mechanism could handle such an exception within that scope? Neil On 14 Jul 2014, at 03:30, Gabriel Gonzalez gabriel...@gmail.com wrote: I have what may sound like an unusual request: I would like to automatically avoid `BlockedIndefinitelyOnSTM` exceptions with a primitive that looks something like this: safe :: STM a - STM (Maybe a) This hypothetical `safe` primitive would attempt a transaction, and if `ghc` detects that this transaction would fail because of an `BlockedIndefinitelyOnSTM` exception it will return `Nothing` instead of throwing an uncatchable exception. I originally simulated a limited form of this behavior using `pipes-concurrency`. I instrumented the garbage collector (using weak references) to detect when an STM variable was garbage collected and to safely cancel any transactions that depended on those variables. You can see the implementation here: https://github.com/Gabriel439/Haskell-Pipes-Concurrency-Library/blob/23e7e2dab472b7e4cde7bea31227a917ce5d5375/src/Pipes/Concurrent.hs#L170 The original purpose behind this was to easily read and write to a channel without having to count references to the channel. I reasoned that the garbage collector *already knew* how many open references there were to channel, so I thought why not use the garbage collector to gracefully cancel transactions that would block just before they would trigger the exception? This worked really well up until ghc-7.8 changed something and the above trick no longer works. To be honest, I'm surprised that it ever worked at all, which is why I'm not requesting restoring the original behavior. Instead, I think providing something like the above `safe` primitive would be nicer, if possible. Would it be possible to implement something like `safe`? Alternatively, is it possible to make the `BlockedIndefinitelyOnSTM` exception catchable? P.S. I'm also interested in learning more about what may have caused the change in behavior in the transition from ghc-7.6 to ghc-7.8. What changes were made to the interaction between STM and weak references that may have triggered this? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cross compiling for Cortex A9
On 07/12/14 07:27 AM, Michael Jones wrote:
Karel,
I have failed to figure out how to make this happen:
(target arch, ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI =
HARD}”)
This is result of running ./configure on arm/ubuntu12.04 -- so I don't
cross-compile, but rather compile natively. This is still preferred way
to be able to run testsuite AFAIK...
I have added poky to the list of vendors in aclocal.m4 then configured like
this:
/configure --target=arm-poky-linux-gnueabi --with-gcc=arm-poky-linux-gnueabi-gcc
But I end up with ARMv5.
I am new to Autotools and the Haskell build system, so I am not sure what
controls this. I assume the idea is that the gcc cross-compiler compiles some
code that checks for versions when it evaluates stuff like:
AC_COMPILE_IFELSE([
AC_LANG_PROGRAM(
[],
[#if defined(__ARM_ARCH_2__) || \
defined(__ARM_ARCH_3__) || \
defined(__ARM_ARCH_3M__) || \
defined(__ARM_ARCH_4__) || \
defined(__ARM_ARCH_4T__) || \
You arm-poky-linux-gnueabi-gcc -v tells what? Also
arm-poky-linux-gnueabi-gcc -dM -E - /dev/null may tell you something.
So I then suspect the compiler needs options like -mcpu=cortex-a9 -mfpu=neon to
make the proper version defined, so that the code can check the architecture.
It depends on how the compiler is configured. -v will tell you. Mine
looks like:
karel@panda:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a
--with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb
--disable-werror --enable-checking=release --build=arm-linux-gnueabi
--host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
Please note --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16
--with-mode=thumb -- I'm sure you will also be able to build a
cross-compiler using those option, so it'll generate ARMv7A code by
default, use just half of VFPv3 regs (VFPv3-D16) and generate Thumbs
isns by default (not ARM).
Karel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine
Hi, I'm having problems installing the OS X bindist of GHC 7.8.3 on my machine. Here are the specs for my machine: Hardware: MacBook Pro, 13-inch, Mid 2009 Operating System: OS X 10.8.5 gcc: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Note that I only have the Xcode 4 CLI tools installed, not Xcode 4 itself. The line that fails is: /usr/bin/gcc -E -m64 -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs -P -DINSTALLING -DLIB_DIR='/opt/ghc/7.8.3/lib/ghc-7.8.3' -DINCLUDE_DIR='/opt/ghc/7.8.3/lib/ghc-7.8.3/include' -DPAPI_INCLUDE_DIR= -DPAPI_LIB_DIR= -DFFI_INCLUDE_DIR= -DFFI_LIB_DIR= '-DFFI_LIB=Cffi' -x c -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header rts/package.conf.in -o rts/dist/package.conf.install.raw cc1: error: unrecognized command line option -Wno-invalid-pp-token cc1: error: unrecognized command line option -Wno-unicode make[2]: *** [rts/dist/package.conf.install] Error 1 make[1]: *** [install] Error 2 make: *** [install] Error 2 Earlier in the configuration process I see: checking XCode version... xcode-select: Error: No Xcode is selected. Use xcode-select -switch path-to-xcode, or see the xcode-select manpage (man xcode-select) for further information. not found (too old?) Could that be the culprit? The entire installation log can be found here: https://gist.github.com/christiaanb/ec06e93fa16fdfdb5fa3 -- Christiaan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine
On Mon, Jul 14, 2014 at 4:53 AM, Christiaan Baaij christiaan.ba...@gmail.com wrote: cc1: error: unrecognized command line option -Wno-invalid-pp-token cc1: error: unrecognized command line option -Wno-unicode Those are clang options, for what it's worth. It seems to be defaulting to Xcode 5 / clang if xcode-select fails; it should probably test against /usr/bin/gcc directly for that case. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Fwd: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine
FWIW Mark had this reply but is apparently not subscribed to, or being rejected by, ghc-users and asked me to forward it. -- Forwarded message -- From: Mark Lentczner mark.lentcz...@gmail.com Date: Mon, Jul 14, 2014 at 7:34 AM Subject: Re: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine To: Christiaan Baaij christiaan.ba...@gmail.com Cc: glasgow-haskell-users glasgow-haskell-users@haskell.org Yes - this is a known problem in GHC (#9257 https://ghc.haskell.org/trac/ghc/ticket/9257) The problem is that there is one gcc invocation in the make install step (!) and that the clang/gcc detection isn't applied at bindist configuire time. Hence, that gcc invocation is based on the compiler of the machine that built the bindist (clang), not the compiler of the machine it is being installed on (gcc). Note that this doesn't affect the installed GHC system: The compiler detection at bindist configure time *is* applied to the ghc tree it installs, just not the bindist make itself! Work around is very easy: make install CC_CLANG_BACKEND=0 - Mark -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Avoiding BlockedIndefinitelyOnSTM exceptions
I don't quite understand your question, but I'll try to give a fuller explanation of the problem I was trying to solve to see if it perhaps answers your question. The motivation behind `pipes-concurrency` was to make it easy for readers and writers to coordinate implicitly (using the garbage collector) instead of explicitly. Here's an example of code that people would use `pipes-concurrency` to write: main = do (output, input) - spawn Single a1 - async $ runEffect $ someProducer - toOutput output a2 - async $ runEffect $ fromInput input - someConsumer mapM_ wait [a1, a2] For people unfamiliar with `pipes` or `pipes-concurrency`, what the above code does is it `spawn`s a `TMVar` that you can read or write. Then it forks two threads, one of which feeds some values to the `TMVar` and the other of which reads some values from the `TMVar`. What was neat about the way `pipes-concurrency` works is that: * If `someProducer` produces fewer values than `someConsumer` requests from `TMVar`, then `someConsumer` would detect that and gracefully terminate instead of trying to read a value from the now-permanently-empty `TMVar`. * If `someConsumer` consumes fewer values than `someProducer` feeds to the `TMVar` then `someProducer` would detect that and gracefully terminate instead of trying to write a new value to the now-permanently-full `TMVar`. Note that throwing an exception to either of these threads is not a suitable substitute for graceful termination in more sophisticated examples. The rationale behind graceful termination is to allow running more logic in these threads after they are done reading or writing from the STM variable. My feeling is that the garbage collector already knows that these reads or writes are doomed, so why not make use of that knowledge to gracefully recover from doomed transactions? On 07/14/2014 12:19 AM, Neil Davies wrote: Gabriel Is the underlying issue one of “scope” - STM variables have global scope, would a batter approach to be to create scope of such things and then some overall recovery mechanism could handle such an exception within that scope? Neil On 14 Jul 2014, at 03:30, Gabriel Gonzalez gabriel...@gmail.com wrote: I have what may sound like an unusual request: I would like to automatically avoid `BlockedIndefinitelyOnSTM` exceptions with a primitive that looks something like this: safe :: STM a - STM (Maybe a) This hypothetical `safe` primitive would attempt a transaction, and if `ghc` detects that this transaction would fail because of an `BlockedIndefinitelyOnSTM` exception it will return `Nothing` instead of throwing an uncatchable exception. I originally simulated a limited form of this behavior using `pipes-concurrency`. I instrumented the garbage collector (using weak references) to detect when an STM variable was garbage collected and to safely cancel any transactions that depended on those variables. You can see the implementation here: https://github.com/Gabriel439/Haskell-Pipes-Concurrency-Library/blob/23e7e2dab472b7e4cde7bea31227a917ce5d5375/src/Pipes/Concurrent.hs#L170 The original purpose behind this was to easily read and write to a channel without having to count references to the channel. I reasoned that the garbage collector *already knew* how many open references there were to channel, so I thought why not use the garbage collector to gracefully cancel transactions that would block just before they would trigger the exception? This worked really well up until ghc-7.8 changed something and the above trick no longer works. To be honest, I'm surprised that it ever worked at all, which is why I'm not requesting restoring the original behavior. Instead, I think providing something like the above `safe` primitive would be nicer, if possible. Would it be possible to implement something like `safe`? Alternatively, is it possible to make the `BlockedIndefinitelyOnSTM` exception catchable? P.S. I'm also interested in learning more about what may have caused the change in behavior in the transition from ghc-7.6 to ghc-7.8. What changes were made to the interaction between STM and weak references that may have triggered this? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cross compiling for Cortex A9
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@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine
Thanks, the work-around did the trick. On 14 July 2014 16:34, Mark Lentczner mark.lentcz...@gmail.com wrote: Yes - this is a known problem in GHC (#9257 https://ghc.haskell.org/trac/ghc/ticket/9257) The problem is that there is one gcc invocation in the make install step (!) and that the clang/gcc detection isn't applied at bindist configuire time. Hence, that gcc invocation is based on the compiler of the machine that built the bindist (clang), not the compiler of the machine it is being installed on (gcc). Note that this doesn't affect the installed GHC system: The compiler detection at bindist configure time *is* applied to the ghc tree it installs, just not the bindist make itself! Work around is very easy: make install CC_CLANG_BACKEND=0 - Mark ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Fwd: how to get ghci to load compiled modules in 7.8?
I sent this to haskell-cafe, but there was no response. On stackoverflow there was no response either. I'm trying one last time, but adding ghc-users (which I should have done at the beginning!). Surely it can't be that no one knows how to load modules in ghci? I know a lot of work was done to enable this, as in https://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault, it seems a waste if no one actually knows how to use it! The 7.8.1 release notes make reference to -dynamic-too, and an unexplained Dynamic Ghci, but implies ghci should just work. Do I need to compile ghci myself in a dynamic way? The DynamicByDefault page also implies that, but I assumed the binary distributions would come with it compiled the right way. This has almost disabled ghci for my work (it can be used, but very slowly and with much retyping of commands, and I find myself avoiding the REPL now), so it's a big regression from 7.6! I added another paragraph from the stackoverflow question. Also, I can't get this to work on linux either, not just OS X. BTW, I got a nice bump in my profiles after upgrading, so 7.8 is mostly good news. Just this one awkward thing keeps it from being all good news. -- Forwarded message -- I recently upgraded to 7.8.2 and I have a silly question. How do you get ghci to load compiled modules? When I try this: % cat T.hs module T where x :: Int x = 42 % ghc -c -dynamic-too T.hs % s T.dyn_hi T.dyn_o T.hi T.hs T.o % ghci GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Prelude :l T [1 of 1] Compiling T( T.hs, interpreted ) Ok, modules loaded: T. *T It still loads the file interpreted, even though there is a .dyn_o present. What am I doing wrong? This is on x86-64 OS X. There is one other thing which may be related. Since I load everything interpreted now, I've noticed that the input gets very laggy when I have a hundred or so modules loaded. Also the haskeline state gets confused, e.g. I hit escape k to get the previous line, but then it spontaneously goes back into insert mode again. It stays balky and awkward for about 15 seconds before returning to normal slightly. It's almost as if, after loading all the bytecode, it's still doing tons of work in the background, with constant GC freezes. But what work could it be doing? The bytecode is loaded and I haven't asked it to do anything yet! I don't know if this is new to 7.8, or if it's a result of loading bytecode instead of binary. Update: loading with -fobject-code to force compilation reduces some of the balkiness, but some is still there! So maybe this is a regression from 7.6? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to get ghci to load compiled modules in 7.8?
On Mon, Jul 14, 2014 at 1:08 PM, Evan Laforge qdun...@gmail.com wrote: I sent this to haskell-cafe, but there was no response. On stackoverflow there was no response either. I'm trying one last time, but adding ghc-users (which I should have done at the beginning!). Surely it can't be that no one knows how to load modules in ghci? I know a lot of work was done to enable this, as in https://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault, it seems a waste if no one actually knows how to use it! See https://ghc.haskell.org/trac/ghc/ticket/8736. The current workaround for GHC 7.8 is to compile with -dynamic, not -dynamic-too. Regards, Reid Barton ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to get ghci to load compiled modules in 7.8?
On Mon, Jul 14, 2014 at 10:36 AM, Reid Barton rwbar...@gmail.com wrote: See https://ghc.haskell.org/trac/ghc/ticket/8736. The current workaround for GHC 7.8 is to compile with -dynamic, not -dynamic-too. That was it! Thanks so much. As an aside, I was kind of expecting a faster link time due to -dynamic, but apparently not. Oh well, I'm happy enough ghci is back. One thing, how about an addition to the release notes in the -dynamic-too section saying By the way, this doesn't actually work, see https://ghc.haskell.org/trac/ghc/ticket/8736.; I'll go update my stackoverflow question. I'm a little surprised, no one else seems to use ghci, or I'd think there would be lots of shouting about this. Or maybe no one has upgraded to 7.8 yet. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to get ghci to load compiled modules in 7.8?
On Mon, Jul 14, 2014 at 11:13 AM, Evan Laforge qdun...@gmail.com wrote: As an aside, I was kind of expecting a faster link time due to -dynamic, but apparently not. Oh well, I'm happy enough ghci is back. Aha, I needed to pass -dynamic when linking too. Sorry for the noise. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to get ghci to load compiled modules in 7.8?
On Mon, Jul 14, 2014 at 11:13 AM, Evan Laforge qdun...@gmail.com wrote: On Mon, Jul 14, 2014 at 10:36 AM, Reid Barton rwbar...@gmail.com wrote: See https://ghc.haskell.org/trac/ghc/ticket/8736. The current workaround for GHC 7.8 is to compile with -dynamic, not -dynamic-too. That was it! Thanks so much. Actually... not quite. -dynamic seems let ghci load, but when I load with the GHCI API, I get this: compile error: interactive session: cannot find normal object file ‘build/debug/obj/Util/Contro.o’ while linking an interpreted expression The proper name is 'Control.hs.dyn_o', so it looks like the suffix mangling code is getting confused. I must be doing something different than ghci anyway, because I have to pass -dynamic in the GHCI API to load, while ghci doesn't seem to need it. And of course ghci doesn't get the mangled filename. One thing is that I'm using '-osuf .hs.o', which is a bit confusing, since it should actually be '.hs.o_dyn', but there's no -odynsuf and I don't really know how all the name mangling in there works. I'll take a look in the ghci code to see how it's doing things. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to get ghci to load compiled modules in 7.8?
On Mon, Jul 14, 2014 at 12:35 PM, Evan Laforge qdun...@gmail.com wrote: Actually... not quite. -dynamic seems let ghci load, but when I load with the GHCI API, I get this: compile error: interactive session: cannot find normal object file ‘build/debug/obj/Util/Contro.o’ while linking an interpreted expression Ack.. I keep doing this. It turns out this goes away if I link with '-dynamic' too. I had turned it off when playing the flag permutation game. So I think I finally have everything working now! Still, the Contro.o thing does look buggy. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Why no `instance (Monoid a, Applicative f)= Monoid (f a)` for IO?
It seems to me that this should be true for all `f a` like: instance (Monoid a, Applicative f)= Monoid (f a) where mappend = liftA2 mappend mempty = pure mempty But I can't seem to find the particular `instance (Monoid a)= Monoid (IO a)` anywhere. Would that instance be incorrect, or does it live somewhere else? FWIW I noticed this when I started thinking about an instance I wanted for 'contravariant': instance (Monoid a, Applicative f)= Monoid (Op (f a) b) where mempty = Op $ const $ pure mempty mappend (Op f) (Op g) = Op (\b- liftA2 mappend (f b) (g b)) at which point I realized (I think) all `f a` are monoidal, and so we ought to be able to get the instance above with just a deriving Monoid. Brandon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
