- Glasgow-haskell-users

Associated types in 6.6?
by Jim Apple 26 Nov '05

26 Nov '05

I see that associated types is already in CVS: http://article.gmane.org/gmane.comp.lang.haskell.cvs.all/19423/match=associ… Will it be in 6.6? Jim

1 0

Rebindable monads?
by Jim Apple 26 Nov '05

26 Nov '05

Where is there documentation for rebindable syntax for monads with class constraints: (>>=) :: (Foo m, Baz a) => m a -> (a -> m b) -> m b http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/9447/match=syntax The users guide seems to disallow such type signatures: http://haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#rebin… Jim

1 0

RE: Re[2]: adding to GHC/win32 Handle operations support of Unicodefilenamesand files larger than 4 GB
by Simon Marlow 26 Nov '05

26 Nov '05

On 24 November 2005 01:17, Bulat Ziganshin wrote: > so, as first step i propose to move middle-level code from GHC.Handle > to Posix.Internals, join FD type definitions, replace CString with > CFilePath where appropriate, and so on. and only after this - make > changes specific for windows. i can do it all. what you will say? Please, go ahead! Your plan to add a new platform-indpendent abstraction layer over the low-level I/O is a good one, I agree with the arguments you put forward. This will indeed make it easier to replace the Handle library in the future, too. > if my changes will be committed only to GHC 6.6 (HEAD) branch, the > problem that types of c_* functions is changed will not be a big > problem - you anyway change some interfaces between major releases. > but now i'm realized that Posix.Internals is part of libraries common > for several Haskell compilers. can such changes break their working? This is a .Internals library, so in theory you only have to look at code in the same package in order to determine whether it breaks anything. It wouldn't hurt to ask the Hugs & nhc98 folk too, just in case. > moreover, i plan to move "throwErrnoIfMinus1RetryOnBlock" to > Foreign.C.Error, and sEEK_CUR/sEEK_SET/sEEK_END - to Posix.Internals. > can it be done? I think so, but this module follows the FFI spec, so it should at the least be documented as an extension (fortunately, strictly speaking Foreign.C.Error doesn't have to always follow the FFI spec, but CError does). > -- Support for Unicode filenames and files>4GB > #ifdef mingw32_HOST_OS Note that we have had support for >4Gb files on Unix for quite some time, it is only Windows that is lacking in this regard. > in ALL the places where this feature test must take place. it will > document the code and give ability to easily find/edit all these > places if this will be needed sometime in the future If you want to make it clearer, then add new CPP symbols WIN32_UNICODE_FILENAMES WIN32_64BIT_OFFSETS these can be set based on mingw32_HOST_OS for now, but it leaves the possibility of using autoconf later. > can i also ask several questions about "new i/o" library? as i see, > this library solves 3 problems: Each of the questions you asked needs more than a one paragraph answer, and there has been a great deal of discussion on these topics in the past. For now, I'll just say that certain aspects of my prototype I/O library replacement are clearly wrong, and need redesigning (eg. creating multiple streams from a single File isn't implementable). I don't really have the bandwidth to put any serious thought into this right now, but there's nothing stopping you from modifying my proposal and/or coming up with something of your own. Cheers, Simon

2 1

RE: still has jump to fast entry point (ghc-5)
by Simon Marlow 25 Nov '05

25 Nov '05

On 24 November 2005 17:02, Malcolm Wallace wrote: > I know this will be going back a bit, but I have a problem with > compiling some code with ghc-5.04.3. The same code goes through > ghc-6.2 with no problems, and until recently there were no problems > with ghc-5.04.3 either. But a recent code change has caused the > following warning messages from ghc-5.04.3: > > still has jump to fast entry point: > r4HK_entry: > leal 12(%ebp), %eax > cmpl 84(%ebx), %eax > jbe .L55 > movl $r4HK_closure, %esi > movl -4(%ebx), %eax > .L56: > jmp *%eax > .L55: > movl 4(%ebp), %esi > addl $12, %ebp > movl $r4HK_fast2, %eax > jmp .L56 > > There are about 350kb of very similar messages: > > still has jump to fast entry point: > r3R_entry: > still has jump to fast entry point: > s4K3_entry: > > and so on. > > Does anyone have any idea what these mean, and how I might go about > fixing them? Although they are only warnings, I'd like my software > to continue to be portable to older versions of ghc if possible. It probably means you have a more recent version of gcc than was available when 5.04.3 was released, and the mangler doesn't like its output. Either, downgrade your gcc (or specify a different gcc with -pgmc), or use the later GHC. Cheers, Simon

1 0

RE: Re[2]: Patch for Word64
by Simon Marlow 25 Nov '05

25 Nov '05

On 24 November 2005 11:07, Bulat Ziganshin wrote: > Hello Matt, > > Thursday, November 24, 2005, 7:52:23 AM, you wrote: > >>>> int64ToWord64# = unsafeCoerce# >>>> word64ToInt64# = unsafeCoerce# > >> (W32# x#) + (W32# y#) = W32# (narrow32Word# (x# `plusWord#` y#)) >> (W64# x#) + (W64# y#) = W64# (int64ToWord64# (word64ToInt64# x# >> `plusInt64#` word64ToInt64# y#)) > >> The definitions are those used on a 32-bit architecture. So, when it >> is cheap the plusWord# function is used, but when it is "relatively >> expensive" then extra conversions are added. Wouldn't it make sense >> to avoid the conversions in all cases, regardless of whether they >> are free or not? > > i'm agree that code simplification you already done is anyway Right > Thing. so it's better to apply your patch AND add abovementioned > definitions to help any other operations. about int32ToWord32# and so > on - they are defined through stg primitives, so anyway defining them > as unsafeCoerce# must make things a little faster No, using a primitive for int32ToWord32# is better, because the compiler knows about primitives and can apply constant-folding. For example int32ToWord32# 0# could turn directly into a Word32# value. Also, unsafeCoerce# must be retained in the Core language, because Core is typed, even though it compiles to no code. Its presence in Core might hinder certain optimisations. We should really have proper primitives for all these 64-bit operations, rather than using FFI calls. Cheers, Simon

1 0

RE: Problems with 6.x compilers
by Simon Marlow 25 Nov '05

25 Nov '05

On 23 November 2005 15:02, kahl(a)cas.mcmaster.ca wrote: > > > 6.4 and 6.4.1: When repeating a build (with ghc --make) all > modules > > are rebuild even if nothing has changed. With > earlier compilers, > > only linking takes place in this setting. > Can I change this > > behaviour? I cannot develop this way. > > > > Should not happen, if it does there is a bug. Can you tell us how > to > repeat the behaviour you're seeing? We aren't seeing any > unecessary > recompilation here. > > I think I had that effect exactly when using -ddump-minimal-imports Thanks, that is now fixed. Cheers, Simon

1 0

still has jump to fast entry point (ghc-5)
by Malcolm Wallace 24 Nov '05

24 Nov '05

I know this will be going back a bit, but I have a problem with compiling some code with ghc-5.04.3. The same code goes through ghc-6.2 with no problems, and until recently there were no problems with ghc-5.04.3 either. But a recent code change has caused the following warning messages from ghc-5.04.3: still has jump to fast entry point: r4HK_entry: leal 12(%ebp), %eax cmpl 84(%ebx), %eax jbe .L55 movl $r4HK_closure, %esi movl -4(%ebx), %eax .L56: jmp *%eax .L55: movl 4(%ebp), %esi addl $12, %ebp movl $r4HK_fast2, %eax jmp .L56 There are about 350kb of very similar messages: still has jump to fast entry point: r3R_entry: still has jump to fast entry point: s4K3_entry: and so on. Does anyone have any idea what these mean, and how I might go about fixing them? Although they are only warnings, I'd like my software to continue to be portable to older versions of ghc if possible. Regards, Malcolm

1 0

RE: problem using ghc-6.5.20051122-i386-unknown-linux.tar.bz2
by Konovalov, Vadim 24 Nov '05

24 Nov '05

... > > Indeed, the compiler I have has version gcc-3.3.4, and this > > mismatches with gcc-3.4.3, also > > > > How should I avoid this problem? > > Why having that precise requirement of GCC version? > > Sorry, that bundle is the output from our nightly build > process, and we > sometimes test specific gcc versions to ensure compatibility. You can > use '-pgmc gcc-3.3.4', or build the sources yourself using ghc 6.4.1. thanks. I was only afraid that it was newly introduced incompatibility, thanks for explanations. There *is* newly introduced incompatibility, though, so PUGS is not built with a following message: .... No context is allowed on a GADT-style data declaration (You can put a context on each contructor, though.) Build failed: 256 at util/build_pugs.pl line 86. But this is probably a subject of different question. Best regards, Vadim.

1 0

RE: Checking for WHNF (a horrible naughty thing)
by Simon Marlow 24 Nov '05

24 Nov '05

On 23 November 2005 18:29, Sigbjorn Finne wrote: > The appended snippet might help.. > > --sigbjorn > > -- whnf.hs > import Foreign.StablePtr > import System.IO.Unsafe > > isWHNF :: a -> Bool > isWHNF a = unsafePerformIO $ do > stl <- newStablePtr a > rc <- isWhnf stl > freeStablePtr stl > return (rc /= 0) > > foreign import ccall safe "isWhnf" isWhnf :: StablePtr a -> IO Int > > /* whnf.c */ > #include "Rts.h" > int > isWhnf(StgStablePtr st) > { > StgClosure* c = (StgClosure*)(stable_ptr_table[(StgWord)st].addr); > return !(closure_THUNK(c)); > } using deRefStablePtr() would be slightly better. Also, you should consider whether you want indirections to be counted as WHNF or not. Also, I think you can make that foreign import "unsafe" (safe will be slow). For more speed you could implement it directly as a primitive. Cheers, Simon

1 0

RE: problem using ghc-6.5.20051122-i386-unknown-linux.tar.bz2
by Simon Marlow 24 Nov '05

24 Nov '05

On 23 November 2005 18:00, Konovalov, Vadim wrote: > I downloaded ghc-6.5.20051122-i386-unknown-linux.tar.bz2 and tried to > use it (as bootstrap for building Haskell at first, but building Pugs > fails the same way) > > It installed fine. > > My attempts to compile something with it result with a following > error: > > ghc-6.5.20051122: could not execute: gcc-3.4.3 > <<ghc: 16599408 bytes, 3 GCs, 123124/123124 avg/max bytes residency (1 > samples), 15M in use, 0.00 IN > IT (0.00 elapsed), 0.11 MUT (0.21 elapsed), 0.02 GC (0.03 elapsed) > :ghc>> > > Indeed, the compiler I have has version gcc-3.3.4, and this > mismatches with gcc-3.4.3, also > > How should I avoid this problem? > Why having that precise requirement of GCC version? Sorry, that bundle is the output from our nightly build process, and we sometimes test specific gcc versions to ensure compatibility. You can use '-pgmc gcc-3.3.4', or build the sources yourself using ghc 6.4.1. Cheers, Simon

1 0