compiling ghc w/o ghc
Hello , i've seen the following report from a man who tried to compile 6.8.1 under linux without having any ghc installed: checking for ghc... no checking for path to top of build tree... ./configure: line 2724: -v0: command not found ./configure: line 2728: utils/pwd/pwd: No such file or directory line 2724: $WithGhc -v0 --make pwd -o pwd the $WithGhc variable is empty afaiu, configure should stop at the moment when previous ghc isn't found (he was extracted ghc-6.8.1-src-extralibs.tar.bz2 and ghc-6.8.1-src.tar.bz2 if that matter) -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[2]: Data.HashTable.hashInt seems somewhat sub-optimal
Hello Jan-Willem, you may be interested to read hashing papers mentioned at http://www.encode.ru/forums/index.php?action=vthreadforum=1topic=413 -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[4]: Data.HashTable.hashInt seems somewhat sub-optimal
Hello Jan-Willem, Thursday, August 30, 2007, 4:28:28 PM, you wrote: http://www.encode.ru/forums/index.php?action=vthreadforum=1topic=413 Not only did I read them, I tried out the Bob Jenkins hash function! i don't propose to use this function, this page just contain a lot of various hash functions together with discussions. in particular, there is info about multiplicative hash which is close to your hashing scheme -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[2]: [GHC] #1002: ghc-6.6 sometimes hangs under Solaris
Hello GHC, Thursday, November 16, 2006, 4:47:02 PM, you wrote: But last night my ghc-6.6 job hung around for about 2 hours but continued. real122m20.462s user5m49.133s sys 0m20.322s my unix knowledge is far from perfect, but may be these times means swap trashing? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[2]: [GHC] #994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
Hello GHC, Monday, November 13, 2006, 3:18:13 PM, you wrote: Unsafe.Coerce. Later proposals might want to move some of the Array and IO operations into this new Unsafe.* hierarchy as well. it seems that you misunderstood situation: you will need to move whole Array implementation to such Unsafe.* module because it is base on the unsafeRead/Write operations. you _cannot_ export only safe operations from Data.Array.* hierarchy and then add unsafe ones in other place -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1000: Refactor HPC support
Hello GHC, Monday, November 13, 2006, 4:24:19 PM, you wrote: #1000: Refactor HPC support -+-- Reporter: simonmar | Owner: yes! you are our 1000's customer and wins an ability to got next 1000 bugs absolutely free! :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #989: Windows native port
Hello GHC, Monday, November 6, 2006, 2:12:25 PM, you wrote: * Convert the pretty printer in the i386 NCG to generate MS/Intel syntax instead of ATT syntax. We can then generate assembly code that MASM can grok. may be i will look into it. for me main problem is to compile ghc itself, but if i will finally arrange this, at least i know both assemblers i'm very interested in implementing this ticket because intel с compiler for windows in visual с -compatible and it is the compiler that generates fastest code in the world (+10% against gcc, afaik). so if my C libraries that i link to haskell program, will be able to compile via intel c, my program should become 10% faster (it's speed inn't depended on haskell code) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Ticket #800 in GHC 6.6
Hello Cyril, Friday, November 3, 2006, 4:55:37 PM, you wrote: It looks like bug #800 http://hackage.haskell.org/trac/ghc/ticket/800 has made it to GHC 6.6. Although Trac reports that it was solved about a month ago in version 6.5, I still see that GHC 6.6 on Windows fails to compile C++ files. A little test and the output follow. Is the bug, by any chance, fixed in any of the nightly builds of the 6.6 branch? ghc/mingw 6.6 anyway doesn't include c++ compiler (and 6.4.2 too) i sucessfully used with both ghc version gcc included in the following archive: http://citkit.dl.sourceforge.net/sourceforge/dev-cpp/devcpp-4.9.9.2_setup.exe of course, in this case you will need to pass all the required params manually if this bug will be fixed, it will be possible to copy just cc1plus.exe and c__ library to the ghc 6.6 installation directory in order to allow ghc compiler cpp files -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: no happy
Hello Christian, Friday, November 3, 2006, 7:46:40 PM, you wrote: Hi Bulat, thanks for your answer, but the code in LALR.lhs:626:34 (happy-1.15) lacks a monad for getBounds (or I'm blind): in this case you should just import Data.Array.Base and define getBounds yourself -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: cabal, extralibs, no happy
Hello Christian, Wednesday, November 1, 2006, 6:12:32 PM, you wrote: 3. the happy-1.15 sources can not be compiled due to http://haskell.org/ghc/docs/6.6/html/users_guide/release-6-6.html # The HasBounds class has been removed from Data.Array.Base, and its bounds method is now in the IArray class. The MArray class has also gained a method getBounds. # Is there any easy fix? may be this will be useful: -- This equalizer routine required because MArray interface was changed in GHC 6.6 #if defined(__GLASGOW_HASKELL__) (__GLASGOW_HASKELL__ = 605) getMBounds arr = getBounds arr #else getMBounds arr = return (bounds arr) #endif usage example: putMArrayWith write h arr= do bounds - getMBounds arr loop 0 (rangeSize(bounds)-1) (\i - unsafeRead arr i = write h) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[2]: [GHC] #942: Windows programs throw uncaught Invalid HANDLE exception on exit
Hello Sigbjorn, Tuesday, October 31, 2006, 10:04:52 PM, you wrote: is that means that current 6.6 precompiled snapshots like http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20061031-i386-unknown-mingw32.tar.gz should work fine? this problem is very important for me too I fixed this one a week or two ago on the 6.6 branch -- http://www.haskell.org/pipermail/cvs-ghc/2006-October/032154.html Have not had the timespace to drag it over to HEAD since then. hth --sigbjorn GHC wrote: #942: Windows programs throw uncaught Invalid HANDLE exception on exit +--- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System |Version: 6.6 Severity: major | Resolution: Keywords: uncaught exception HANDLE exit | Difficulty: Unknown Testcase: N/A | Architecture: x86 Os: Windows | +--- Changes (by [EMAIL PROTECTED]): * severity: normal = major Comment: I've changed the severity to major because I feel this bug prevents me distributing any binaries compiled under ghc6.6 for Windows, since whether or not the bug is visible (ie if you choose to run the binary under a debugger), obviously something is very wrong indeed with the runtime or else it wouldn't be trying to use an invalid handle (or cause one of the windows DLLs to do so) at program exit. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
smart relinking bug
Hello Simon, ghc 6.6 includes smart relinking capability which don't relink exe file if it already exists and .hs source files was not changed. that's great but ignores other .o files that can be also linked to program, for example those that was compiled from C sources: gcc -c -o a.o a.c ghc --make Main.hs a.o this command incorrectly don't relinks executable if a.c was changed but Main.hs wasn't -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[2]: smart relinking bug
Hello Lemmih, Saturday, October 21, 2006, 8:11:02 PM, you wrote: gcc -c -o a.o a.c ghc --make Main.hs a.o this command incorrectly don't relinks executable if a.c was changed but Main.hs wasn't Did you mean a.o instead of a.c? if a.c changes then first line will recompile it and change a.o too :) for '--make' command a.o will be changed and main.hs remains old -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
{- INLINE range #-}
Hello bugs,
GHC.Arr contains strange quasi-pragmas that missing # in '{-#'
sequence. is it a bug or just a way to temporarily disable pragma?
instance (Ix a, Ix b) = Ix (a, b) where -- as derived
{- INLINE range #-}
range ((l1,l2),(u1,u2)) =
[ (i1,i2) | i1 - range (l1,u1), i2 - range (l2,u2) ]
{- INLINE unsafeIndex #-}
unsafeIndex ((l1,l2),(u1,u2)) (i1,i2) =
unsafeIndex (l1,u1) i1 * unsafeRangeSize (l2,u2) + unsafeIndex (l2,u2) i2
{- INLINE inRange #-}
inRange ((l1,l2),(u1,u2)) (i1,i2) =
inRange (l1,u1) i1 inRange (l2,u2) i2
--
Best regards,
Bulat mailto:[EMAIL PROTECTED]
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[2]: [GHC] #710: library reorganisation
Hello GHC,
Wednesday, September 27, 2006, 9:32:37 PM, you wrote:
* Problem using `--make` when compiling the base package ([ticket:
#909]).
it will be really great. now, afaiu, i can't work on this package
without building entire GHC
* We'd lose the ability to do parallel module building within each
library ([ticket: #910]).
it don't have anything common with this ticket, imho
* Currently the implementations don't agree on what `Read` is, as the new
`ReadP` requires rank-2 or rank-n polymorphism. I am told Haskell' will
have one or the other, so this will come in time.
we are not developing H98 library. we have very practical goal - make
common lib for commonly used haskell compilers. at this moment, i
think, ghc/hugs/nhc/yhc/jhc should be targeted and all they have it
in common, i think that it will be better to require implementation of
R2P from any compiler that want to use base lib. and i'm sure that at
least R2P will be included in H' because it is used in runST and ReadP
* For the deps from common packages to impl-specific packages we
obviously need some sort of conditional support in Cabal.
it is by itself very important ability, we already discussed this. but
for compiler dependencies we can use just custom Setup.hs like this:
-- This custom Cabal build script adds Win32 package to the list of
-- dependencies if we build on the Windows platform
main = do pkg_descr_file - defaultPackageDesc
pkg_descr - readPackageDescription pkg_descr_file
let isWindows = mingw `isPrefixOf` System.Info.os
config = if isWindows
then pkg_descr { buildDepends = Dependency Win32
AnyVersion
: buildDepends pkg_descr
}
else pkg_descr
defaultMainNoRead config
* The code used by default class definitions needs to be pretty low down
in the hierarchy, and in particular `fail s = error s` in the `Monad`
class pulls in the huge exception type. This might be simplified with an
extensible exception replacement?
* Standalone deriving declarations (separate from the data declaration)
make some things a lot easier. I think bringert has a working
implementation for GHC, but it only truly helps if it's in all impls;
something for Haskell'?
i think it's great feature and definitely should be proposed for H'
standard
* It's unfortunate that we can't make imported and exported class
instances explicit, so the compiler won't be checking that we are giving
consistency across impls.
please mention that all this deals with type classes. and the
`base-types-classes` package too. i believe that we can write vase
package without type classes or at least without type classes exposed
to user. type class don't add new functionality, it just provides
simpler access to the existing one
throwing out type classes means that we should write `intMul` instead
of '*' but that is not much loss for such fundamental lib. i think
that core lib should export just functions and types but not operators
nor classes, which should be defined in application libs. this will
allow to make alternate implementations without going into
compiler-specific details. say, for Char it's enough to define
int2Char, char2Int, minCharBound, maxCharBound and then all the instances
for Enum, Ord and likewise classes can be defined in portable way
are you know any examples of compiler-dependent code (i.e. in GHC.*)
that can't be rewritten in class-less way?
In what follows, I haven't given a huge amount of thought to names, but I
don't think there's any need to do so yet.
My conclusions were that ultimately something like this would be good
(with impl replaced with ghc, hugs, ...):
* `impl-prim` at the bottom; defines things like the `Int` type
(basically all the types and functions needed by the next layer.
* `base-types-classes` next, which just have class declarations but
probably no instances.
* `impl-base next`; This is where all GHC's instances with `I#`'s etc
would go.
* `base` on top of that, with anything that can't be forked off into
another package.
this is a smart design, implying that we need type classes in base
package. pros for your design:
* base package already uses classes in compiler-dependent code so it
may be easier to implement
* class-using code is definitely simpler and more readable ('*' vs intMul)
pros for my design:
* it uses two layers instead of four
* it leaves room to make any definitions of base classes in
application libraries. suppose that i want to implement new Read
class. it will look strange with your design. although, on the other
side, compiler deriving mechanism can't work with alternative class
definitions too...
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Glasgow-haskell-bugs mailing list
Re[2]: [GHC] #806: hGetBufNonBlocking doesn't work with -threaded on Windows
Hello GHC, Monday, September 25, 2006, 4:55:52 PM, you wrote: #806: hGetBufNonBlocking doesn't work with -threaded on Windows is not it the same problem as my favorite http://hackage.haskell.org/trac/ghc/ticket/637 ? i.e. lack of separate IO Manager thread makes it impossible to implement hGetBufNonBlocking? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #870: extra commas accepted in import export lists
Hello GHC,
Saturday, August 19, 2006, 9:46:38 PM, you wrote:
GHC accepts non-standard imports like
{{{
import M (,,foo,,,bar,,,)
}}}
as Duncan said, it's Good Thing. i permanently use this trick in the
export lists. it's much better to change Haskell standard :)
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #840: GHC on loosing its handles takes 100% CPU
Hello GHC, Wednesday, August 2, 2006, 4:33:09 PM, you wrote: #840: GHC on loosing its handles takes 100% CPU import System.Process main = runInteractiveCommand ghc When run terminates immediately, as expected, but leaves an instance of ghc running. The ghc process takes up 100% of the CPU time, and seemingly does nothing. well, i have similar problem: there are only 256 megs on my machine and sometimes when ghc compilation uses more than 200 megs and starts trashing memory, i tries to stop it by hitting Ctrl-C. in this situation it's rather typical that i got back my console (and rerun ghc) but old GHC process don't killed and continue to compile program. i can investigate it further but don't know what to do. at least it seems that memory trashing is required to uncover this problem. i also should note that i run ghc --make from the .cmd file so there is a whole stack of processes runned. may be i just kill higher-level ghc (or even cmd) and lower-level ghc still continue to do it's job? i'm not sure.. -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
lack of automatic recompilation after library updating
Hello glasgow-haskell-bugs, i just reinstalled FPS library with new version downloaded via darcs (both old and new versions are 0.7, difference is few days only) i run the following to update lib: runghc Setup.hs unregister runghc Setup.hs clean runghc Setup.hs build runghc Setup.hs install and then i try to rebuild my app. it does not feels that FPS library was updated and don't recompiled modules that use it. can this be considered as bug? ghc 6.4.2/windows -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[2]: Bug with Char.isAlpha
Hello Simon, Wednesday, May 31, 2006, 5:57:26 PM, you wrote: This looks like some kind of input problem: I get the same results as you when using a Windows command shell, but not when using an xterm or Prelude '§' '\245' but '\245' is not the § character, it is the õ character. So the command shell has done some translation before GHCi even saw the character. windows? :) it's the wisest system in the world about Char encodings. once i counted that my console program use 5 (FIVE!) different encodings. in particular, ANSI codepage for cmdline and filenames, OEM codepage for console I/O. you should use SetConsoleCodepage system call (afaik, this way you can even set UTF-8 encoding) to switch console to using ANSI CP or you can translate your inputoutput between OEM codepage and what you actually need -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #770: Huge array leads to various crashes
Hello GHC, Friday, May 12, 2006, 2:48:41 PM, you wrote: Component: Runtime System |Version: 6.5 20:32 dons:: array (minBound,maxBound) (zip [0..] (repeat ())) :: Array Int () i'm pretty sure that it's a bug in array library, because it first constructs array of 2^31*4 = 0 bytes (modulo 2^32), and then tries to use unsafe indexing operations on it. moreover, 6.4 should suffice form the same problem ... well, i wrote about problem for unboxed arrays (i should test it), while you reported bug in boxed arrays what is a really problem in GHC's newArray# implementation -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc releasing memory during compilation
Sunday, March 12, 2006, 8:00:05 PM, you wrote: ghbrho Subject: ghc releasing memory during compilation ghbrho Am I right in thinking that ghc's rts can free memory back to the system ghbrho when the heap pressure reduces (at least if it's doing a compacting GC)? ghbrho In this case if it can do so, it should be quite dramatic. It'd ought to ghbrho be able to go from 400Mb back down to just a few Mb or so. i've suggested the same just 11 months ago. after long discussion Simon Marlow declined my proposal because this will raise gc times in the situations when memory is enough by whole 10%! when i suggested just to check available PHYSICAL memory he answered that he don't know that is physical memory, only virtual memory matters sorry for my style, but i've proposed rather detailed solution of this problem and i'm discontented what i was not heard at that time :( ... you can find details in thread starting with the following letter: 2) if, for example, program's data before GC is 80 mb and after GC is 60 mb then the program will occupy after GC the whole 140 mb and ALL this space will be marked by OS as used! if there's a memory shortage, old program data even can be swapped to disk despite the fact that we absolutely don't need them! that behaviour significantly enlarge memory needs of GHC-compiled programs if this unused memory will be returned to OS or marked as unneeded after GC then will problem will go on. preferably this must be done during the time of GC, on each page which contents has been already compacted. in this case such program will never use more than 80mb of real memory (+ 1 page + memory for GC) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
TH bug
Hello ,
attempt to compile this module:
{-# OPTIONS_GHC -fglasgow-exts -fth #-}
import Language.Haskell.TH
f = match [p|0|] [|return ()|] []
produce the following error:
ghc.EXE: panic! (the `impossible' happened, GHC version 6.4.1):
typecheck/TcSplice.lhs:(128,0)-(150,44): Non-exhaustive patterns in
function tc_bracket
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
--
Best regards,
Bulat mailto:[EMAIL PROTECTED]
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[2]: bug report
Hello Simon, Wednesday, January 04, 2006, 11:22:50 AM, you wrote: Simon, look at [EMAIL PROTECTED] part of this SimonM's letter: If anyone is interested, this turned out to be a bug in the Network.BSD module, namely that getHostByName isn't thread safe because it is based on the C library function gethostbyname(), which returns data in a single static area. SPJ Meanwhile, you've definitely hit a bug. Can you make a reproducible SPJ test case so we can look into it? SPJ | a.out: internal error: scavenge_stack: weird activation record found SPJ on stack: 6 SPJ | Please report this as a bug to glasgow-haskell-bugs@haskell.org, SPJ | or http://www.sourceforge.net/projects/ghc/ SPJ | SPJ | I'm not sure whether or not it makes a difference, but I got the error SPJ | message above directly after the following error message: SPJ | SPJ | a.out: getHostByName: does not exist (no such host entry) SPJ | SPJ | I've been able to determine that this is not a sporadic error. In SPJ | fact, this happens every time I get a getHostByName: does not exist SPJ | (no such host entry) error message. I can make this happen whenever I SPJ | want. SPJ | -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[2]: Signal inconsistency between GHC and GHCi
Hello Sven, Sunday, January 01, 2006, 2:27:01 PM, you wrote: [ usleep/nanosleep trouble deleted... ] may be you comile with -threaded? ghci don't use this option, afaik SP The SIGALRM happen with purely interpreted code and even without loading any SP code at all into GHCi... :-( i say that your COMPILED code works ok because it uses -threaded, but GHCi fails because it just never use this option -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci module list
Hello Frederik, Wednesday, December 21, 2005, 4:11:21 AM, you wrote: FE On an aside, I was wondering about the feasibility of having some sort FE of feature resembling Octave's (and probably Matlab's) function FE files implementation, in which modified files are automatically FE reloaded by the interpreter. I guess a timestamp check could happen FE for each loaded module before ghci executes each new piece of FE command-line input. I wonder how useful people think this would be. it implemented in hugs (at least winhugs) and i found it very handy -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-6.4.1: panic - Prelude.last: empty list
Hello Einar,
Sunday, October 30, 2005, 4:20:20 PM, you wrote:
EK I am having problems with GHC 6.4.1 dying with the message:
EK ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1):
EK Prelude.last: empty list
EK The source is nontrivial and contains template haskell. The error
EK seems to appear after byte code generation.
are you will be glad to see trivial source of this problem? :)
{-# OPTIONS_GHC -fglasgow-exts -fth #-}
module Main where
main = return ()
$( [d| |] = return.tail)
C:\!\Haskell\ghc --make -ddump-splices test-derive.hs
Chasing modules from: test-derive.hs
Compiling Main ( test-derive.hs, test-derive.o )
Loading package base-1.0 ... linking ... done.
Loading package haskell98-1.0 ... linking ... done.
Loading package template-haskell-1.0 ... linking ... done.
ghc.EXE: panic! (the `impossible' happened, GHC version 6.4.1):
Prelude.tail: empty list
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
as you see, TH sometimes just don't caught exceptions in your TH code.
moreover, with -ddump-splices TH can print code it generated and only
then panic on error in generation routine!
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
bug in ghc-6.4-src\libraries\base\Data\Version.hs
bug in ghc-6.4-src\libraries\base\Data\Version.hs: instance Eq Version where v1 == v2 = versionBranch v1 == versionBranch v2 all (`elem` (versionTags v2)) (versionTags v1) -- tags may be in any order this really checks that v1.tags is subset of v2.tags. must be changed to import Data.List( intersperse, sort ) instance Eq Version where v1 == v2 = versionBranch v1 == versionBranch v2 sort (versionTags v1) == sort (versionTags v2) -- tags may be in any order -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[2]: the impossible happened
Hello Tomasz, Monday, May 23, 2005, 1:49:03 PM, you wrote: TZ It seems that there are not that many uses of fromJust in GHC's sources. TZ I guess that removing them or at least making them report a source TZ location in case of failure (for example using a CPP macro like in TZ darcs) would be an good task for a wannabe GHC hacker. Unfortunately, TZ I can't volunteer at this moment. imho, addition of filename/linenumber to all standard function failures (head [] and so on) will be VERY useful. only last days i goes thorough searching two such errors - one with maximum and second also with maximum :) i have luck to use this function only in several places, so my debugging was nearly straightforward, but addition of linenumber to error message would be very helpful - just like message about pattern matching failure give us the immediate place of problem also it will be cool to have ability to add such annotations to my own functions, smthg like: head (x:xs) = x head [] = superError head [] which will print: Error: head [] in Module.hs:155 -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[2]: the impossible happened
Hello Donald, Monday, May 23, 2005, 4:06:08 PM, you wrote: also it will be cool to have ability to add such annotations to my own functions, smthg like: head (x:xs) = x head [] = superError head [] which will print: Error: head [] in Module.hs:155 DBS You can do this already with GHC.Base.assert (almost): sorry, i want to get message with linenumber where head was CALLED, not defined -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[4]: the impossible happened
Hello Simon, Monday, May 23, 2005, 6:46:14 PM, you wrote: SPJ | head (x:xs) = x SPJ | head [] = superError head [] SPJ | SPJ | which will print: Error: head [] in Module.hs:155 SPJ A difficulty is that the caller of 'head' might itself be called from SPJ somewhere else: you are right. i forget that it needs run-time support SPJ It's all very like cost-centre stacks, which is why GHC provides the -xc SPJ option when you are profiling. I think that give you what you want --- SPJ but you have to compile your program profiled. i never used -prof, so i can't comment this. btw, -prof is not compatible with -threaded, at least in my distribution (i guess that it may be just lack of appropriately compiled libraries) SPJ Another take on this is that you want an implicit parameter SPJ head :: (%loc :: Location) = [a] - a SPJ so that 'head' can report %loc when it fails. Now you'd need to give SPJ rules to say where %loc is bound. It'd be a pretty magic kind of SPJ implicit parameter. Or should it be a stack of locations? of course, stack! it's look very beatiful. calling stack in lazy language - that will be amazing! :-) i foresee that this implicit parameter, if it will be added to GHC, may also be used for other debugging purposes but it's not obvious which calls we must keep in this stack. to be exact, it's possible to save tail-recursed calls while omitting indirect-recursive calls (which also will be tail-recursive)? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[2]: Feature request: Windows ZIP Distribution
Hello Sigbjorn, Wednesday, May 18, 2005, 8:38:55 PM, you wrote: SF The 6.4 installer has a UI bug that may prevent you from using SF it on a box where you don't have admin privs. Try starting up the installer, SF hit Next, followed by Back. That should bring up a dialog letting you choose SF whether to perform a user or machine wide installation. Select the former nice bug! :) you can cut installer size in 1.5-2 times by repacking it with another compressor - LZMA. i tried this on the your 6.4 distribution and whole installed directory was packed down to 26 megs to get this work you can either switch to Nullsoft installer, which has support for LZMA, or create self-extracting module with help of 7-zip (www.7-zip.org) anf include this self-extractor in your installer in order to test lzma compression, download abovementioned 7-zip and try it on some directory with the following cmdline: 7z a archive -r -mx9 -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[2]: Feature request: Windows ZIP Distribution
Hello Sigbjorn, Thursday, May 19, 2005, 9:18:56 PM, you wrote: SF That's an impressive reduction in size; compressing the SF CAB file inside the MSI using the LZW-based compressor SF that Microsoft provides with their 'makecab' utility didn't LZX (very different from LZW, born long ago, in 1984) btw, while writing this letter i compressed GHC 6.4 installation with cabarc. it results in 33 megs only (!). may be when you creating your installation, you are using MSZIP compression instead of LZX? or you compress with LZX:15, i.e. with minimal 32 kb dictionary instead of LZX:21? SF make much of a difference in size (but increased compression SF time quite a bit.) I'm idly speculating that LZMA's larger dictionaries SF is what's paying off here. the difference is also in format of compressed data. in particular, lzma use arithmetic instead of huffman compression to futher compress data SF I'm not planning on switching to 7-Zip in the near future though. you are not understood me. with help of 7-zip you can create EXE-file, which will self-extract all the compressed files when runned (it's much like to that any installer does). so you can either: 1) use microsoft installer but include just one self-extracting EXE file in it. so in beginning of installation this EXE must be runned, it will create all the dustributed files and then normal installation procedure will arrange all other tasks 2) use Nullsoft installer which can compress files with LZMA. of course, in this scenario ypu will need to rewrite all installation scripts/configs to deal with new installer-creation software 3) you can also use 7-zip's own installation-creating facility, which is based on it's SFX. afaik, this installer just extracts all files in archive and then runs program you specified, so in this case you must arrange all installation tasks by hand-made program SF However, I think Brian Smith's suggestion of offering up a SF .zip'ed up version of the GHC distribution tree is a good SF one plan to do that for the next release. It can then be used SF to derive other distribution/installer formats. i think that other distributions can easily be created by just installing current one and then compressing ghc-6.4 directory with appropriate archiver. or i am wrong? in any case, if you can provide lzma-based distribution in any form (some installer or just .7z archive) i will bw very grateful. my bandwidth is 56K only :( btw, if you are interested in playing with lzma and other modern compression algorithms included in your own program, you can download Compression'2005 library from http://freearc.narod.ru -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
GHC 6.4/mingw32: files larger than 4 GB and hFileSize/hSetFileSize/c_stat
While GHC I/O library on mingw32 platform perfectly reads and writes files larger than 4 GB, functions hFileSize/c_fstat, hSetFileSize/c_ftruncate and c_stat are still tied to C functions returning 32 bit values and as a result truncate larger sizes to their low 32 bits. Can this behaviour be fixed in the next bug-fix version? -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
