November 2005 - Glasgow-haskell-users

RE: GHC-6.4.1 on FreeBSD-amd64 port progress
by Simon Marlow 30 May '06

30 May '06

On 25 October 2005 10:01, Wilhelm B. Kloke wrote: > Simon Marlow <simonmar(a)microsoft.com> schrieb: >> On 24 October 2005 19:04, Wilhelm B. Kloke wrote: >> >> Is it that it does not find the libraries, or does it find the >> libraries but still gets a bunch of undefined references? If the >> latter, then there could be an issue with the mangler. Try an 'nm' >> on libHSbase.a to see if the missing symbols are actually defined. > > Nm shows that the problem may come from splitting. The missing symbols > are marked as locals (small d); being in different .o modules they > are not resolved. Try with splitting off: set SplitObjs=NO in your mk/build.mk. Cheers, Simon

3 2

RE: Associated types in 6.6?
by Simon Peyton-Jones 29 Nov '05

29 Nov '05

| Is that because GHC's TIL is not exactly System F? It's an extension of System F (e.g. with data types, existentials, GADTs). But we're not sure it's the right extension yet. Stay tuned. | > As ever, we tend to work harder on things that folk appear to want; | | Unrelated question: will "boxy" types allow forall-quantified types in | instance declarations? Have not thought about that; do offer examples of how useful it'd be. Simon

1 0

RE: Associated types in 6.6?
by Simon Peyton-Jones 29 Nov '05

29 Nov '05

| I see that associated types is already in CVS: | | http://article.gmane.org/gmane.comp.lang.haskell.cvs.all/19423/match=ass ociated | | Will it be in 6.6? I hope so but I am not sure. The trick lies in coming up with a suitable typed intermediate representation for the program -- System F isn't enough. Manuel Chakravarty and Martin Sulzmann and I have been working on an idea, but it's not yet clear whether we'll have it worked out and implemented at the same time as 6.6. As ever, we tend to work harder on things that folk appear to want; so anyone who is keen on associated types, do sing out and describe your application a bit. Simon

3 2

calling system gives exception, waitForProcess
by Neil Mitchell 28 Nov '05

28 Nov '05

Hi, On Windows XP, with GHC 6.4.1, I get the following error consistently when calling "system", from the module System. I get this error on two entirely different computers, one slow (750Mhz) system, and one fast (3Ghz) system. Its easiest to demonstrate when using GHCi, but the problem also occurs when running Haskell programs compiled with GHC. Prelude System> system "yhi Main" PreludeList.!!: on empty list *** Exception: waitForProcess: does not exist (No such file or directory) >From a windows standard console, in the same current directory, I get: Windows> yhi Main PreludeList.!!: on empty list When calling yhi using system in other circumstances (on other programs), it works fine. The "PreludeList.!! ..." text is being generated by the yhi program. The yhi program is written in C, and is available from http://www.cs.york.ac.uk/~ndm/yhc/. Unfortunately this is probably a bit too large to use as a minimal test case, and takes quite a while to install/configure at the moment. Any idea why the waitForProcess error is being raised? Thanks Neil

1 0

RE: Rebindable monads?
by Simon Peyton-Jones 28 Nov '05

28 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=synt ax | | The users guide seems to disallow such type signatures: | | http://haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#re bindable-syntax I don't think it's in 6.4. Here's the documentation from the HEAD. Simon 7.3.5. Rebindable syntax GHC allows most kinds of built-in syntax to be rebound by the user, to facilitate replacing the Prelude with a home-grown version, for example. You may want to define your own numeric class hierarchy. It completely defeats that purpose if the literal "1" means "Prelude.fromInteger 1", which is what the Haskell Report specifies. So the -fno-implicit-prelude flag causes the following pieces of built-in syntax to refer to whatever is in scope, not the Prelude versions: * An integer literal 368 means "fromInteger (368::Integer)", rather than "Prelude.fromInteger (368::Integer)". * Fractional literals are handed in just the same way, except that the translation is fromRational (3.68::Rational). * The equality test in an overloaded numeric pattern uses whatever (==) is in scope. * The subtraction operation, and the greater-than-or-equal test, in n+k patterns use whatever (-) and (>=) are in scope. * Negation (e.g. "- (f x)") means "negate (f x)", both in numeric patterns, and expressions. * "Do" notation is translated using whatever functions (>>=), (>>), and fail, are in scope (not the Prelude versions). List comprehensions, mdo (Section 7.3.3, "The recursive do-notation " <file:///\\Cam-01-unx\simonpj\builds\HEAD-1\ghc\docs\users_guide\users_g uide\syntax-extns.html#mdo-notation> ), and parallel array comprehensions, are unaffected. * Arrow notation (see Section 7.7, "Arrow notation " <file:///\\Cam-01-unx\simonpj\builds\HEAD-1\ghc\docs\users_guide\users_g uide\arrow-notation.html> ) uses whatever arr, (>>>), first, app, (|||) and loop functions are in scope. But unlike the other constructs, the types of these functions must match the Prelude types very closely. Details are in flux; if you want to use this, ask! In all cases (apart from arrow notation), the static semantics should be that of the desugared form, even if that is a little unexpected. For emample, the static semantics of the literal 368 is exactly that of fromInteger (368::Integer); it's fine for fromInteger to have any of the types: fromInteger :: Integer -> Integer fromInteger :: forall a. Foo a => Integer -> a fromInteger :: Num a => a -> Integer fromInteger :: Integer -> Bool -> Bool Be warned: this is an experimental facility, with fewer checks than usual. Use -dcore-lint to typecheck the desugared program. If Core Lint is happy you should be all right.

1 0

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