Re: Porting to DragonFly BSD
> "Goetz" == Goetz Isenmann writes:
Goetz> With the attached errno_ptr.{h,c} I create a shared
Goetz> library, that encapsulates the errno access, install the
Goetz> header file as /usr/pkg/include/errno_ptr.h and the shared
Goetz> lib as /usr/pkg/lib/liberrno_ptr.so
Goetz> Building ghc-6.10.4 with the attached patch (only a quick
Goetz> hack, to check the idea) I get a result, that looks much
Goetz> better.
Goetz> @Colin: Maybe you can test and use this hack.
It seems to work alright.
--
Colin Adams
Preston Lancashire
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Porting to DragonFly BSD
> "Karel" == Karel Gardas writes: Karel> Seeing DragonFly BSD and `make' together with your make Karel> error messages rings an alarm here with a suggestion to use Karel> GNU make. That's a good alarm you have :-) gmake works much better. Thanks. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Porting to DragonFly BSD
> "Goetz" == Goetz Isenmann writes:
Goetz> My current strategie is, to avoid the problem in a first
Goetz> step.
Goetz> With the attached errno_ptr.{h,c} I create a shared
Goetz> library, that encapsulates the errno access, install the
Goetz> header file as /usr/pkg/include/errno_ptr.h and the shared
Goetz> lib as /usr/pkg/lib/liberrno_ptr.so
Goetz> Building ghc-6.10.4 with the attached patch (only a quick
Goetz> hack, to check the idea) I get a result, that looks much
Goetz> better.
Goetz> @Colin: Maybe you can test and use this hack.
I've finally got round to trying this. I'm having a problem which
maybe has a simple known solution.
What I have done so far:
1) Built and deployed the shared library as detailed above
2) Applied the diff with patch http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Porting to DragonFly BSD
> "Goetz" == Goetz Isenmann writes: Goetz> @Colin: Maybe you can test and use this hack. I won't have any time for the next three weeks (work then holiday). -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Porting to DragonFly BSD
> "Goetz" == Goetz Isenmann writes: Goetz> Until now I had no time and energie to dig deeper into the Goetz> problem [1], that looks to me, like rts/Linker cannot load Goetz> any object file that references errno. Goetz> My guess is, that for dragonflys "extern __thread int Goetz> errno;" we do not only need to add a new case in Goetz> rts/Linker.c but also need to generate different code for Goetz> this thread local storage access. Goetz> [1] $ ghci GHCi, version 6.10.4: Goetz> http://www.haskell.org/ghc/ :? for help Loading package Goetz> ghc-prim ... linking ... done. Loading package integer Goetz> ... linking ... done. ghc: Goetz> /var/tmp/isenmann/ghc-6.10.4-3/lib/ghc-6.10.4/base-4.1.0.0/HSbase-4.1.0.0.o: Goetz> unhandled ELF relocation(Rel) type 15 Goetz> Loading package base ... linking ... ghc: unable to load Goetz> package `base' After some googling, and learning very little, I speclated that simply adding a third line for R_386_TLS_IE with the same action as the first line - just storing value, might work: case R_386_TLS_IE: *pP = value; break; This seems to work up to a point. That is I get no crashes in ghci. I do appear to have some line-feed problems. So if I type: Prelude> let x = 10 It appears to do nothing, but that is not the case - I can then overtype with :t x and ghci responds with: x :: Integerxx = 10 Prelude> So maybe this is a readline/haskelline issue? I then tried a cabal install of my website application. This fails, but I think it is because I need to apply various patches to haskelldb modules that are not yet in hackage. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Porting to DragonFly BSD
> "Goetz" == Goetz Isenmann writes: Goetz> Maybe you could start with something like: Goetz> $ curl -o ghc-6.10.4-3.tar.bz2 \ ; Goetz> http://www.goetz-isenmann.de/dfly/ghc-6.10.4-3.tar.bz2 $ Goetz> curl -o cabal http://www.goetz-isenmann.de/dfly/cabal $ tar Goetz> xzf ghc-6.10.4-3.tar.bz2 -C /var/tmp/isenmann $ Goetz> PATH=/var/tmp/isenmann/ghc-6.10.4-3/bin:$PATH $ ./cabal Goetz> update $ ./cabal install --user cabal-install This looks confusing to me - you name the file .bz2 yet you are saying use tar xzf to extract it (as if it were gzipped0. Whatever, I can't decompress it. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Ghci fails to load modules, but ghc compiles OK
I've been using ghc 6.10.3 on 64-bit Linux to compile my application, and it runs OK, modulo bugs. I want to debug a problem, so I load it in ghci, but when i type main I get: Loading package network-2.2.1.1 ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol my_inet_ntoa whilst processing object file /usr/lib64/ghc-6.10.3/network-2.2.1.1/HSnetwork-2.2.1.1.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. Why would ghci have a problem, but not ghc? -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Functions for builtin operators (?)
> "Simon" == Simon Peyton-Jones writes: Simon> sorry, got diverted by paper writing. Well, I've got diverted by the dragonfly season starting, so i don't suppose I shall look at this again until October. Simon> GHC desugars Hsakell into Core, and it's Core that you are consuming in the ESC Simon> stuff. However, Core for an *overloaded* function contains Simon> dictionary applications and abstractions. Furthermore, Simon> overloaded operators turn into selectors, which pick out a Simon> particular field from a dictionary. See any description of Simon> how to compile type classes for examples of this. Simon> So here you've got something like (>) d x y where (>) is Simon> defined like this (>) (MkOrd _ _ gr _) = gr That is, (>) Simon> picks out the gr field from the dictionary. So it's all Simon> very higher-order in reality. And that is what is giving Simon> trouble to the ESC stuff. After all, what do we know about Simon> *all* implementations of (>) at *all* types? Not much! Simon> Dana and I did not explore much how to give a good Simon> treatment to overloaded functions. I would not expect it Simon> to "just work". Simon> I hope this helps a bit Thanks. I feared it wasn't going to be easy. Maybe I'll think about it in October. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Functions for builtin operators (?)
> "Simon" == Simon Peyton-Jones writes: Simon> Nowhere. It's a name generated by GHC itself during Simon> compilation. OK. Is there some way to recognise what the function is? The problem is with ESC/Haskell. I have managed to get the code integrated into the 6.11 tree, and it works up to a point. It produces output like: Len.hs:4:0: Len.pos does not satisfy its contract! Counter example: Len.pos with argument(s) x (Inside _GHC.Classes.>_ ( tpl_B6 )) x ((GHC.Types.I# 0)) which is basically saying that it can't trust _GHC.Classes.>_ ( tpl_B6 ) to do anything in particular, as it doesn't know anything about it. So it would be good to add code that recognises these functions. At best, to know the semantics of each one. Colin> | Where is a function with a name like the following Colin> defined in the ghc source | code? Colin> | Colin> | .Classes.>_ ( tpl_B6 ) -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Functions for builtin operators (?)
Where is a function with a name like the following defined in the ghc source code? .Classes.>_ ( tpl_B6 ) I've tried searching for such names - all I can find is a comment referring to tpl_B2. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
doCorePass
Between 6.8 and 6.11, function doCorePass in module SimplCore has changed types from: CoreToDo -> HscEnv -> UniqSupply -> RuleBase -> ModGuts -> IO (SimplCount, ModGuts) to: CorePass (== CoreToDo) -> ModGuts -> CoreM ModGuts and it isn't easy for me to figure out the relationship between the two types. Is there some sort of formula I can follow to convert a function with the first type to the second? -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unable to compile ghc from darcs
>>>>> "Colin" == Colin Paul Adams writes: >>>>> "Simon" == Simon Marlow writes: Simon> "Incorporated ESC/Haskell", perhaps that made some changes? I found it. maybeParen was added to the export list for HsTypes. I've added a hiding clause for it when importing HsSyn unqualified into GHC. (I don't know if that's the best fix - this isn't my code - I'm just trying to incorporate it into the current version so I can check the contracts in my code. I'm really out of my depth - I should learn to swim first) Anyway, it does the trick - the make now completes. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unable to compile ghc from darcs
> "Simon" == Simon Marlow writes:
Simon> start with 'darcs w' - I noticed you had a 1-line change to
Simon> GHC.hs, what was that? Also you had a local patch
You can see it in the diff below. But as the diff is not complete,
it's not very informative.
Simon> "Incorporated ESC/Haskell", perhaps that made some changes?
Yes, but I can't see how they could affect haddock.
Here is the output of darcs w. I don't see anything that explains the
problem. But it is not conatinging the full history of changes from
the online repository.:
hunk ./compiler/ghc.cabal.in 68
+Build-Depends: parsec >= 2.1 && < 3
hunk ./compiler/ghc.cabal.in 452
- Verify
- BasicAbs
- EscSyn
+Verify
+BasicAbs
+EscSyn
hunk ./compiler/ghc.cabal.in 457
- HsContract
- TcHsContract
+HsContract
+TcHsContract
hunk ./compiler/main/DynFlags.hs 143
+ | Opt_D_dump_vr
+ | Opt_D_dump_vr_trace
hunk ./compiler/main/DynFlags.hs 963
+ | CoreDoVerify Int -- the Int: unrolling depth during CEG unrolling
+ | CoreDoVerifyWOThmProver Int-- the Int: unrolling depth during CEG
unrolling
hunk ./compiler/main/GHC.hs 1228
+ mg_contracts = emptyContractEnv,
hunk ./compiler/main/HscTypes.lhs 1019
- mg_contracts :: !ContractEnv,-- contracts {-# CONTRACT f :: {x |
x>0} -> {r | r > x} #-}
+ mg_contracts :: !ContractEnv, -- ^ contracts {-# CONTRACT f :: {x |
x>0} -> {r | r > x} #-}
hunk ./compiler/rename/RnSource.lhs 19
+ extendLocalRdrEnv,
hunk ./compiler/rename/RnSource.lhs 55
+import HsContract
+
hunk ./compiler/simplCore/SimplCore.lhs 183
-doCorePass (CoreDoVerify n)= {-# SCC "Verification" #-} ^I$
- verifyBinds n
+--doCorePass (CoreDoVerify n)= {-# SCC "Verification" #-} ^I$
+-- verifyBinds n
hunk ./compiler/simplCore/SimplCore.lhs 186
-doCorePass (CoreDoVerifyWOThmProver n) = {-# SCC "VerifyWOProver" #-} $
- verifyBindsWOThmProver n
+--doCorePass (CoreDoVerifyWOThmProver n) = {-# SCC "VerifyWOProver" #-} $
+-- verifyBindsWOThmProver n
--
Colin Adams
Preston Lancashire
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unable to compile ghc from darcs
> "Simon" == Simon Marlow writes: Simon> Is it possible that you changed the exports of the GHC Simon> module, perhaps? Haddock is complaining about a name class Simon> with maybeParen from the GHC module, but I can't see how Simon> maybeParen is exported from GHC, unless that's something Simon> you changed. Maybe by accident. How do I do a diff for ghc/ghc.cabal.in against the online repository? If I search for maybeParen in the added modules, I can only find one occurrence, and that is in a commented-out functions. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unable to compile ghc from darcs
> "Simon" == Simon Marlow writes: Simon> $ ./darcs-all w -s Only: == running darcs w -s --repodir . M ./compiler/ghc.cabal.in -5 +6 M ./compiler/main/DynFlags.hs +4 M ./compiler/main/GHC.hs +1 M ./compiler/main/HscTypes.lhs -1 +1 M ./compiler/rename/RnSource.lhs +3 M ./compiler/simplCore/SimplCore.lhs -4 +4 which is what I expect. Nothing that touches Haddock, as far as I know. Simon> $ ./push-all http://darcs.haskell.org/ --dry-run == running darcs push --no-set-default http://darcs.haskell.org//ghc --dry-run --repodir . NOTE: Pushing to http URLs is not supported. You may be able to hack this to work using DARCS_APPLY_HTTP Would push the following changes: Fri Mar 27 19:06:16 GMT 2009 co...@colina.demon.co.uk * Incorporated ESC/Haskell was all that was found. That's the comment for the changes above. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unable to compile ghc from darcs
>>>>> "Simon" == Simon Marlow writes:
Simon> Colin Paul Adams wrote:
>>>>>>> "Simon" == Simon Marlow writes:
>>
>> >> 6.11.20090319 (formerly bootstrapped from 6.10.1).
>>
Simon> Ah, there's your problem. In general you can't bootstrap
Simon> GHC using a development snapshot, we only support building
Simon> using fixed released versions.
>>
>> So I re-installed ghc 6.10.1.
>>
>> Same problem.
>>
>> N.B. haddock --version now reports 2.3.0
Simon> I have to ask - you did do a complete 'make distclean'
Simon> etc. before rebuilding?
I did.
Simon> If so, could you send me a complete log of the build.
My xterm window doesn't have a big enough buffer. Should I run the
complete procedure (starting with make distclean) all over again,
diverting output and error to a file?
--
Colin Adams
Preston Lancashire
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unable to compile ghc from darcs
> "Simon" == Simon Marlow writes: >> 6.11.20090319 (formerly bootstrapped from 6.10.1). Simon> Ah, there's your problem. In general you can't bootstrap Simon> GHC using a development snapshot, we only support building Simon> using fixed released versions. So I re-installed ghc 6.10.1. Same problem. N.B. haddock --version now reports 2.3.0 -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unable to compile ghc from darcs
> "Simon" == Simon Marlow writes: Simon> Are you using a build tree made with lndir? If you, you Simon> probably want to link the _darcs directory from your source Simon> tree into your build tree. This will enable configure to Simon> generate a more accurate version number, which will Simon> probably fix the compile problem with Haddock. >> >> I don't think so. I am just typing ./configure and make within >> the source tree (the parent of the _darcs directory). Is this >> bad? Simon> No, that should be fine. The Haddock build error indicates Simon> that either your Haddock sources are out of date with Simon> respect to your GHC sources, or Haddock thinks your GHC is Simon> a different version than it really is. Simon> What GHC are you using to bootstrap with, BTW? 6.11.20090319 (formerly bootstrapped from 6.10.1). So it used to work. haddock --version says 2.4.2 -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unable to compile ghc from darcs
> "Simon" == Simon Marlow writes: >> src/Haddock/Backends/Html.hs:1532:4: Ambiguous occurrence >> `maybeParen' It could refer to either >> `Haddock.Backends.Html.maybeParen', defined at >> src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', >> imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 >> Simon> Are you using a build tree made with lndir? If you, you probably want Simon> to link the _darcs directory from your source tree into Simon> your build tree. This will enable configure to generate a Simon> more accurate version number, which will probably fix the Simon> compile problem with Haddock. I don't think so. I am just typing ./configure and make within the source tree (the parent of the _darcs directory). Is this bad? -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unable to compile ghc from darcs
> "Donnie" == Donnie Jones writes: Donnie> Hello Colin, In my working with GHC, I have found this Donnie> page very helpful since it succinctly outlines the steps Donnie> for Rebuilding GHC and ensuring you are up-to-date with Donnie> everything GHC needs: Donnie> http://hackage.haskell.org/trac/ghc/wiki/Building/Rebuilding Thanks. I did this and it cured the TH problems, but I still have haddock problems: src/Haddock/Backends/Html.hs:1495:4: Ambiguous occurrence `maybeParen' It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 src/Haddock/Backends/Html.hs:1511:4: Ambiguous occurrence `maybeParen' It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 src/Haddock/Backends/Html.hs:1515:4: Ambiguous occurrence `maybeParen' It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 src/Haddock/Backends/Html.hs:1532:4: Ambiguous occurrence `maybeParen' It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unable to compile ghc from darcs
> "Austin" == Austin Seipp writes: Austin> Excerpts from Colin Paul Adams's message of Sun Mar 29 Austin> 09:29:43 -0500 2009: >> I was getting errors somewhere in haddock about some ambiguous >> function, so I did a darcs pull to see if that would pull in a >> fix for the problem (unfortunately I didn't make a note of the >> errors). >> >> But now the compile fails earlier with errors in >> deSugar/DsMeta.hs: >> >> deSugar/DsMeta.hs:471:48: Not in scope: type constructor or >> class `TH.InlineSpecQ' Austin> Sounds like it has to do with a template haskell update. >> From the root of the source tree, do: Austin> $ make distclean $ ./darcs-all pull -a Austin> $ ./configure ... $ make ... Austin> like usual. Thanks. That gets me bsak to the original problem, which is: [23 of 24] Compiling Haddock.Backends.Html ( src/Haddock/Backends/Html.hs, dist-install/build/haddock/haddock-tmp/Haddock/Backends/Html.o ) src/Haddock/Backends/Html.hs:1495:4: Ambiguous occurrence `maybeParen' It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 src/Haddock/Backends/Html.hs:1511:4: Ambiguous occurrence `maybeParen' It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 etc. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Unable to compile ghc from darcs
I was getting errors somewhere in haddock about some ambiguous function, so I did a darcs pull to see if that would pull in a fix for the problem (unfortunately I didn't make a note of the errors). But now the compile fails earlier with errors in deSugar/DsMeta.hs: deSugar/DsMeta.hs:471:48: Not in scope: type constructor or class `TH.InlineSpecQ' deSugar/DsMeta.hs:504:16: Not in scope: type constructor or class `TH.TyVarBndr' deSugar/DsMeta.hs:538:50: Not in scope: type constructor or class `TH.TyVarBndr' deSugar/DsMeta.hs:640:29: Not in scope: type constructor or class `TH.Kind' etc. Is the code in darcs supposed to be compilable normally? And what can I do about such situations? Just report them here? -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mkIfThenElse
> "Max" == Max Bolingbroke writes: Max> It moved to MkCore Thanks. What about mkWildId from Id.lhs? That one seems to have vanished. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
mkIfThenElse
This function has disappeard from CoreUtils in recent release(s). I am portfing some code which uses this function (just once). What should I be looking to use instead? -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How do I add new dependencies and source files into the build system?
> "Donnie" == Donnie Jones writes: Donnie> Hello Colin, I believe you should edit Donnie> compiler/ghc.cabal.in -- I believe this file is the input Donnie> for cabal and used to create the ghc.cabal which gets Donnie> re-created at ./configure. Donnie> Also, you may want to look into Ways Donnie> (compiler/main/StaticFlags.hs and mk/config.mk.in) if you Donnie> plan on adding any compile-time (static) flags. Donnie> Hope that helps. -- Donnie Jones Yes, thanks. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How do I add new dependencies and source files into the build system?
I have added a subdirectory named verify to the compiler directory, and made a change to simplCore to call functions from it. I have managed to get it to compile by editing ghc.cabal in the compiler directory (after some problems with cabal which are now sorted). But I think this is not the correct way to do it, as ./configure rebuilds this file, it seems. Where should I be doing this? -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't find parsec
> "Don" == Don Stewart writes: Don> colin: >> I am trying to incorporate Dana Xu's static contract checking >> code into ghc 6.11. I've run into a problem that puzzles me. I >> am getting the following error message: >> >> >> verify/SimplIface.lhs:16:7: Could not find module >> `Text.ParserCombinators.Parsec.Language': Use -v to see a list >> of the files searched for. >> >> >> But a quick find command shows that >> >> ./utils/ext-core/Language/Core/ParsecParser.hs >> >> has this very same import, so I figure it must be usable within >> the compiler. What do I have to do to get it to find this >> module? Don> cabal install parsec? Well, I thought it was installed (I already have pasec-3.0.0 installed by cabal for the game I'm writing.). But I see now that if I try it I get parsec 2 installed. However, I still get the same error message. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Can't find parsec
I am trying to incorporate Dana Xu's static contract checking code into ghc 6.11. I've run into a problem that puzzles me. I am getting the following error message: verify/SimplIface.lhs:16:7: Could not find module `Text.ParserCombinators.Parsec.Language': Use -v to see a list of the files searched for. But a quick find command shows that ./utils/ext-core/Language/Core/ParsecParser.hs has this very same import, so I figure it must be usable within the compiler. What do I have to do to get it to find this module? -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Adding DPH to HEAD
>>>>> "Ian" == Ian Lynagh writes: Ian> Hi Colin, Ian> On Thu, Mar 19, 2009 at 02:53:23PM +, Colin Paul Adams wrote: >> I tried following the advice on the DPH wiki: >> >> ./sync-all --dph get Ian> I would recommend starting with a clean tree by untarring Ian> http://darcs.haskell.org/ghc-HEAD-2009-01-09-ghc-corelibs-testsuite.tar.bz2 Ian> and then doing ./darcs-all pull -a ./darcs-all --dph get Ian> For now, avoid any instructions that tell you to use git or Ian> sync-all. OK. That seems to work. Everything up to make install went fine. After the re-install, I need to re-install various packages using Cabal in order to compile my program afresh. So I then went back to the ghc directory, and typed make again - just to see. I get this: Configuring installPackage-1.0... /home/colin/ghc/libraries/cabal-bin ghc /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 build --distpref dist-inplace --ghc-option=-H32m --ghc-option=-O --ghc-option=-Wall Preprocessing executables for installPackage-1.0... Building installPackage-1.0... [1 of 1] Compiling Main ( installPackage.hs, dist-inplace/build/installPackage/installPackage-tmp/Main.o ) installPackage.hs:4:0: Bad interface file: /home/colin/ghc/libraries/Cabal/dist-bootstrapping/build/Distribution/PackageDescription.hi mismatched interface file versions (wanted "61120090319", got "61120090317") make[2]: *** [with-bootstrapping-compiler] Error 1 make[2]: Leaving directory `/home/colin/ghc/utils/installPackage' make[1]: *** [with-bootstrapping-compiler.installPackage] Error 2 make[1]: Leaving directory `/home/colin/ghc/utils' make: *** [stage1] Error 2 I have no idea what is going on. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Adding DPH to HEAD
I tried following the advice on the DPH wiki:
./sync-all --dph get
This wouldn't run because of permissions, so I tried putting sh in
front of the command. This produced a lot of error messages:
./sync-all: line 3: use: command not found
./sync-all: line 4: use: command not found
./sync-all: line 8: git: command not found
./sync-all: line 8: my: command not found
./sync-all: line 8: chomp: command not found
./sync-all: line 9: git: command not found
./sync-all: line 9: my: command not found
./sync-all: line 9: chomp: command not found
./sync-all: line 10: git: command not found
./sync-all: line 10: my: command not found
./sync-all: line 10: chomp: command not found
./sync-all: line 12: my: command not found
./sync-all: line 13: my: command not found
./sync-all: line 15: syntax error near unexpected token `{'
./sync-all: line 15: `if ($defaultrepo =~ /^...*:/) {'
Following a suggestion from Simon Marlow, I instead tried:
./darcs-all --dph get
which was more successful. Does the wiki page need updating?
But when I then typed
make
I got:
--constraint="Cabal == 1.7.0"
Configuring installPackage-1.0...
cabal-bin: The following installed packages are broken because other packages
they depend on are missing. These broken packages must be rebuilt before they
can be used.
package Cabal-1.7.0 is broken due to missing package array-0.2.0.0,
containers-0.2.0.0, process-1.0.1.0
make[2]: *** [with-bootstrapping-compiler] Error 1
make[2]: Leaving directory `/home/colin/ghc/utils/installPackage'
make[1]: *** [with-bootstrapping-compiler.installPackage] Error 2
make[1]: Leaving directory `/home/colin/ghc/utils'
make: *** [stage1] Error 2
What do I do in such circumstances? I tried a
cabal install Cabal --rebuild
which seemed to work OK, but when i type
make
again i get the same error as before.
--
Colin Adams
Preston Lancashire
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Advice wanted on parallel processing
>>>>> "Brandon" == Brandon S Allbery KF8NH writes: Brandon> On 2009 Mar 18, at 16:59, Colin Paul Adams wrote: >>>>>>> "Brandon" == Brandon S Allbery KF8NH >>>>>>> writes: >> >>>> The array has 12 elements. >> Brandon> How many times do you call it? Perhaps the real Brandon> optimization you need is to memoize. >> >> Very many times indeed. But it is a different array on most >> occasions (I am not updating in place). >> >> It represents one rank of the board on which the game is >> played. The move generator produces a new board for each move. Brandon> It might be helpful for you to show more of the program. I'm not sure which bits to show that might be revealing. The whole thing can be seen by darcs pull http://code.haskell.org/srv/code/chu-shogi/ if you are particularly interested. Board.hs is where rank_value is to be found. You would also need darcs pull http://code.haskell.org/srv/code/game-tree/ Brandon> One thing to keep in mind about parallelization is that Brandon> the level at which happens matters: if individual Brandon> calculations across the list are fast, all you gain by Profiling shows that nearly all the time is spent in evaluating the position. I'm doing that (at the moment) by evaluating each square in isolation (that might change in the future), then summing each rank, and then summing the ranks. Brandon> parallelizing it is MP synchronization/locking overhead. Brandon> On the other hand, it's possible that if the caller can Brandon> be rearranged so that rank_value is computed on another Brandon> CPU while it's doing something else, you could gain quite Brandon> a bit. Or maybe the caller is itself at the right level Brandon> to parallelize. So at first glance it looked as if the calculation for each rank (and indeed each cell) should be able to proceed completly independently of each other. But the profile shows no time allocated to the children of rank_value (although cell_value, which is called by it, uses a lot of time). So my intution seems defeated. perhaps by code-rewriting, although I can't imagine how. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Advice wanted on parallel processing
> ">" == j waldmann writes: >> (I am not updating in place). The move generator produces a >> new board for each move. >> Well, this is sound design, but current memory managers may not >> be up to it. If you check the (board) game programming >> literature, you'll find that engine authors take great efforts >> to bypass automatic memory management (do all updates on the >> "current" board in-place, and write their own malloc/free for >> game tree nodes). I know it. In fact I wrote a program for this game about 10 years ago, in C++, which did all updates in place. It wasn't very good (although being the only one that implemented the rules correctly - as far as I could tell - they are very complicated - was necessarily the best). Now I want to have another go in Haskell. Reading about DPH inspired me to give it a try, although I'm not attempting to use DPH yet. Probably I was too naive thinking I was going to be able to exploit parallelism without pain. >> This becomes even more important when trying to exploit >> concurrency. In theory, that's all very nice (you can evaluate >> independent branches of the game tree in parallel) but in >> practice, you're doomed if your memory allocator/collector is >> still essentially single-threaded (that is, blocks all >> threads). OK, that's interesting. GHC's collector is still stop-the-world at the moment, right? I read in the recent paper that it is intended to try to remedy that soon, in which case I can try again to see if that improves matters. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Advice wanted on parallel processing
> "Brandon" == Brandon S Allbery KF8NH writes: >> The array has 12 elements. Brandon> How many times do you call it? Perhaps the real Brandon> optimization you need is to memoize. Very many times indeed. But it is a different array on most occasions (I am not updating in place). It represents one rank of the board on which the game is played. The move generator produces a new board for each move. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Advice wanted on parallel processing
> "Daniel" == Daniel Fischer writes:
Daniel> generate_moves_for_piece produces a list. rwhnf forces
Daniel> this list enough to see if it's [] or (_:_) (rwhnf x = x
Daniel> `seq` ()), that doesn't get enough work done in each
Daniel> thread to compensate the overhead. Try using rnf after
Daniel> writing an NFData instance for Move.
Daniel> If e.g.
Daniel> data Move = Move {from :: Position, to :: Position}
Daniel> , the instance would be
Daniel> instance NFData Move where rnf (Move f t) = rnf f `seq`
Daniel> rnf t `seq` ()
It made no difference to the timings whatsoever.
Anyway, at that point I decided to revert to the first rule of
performance tuning, and profiled the program for time. The move
generator was using less than 3% of the cpu time, so that was clearly
a waste of time on my part.
The one routine that stood out was this one (about 35% CPU time, with
0% attributed to children):
-- | Value of one rank of the board
rank_value :: (Int, Array Int Square) -> Int
rank_value (rank_coord, rank') = sum (map (cell_value rank_coord)
(assocs rank'))
The array has 12 elements.
So I tried changing the map to parMap rnf. This gave timings of:
>> -N1 93 seconds -N2 105 seconds -N3 206 seconds
at which point I decided I hadn't got a clue what was going on.
--
Colin Adams
Preston Lancashire
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Advice wanted on parallel processing
I've just managed to build ghc 6.11 (Thanks Simon).
I did this for two reasons, one of which is I want to try to improve
the speed of the AI for the Chu Shogi program I am writing by making
use of parallel processing. I have a 4-core Xeon runing Fedora Linux
10 (AMD64).
I have a repeatable scenario for timings. With ghc 6.10.1, no threaded
runtime, the computer takes 51 or 52 seconds to move (experimental
variation up to 1.2 seconds).
With ghc 6.11, it takes the same time.
If I switch on the threaded runtime, then it rises slightly (perhaps
not significantly - I measure 53-54 seconds). With 2, 3 or 4
processors, I measured (one-off, so not reliable) 65, 55 and 58
seconds respectively.
Well, that doesn't really matter, provided I can get the time back
with interest by exploiting parallelism. My first thought for an
"easy" win is the move generator. At present I have this code:
-- | Generate all legal moves from state.
--
-- The best moves (according to some heuristic) should come first
generate_moves :: (Non_interactive_state, Maybe Move) ->
[(Non_interactive_state, Maybe Move)]
generate_moves (state, _) =
let colour = case is_black_to_play state of
True -> Black
False -> White
pieces' = all_pieces_of_colour (board state) colour
unsorted = concatMap (generate_moves_for_piece state) pieces'
sorted = sortBy best_move unsorted
moves = mapMaybe new_move sorted
in {-trace (concat (intersperse "\n" (map (print_move . fromJust . snd)
moves)))-} moves
where new_move mv =
case update_from_move (state, Nothing) mv of
Nothing -> Nothing
Just (st', Nothing) -> Just (st', Just mv)
and my idea was to run the call to generate_moves_for_piece in
parallel over the pieces' list. I thought I could do that simply by
replacing concatMap with parFlatMap, but discovered I need to supply
an extra argument - a Strategy. Not knowing what this should be
(where's the best place to read up on this?) I tried specifying rwhnf.
My timings then are:
-N1 83 seconds
-N2 57 seconds
-N3 58 seconds
-N4 60 seconds
so a complete failure.
Where should I go from here?
--
Colin Adams
Preston Lancashire
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bootstrapping the compiler
> "Simon" == Simon Marlow writes: Simon> Your problem appears to be that you have set $(GHC) to Simon> ghc --make -fno-warn-unrecognised-pragmas Simon> $(GHC) should be set to the path to GHC, nothing else. You're right. I was using that prior to cabalizing my other project. I'll scrap it now. Thanks. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bootstrapping the compiler
>>>>> "Colin" == Colin Paul Adams writes: Colin> I tried again with the same result. Is this a known Colin> problem, or do I have investigate myself? >>>>> "Colin" == Colin Paul Adams writes: Colin> I have just downloaded a darcs snapshot, pulled patches and P.S. This was the January 2009 snapshot of HEAD (the 118 MB version). -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bootstrapping the compiler
I tried again with the same result. Is this a known problem, or do I have investigate myself? >>>>> "Colin" == Colin Paul Adams writes: Colin> I have just downloaded a darcs snapshot, pulled patches and Colin> followed the instructions at Colin> http://hackage.haskell.org/trac/ghc/wiki/Building/QuickStart Colin> When I got to do Colin> make Colin> it didn't work. The tail of the output looks like this: Colin> [55 of 55] Compiling Main ( cabal-bin.hs, Colin> /home/colin/ghc/libraries/bootstrapping/Main.o ) Linking Colin> cabal-bin ... echo "[]" > bootstrapping.conf.tmp cd Colin> extensible-exceptions && Colin> /home/colin/ghc/libraries/cabal-bin ghc --make Colin> -fno-warn-unrecognised-pragmas Colin> /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 clean Colin> --distpref=dist-bootstrapping unrecognised command: Colin> /home/colin/ghc/libraries/bootstrapping.conf (try --help) Colin> make[1]: [bootstrapping.conf] Error 1 (ignored) cd Colin> extensible-exceptions && Colin> /home/colin/ghc/libraries/cabal-bin ghc --make Colin> -fno-warn-unrecognised-pragmas Colin> /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 Colin> configure --distpref=dist-bootstrapping --with-compiler=ghc Colin> --make -fno-warn-unrecognised-pragmas Colin> --with-hc-pkg=/usr/local/bin/ghc-pkg Colin> --package-db=/home/colin/ghc/libraries/bootstrapping.conf.tmp Colin> unrecognised command: Colin> /home/colin/ghc/libraries/bootstrapping.conf (try --help) Colin> make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving Colin> directory `/home/colin/ghc/libraries' make: *** [stage1] Colin> Error 2 Colin> I then tried the following: Colin> [co...@susannah ghc]$ ls libraries/bootstrapping.conf ls: Colin> cannot access libraries/bootstrapping.conf: No such file or Colin> directory [co...@susannah ghc]$ ls Colin> libraries/bootstrapping.conf.tmp Colin> libraries/bootstrapping.conf.tmp Colin> It looks to me like all I have to do is to rename Colin> libraries/bootstrapping.conf.tmp Colin> to Colin> libraries/bootstrapping.conf Colin> but I don't see why this is happening. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Bootstrapping the compiler
I have just downloaded a darcs snapshot, pulled patches and followed the instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/QuickStart When I got to do make it didn't work. The tail of the output looks like this: [55 of 55] Compiling Main ( cabal-bin.hs, /home/colin/ghc/libraries/bootstrapping/Main.o ) Linking cabal-bin ... echo "[]" > bootstrapping.conf.tmp cd extensible-exceptions && /home/colin/ghc/libraries/cabal-bin ghc --make -fno-warn-unrecognised-pragmas /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 clean --distpref=dist-bootstrapping unrecognised command: /home/colin/ghc/libraries/bootstrapping.conf (try --help) make[1]: [bootstrapping.conf] Error 1 (ignored) cd extensible-exceptions && /home/colin/ghc/libraries/cabal-bin ghc --make -fno-warn-unrecognised-pragmas /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 configure --distpref=dist-bootstrapping --with-compiler=ghc --make -fno-warn-unrecognised-pragmas --with-hc-pkg=/usr/local/bin/ghc-pkg --package-db=/home/colin/ghc/libraries/bootstrapping.conf.tmp unrecognised command: /home/colin/ghc/libraries/bootstrapping.conf (try --help) make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/home/colin/ghc/libraries' make: *** [stage1] Error 2 I then tried the following: [co...@susannah ghc]$ ls libraries/bootstrapping.conf ls: cannot access libraries/bootstrapping.conf: No such file or directory [co...@susannah ghc]$ ls libraries/bootstrapping.conf.tmp libraries/bootstrapping.conf.tmp It looks to me like all I have to do is to rename libraries/bootstrapping.conf.tmp to libraries/bootstrapping.conf but I don't see why this is happening. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Reliability of trace?
>>>>> "Isaac" == Isaac Dupree writes:
Isaac> Colin Paul Adams wrote:
>> I'm trying to use Debug.Trace to debug some tree-walking that
>> I've written.
>>
>> It seems to me that I am missing some traces on intermediate
>> function calls. I guess that ghc is re-arranging the code in
>> such a way that some of these intermediate calls
>> disappear. Anyway of stopping this? I already specify -O0.
Isaac> right; with -O0 you get pretty much the exact amount of
Isaac> sharing that your code suggests
Isaac> are you sure those traces are attached to expressions that
Isaac> are being evaluated at all? Remember how lazy Haskell
Isaac> is...
I was was absolutely sure of what was happening, I wouldn't need to
run a trace :-).
But I do know certain things about what is happening, and I cannot see
how the code can avoid some of these trace statements.
Anyway, I think I know how to fix my code now.
When I've done it, I'll put the traces back on, and see if I can
understand what is happening. If not, I'll post the code here, and ask
the question again, for future enlightenment.
--
Colin Adams
Preston Lancashire
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reliability of trace?
I'm trying to use Debug.Trace to debug some tree-walking that I've written. It seems to me that I am missing some traces on intermediate function calls. I guess that ghc is re-arranging the code in such a way that some of these intermediate calls disappear. Anyway of stopping this? I already specify -O0. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-beginners] Baffled by Parsec
>>>>> "Felipe" == Felipe Lessa writes: Felipe> On Sun, Feb 22, 2009 at 4:50 AM, Colin Paul Adams Felipe> wrote: >> OK - I see it here, but I was looking in >> Text.ParserCombinators.Parsec.Char, where I can't see it (I can >> see satisfy). I can't see how I am supposed to make that >> apparently disconnected leap (other than by asking here, which >> works :-) ) Felipe> It is there, too! =P Felipe> http://hackage.haskell.org/packages/archive/parsec/3.0.0/doc/html/Text-ParserCombinators-Parsec-Char.html#v%3Adigit Hm. It's not on my local copy of the GHC libraries documentation (ghc 6.10.1), although if I click the source button, I can see it. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Warning about unrecognised pragma
> "Simon" == Simon Marlow writes: Simon> There's a flag to turn off the warnings: Simon> -fno-warn-unrecognised-pragmas. Looks like we forgot to Simon> document it, though - thanks for highlighting it. Simon> http://hackage.haskell.org/trac/ghc/ticket/3031 Great! That does the trick. Thanks. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Warning about unrecognised pragma
>>>>> "Colin" == Colin Paul Adams writes: Colin> I am getting messages: Board_representation.hs:407:0: Colin> Unrecognised pragma Colin> Board_representation.hs:442:0: Unrecognised pragma Colin> Board_representation.hs:458:0: Unrecognised pragma Colin> etc. Colin> (GHC 6.10.1) Colin> I looked into the documentation to see how to supress these Colin> warnings (prefereably for the particular pragma concerned), Colin> but I found (from 8.13): Colin> "any pragma encountered with an unrecognised word is (silently) ignored." I didn't see any reactions to this. Is it not a bug to emit the error message "Unrecognised pragma"? If it isn't, then is the documentation sentence quoted above a documentation bug? And how do I trun off the message - it is very incovenient, as I get an awful lot of them, and it makes it hard for me to see real error messages. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Warning about unrecognised pragma
I am getting messages: Board_representation.hs:407:0: Unrecognised pragma Board_representation.hs:442:0: Unrecognised pragma Board_representation.hs:458:0: Unrecognised pragma etc. (GHC 6.10.1) I looked into the documentation to see how to supress these warnings (prefereably for the particular pragma concerned), but I found (from 8.13): any pragma encountered with an unrecognised word is (silently) ignored. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: gtk2hs and MacPorts
> "Christian" == Christian Maeder <[EMAIL PROTECTED]> writes: Christian> began at some stage to compile ghc-6.10.1 which I Christian> aborted, because I thought, gtk2hs would not work with Christian> ghc-6.10.1. I managed to compile it on Linux with 6.10.1 against contents of darcs repository. Seems to work OK. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linking to Haskell code from an external program
>>>>> "Jason" == Jason Dusek <[EMAIL PROTECTED]> writes: Jason> Colin Paul Adams <[EMAIL PROTECTED]> wrote: >> I've managed to solve it this morning. It was the way I was >> setting up argc and argv (badly) for the call to hs_init. >> Doing it properly means there are no longer any crashes with >> either Eiffel compliler. Jason> What is the "bad" way to set them up? Any way that doesn't conform to the specification, I guess. So it was all my fault. (I haven't done any significant C programming for at least 6 years. And I hate it these days.) -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linking to Haskell code from an external program
> "Simon" == Simon Marlow <[EMAIL PROTECTED]> writes: >> Links now, but I'm still getting the crash in the garbage >> collector. :-( Simon> Perhaps try reducing the example until the problem goes Simon> away, so we can see at which stage it gets introduced? Or Simon> can you boil down your example to something we can Simon> reproduce? I've managed to solve it this morning. It was the way I was setting up argc and argv (badly) for the call to hs_init. Doing it properly means there are no longer any crashes with either Eiffel compliler. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linking to Haskell code from an external program
>>>>> "Simon" == Simon Marlow <[EMAIL PROTECTED]> writes: Simon> Colin Paul Adams wrote: >>>>>>> "Simon" == Simon Peyton-Jones <[EMAIL PROTECTED]> >>>>>>> writes: >> Simon> It looks as if you are somehow failing to link your binary Simon> with package 'base'. (Are you using 'ghc' as your linker; Simon> you should be.) But others are better than I at this kind Simon> of stuff. >> >> I have base-4.0.0.0 specified. >> >> No, I am not using ghc as the linker. Since I am calling the >> Haskell routine from an Eiffel program, I don't see how I could >> do that with any sort of ease. Simon> I think you'll have to post complete instructions to Simon> reproduce the problem you're having; it's hard to piece it Simon> together from the information you've given. The problem Simon> will be in the details somewhere. It seems it was some complication when switching from 6.8 to 6.10. I didn't clean up properly. Links now, but I'm still getting the crash in the garbage collector. :-( -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Backspace/delete/history in ghci
> "Judah" == Judah Jacobson <[EMAIL PROTECTED]> writes: Judah> somewhere? If you're compiling it yourself, you'll need to Judah> first install Fedora's libedit-devel package. Judah> Hope that helps, -Judah It did. It's working fine now. Thanks. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Backspace/delete/history in ghci
>>>>> "Judah" == Judah Jacobson <[EMAIL PROTECTED]> writes: Judah> On Mon, Nov 24, 2008 at 1:56 AM, Colin Paul Adams Judah> <[EMAIL PROTECTED]> wrote: >> I can't use the backspace key, or arrow keys in ghci (6.10.1) >> as i would normally expect to on any program on Linux. >> Judah>Did you compile ghc yourself or download the distribution Judah> from somewhere? I compiled it myself, since there doesn't seem to be an rpm available for Fedora 9 yet for 6.10.1. Judah> If you're compiling it yourself, you'll need to Judah> first install Fedora's libedit-devel package. OK. But how come it compiled at all in that case? -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Backspace/delete/history in ghci
>>>>> "Simon" == Simon Marlow <[EMAIL PROTECTED]> writes: Simon> Colin Paul Adams wrote: >> I can't use the backspace key, or arrow keys in ghci (6.10.1) >> as i would normally expect to on any program on Linux. >> >> Is this connected with the readline/editline/haskelline debate >> I have observed recently? Simon> You seem to be encountering an unusually severe reaction to Simon> the editline switchover. What terminal type is this? It's Terminal 2.22.2 - A terminal emulator for the GNOME desktop, on linux (Fedora 9 64-bit). -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Backspace/delete/history in ghci
I can't use the backspace key, or arrow keys in ghci (6.10.1) as i would normally expect to on any program on Linux. Is this connected with the readline/editline/haskelline debate I have observed recently? -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linking to Haskell code from an external program
> "Simon" == Simon Peyton-Jones <[EMAIL PROTECTED]> writes: Simon> It looks as if you are somehow failing to link your binary Simon> with package 'base'. (Are you using 'ghc' as your linker; Simon> you should be.) But others are better than I at this kind Simon> of stuff. I have base-4.0.0.0 specified. No, I am not using ghc as the linker. Since I am calling the Haskell routine from an Eiffel program, I don't see how I could do that with any sort of ease. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Grammar for (Glasgow) Haskell
> "Duncan" == Duncan Coutts <[EMAIL PROTECTED]> writes: Duncan> ls compiler/parser reveals... Duncan> Lexer.x Parser.y.pp Thanks. Duncan> However you might get further using the ghc api package. Could be. But how do I make use of it? -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Grammar for (Glasgow) Haskell
Is this available as a happy file (or something similar)? I tried searching the 6.10.1 source package for *.y, but the three files I found don't seem to be what I'm looking for. What I want to try to do is to generate C wrappers to call GHC-compiled code by parsing foreign export declarations. But I figure just searching the code for a regular expression on the lines of foreign[ ]+export is going to be over-simplistic. But I'd rather not type in all the Haskell grammar myself (I'm lazy - you wouldn't expect any other sort of person on this list, I assume :-) ). -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linking to Haskell code from an external program
>>>>> "Colin" == Colin Paul Adams <[EMAIL PROTECTED]> writes: >>>>> "Simon" == Simon Marlow <[EMAIL PROTECTED]> writes: Colin> I then attempted to move it into Eiffel. I can compile the Colin> C code OK, but I'm running into problems with linking. >>> Colin> I solved most of the problems by adding the -v flag to the Colin> call to ghc which I used to link the original (haskell + c Colin> only) program, and cut-and-paste the linker options from Colin> their into the Eiffel configuration file. This isn't really Colin> satisfactory - I would like some automatic way to determine Colin> what the flags should be. Simon> The only other way I can think of is to construct the Simon> arguments yourself by querying the package database, Simon> e.g. "ghc-pkg field ld-options rts", but you'll have to Simon> combine the information from several different fields of Simon> the packages you use, and basically reproduce what GHC does Simon> to construct the ld command line. I have upgraded to ghc 6.10.1 by compiling from source. Now I can't get it to link, either using my previous method of linking a standalone C program via ghc -v, and copying the -u options, or by running: ghc-pkg field rts ld-options (I found out by trial-and error that the syntax you gave above was inverted). In both cases, I get errors: /home/colin/fib/Fib.o: In function `r131_info': (.text+0x79): undefined reference to `base_GHCziBase_ZC_con_info' /home/colin/fib/Fib.o: In function `r131_info': (.text+0x10f): undefined reference to `base_GHCziBase_ZMZN_closure' /home/colin/fib/Fib.o: In function `s13p_info': (.text+0x157): undefined reference to `base_GHCziBase_ZMZN_closure' /home/colin/fib/Fib.o: In function `s13F_info': (.text+0x2cf): undefined reference to `base_GHCziBase_ZMZN_closure' /home/colin/fib/Fib.o: In function `s13c_info': (.text+0x32): undefined reference to `base_GHCziNum_plusInteger_info' /home/colin/fib/Fib.o: In function `r131_info': (.text+0x124): undefined reference to `base_GHCziList_foldr21_info' /home/colin/fib/Fib.o:(.data+0x0): undefined reference to `base_GHCziNum_Szh_static_info' /home/colin/fib/Fib.o:(.data+0x10): undefined reference to `base_GHCziNum_Szh_static_info' /home/colin/fib/Fib.o: In function `r131_closure': (.data+0x38): undefined reference to `base_GHCziBase_ZC_static_info' /home/colin/fib/Fib.o: In function `r131_closure': (.data+0x58): undefined reference to `base_GHCziBase_ZC_static_info' collect2: ld returned 1 exit status I tried in desperation to add -u flag for each of the undefined symbols above, but it makes no difference. I'm quite lost now. My C code looks like this: static char * program_name = "Eiffel program"; static char * terminator = (char *) 0; int argc; char **argv[2]; argc = 1; argv [0] = &program_name; argv [1] = &terminator; hs_init(&argc, argv); #ifdef __GLASGOW_HASKELL__ #include "Fib_stub.h" extern void __stginit_Fib ( void ); hs_add_root(__stginit_Fib); #endif return (fibonacci_hs($n)); hs_exit(); (and in addition there are includes for and "HsFFI.h" somewhere preceding the above). -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linking to Haskell code from an external program
> "Simon" == Simon Marlow <[EMAIL PROTECTED]> writes: Colin> I then attempted to move it into Eiffel. I can compile the Colin> C code OK, but I'm running into problems with linking. >> Colin> I solved most of the problems by adding the -v flag to the Colin> call to ghc which I used to link the original (haskell + c Colin> only) program, and cut-and-paste the linker options from Colin> their into the Eiffel configuration file. This isn't really Colin> satisfactory - I would like some automatic way to determine Colin> what the flags should be. Simon> The only other way I can think of is to construct the Simon> arguments yourself by querying the package database, Simon> e.g. "ghc-pkg field ld-options rts", but you'll have to Simon> combine the information from several different fields of Simon> the packages you use, and basically reproduce what GHC does Simon> to construct the ld command line. Can you point me at where it does this? Thanks. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
> "Arnar" == Arnar Birgisson <[EMAIL PROTECTED]> writes: Arnar> To clarify - most of modern fonts do in deed have Arnar> latin-greek-cyrillic (including the U+03BB lambda), but I Arnar> was referring to the specific math symbols such as the Arnar> U+1D6CC bold lam(b)da, which reside in the Supplementary Arnar> Multilingual Plane (SMP). Those are indeed not present in Arnar> my fonts, including Lucida Math and Adobe Mathematical Pi). I tackled David Carlisle about this too: David> On windows there's cambria math (unfortunately with a restrictive licence that restricts it to that platform, though you can get it for free by getting (for example) the free powerpoint viewer from microsoft) for a free font with a full range of characters best bet is stix font which has been 10 years in the making and is currently between beta and full release (but late again) the stix site removed the fonts after the beata test but you can get them from mozilla, and you need them if reading mathml in FF3. http://www.stixfonts.org/ http://www.mozilla.org/projects/mathml/fonts/ Colin > echo $(uc 1D6cc) - doesn't print anything recognizable David> That would require not only fonts with glyphs in that slot but also that the software (xterm here) understands plane 1 not just the 16bit unicode 2 support. I don't know whether xterm does or not. I downloaded the fonts, but xterm still doesn't display the character concerned. Nor does Firefox, although I haven't tried it with MathML yet. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
Jan> Some others are (I have no idea why they are referenced as Jan> "lamda" instead of "lambda"): See http://unicode.org/notes/tn27/ : "U+039B GREEK CAPITAL LETTER LAMDA U+03BB GREEK SMALL LETTER LAMDA * The use of the spelling lamda derives from ISO 10646. This does not mean that it is more correct than lambda, merely that the spelling without the 'b' is the one used in the formal character names." -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Crash in garbage collector
>>>>> "Colin" == Colin Paul Adams <[EMAIL PROTECTED]> writes: Simon> If you're calling a Haskell library from C, the problem Simon> might be that you forgot hs_add_root(), or that your Simon> hs_add_root() isn't pointing to the right module (it should Simon> point to the module that transitively imports all the other Simon> modules in your library). You can use multiple Simon> hs_add_root() calls if necessary. Colin> I'm sure I have that right. There is only one Colin> module. Unless somehow the __GLASGOW_HASKELL__ symbol isn't Colin> getting defined for the C compile. I'll try removing the Colin> #ifdef to see if that makes a difference. It wasn't that. And yum has just updated my version of ghc from 6.8.2 to 6.8.3 - no 6.10.1 available yet. I'll just wait for that first, in case the new GC makes a change. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Crash in garbage collector
>>>>> "Simon" == Simon Marlow <[EMAIL PROTECTED]> writes: Simon> Colin Paul Adams wrote: >>>>>>> "Ian" == Ian Lynagh <[EMAIL PROTECTED]> writes: >> Ian> If you were lucky it would abort with an assertion Ian> failure. Anyway, gdb should now have debugging symbols to Ian> work with. >> >> It already did (I passed the -g option to gcc). >> >> I guess I will need to install the GHC source to get file >> listings. That sounds like hard work. I think I'll wait for >> 6.10.1 . Simon> If you're calling a Haskell library from C, the problem Simon> might be that you forgot hs_add_root(), or that your Simon> hs_add_root() isn't pointing to the right module (it should Simon> point to the module that transitively imports all the other Simon> modules in your library). You can use multiple Simon> hs_add_root() calls if necessary. I'm sure I have that right. There is only one module. Unless somehow the __GLASGOW_HASKELL__ symbol isn't getting defined for the C compile. I'll try removing the #ifdef to see if that makes a difference. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Crash in garbage collector
> "Ian" == Ian Lynagh <[EMAIL PROTECTED]> writes: Ian> If you were lucky it would abort with an assertion Ian> failure. Anyway, gdb should now have debugging symbols to Ian> work with. It already did (I passed the -g option to gcc). I guess I will need to install the GHC source to get file listings. That sounds like hard work. I think I'll wait for 6.10.1 . -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Crash in garbage collector
>>>>> "Ian" == Ian Lynagh <[EMAIL PROTECTED]> writes: Ian> On Sat, Nov 15, 2008 at 05:31:12PM +, Colin Paul Adams wrote: >> > Can you suggest how I should go about investigating this problem >> further? Ian> Try linking with -debug, and running with +RTS -DS. That Ian> might reveal the problem, and if not you should get more Ian> useful info from gdb. I added the -debug link flag. Add I added +RTS and -DS as command-line arguments in the call to hs_init() (I presume that's what you meant me to do). I can't notice any difference. Where should I be looking for the information? -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RPM for 6.10.1 on Fedora?
I have 6.8.2 installed here (Fedora 9 x86_64). Doing a yum update says no update available. Does this mean I have yum wrongly configured, or is it just the case that the 6.10.1 roms haven't been built yet? -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Crash in garbage collector
I managed to get calling a Haskell function from an Eiffel program working with one Eiffel compiler, but when I compiled the program with a different Eiffel compiler, and ran it, I get a crash, apparently in the GHC garbage collector: (gdb) backtrace #0 0x00452fc0 in evacuate () #1 0x0043b7f8 in scavenge_static () #2 0x00439ea4 in GarbageCollect () #3 0x004351df in scheduleDoGC () #4 0x004353da in exitScheduler () #5 0x004345a2 in hs_exit_ () #6 0x0041900c in T21f3 (C=0x1971f80, a1=7) at fib1.c:1200 #7 0x004191a8 in T21c10 () at fib1.c:1000 #8 0x00419356 in main (argc=, argv=) at fib1.c:11616 Can you suggest how I should go about investigating this problem further? -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linking to Haskell code from an external program
Embarassing - I simply forgot to include Fib.o in the link.
So it links now (program crashes, but I can try to sort that out).
I'm still intereted in knowing how to automatically get the list of
required libraries.
>>>>> "Colin" == Colin Paul Adams <[EMAIL PROTECTED]> writes:
Colin> I am trying to call a Haskell function from an Eiffel
Colin> program, using C as an intermediary.
Colin> For starters, I compiled and ran a variation of the program
Colin> shown in
Colin> http://haskell.org/haskellwiki/Calling_Haskell_from_C, to
Colin> make sure I had the C-code right.
Colin> I then attempted to move it into Eiffel. I can compile the
Colin> C code OK, but I'm running into problems with linking.
Colin> I solved most of the problems by adding the -v flag to the
Colin> call to ghc which I used to link the original (haskell + c
Colin> only) program, and cut-and-paste the linker options from
Colin> their into the Eiffel configuration file. This isn't really
Colin> satisfactory - I would like some automatic way to determine
Colin> what the flags should be.
Colin> The remaining problem has me stumped. I am getting the
Colin> following messages:
Colin> big_file_C4_c.c:(.text+0x9f4f): undefined reference to
Colin> `__stginit_Fib' /home/colin/fib/Fib_stub.o: In function
Colin> `stginit_export_Fib_zdffibonaccizuhszuaQO':
Colin> Fib_stub.c:(.text+0x5): undefined reference to
Colin> `Fib_zdffibonaccizuhszuaQO_closure'
Colin> /home/colin/fib/Fib_stub.o: In function `fibonacci_hs':
Colin> Fib_stub.c:(.text+0x32): undefined reference to
Colin> `Fib_zdffibonaccizuhszuaQO_closure'
Colin> The Haskell code looks like this:
>> {-# LANGUAGE ForeignFunctionInterface #-}
>>
>> module Fib where
>>
>> import Foreign.C.Types import CString
>>
>> fibonacci :: Int -> String fibonacci n = show (fibs !! n) where
>> fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
>>
>> fibonacci_hs :: CInt -> IO CString fibonacci_hs = newCString
>> . fibonacci . fromIntegral
>>
>> foreign export ccall fibonacci_hs :: CInt -> IO CString
Colin> And the C code (in an Eiffel wrapper) looks like this:
Colin> haskell_fib (n: INTEGER): POINTER is -- String
Colin> representation of `n'th Fibonacci number as a string
Colin> external "C inline use ,%"HsFFI.h%"" alias "[
Colin> #ifdef __GLASGOW_HASKELL__ #include "Fib_stub.h" extern
Colin> void __stginit_Fib ( void ); #endif
Colin> int argc; char *argv[0]; argc = 0;
Colin> hs_init(&argc, &argv); #ifdef __GLASGOW_HASKELL__
Colin> hs_add_root(__stginit_Fib); #endif return
Colin> (fibonacci_hs($n)); hs_exit(); ]" end
Colin> I can't find any mention of the word "fibonacci" in the
Colin> output from the ghc run, and I don't know where this
Colin> _closure stuff is coming from. Can you help? -- Colin
Colin> Adams Preston Lancashire
Colin> ___
Colin> Glasgow-haskell-users mailing list
Colin> Glasgow-haskell-users@haskell.org
Colin> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--
Colin Adams
Preston Lancashire
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Linking to Haskell code from an external program
I am trying to call a Haskell function from an Eiffel program, using C
as an intermediary.
For starters, I compiled and ran a variation of the program shown in
http://haskell.org/haskellwiki/Calling_Haskell_from_C, to make sure I
had the C-code right.
I then attempted to move it into Eiffel. I can compile the C code OK,
but I'm running into problems with linking.
I solved most of the problems by adding the -v flag to the call to ghc
which I used to link the original (haskell + c only) program, and
cut-and-paste the linker options from their into the Eiffel
configuration file. This isn't really satisfactory - I would like some
automatic way to determine what the flags should be.
The remaining problem has me stumped. I am getting the following
messages:
big_file_C4_c.c:(.text+0x9f4f): undefined reference to `__stginit_Fib'
/home/colin/fib/Fib_stub.o: In function
`stginit_export_Fib_zdffibonaccizuhszuaQO':
Fib_stub.c:(.text+0x5): undefined reference to
`Fib_zdffibonaccizuhszuaQO_closure'
/home/colin/fib/Fib_stub.o: In function `fibonacci_hs':
Fib_stub.c:(.text+0x32): undefined reference to
`Fib_zdffibonaccizuhszuaQO_closure'
The Haskell code looks like this:
>{-# LANGUAGE ForeignFunctionInterface #-}
>
>module Fib where
>
>import Foreign.C.Types
>import CString
>
>fibonacci :: Int -> String
>fibonacci n = show (fibs !! n)
>where fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
>
>fibonacci_hs :: CInt -> IO CString
>fibonacci_hs = newCString . fibonacci . fromIntegral
>
>foreign export ccall fibonacci_hs :: CInt -> IO CString
And the C code (in an Eiffel wrapper) looks like this:
haskell_fib (n: INTEGER): POINTER is
-- String representation of `n'th Fibonacci number as a string
external "C inline use ,%"HsFFI.h%""
alias "[
#ifdef __GLASGOW_HASKELL__
#include "Fib_stub.h"
extern void __stginit_Fib ( void );
#endif
int argc;
char *argv[0];
argc = 0;
hs_init(&argc, &argv);
#ifdef __GLASGOW_HASKELL__
hs_add_root(__stginit_Fib);
#endif
return (fibonacci_hs($n));
hs_exit();
]"
end
I can't find any mention of the word "fibonacci" in the output from
the ghc run, and I don't know where this _closure stuff is coming
from. Can you help?
--
Colin Adams
Preston Lancashire
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reading files via http or ftp
Has anyone used the Socket library to read files specified via an http and/or ftp URL? -- Colin Paul Adams Preston Lancashire ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
compiling hmake
Can anyone tell me what options to pass to configure when trying to compile hmake with ghc 5.02? -- Colin Paul Adams Preston Lancashire ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
