- Glasgow-haskell-users

incorrect implementation of :show bindings?
by Peter Hercek 23 Jan '09

23 Jan '09

Hi, Bindings displayed with ":show bindings" do not correspond to what can be observed by printing values explicitly for example using ":force". Is it supposed to work like that? If yes, why? Notice the value and type reported for variable "test" after it has been redefined in the example at this post end. Thanks, Peter. status:0 peter@dwarf [703] /tmp % ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> let test = 0 Prelude> :show bindings test :: Integer = _ Prelude> :force test test = 0 Prelude> let test = "zero" Prelude> :show bindings test :: Integer = 0 Prelude> :force test test = ['z','e','r','o'] Prelude> :quit Leaving GHCi. status:0 peter@dwarf [704] /tmp %

2 2

no breakpoint location for list construction?
by Peter Hercek 21 Jan '09

21 Jan '09

Hi, Is it correct that there is no breakpoint location at list construction place: line "5 then [x]" ? Notice that :steplocal does not stop there before "[1]" is printed when debugging expression "test 1". Thanks, Peter. status:0 peter@metod [721] ~/tmp % cat b.hs hlp x = [-x] test x = if x >= 0 then [x] else hlp x status:0 peter@metod [722] ~/tmp % ghci b.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package filepath-1.1.0.0 ... linking ... done. Loading package directory-1.0.0.0 ... linking ... done. Loading package ghciext-0.1 ... linking ... done. [1 of 1] Compiling Main ( b.hs, interpreted ) Ok, modules loaded: Main. *Main> :break 4 Breakpoint 0 activated at b.hs:4:5-10 *Main> test 1 Stopped at b.hs:4:5-10 _result :: [a] = _ 3 test x = 4 if x >= 0 5 then [x] [b.hs:4:5-10] *Main> :steplocal [1] *Main> test (-1) Stopped at b.hs:4:5-10 _result :: [a] = _ 3 test x = 4 if x >= 0 5 then [x] [b.hs:4:5-10] *Main> :steplocal Stopped at b.hs:6:9-13 _result :: [Integer] = _ x :: Integer = -1 5 then [x] 6 else hlp x 7 [b.hs:6:9-13] *Main> :steplocal [1] *Main> :quit Leaving GHCi. status:0 peter@metod [723] ~/tmp %

1 0

Re: new build system build fails on Solaris/x86
by Karel Gardas 21 Jan '09

21 Jan '09

