Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2
What are the plans for http://hackage.haskell.org/trac/ghc/ticket/5623 which seems to be still open? Quoting form the ticket ... Just to spam a little more, it seems that the HEAD happily duplicates all computations on unboxed types. It even duplicates x+x in this example: foo :: Float - Float foo x = let y = x+x in y+yI haven't tested but this looks bad for performance critical code. Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
Ian Lynagh ig...@earth.li schrieb im Newsbeitrag news:20110729182136.ga2...@matrix.chaos.earth.li... We are pleased to announce the first release candidate for GHC 7.2.1: Is it normal for the windows build to have 99 unexpected failures? http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-stable/289.html Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc 6.12.3: Data.Array.Diff and package diffarray
Hello, According to the release notes there is a new package that now contains the module Data.Array.Diff. According to Ian's commit this package is called diffarray. This package does not seem to be available on Hackage. Could someone upload it? Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] ghc as a library and profiling
Simon Marlow [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Yes, by default we don't build or supply the GHC package with profiling, because of the extra bloat it would add to the downloads and the time taken to build it. Why is a program so large when I use the GHC module? Under windows with GHC 6.6.1 I get a 17MB executable, whereas the ghc executable itself is only around 7MB. Surely the GHC as a library shouldn't make the executable larger as GHC itself?? Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Feature request/help: evaluating template haskell at runtime
Hello, I am attempting some genetic programming in Haskell. Rather than defining my own data type for programs and writing my own interpreter, I want to use the template haskell expression data types and evaluate them with the rts's byte code interpreter. This gives me a nice fast interpreter that provides the statistics that I want. I could pretty print the template haskell and then execute the result string using the GHC module or hs-plugins, but I would like to save the pretty printing and parsing as normally the program generation time is important by GP. I have being looking at module TcSplice. I see that I need to run the TH expression through function convertToHsExpr, but after that I am stuck. This produces LHsExpr RdrName and I need to get CoreSyn.CoreExpr. What functions to use? dsLExpr :: LHsExpr Id - DsM CoreSyn.CoreExpr seems one important step, but I haven't figured out how to get from LHtsExpr RdrName to LHsExpr Id. It would be nice to have standard GHC functionality to have the ability to compile and evaluate template haskell at runtime using the GHC library. Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans: esc branch
What are the plans for the esc branch? Are the changing going to be merged? Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
I vote for 6.8. Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] GHC Error question
There may be a heuristic that would help more programs to go through... but I prefer asking the programmer to make the desired behaviour explicit. Simon How can the user make this explicit? With the class C a b where op :: a - a instance C Int Int where op a = -a test d = op d example, I have been unable to figure out what type annotations I need to add to 'test', for exampl,e to define test to be for the C Int Int instance. Or is it simply impossible in GHC to give test a type signature and to use it as a useful function? Example ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: building GHC (head) on windows MINGW: HsRegexPosixConfig.h: Nosuch file or directory
Brian Smith" [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED]... On 9/30/06, Rene de Visser [EMAIL PROTECTED] wrote: What do I need to install for the regex library support on MINGW?It looks like the regex library needs the posix library, and in my MINGW /MSYS installation I don't find one(and neither does configure). I have not run into this problem with the regex library but I ran into a similar one when building network. Did you get the regex library after you had already run autoreconf? If so, you need to run autoreconf and ./configure again in the ghc root directory. Hello, I seem to have worded myself poorly. I don't have regex.h on my system. And that seems to be the problem. It doesn't come standard with Mingw and MSYS. Where do I get a posix regex library for Mingw/MSYS? Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: (Windows) ANNOUNCE: GHC 6.6 Second Release Candidate
Ian Lynagh [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] http://www.haskell.org/ghc/dist/current/dist/ Hello Ian, Is it on purpose that the lastest windows build does not include cabal-install? Since the September builds I don't see any logs for the mingw build? Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
building GHC (head) on windows MINGW: HsRegexPosixConfig.h: No such file or directory
Hello, What do I need to install for the regex library support on MINGW? It looks like the regex library needs the posix library, and in my MINGW / MSYS installation I don't find one (and neither does configure). Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
more fixups for GHC docs: ddump flags
The flags under section 4.17.26. Compiler debugging options seem to be out of date. They seem to be wrong for both 6.42 and 6.6 For example --ddump-cmm is not listed, but works. But --ddump-absC is listed, and gives the error unknown flag. I can't get -ddump-stix to work either. Gone, or renamed, or only works in combination with other flags? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: small errors in ghc 6.6
Tomasz Zielonka [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] BTW. The -fno-recomp option has a very unintuitive name, at least for me. When I see -fno-recomp, my brain thinks no recompilation, meaning no unneccesary recompilation, which is what --make does by default. Using -fno-recomp causes all modules to be recompiled, whether they changed or not. I think one of -frecomp or -fno-recomp-checking would be much clearer. But it's probably too late to change that... I believe this is worth fixing. Everytime I see -fno-recomp I always read it as no recompilation. A synonym could be added in 6.6. I would suggest -fforce-recomp for force recompilation. In 6.8 -fno-recomp could be flagged as obsolete. In 7.0 it could be removed. Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
internal error: asyncRead#, ghci and fps (windows) (trac 806)
Is there anyway to turn off that ghci runs in threaded mode on windows? fps 0.8 (and software that uses fps) triggers trac error #806. This means that I cannot run such things interactively :-( Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Program slower with local definitions
Michael Marte [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Hello *, I noticed a five percent speed up by making local definitions global. Maybe the global defintions are monomorphic, and the local defintions are polymorphic. You could evaluate the types of the global types and apply them to the local definitions to see if that then gives the same result. (just guessing). Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: instance overlap in 6.6 candidate
Simon Peyton-Jones [EMAIL PROTECTED] schrieb im Newsbeitrag | | This gives the user possibility to redefine a certain part of the | library instance. | Is not ghc-6.4.1 better at this point? Perhaps. That's what I'd like feedback about. What do others think? ... Simon What are the disadvantages of compiling every library with -fallow-overlapping-instances? Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.5 error? Illegal polymorphic or qualified type
Hello, I tried to compile HAppS using the latest GHC snapshot (in compiles fine with 6.41). I for example get the error /home/rene/repos/HAppS/src/HAppS/MACID/Var.hs:23:0: Illegal polymorphic or qualified type: forall state event. Ev state event (ref t) In the type signature for `newEmptyRef': newEmptyRef :: (Monoid t, Ref ref) = AnyEv (ref t) Note that AnyEv is defined as type AnyEv a = forall state event. Ev state event a This should be OK shouldn't it? At least in works in 6.41 and everythis is quantified. Exactly what does the error message Illegal polymorphic or qualified type mean? Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
inside the GHC code generator
The following link gives reasons for not generating via C http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=4zp8kn7xe.fsf_-_%40beta.franz.com Naturally a number of these are common lisp specific, however I think that Haskell and GCC are quite semantically different, so using GCC might prevent a lot of optimizations, that aren't possible in C, but would be in GHC. The OCAML-OPT backend is supposed to produce i386 assembly that is competitive with GCC. Maybe this could be ported to GHC? Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: inside the GHC code generator
seems that you don;t understand the situation. ghc compiles Haskell to language called core, do almost all optimizations at level of this language, then translates final result to the STG language from that the C-- code is generated. changing the translation of STG can't prevent ANY ghc optimization. although iy is not so easy because ghc code generation and RTS closely tied together I should have been a bit clearer here. I meant that optimizations that are available from STG - Assembler, are better than STG - C - Assembler. GHC currently doesn't do most of the optimizations I am thinking of. -- Bit tagging to reduce pointer chasing, speed up pattern matching. Due to memory latency and speed it is quicker to do bit masking rather than memory reads -- Parameter passing and regisgter usage opimizations that rely on the structure of the RTS. -- Multiple stacks with custom frame layout. -- dynamic code optimization etc. -- Taking advantage of special assember instructions and flags. Though I have also seen comments that you can do a lot of these with GCC if you do your own stack and parameter management. i.e. don't use the C stack at all. Though your suggestions are probably better than nothing, which is probably what the alternative is (for instance I have not sufficient time to work on these things). Note that I didn't say that the assembly generation of OCAML was better than GCC, just that it was comparable. Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: inside the GHC code generator
From: Bulat Ziganshin [EMAIL PROTECTED] Hello Rene, i done reading. my question - is YOU read this? the lisp problems have almost nothing in common with haskell It is a long time since i read this, but some things come to mind. Listed below. Maybe GHC should generate better C. I am just not sure whether this will bring the best global (as opposed to micro-optimizations) performance. However doing anything else might be difficult. Generating better C might also be much more difficult for idioms that don't exist in C, and might encourage people to write Haskell that looks like C (in order to get C like performance). I prefer idiomatic Haskell. It would be nice if this could be fast. But can idiomatic Haskell be translated to efficient C? It might not have many direct loops for example. -- Other notes Integer is about 30 times slower than it needs to be on GHC if you have over half the values between 2^-31 and 2^31. On i386 can you basically can test the low bit for free (it runs in parallel to the integer add instruction). This would allow only values outside this range to required calling the long integer code. Such an optimization is not easily done in C. This encourages Haskell programmers to always use Int, even if the value might get too big, because Integer is too slow. Also Tail recursion is more general than looping. A general tail call optimization will bring better returns than a loop optimization in GHC (though I could be wrong here). This requires special stack handling. Also not so easy in C. If only simple loops are optimized it will encourage people to always code loops in their haskell rather than perhaps using more appropriate constructs. Also take the Maybe data type with Nothing and Just ... or any other datatypes with 0 and 1 variable constructors. Here these could be represent by special values for the 0 variable case and bit marking on the single constructor values. This could lead to good optimizations on case expressions. Also not so easy in C. The lack of this feature encourages people to encode their datatypes as Int's to get speed. Also not good. Whether we can communicate the non aliasing and aliasing properties of GHC to the C compiler, I am also not so sure. Also in GHC, I am not sure whether stack base locals are the best move. It might be best to have a fixed page as register spill in some cases. If you wish to pass and return unboxed tuples without reboxing you will probably required a special function interface with double entry points (I think this can be done in C, but it is a bit tricky). Summary: If only C like Haskell is fast, we end up with Haskell that looks like C. Yuck. Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Re[2]: inside the GHC code generator
From: Bulat Ziganshin [EMAIL PROTECTED] i answered in the original letter (search for Cray :) Re-reading this, I see that you have a well defined goals that cover most of my points. seems that you don't seen the attached files. tail calls are optimized in gcc No I don't see any attached files (on any of your emails). Best of luck with your optimisations. I will look forward to using them. (Although I don't like the style of the shootout code, I find it very useful in helping me speed up my own code, and yes I find it better in write Haskell in such a style, than to use FFI and call C). Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Proposal: Improved error message of Error in array index
One idea that occurred to us recently is this: GHCi could provide a simplified version of the cost-centre-stack machinery *all the time*, Simon This still doesn't explain to me why C:\Haskell\devmain +RTS -xc gave GHC.Arr.CAFmain: Error in array index (This is with full profiling turned on) This sort of stack is not going to help anyone. What I think would be good is the ability to compile the executable with a top level exeception handler which goes into a low level debugger where you can examine the thunk and its surroundings. I presume that some type information is retained for the garbage collector? Enough to tell integers from pointers? Also error Error in array index ++ internal_show_b b ++ internal_show_i i could be done, which wouldn't have the problem of exporting unwanted show instances. Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Proposal: Improved error message of Error in array index
I suggest that the code in GHC.Arr be changed from error Error in array index to error Error in array index ++ show b ++ show i so that the bounds and offending index is shown. This is easy to do as the information is already available, and would in most cases be of great help to the user in guessing which code was causing the error. Background: I have some stochastic estimation code which after a few hours running produces this error. I then recompiled with full profiling and did C:\Haskell\devmain +RTS -xc main +RTS -xc GHC.Arr.CAFmain: Error in array index Not very usefull, though I wouldn't have guessed that the code containing the error code in GHC.Arr is reduced to a CAF. Further details: If I do 100 simulations it runs OK. If I do 1000 simulations it produces the above error. There is no case where the array indicies depend on the number of simulations (I simply accumulate results). In my case I can probably figure out where the error occurs, as it must be an event with probability between 1e-6 and 1e-7 which In my case gives me a clue (I hope I guess correctly). But in other situations the only chance I guess would be to recompile GHC as I suggest above. Due to the high number of simulations required and the long running time, finding the error by bisection would be tedious. Adding debugging code would probably increase the run time to days instead of hours. Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Array operations and pinning
Hello,
Where is the documentation on how pinning works in the GHC garbage collector
(from a GHC users point of view).
I have copied the following code from array/IO.hs and am thinking that it is
assuming that the array is pinned? What triggers the pinning?
On a second note.
Why is the type signiture so constricted. The code below works on any
IOUArray (which is very usefull, not just on Int Word8). Naturally this
assumes the particular in memory array layout that GHC uses on a particular
platform, so would not be compatible (probably) with other Haskell
compilers.
Rene.
hPutArray
:: Handle -- ^ Handle to write to
- IOUArray Int Word8-- ^ Array to write from
- Int -- ^ Number of 'Word8's to write
- IO ()
hPutArray handle (IOUArray (STUArray l u raw)) count
| count == 0
= return ()
| count 0 || count rangeSize (l,u)
= illegalBufferSize handle hPutArray count
| otherwise
= do wantWritableHandle hPutArray handle $
\ [EMAIL PROTECTED] haFD=fd, haBuffer=ref, haIsStream=stream } -
do
[EMAIL PROTECTED] bufBuf=old_raw, bufRPtr=r, bufWPtr=w, bufSize=size
}
- readIORef ref
-- enough room in handle buffer?
if (size - w count)
-- There's enough room in the buffer:
-- just copy the data in and update bufWPtr.
then do memcpy_baoff_ba old_raw w raw (fromIntegral count)
writeIORef ref old_buf{ bufWPtr = w + count }
return ()
-- else, we have to flush
else do flushed_buf - flushWriteBuffer fd stream old_buf
writeIORef ref flushed_buf
let this_buf =
Buffer{ bufBuf=raw, bufState=WriteBuffer,
bufRPtr=0, bufWPtr=count, bufSize=count }
flushWriteBuffer fd stream this_buf
return ()
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
