RE: [Haskell] Using -main-is with GHC 6.4/Windows
[Redirecting to GHC users, which is where GHC-specific questions belong] | OK, it's not so bad. If I delete the AffyDataCalc.o file before compiling | AffyDataCalcTest, it all works fine. ... | Hmmm... is there something the GHC --make feature can do to force | recompilation of the other modules previously compiled as main | modules? Just a thought. We're always wary of adding too much magic! I'll add a note to the -main-is documentation though. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Klyne Sent: 17 March 2005 15:57 To: Haskell Mailing List Subject: [Haskell] Using -main-is with GHC 6.4/Windows I've been trying to use the -main-is option with GHC 6.4 on Windows. In isolation it works fine, but it still doesn't achieve what I hoped it would. Consider this compilation output frgament: [[ Compiling AffyDataCalcTest ( AffyDataCalcTest.hs, AffyDataCalcTest.o ) Linking ... ./AffyDataCalc.o(.data+0xa70):fake: multiple definition of `ZCMain_main_srt' AffyDataCalcTest.o(.data+0x1fc):fake: first defined here ./AffyDataCalc.o(.data+0xa78):fake: multiple definition of `ZCMain_main_closure' AffyDataCalcTest.o(.data+0x204):fake: first defined here ./AffyDataCalc.o(.text+0x9158):fake: multiple definition of `ZCMain_main_info' AffyDataCalcTest.o(.text+0x1ff0):fake: first defined here ./AffyDataCalc.o(.text+0x9408):fake: multiple definition of `__stginit_ZCMain' AffyDataCalcTest.o(.text+0x20c0):fake: first defined here ]] The module 'AffyDataCalc' contains a function called 'main', which is the topo-level function of the target program I have under development. The module AffyDataCalcTest also has top-level function called runtest, which, you guessed it, runs a test of the program functions. It seems that the top-level functions still interfere with each other. [later] OK, it's not so bad. If I delete the AffyDataCalc.o file before compiling AffyDataCalcTest, it all works fine. [[ E:\OxfordCVS\DTGED\AffyDataghc --make -fglasgow-exts -iD:\Cvs\DEV\HaskellUti C:\Dev\Haskell\Lib\HUnit;C:\Dev\Haskell\Lib\Parsec;C:\Dev\Haskell\MyLibs \ -o yDataCalcTest.exe -main-is AffyDataCalcTest.runtest AffyDataCalcTest Chasing modules from: AffyDataCalcTest Compiling ParseCSV ( ./ParseCSV.hs, ./ParseCSV.o ) Compiling FormatCSV( ./FormatCSV.hs, ./FormatCSV.o ) Skipping ListHelpers ( D:\Cvs\DEV\HaskellUtils/ListHelpers.hs, D:\Cvs\D HaskellUtils/ListHelpers.o ) Compiling AffyDataCalc ( ./AffyDataCalc.hs, ./AffyDataCalc.o ) Skipping HUnitLang( C:\Dev\Haskell\Lib\HUnit/HUnitLang.lhs, C:\Dev\H ell\Lib\HUnit/HUnitLang.o ) Skipping HUnitBase( C:\Dev\Haskell\Lib\HUnit/HUnitBase.lhs, C:\Dev\H ell\Lib\HUnit/HUnitBase.o ) Skipping HUnitText( C:\Dev\Haskell\Lib\HUnit/HUnitText.lhs, C:\Dev\H ell\Lib\HUnit/HUnitText.o ) Skipping HUnit( C:\Dev\Haskell\Lib\HUnit/HUnit.lhs, C:\Dev\Haske Lib\HUnit/HUnit.o ) Skipping TestHelpers ( D:\Cvs\DEV\HaskellUtils/TestHelpers.hs, D:\Cvs\D HaskellUtils/TestHelpers.o ) Compiling AffyDataCalcTest ( AffyDataCalcTest.hs, AffyDataCalcTest.o ) Linking ... E:\OxfordCVS\DTGED\AffyDataaffydatacalctest Cases: 2 Tried: 0 Errors: 0 Failures: 0AffyDataCalc done. Cases: 2 Tried: 1 Errors: 0 Failures: 0AffyDataCalc done. Cases: 2 Tried: 2 Errors: 0 Failures: 0 E:\OxfordCVS\DTGED\AffyDataghcc AffyDataCalc ]] Hmmm... is there something the GHC --make feature can do to force recompilation of the other modules previously compiled as main modules? Just a thought. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: cpphs (was Re: Haskell on Red Hat Enterprise...)
On 17 March 2005 23:03, Andy Moran wrote: Malcolm Wallace wrote: Andy Moran [EMAIL PROTECTED] writes: I notice that cpphs understands CPP stringification (if invoked with --hashes). Most of the gcc 3.4 failures (in fact, all of that I've seen) have to do with fooling -traditional into turning macro constants into Haskell strings, which can more readily be done with the #-operator. So, would using cpphs mean we could do away with the string gap hack? Without seeing the examples in question, I can't say for definite, but cpphs /does/ preserve string gaps in source code in all cases. Here's an example, from 6.2.1's ghc/utils/ghc-pkg/Main.hs: -- hackery to convice cpp to splice GHC_PKG_VERSION into a string version :: String version = tail \ \ GHC_PKG_VERSION HEAD uses a Makefile-generated Version.hs instead. Simon M.: are all instances of the above trick replaced by analogues of this much neater mechanism? Yes, I fixed all these in 6.2.2 or thereabouts. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: cpphs (was Re: Haskell on Red Hat Enterprise...)
On 17 March 2005 17:23, Malcolm Wallace wrote: The only real issue currently preventing ghc from adopting cpphs is ideological (GPL licensing). We've no objection to making changes to GHC to make it easy to use in conjuction with cpphs (./configure --with-cpps or whatever), so 3rd-party packagers can provide GHC packages that use cpphs if they wish. However, we won't be adding cpphs to the GHC source tree, or requiring it to be installed to build GHC, or shipping it in the standard distributions. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Parse error
On 17 March 2005 19:43, Dmitri Pissarenko wrote:
In the attachment you will find a file, in which I try to access Java
from Haskell using the Java bridge for functional languages.
For details see
http://sourceforge.net/projects/jvm-bridge/
and
http://dapissarenko.com/resources/2005_02_17_eigenvaluesJava/2005_02_17_
eigenva
luesJava.pdf
When I try to compile the attached file using
ghc +RTS -c -RTS -package javavm -c EigenvalueCalculatorHaskell.hs -o
EigenvalueCalculatorHaskell.o
I get the error
EigenvalueCalculatorHaskell.hs:28: parse error on input `putStrLn'
Your code is using a mixture of explicit and implicit layout: your
do-expressions have curly braces {...} and semicolons, but the
let-expression on line 22 does not. I suggest adding the layout tokens
to the let-expression to fix it.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Using -main-is with GHC 6.4/Windows
At 09:29 18/03/05 +, Simon Peyton-Jones wrote: [Redirecting to GHC users, which is where GHC-specific questions belong] OK (but I'm not subscribed to that list, so pls copy me on any further comment, if any.) | OK, it's not so bad. If I delete the AffyDataCalc.o file before compiling | AffyDataCalcTest, it all works fine. ... | Hmmm... is there something the GHC --make feature can do to force | recompilation of the other modules previously compiled as main | modules? Just a thought. We're always wary of adding too much magic! I can appreciate that. It did strike me as a little strange (magic, even?) that the result of compiling a module named explicitly on the GHC command line is different from the implicit compilation performed when chasing imports. (I think I understand *why* it happens, but it still seems a little strange.) By way of exploring the issue, rather than actually asking for any of the following to be done, some thoughts I had are: (a) generate the program initialization/finalization entry points in a separate .o file from the compiled module, and include that in the link. (b) use a different output filename (e.g. module_main.o) when compiling a module as a program entry point. (c) combination of (a) and (b) - compile base module as non-main, and a separate output file for the program startup magic with a name based on but different from the corresponding source module. I'll add a note to the -main-is documentation though. Thanks. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cpphs (was Re: Haskell on Red Hat Enterprise...)
Andy Moran [EMAIL PROTECTED] writes: -- hackery to convice cpp to splice GHC_PKG_VERSION into a string version :: String version = tail \ \ GHC_PKG_VERSION OK, it turns out that this is pretty tricky to do in cpp, even with full scope of -ansi or -traditional behaviour. In fact, the hack shown is the only way to achieve it (demonstrated below), and the hack fails with cpphs /because/ of the string gap! By contrast, cpphs --text makes the original task very straightforward. (The option turns off source-code lexing of the file as Haskell, so that macros can be expanded within quotes.) Here are a variety of ways you might attempt stringification: #define GHC_PKG_VERSION 6.2.2 -- hackery to convice cpp to splice GHC_PKG_VERSION into a string version :: String version = tail \ \ GHC_PKG_VERSION version2 = GHC_PKG_VERSION #define v3 GHC_PKG_VERSION version3 = v3 #define stringify(s) #s version4 = stringify(GHC_PKG_VERSION) #define stringify2(s) s version5 = stringify2(GHC_PKG_VERSION) And here are the results: cpp -ansi version = tail \ GHC_PKG_VERSION version2 = GHC_PKG_VERSION version3 = GHC_PKG_VERSION version4 = GHC_PKG_VERSION version5 = s cpp -traditional version = tail \ \ 6.2.2 version2 = GHC_PKG_VERSION version3 = GHC_PKG_VERSION version4 = #6.2.2 version5 = GHC_PKG_VERSION cpphs version = tail \ \ GHC_PKG_VERSION version2 = GHC_PKG_VERSION version3 = GHC_PKG_VERSION version4 = #6.2.2 version5 = GHC_PKG_VERSION cpphs --hashes version = tail \ \ GHC_PKG_VERSION version2 = GHC_PKG_VERSION version3 = GHC_PKG_VERSION version4 = GHC_PKG_VERSION version5 = GHC_PKG_VERSION cpphs --text version = tail \ \ 6.2.2 version2 = 6.2.2 version3 = 6.2.2 version4 = #6.2.2 version5 = 6.2.2 cpphs --text --hashes version = tail \ \ 6.2.2 version2 = 6.2.2 version3 = 6.2.2 version4 = 6.2.2 version5 = 6.2.2 HEAD uses a Makefile-generated Version.hs instead. Simon M.: are all instances of the above trick replaced by analogues of this much neater mechanism? I agree that, ultimately, generating the source code directly is better than using cpp-ish stuff. So, cpphs' version of traditional is truer to tradition than gcc's, it seems. Well, no not really: cpphs is pretty close to cpp -traditional, and cpphs --hashes is pretty close to cpp -ansi, with the treatment of string gaps causing the only slight differences. gcc -E -traditional -x c doesn't expand within quotes, which is why hacks like the above were introduced. Whilst there /is/ a visible difference between cpp and cpphs for expansion within quotes, where the quotes are located within the definition of the macro (see version5), it isn't relevant here. Your highlighted problem was to do with expansion of macros inside quotes within the main body of the file. Ordinary cpp has no ability to do this whatsoever - the file is always lexed for strings and comments - whilst cpphs is more flexible. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.4 vs 6.2.2 can't compile darcs-1.0.2
Hello! Today I've tried to compile darcs-1.0.2 and for that I've installed the ghc-6.4-i386-unknown-linux.tar.bz2 (in-place) When I tried to compile, configure script from darcs complained that it couldn't figure out how to do OpenFd (or someting similar). Then I've installed ghc-6.2.2-i386-unknown-linux.tar.bz2 (also in-place). Now compilation was sucessfull. Are these 2 versions not compatible? -- Minds, like parachutes, function best when open ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: comments on the GHC API
Hi Matthias, I think most of what you're asking for is planned... On 17 March 2005 16:59, Matthias Neubauer wrote: I just had a first look at the sketch for the planned GHC API (ghc/compiler/main/GHC.hs), since we are very keen on using it ... Our group would mostly like to make use of a compilation manager/module system implementation for Haskell---so these are the parts I concentrated on for now. More specifically, the scenario how we would like to use a GHC library is the following: So far, we've implemented a static analysis for (single) Haskell modules. To make our tool ready for a wider use, we would like extend it to full Haskell 98 (plus extensions). What we therefore would like to ask a GHC library is, given a specific module A, to compile all the other modules that A is dependent on, load them into a context for A, and start processing A up to the point where the actual type-checking of A would commence. After that, we would like to query the library about the initial (type) environment of A (that is, get out a complete summary of all the imported bindings, classes, methods, etc) to then proceed with our own analysis instead of using GHC's type inferencer. I see two basic ways how a GHC library could help us to achieve this: - The library both offers a separate module dependency analysis and also lets us use the compiler in one-shot mode. We then could first calculate the dependencies of A, compile them separately, and calculate the initial environment of A manually by combining the interfaces of the imported modules. Of course, we would also need the possibility to access the imports of A (including renamings and such) without the need to compile A as a whole. - Loading a set of targets (using *load*) can be controlled in a more fine-grained way. Instead of just offering the possibility to compile a set of targets either completely or not at all, there is an option to compile targets only up to a certain compilation phase (or alternatively, to optionally keep intermediate results occurring between the phases to be able to retrieve them afterwards.) The 'load' function lets you load only up to a certain module, and the JustTypecheck mode stops before code generation and lets you inspect the typechecked code. Using this, you can compile one module at a time and get the typechecked code out - does that sound ok? There are some areas to do with getting access to the typechecked class declarations and some other parts of the module that we have still to sort out. The refactoring folks also want access to the renamed code (before typechecking), which includes more of the original declarations. We, for our part, would need parts of the intermediate result (that is, the type environment and class declarations) existing either before parsing A, after parsing A, or, even better, after renaming A. Other users may be interested in other intermediate results. What do others think? Some more, rather random, remarks: - I guess v_CmdLineMode and friends are iorefs that are supposed to live globally in GHC.hs. Couldn't you also pack them into a separate data type created by *init* and later share them between several sessions. The CmdLineMode will be private to the front end only, but there's a related GhcMode that now lives in the DynFlags. Take a look at the HEAD as it is now (I just commmitted some big changes in this area in preparation for the GHC API). Maybe we could even introduce a Session monad? Looking at all the functions again, they all seem to have Session arguments ... - I guess the exported name *GhcSession* should read *Session* (or better the other way around) - Same for *GhcMode* vs. *GhciMode* - What's the purpose of having a mode argument for newSession? As I read the rest of the API, *load* is the only way to trigger the compilation of targets. And *load* seems to be intended to work similar to the interactive mode only. load might compile and link object code in --make mode, or compile and dynamically-link bytecode in --interactive mode. - What are Module, ModSummary, ModIface, HsTypecheckedGroup, HsGroup, TyThing, and Type standing for (I know of course ...)? How complicated would it be to return already existing (TH) data types instead of exposing/specifying more of GHC's internals? The TH types aren't really rich enough for all the purposes we expect this interface to be used for. In particular, the data type needs to include the full GHC language, it needs to include full source location information (the refactoring folks need this, and so does Visual Studio), and it needs to include type information for identifiers. Only HsSyn includes all this. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org
Re: How can I make a counter without Monad?
On Wed, 16 Mar 2005, Peter Davis wrote: On 2005-03-16 02:52:39 -0800, Nicolas Oury [EMAIL PROTECTED] said: instance Splittable Integer where split n = (2*n,2*n+1) I haven't played much with the Splittable class yet, but what would be wrong with instance Splittable Integer where split n = (n,n+1) If you recursively split the left-hand result then that overlaps with the right-hand result. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ HUMBER THAMES DOVER: WEST OR SOUTHWEST 4 OR 5, OCCASIONALLY 6 IN HUMBER, BECOMING VARIABLE 3. OCCASIONAL RAIN OR DRIZZLE. MODERATE OR POOR WITH FOG BANKS. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] GHC: Setting default +RTS options at compile time?
[Redirecting to GHC users, which is the right place for GHC related questions.] | Is there any way to specify at compile/link time default options for GHC | program +RTS options? No. This is a long-standing feature request. It makes perfect sense, but needs someone to design and implement it. So far not enough people have yelled loudly enough for us to do it. Any volunteers? Simon | aside | Why do I want this? I'm using GHC to write a program that will be used by | non-comp uting people to preprocess some data in conjunction with an 18Mb | database file. To load the database into a Data.Map value requires more | than GHC's default 256Mb of heap, and I'd like to increase the program's | default heap size, rather than telling users to use the +RTS -M100M option, | as its one less thing to get wrong. There are of course other possible | solutions, but in this case specifying a default heap size at compile time | seems to be the most natural. | /aside ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4 vs 6.2.2 can't compile darcs-1.0.2
av: Hello! Today I've tried to compile darcs-1.0.2 and for that I've installed the ghc-6.4-i386-unknown-linux.tar.bz2 (in-place) When I tried to compile, configure script from darcs complained that it couldn't figure out how to do OpenFd (or someting similar). Then I've installed Sounds like the configure script for darcs needs to be updated to handle the 6.4 libraries (not surprising). Otherwise darcs should work fine with 6.4, though some of the libraries may have changed and require cpp trickery. You should take this up on the darcs list, though they're probably already trying out 6.4 I'd think. ghc-6.2.2-i386-unknown-linux.tar.bz2 (also in-place). Now compilation was sucessfull. Are these 2 versions not compatible? They're not compatible in that the library APIs have changed in some cases, and newer libraries have come into place. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Problem starting GHC 6.4 on windows 98
When trying to run GHC 6.4 (from the installer) on Windows 98, I get the following error message: The GHC.EXE file is linked to missing export SHELL32.DLL:SHGetFolderPathA From what I've been able to determine, on Windows version prior to Windows 2000, this function was instead exported from shfolder.dll, which is retained in later versions of Windows for backward compatibility, and on newer version of Windows, simply calls the version in shell32.dll. So it looks to me like GHC 6.4 from the installer won't be able to run on Windows 98 unless the executable in the installer is updated to link this function from shfolder.dll instead. -James ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem starting GHC 6.4 on windows 98
Thanks, this issue was fixed a couple of hours ago in the CVS repository based on similar feedback from other Win9x users. Expect to see an updated installer sometime early next week. --sigbjorn - Original Message - From: J L Russell [EMAIL PROTECTED] To: glasgow-haskell-users@haskell.org Sent: Friday, March 18, 2005 20:26 Subject: Problem starting GHC 6.4 on windows 98 When trying to run GHC 6.4 (from the installer) on Windows 98, I get the following error message: The GHC.EXE file is linked to missing export SHELL32.DLL:SHGetFolderPathA From what I've been able to determine, on Windows version prior to Windows 2000, this function was instead exported from shfolder.dll, which is retained in later versions of Windows for backward compatibility, and on newer version of Windows, simply calls the version in shell32.dll. So it looks to me like GHC 6.4 from the installer won't be able to run on Windows 98 unless the executable in the installer is updated to link this function from shfolder.dll instead. -James ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