Christian Maeder wrote: > Karel Gardas wrote: >> Hello, >> >> I need to double check: I'm talking here about new build system. I've >> invoked simple `gmake'. Also your builds is fine since editline seems to >> find readline header file which seems to satisfy it while this is not in >> my case. > > Although my configure finds readline header files, this is not enough > for editline. Both configure calls fail, but in my case the failure is > correctly handled by the build system via touching editline/unbuildable OK. > >> How have you configure to allow it to find readline? > > It is just a wrong readline.h for libreadline (lying around) and I only > called ./configure I did just as usuall: bash ./boot ./configure --prefix=/tmp/ghc-new-build-system-bin gmake For boot I'm using autoconf-2.62/automake-1.10.1 and GHC 6.8.3 Thanks, Karel

3 2

git
by Lennart Augustsson 21 Jan '09

21 Jan '09

What port is git using for getting the ghc repo via http? I'm getting this message behind our thick firewall: fatal: http://darcs.haskell.org/ghc.git/info/refs download error - Failed connect to darcs.haskell.org:1080; Operation now in progress It makes me think port 1080 is involved, and I don't think any access to that port is allowed. If the repo is not totally available on port 80 (or the https port) then it's impossible to get from behind paranoid firewalls. -- Lennart

2 2

Questions regarding uvector 0.1.0.3
by Tyson Whitehead 19 Jan '09

19 Jan '09

I've been looking at uvector and had some questions (hopefully this is the right mailing list for this, if not, sorry, and please direct me properly). First, is there any design thing deeper than just supporting things like the unit and pair arrays for layering UArr on top of the underlying BUArr? Second, the STG code and the native and via-C assembler generated by ghc 6.8.2 with -O2 for test :: UArr Int -> Int -> Int test = indexU where indexU :: UA e => UArr e -> Int -> e indexU arr n = indexS (streamU arr) n is a loop that simultaneously increments the offset while decrementing the index until it reaches the desired position. If I understand correctly, this indexU definition was used instead of just bring indexU from UArr into scope in order to cancel any possible unstreamU in arr, and this is a big part of the whole streamU/unstreamU magic. It replaces what would other require N^2 rules to avoid a bunch of temporaries with one. I wonder if a rule code be added to change any outstanding "indexS (streamU arr) n" into an UArr indexU after streamU/unstreamU fusion? Such rules for each of these type of functions (i.e., ones that aren't of the form "= unstreamU . ...") would also not be N^2 and would eliminate temporary streams. Thanks! -Tyson PS: Nice code by the way. : )

1 0

RE: Differences in pattern matching syntax?
by Han Joosten 18 Jan '09

18 Jan '09

Hi, I do not use -O to compile, as far as I know. I use eclipsefp and I use the defaults from it. I will upload my modules as a zip file, so you can reproduce the error. It also contains a README.txt file that explains how to reproduce it. Hope that helps. http://www.nabble.com/file/p21439653/src.zip src.zip Simon Peyton-Jones wrote: > > I agree that's odd. Are you using -O? Can you give us a reproducible > test case? > > (The only think I can think is that the line > | Gc{} -> Tm (grspe r) > will build a thunk for (grspe r), and depending on the context I suppose > you might get a lot of those.) > > Thanks > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces(a)haskell.org > [mailto:glasgow-haskell-users- > | bounces(a)haskell.org] On Behalf Of Han Joosten > | Sent: 12 January 2009 21:54 > | To: glasgow-haskell-users(a)haskell.org > | Subject: Differences in pattern matching syntax? > | > | > | Hi, > | > | I have two alternatives to specify a specific function. They both > compile > | ok, but the first one crashes (Stack space overflow) while the second > one > | runs fine. > | I use GHC 6.10.1 on windowsXP > | > | Alternative 1: > | antecedent :: Rule -> Expression > | antecedent r = case r of > | Ru{} -> if (rrsrt r == AlwaysExpr) then error > ("(Module > | ADLdataDef:) illegal call to antecedent of rule "++show r) > | else > | rrant r > | Sg{} -> antecedent (srsig r) > | Gc{} -> Tm (grspe r) > | Fr{} -> frcmp r > | > | Alternative 2: > | antecedent :: Rule -> Expression > | antecedent r@(Ru AlwaysExpr _ _ _ _ _ _ _ _) = error ("(Module > ADLdef:) > | illegal call to antecedent of rule "++show r) > | antecedent (Ru _ a _ _ _ _ _ _ _) = a > | antecedent (Sg _ rule _ _ _ _ _) = antecedent rule > | antecedent (Gc _ d _ _ _ _ _) = Tm d > | antecedent (Fr _ _ e _) = e > | > | Both alternatives compile, but if i use Alternative 2, then my program > runs > | fine. If I use Alternative 1 instead, I get a stack space overflow. > | > | I would think that both alternatives would have the same semantics. So i > am > | surprised that one runs fine, while the other one crashes. > | > | Could anyone explain what is going on? > | Thanks! > | > | Han Joosten > | > | ---------------------------- > | Might help, here is the data definition: > | > | data Rule = > | -- Ru c antc p cons cpu expla sgn nr pn > | Ru { rrsrt :: RuleType -- ^ One of the following: > | -- | Implication if this is > an > | implication; > | -- | Equivalence if this is > an > | equivalence; > | -- | AlwaysExpr if this is > an > | ALWAYS expression. > | , rrant :: Expression -- ^ Antecedent > | , rrfps :: FilePos -- ^ Position in the ADL file > | , rrcon :: Expression -- ^ Consequent > | , r_cpu :: Expressions -- ^ This is a list of > | subexpressions, which must be computed. > | , rrxpl :: String -- ^ Explanation > | , rrtyp :: (Concept,Concept) -- ^ Sign of this rule > | , runum :: Int -- ^ Rule number > | , r_pat :: String -- ^ Name of pattern in which it > was > | defined. > | } > | -- Sg p rule expla sgn nr pn signal > | | Sg { srfps :: FilePos -- ^ position in the ADL file > | , srsig :: Rule -- ^ the rule to be signalled > | , srxpl :: String -- ^ explanation > | , srtyp :: (Concept,Concept) -- ^ type > | , runum :: Int -- ^ rule number > | , r_pat :: String -- ^ name of pattern in which it > was > | defined. > | , srrel :: Declaration -- ^ the signal relation > | } > | -- Gc p antc cons cpu _ _ _ > | | Gc { grfps :: FilePos -- ^ position in the ADL file > | , grspe :: Morphism -- ^ specific > | , grgen :: Expression -- ^ generic > | , r_cpu :: Expressions -- ^ This is a list of > | subexpressions, which must be computed. > | , grtyp :: (Concept,Concept) -- ^ declaration > | , runum :: Int -- ^ rule number > | , r_pat :: String -- ^ name of pattern in which it > was > | defined. > | } > | -- Fr t d expr pn -- represents an automatic computation, such as * > or +. > | | Fr { fraut :: AutType -- ^ the type of automatic > | computation > | , frdec :: Declaration -- ^ where the result is to be > | stored > | , frcmp :: Expression -- ^ expression to be computed > | , frpat :: String -- ^ name of pattern in which it > was > | defined. > | } > | > | -- > | View this message in context: > http://www.nabble.com/Differences-in-pattern-matching-syntax-- > | tp21416338p21416338.html > | Sent from the Haskell - Glasgow-haskell-users mailing list archive at > Nabble.com. > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users(a)haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- View this message in context: http://www.nabble.com/Differences-in-pattern-matching-syntax--tp21416338p21… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

7 11

how to load an additional file to ghci
by Peter Hercek 16 Jan '09

16 Jan '09

Is it possible to load one more module to ghci without unloading the modules I have already loaded? The module I would like to load in addtion is not installed and I do not want it installed. It is also independent of any other modules. There is no dependency from the modules already loaded to the one I would like to add. How to achieve something like "load a module in this file in addition to what I have already loaded and do not modify the the context for expression evaluation (:module) ... just make the exported functions in the file available through fully qualified names". It would be handy for some helper stuff I have which is project independent and too often modified to be installed. Peter.

2 2

Re: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2
by Simon Marlow 14 Jan '09

14 Jan '09

Sigbjorn Finne wrote: > Thanks Simon, > > great stuff; I like the introduction of these 'native code finalizers', > they've > been sorely missed at times. > > You don't say, but will there be a dynamic check to catch such re-entries? There is (now) a dynamic check, yes. Cheers, Simon

1 0

HEADS UP: finalizer changes coming in GHC 6.10.2
by Simon Marlow 14 Jan '09

14 Jan '09

By popular demand, GHC 6.10.2 will support finalizers that are actually guaranteed to run, and run promptly. There aren't any API changes: this happens for finalizers created using newForeignPtr as normal. However, there's a catch. Previously it was possible to call back into Haskell from a finalizer (finalizers are C functions), by using foreign import "wrapper" or foreign export. According to the FFI spec, whether this is allowed or not is "system dependent". In GHC 6.10.1 and earlier it was allowed, but in 6.10.2 and later it is not. The reason being that C finalizers are now executed directly by the GC, when the runtime is not in a position to handle callbacks. You can still have fully-fledged Haskell finalizers if you want: we have Foreign.Concurrent.newForeignPtr for that purpose. But those finalizers are not subject to the same promptness guarantees that you get with C finalizers - they run in a separate thread, and are not guaranteed to be run at program exit. We'll make sure this is documented prominently in the 6.10.2 release notes, but I thought a heads-up would be a good idea right now as it turns out that there are existing libraries (e.g. LLVM) that will be affected. Cheers, Simon

2 2

GHCi, version 6.10.1 crashes without message
by Heiko Studt 14 Jan '09

14 Jan '09

Hi (and hello everybody), I read the FAQ, I searched down till Nov 2008, but did not find anything. I hope I didn't miss a FAQ or somewhat. (If so, please apologize!) My (freshly installed) GHCi 6.10.1 runs on Windows XP on Intel Dual Core. I used the .msi of the Webpage some two weeks ago. I got some strange program as example and tried out - and my ghci died quitly without any helping message. Here is the original programm: | f x y z = a + b*c + b + fun c | where a = x * y + z | b = c * fun x | c = a * b | fun x = x * x + 1 For testing out in previous of this posting, the following is the very same and had the same problem: | let f x y z = a + b*c + b + fun c where {a = x * y + z; b = c * fun x; c = a * b; fun x = x * x + 1} The query to die was "f 1 2 3". I tried with verbose ghci: | C:\...\ghc-6.10.1\bin>ghci -v | GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help | Glasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC | version 6.8.3 | Using package config file: C:\...\GHC-61~1.1\package.conf | hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0 | wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 | wired-in package integer mapped to integer-0.1.0.0 | wired-in package base mapped to base-4.0.0.0 | wired-in package rts mapped to rts-1.0 | wired-in package haskell98 mapped to haskell98-1.0.1.0 | wired-in package syb mapped to syb-0.1.0.0 | wired-in package template-haskell mapped to template-haskell-2.3.0.0 | wired-in package dph-seq mapped to dph-seq-0.3 | wired-in package dph-par mapped to dph-par-0.3 | Hsc static flags: -static | Loading package ghc-prim ... linking ... done. | Loading package integer ... linking ... done. | Loading package base ... linking ... done. | Prelude> let f x y z = a + b*c + b + fun c where {a = x * y + z; b = c * fun x; | c = a * b; fun x = x * x + 1} | *** Parser: | *** Desugar: | *** Simplify: | *** CorePrep: | *** ByteCodeGen: | Prelude> f 1 2 3 | *** Parser: | *** Desugar: | *** Simplify: | *** CorePrep: | *** ByteCodeGen: | | C:\...\ghc-6.10.1\bin> I hope I could help finding some strange bug, killing 99% of your problems with Haskell, life and love, although I am very sure this one is only minor... ;-) MFG (With friendly regards) -- Heiko Studt <studt(a)fmi.uni-passau.de>

4 4