Re: Why does sizeOf Word64 = 4?
sn 2003-11-09 klockan 03.32 skrev Ben Escoto: Hi, I'm trying to learn about Haskell's FFI (running 6.0.1 on linux) and see the following weird behavior with ghci: Prelude :module Data.Word Foreign.Storable Foreign.Ptr Prelude Foreign.Ptr Foreign.Storable Data.Word sizeOf nullPtr 4 Prelude Foreign.Ptr Foreign.Storable Data.Word sizeOf (nullPtr :: Ptr Word64) 4 Shouldn't sizeOf nullPtr return an error? And sizeOf a Ptr Word64 should be 8 I think. The size of a pointer is not the same as the size of what it points at. On ia32 (x86) architectures, the size of a pointer is always 4 bytes (32 bits). Regards, Martin ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
happy, ghc and {# OPTIONS #} pragma
I am trying to get an {-# OPTIONS #-} pragma to appear in my Happy
generated file, since I use warnings and want to disable them for this
file. I'm putting the pragma first in the module header section of my
Happy file.
My problem is that the generated file starts like this (the first pragma
is generated by Happy):
{-# OPTIONS -fglasgow-exts -cpp #-}
-- parser produced by Happy Version 1.13
{-# OPTIONS -fno-warn-unused-matches #-}
This means that GHC will only see the first one. Is there a way to make
Happy put the pragma above the comment, or not produce the comment at
all?
Or is there a way to make GHC recognise the pragma even though it is
after a comment?
Regards,
Martin
--
Martin Norbäck [EMAIL PROTECTED]
Kapplandsgatan 40 +46 (0)708 26 33 60
S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/
SWEDEN OpenPGP ID: 3FA8580B
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc errrorformat for vim
Errors from the GHC haskell compiler looks something like this: Apa.hs:3: parse error (possibly incorrect indentation) Bepa.hs:15: Warning: Module `Cepa' is imported, but nothing from it is used \t (except perhaps to re-export instances visible in `Cepa') So I'd thought I'd make a vim 'errorformat' for it, and here it is: set errorformat+=%A%f:%l:\ %m,%A%f:%l:,%C%\\s%m,%Z I'm posting this to the mailing list to get comments, and to get indexed by the search engine, but without having to put this on a page. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHCi-5.04.2: Windows Open with ... problem.
fre 2003-02-14 klockan 09.41 skrev Simon Peyton-Jones: Weÿll merge the fix into the 5.04 branch. Weÿre planning another 5.04 release (5.04.4), which has numerous small fixes, sometime ´soon¡, but exactly when depends on demand. When would you need it for your course? Will this release include the -odir fix (the one for hiearchical names)? We are having problems in a particular case: We are building a program which contains of a number of haskell files, and a C wrapper that calls the haskell functions. When compiling the haskell files header files are generated, which are needed to compile the C wrapper. We do this something like this ghc --make Module.hs -odir lib gcc -c wrapper.c ghc wrapper.o odir/*.o Do we have to wait for a version that does -odir correctly, or is there a better way to do this? The problem is that if we compile without -odir the object files are generated where the source files are, and those directories (it's our custom haskell libraries) include a lot of source and object files that should not be part of this program. Regards, Martin -- Martin Norbäck [EMAIL PROTECTED] Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Using --make with -odir and hierarchical modules
The GHC manual needs to specify what happens when you use -odir and hierarchical modules with --make. I posted to the list about this before but it was not resolved: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-October/004178.html Here is an example: . |-- Library | |-- Bar | | `-- Module.hs | `-- Foo | `-- Module.hs `-- Program |-- Program.hs `-- output Program.hs uses Bar.Module and Foo.Module. Then, doing cd to Program # ghc -i../Library --make Program ghc-5.04.2: chasing modules from: Program Compiling Bar.Module ( ../Library/Bar/Module.hs, ../Library/Bar/Module.o ) Compiling Foo.Module ( ../Library/Foo/Module.hs, ../Library/Foo/Module.o ) Compiling Main ( Program.hs, ./Program.o ) ghc: linking ... everything works fine. Using -odir: # ghc -i../Library -odir output --make Program ghc-5.04.2: chasing modules from: Program Compiling Bar.Module ( ../Library/Bar/Module.hs, output/Module.o ) Compiling Foo.Module ( ../Library/Foo/Module.hs, output/Module.o ) Compiling Main ( Program.hs, output/Program.o ) ghc: linking ... LONG LINKER ERROR Error, since both modules are compiled to the same file. This should not happen. What should be done about it? Solution 1: -odir is relative to the source directory (files will end up in Library/Bar/output/Module.o and Library/Foo/output/Module.o). This is a change of semantics from the earlier behaviour of -odir (files are put in another place). On the other hand, it may be more natural to put files relative to their source, like --make without -odir does. The question remains what to do if -odir is an absolute path. Solution 2: files put in -odir are put in directories (files will end up in Program/output/Bar/Module.o and Program/output/Foo/Module.o) This is also a slight change in semantics, since files are put in directories. May affect Makefiles that does ar output/*.o or similar. Solution 3: files put in -odir will have their full module name (files will end up in Program/Output/Bar.Module.o and Program/Output/Foo.Module.o) This is an ever lesser change in semantics, and is better than solution 2 in my opinion. I would recommend using solution 1 if the path name is relative and solution 3 if it's absolute. Regards, Martin -- Martin Norbäck [EMAIL PROTECTED] Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hierarchical modules and compilation output redirection
I am using hierarchical modules with ghc, and I have a bunch of common modules used by several projects, which should build on serveral platforms. Now, assume I have the following: . |-- Bar | `-- Module.hs |-- Foo | `-- Module.hs `-- Main.hs Main imports both Bar.Module and Foo.module. Currently I am using -osuf ARCHITECTURE.o with ghc --make, which works, but clutters the common modules directory with .o files. (I may want to keep it clean.) So I want to redirect the output with -odir OUTPUT_DIR However it won't work since ghc wll put the compilation output of both modules in OUTPUT_DIR/Module.o and subsequently fail to link. Is there a way to get the files named Bar.Module.o and Foo.Module.o or such? Is there a better way? Another thing that would be good would be a way to redirect output to a directory relative to where the source file is, say for instance that the output of Bar/Module.hs should be put in Bar/ARCHITECTURE/Module.o and the output of Foo/Module.hs should be put in Foo/ARCHITECTURE/Module.o. This is just a cosmetic matter, since I can use -osuf and get a similar effect, but using a separate dir would reduce clutter in the directory. Regards, Martin ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Hierarchical modules and compilation output redirection
tis 2002-10-15 klockan 17.18 skrev Simon Marlow: However it won't work since ghc wll put the compilation output of both modules in OUTPUT_DIR/Module.o and subsequently fail to link. Perhaps -odir should append the full module name as a directory (i.e. the default behaviour would be a special case where -odir is .). At least it should be made to work with hierarchical modules with the same last name. Perhaps -odir should be made relative to the location of the source file (unless an absolute path is specified, then you have to do something else). Or have -opre and be able to specify a directory there. (i.e -opre objs/). It sounds like what you want is a way to specify a general mapping function from module names to object file names, perhaps in Haskell. Something like $ ghc -omap \m - $ARCHITECTURE ++ \ map (\x - if x == '.' then '/' else x) m ++ \ \.o\ I'm only kidding, but we could implement this if we wanted :-) How about having a make rule which just moves the object file to the required place after compilation? Well, that's a possibility, but then I can't use --make and reuse the already-compiled object files when using the modules for another project. No biggie of course. All this is of course due to using the --make feature of ghc instead of using a proper Makefile with dependancies. I've found that using --make speeds the compilation up by a great deal, so it would be nice to be able to continue using that. -omap is maybe a bit to generic, but it would be fun. Regards, Martin ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc --make and static libraries
How do I go about linking to a static library when using --make? If i do ghc --make Module libmodulelib.a then ghc syas: chasing modules from Module,libmodulelib.a and complains about not being able to find the _module_ modulelib.a. Likewise on windows, if I do ghc --make Module modulelib.dll it also complains about not finding the _module_ modulelib.dll. If I specify the object files that makes up modulelib then there are no complaints, likewise, if I link without --make, ghc uses the library just fine. Is this the intended behaviour, and if it is, how do I go about linking with libraries when using --make? Regards, Martin signature.asc Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signeradmeddelandedel
Re: ghc --make and static libraries (SOLUTION)
tor 2002-10-10 klockan 14.02 skrev Martin Norbäck: How do I go about linking to a static library when using --make? If i do ghc --make Module libmodulelib.a then ghc syas: chasing modules from Module,libmodulelib.a and complains about not being able to find the _module_ modulelib.a. Likewise on windows, if I do ghc --make Module modulelib.dll it also complains about not finding the _module_ modulelib.dll. If I specify the object files that makes up modulelib then there are no complaints, likewise, if I link without --make, ghc uses the library just fine. Is this the intended behaviour, and if it is, how do I go about linking with libraries when using --make? Thanks for those who replied. I found a solution: use -optllibmodulelib.a and -optmodulelib.dll and they will be ignored and just passed on to the linker as they should be. Regards, Martin signature.asc Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signeradmeddelandedel
The readline issue
Sorry for starting this GPL flame war. It was not my intention. I'm not worried about the license on ghc itself, but more on the fact that by using ghc to compile non-gpl programs you can violate the readline license. It seems steps are being taken to avoid this, by putting the Readline module in a separate package and noting this in the users guide. So I am a happy camper now. -- Martin Norbäck [EMAIL PROTECTED] Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B signature.asc Description: PGP signature
Re: install question
lör 2002-05-25 klockan 23.26 skrev chris.danx: Hi, apologies if this is slightly OT (Linux is new to me, by about 24 hours; I see version numbers and freak out), can the ghc 5.02.3 rpms for suse 7.3 be used with suse 8.0? You probably should just try and see if the RPMS install, and try to compile a small program. If they don't install, then perhaps there is some compatibility RPM for suse that you can install. Regards, Martin -- Martin Norbäck [EMAIL PROTECTED] Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B signature.asc Description: PGP signature
Re: module namespaces with Prelude
tor 2002-04-25 klockan 01.07 skrev Johan Nordlander: One might also argue that the problem is these extra roots that are implicitly added to the search path. Arguably, dropping the current directory and the directory of the importing module from the search path would solve the problems listed above. But there's still a possibility to list overlapping directories in the search path proper, so dropping the implicit directories wouldn't really cure the disease, only make it less prominent. Furthermore, this feature is there because it has been in Hugs for a long time, and many people seem to rely on it quite heavily. But how would adding the directory of an importing module make any difference? Assuming non-hierarchical names, if the importing module is found, then it's directory already must be in the seach path. So there is no reason to add it. All in all, dropping all implicit directories from the search path gets my vote. Dropping all implicit directories but the current directory gets mine. On the other hand, adding . to the search path is no big trouble, and then it will work exactly like java. A compiler could even allow search paths to be tar-files (or tar.gz, tar.bz2, zip, jar, ...). Regards, Martin signature.asc Description: PGP signature
Re: scope in ghci. Reply
fre 2002-02-15 klockan 07.26 skrev S.D.Mechveliani: Martin Norb [EMAIL PROTECTED] writes I just noticed this behavior with ghci After loading a module with :l Module you can't use the Prelude functions unqualified, you just get things like interactive:1: Variable not in scope: `show' I am pretty sure that this worked some days ago, and I was using the same version then. I feel totally confused. Has this happened to anyone else? Even if Prelude is visible, still the library items are not. (List.sort, Ratio ...). Maybe, this is natural, I do not know. But I'm not talking about its library items, I am talking about things like sort, =, and print. Surely they will be visible at all times, the Prelude is automatically imported into all modules (unless it's explicitly imported in the module, which is not the case here). Although this semantics only makes sense for compiled programs, I think it's a resonable thing to have the Prelude always visible in ghci. When ghci is first started, the Prelude is visible, so it would be reaonable not to hide it when a module is loaded. Perhaps if the module exports a symbol already in the prelude it could be hidden. I think this is a bug in ghci. Regards, Martin -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. SIGBORE: Signature boring error, core dumped ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: strange behavior with ghci version 5.02.2
fre 2002-02-15 klockan 10.48 skrev Simon Marlow: After loading a module with :l Module you can't use the Prelude functions unqualified, you just get things like interactive:1: Variable not in scope: `show' I am pretty sure that this worked some days ago, and I was using the same version then. I feel totally confused. Has this happened to anyone else? Yes, for some modules it happens for others it doesn't. Kind of strange. SuSE 7.3 rpms here, v. 5.02.2 J.A. You're probably loading compiled versions of these modules. GHC 5.02.2 will only give you the exports of a compiled module when it is selected with :module. Yes, I was loading a compiled module, and indeed, removing the Module.o file, enables me to use Prelude functions after loading it with :l Module. A clean semantics for this in ghci would be to view the interpreter as a module and all modules with :module and :load are treated just as if imported into this module. So you could write :load qualified Module :load Module hiding (name) and so on. In any case, there should be no difference in semantics between loading an interpreted module and a compiled one. If there are big problems in keeping the semantics the same, then I suggest always interpreting the module :loaded, even if a compiled version exists. Regards, Martin -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. SIGBORE: Signature boring error, core dumped ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
strange behavior with ghci version 5.02.2
I just noticed this behavior with ghci After loading a module with :l Module you can't use the Prelude functions unqualified, you just get things like interactive:1: Variable not in scope: `show' I am pretty sure that this worked some days ago, and I was using the same version then. I feel totally confused. Has this happened to anyone else? Regards, Martin -- Martin Norbäck Safelogic AB [EMAIL PROTECTED]Stena Center 1C +46 (0)31 772 81 70S-412 92 GÖTEBORG http://www.safelogic.seSWEDEN ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linking Problem, ghc 5.02: cannot find -lreadline
tis 2002-02-05 klockan 11.53 skrev Marc van Dongen: When I tried to compile some large program I was delighted to see that all object files got created smoothly. At the linking stage I got an error: ''cannot find -lreadline collect2: ld returned 1 exit status'' I couldn't find anything about this on the web or in the mini faq. Anybody there to give me a quick hint how to get around this? Install the readline-devel package. Regards, Martin -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. SIGBORE: Signature boring error, core dumped ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
5.02.2 binary incompatible with 5.02.1
I just noted that 5.02.2 is binary incompatible with 5.02.1 which is a minor nuisance, since I must then recompile all my .o-files. This was not mentioned in the release notes, perhaps it was unintentional? On the other hand, the time of compilation of my happy parser decreased from 20 minutes to 10 minutes, probably because of the lower memory usage. So, I am not that angry :) Regards, Martin -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. SIGBORE: Signature boring error, core dumped ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: 5.02.2 binary incompatible with 5.02.1
tis 2002-01-22 klockan 15.48 skrev Simon Marlow: I just noted that 5.02.2 is binary incompatible with 5.02.1 which is a minor nuisance, since I must then recompile all my .o-files. This was not mentioned in the release notes, perhaps it was unintentional? Yes, this is the case for *all* releases of GHC, even minor ones(*). It would be nice to improve this situation, but unfortunately retaining binary compatibility is not straightforward due to the high level of coupling between compiled modules - the price you pay for aggressive inter-module optimistaion. Ok, then I would like to make a request that this fact is caught before linking, since the linker error is a bit non-informative. There is a version string in the .hi-file, but it only says 502, which is the same in both releases, so it doesn't help. Perhaps ghc should put 5022 there? Regards, Martin -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. SIGBORE: Signature boring error, core dumped ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
