- Glasgow-haskell-users

RE: Porting mips-sgi-irix65 [help]
by Simon Marlow 13 Dec '02

13 Dec '02

> Box : mips-sgi-irix65 > Version : 4.08.2 Unregisterised ( using > mini-interpreter) > Source File : nfibI.hc > ( compiled on a running box i386-unknown-linux ) > -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER > -fno-asm-manling > -funregistered -fvia-C -C > Traced File : ghc/rts/GC.c ( Garbage collector ) > References : ghc/includes/Closures.h,ClosureTypes.h,ClosureMacros.h > "Implementing lazy functional Lan..." [Peyton Jones] > > Session: > ======== > bash-2.04$ ghc -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER > -fno-asm-mangling > -funregistered -fvia-C nfibI.hc -o nfibI > > bash-2.04$ ./nfibI --run in irix > nfibI: fatal error: evacuate: strange closure type 4137 > > bash-2.04$ ./nfibI --run in linux > 2692537 > > Linux closure-type sequence: Irix closure-type sequence: > ============================ > ================================= > 59 (TSO) 59 > 59 59 > 59 59 > 10 (CONST_NOCAF_STATIC) 10 > 10 10 > 33 (IND_STATIC) 4137 (zzz! Max number 64 !) > 17 (FUN_STATIC) > 33 > 17 > 33 > 29 Something is wrong with the heap layout perhaps, or maybe the info tables. I can't tell much more from the information above; you'll need to fire up gdb on the executable and dig into the contents of the heap and info tables at the point of the crash. Cheers, Simon

1 0

RE: Problems with main in a lib*.a. Is that a bug?
by Simon Marlow 12 Dec '02

12 Dec '02

> Ok, I have made a "ghc -v"and see the problem : > > * on OS X, a SDL program must have a main function supplied > by a lib : > libSDLmain.a > * This is achieved by adding -lSDLmain at the command line. > > * libHSrts.a supply a main. My program is linked against this > lib by a -lHSrts. > > ld is called by ghc with args : > [...] lHSrts [...] -lSDLmain [...] Hmm, I just checked the source, and GHC definitely calls the linker passing any -l options from the command line *before* -l options from packages (-lHSrts comes from the rts package). And I just tried a small example with -lfoo on the command line, and it does indeed come before -lHSrts. So could you post *exactly* what you're doing, the full command lines and the full output from ghc -v so we can see what's going wrong. Cheers, SImon

1 0

File searching
by Simon Marlow 12 Dec '02

12 Dec '02

Hi Folks, I've attached a Haskell module that describes GHC's file searching strategy in the form of a simplified implementation, which serves as a precise description of what GHC actually does. I'm hoping we can use this as a starting point from which to discuss extensions. I've already added two extensions (see the source for details). The simulation is complete, in that it covers what happens with packages, what happens when you name a source file on the command-line, what happens with files named in a ':load' command in GHCi, and so on. All the various flags affecting GHC's search behaviour can also be tweaked. Enjoy... Cheers, Simon

1 0

RE: Calling ghc dll's with MSVC++ code
by Simon Peyton-Jones 12 Dec '02

12 Dec '02

I don't know if you got a reply to his message. (You should send GHC-specific mail to glasgow-haskell-users, not the main Haskell list, incidentally.) I'm not confident that creating Haskell DLLs is working at the moment. Has anyone else done it? Trouble is, there isn't yet a critical mass of DLL users to be sure that it works and stays working. Which is a bit of a chicken and egg problem. Windows programmers unite! Simon -----Original Message----- From: Mauricio Carvalho [mailto:m.decarvalho@telia.com] Sent: 03 December 2002 14:13 To: haskell(a)haskell.org Subject: Calling ghc dll's with MSVC++ code Hey! I need to call haskell DLL's from a c++ program, and this C++ is written in Microsoft's Visual C++ 6.0 I created the DLL sing the directives given at ghc user's guide (11.3 and 11.4) and created the dll. To create a .lib import file, I linked with the option -optdll--output-lib -optdllMyDll.lib I can compile and link my C++ problem, but when I run it, it crashes. I tried even to create a DLL from a C source I'm sure it works (as I created the DLL before with MSVC++ environment, and I could make it work out), and even this DLL crashes whe its functions are accessed. I'm using GHC 5.0.4.1 Is there some special command lines that must be used to create DLLs to be used with windows? Or is there some known difficulty doing it? Someone that succeded can please tell me exactly how was it done? If more info is needed, I can send the sources and command lines I used to compile. ps: I'm not using cygwin (i don't have it installed in my computer actually), but as far as I understood, it shouldn't be a problem ´Thanks for help! Mauricio

1 0

RE: Proposals for changes to searching behaviour
by Simon Marlow 11 Dec '02

11 Dec '02

> > - We could provide the ability to specify a module prefix > to associate > > with a directory in the search path. For example, you could say > > that the directory '.' is associated with the module prefix > > "Graphics.Rendering.OpenGL" and avoid having to place > your sources > > in the directory Graphics/Rendering/OpenGL. > > > > I'm not sure what syntax we'd use for this. Henrik suggested > > placing the module prefix in square brackets before the > directory, > > eg. > > ghc -i '-i[Graphics.Rendering.OpenGL].' > > Does that mean I can refer to X.hs as > [Graphics.Rendering.OpenGL(.Graphics.Rendering.OpenGL)*/]X.hs ?-) > Probably no problem with Haskell's explicit imports. Good point, which should be cleared up. We don't intend GHC to have any knowledge of relative pathnames and the meaning of '.' or '..'. So the meaning of an import path [Graphics.Rendering.OpenGL]D would be simply this: when looking for a module's source/interface, if the module name is of the form Graphics.Rendering.OpenGL.M, then we look for D/M.hs. If it doesn't exist, we move on to the next entry in the search path. Cheers, Simon

2 1

RE: Problems with main in a lib*.a. Is that a bug?
by Simon Marlow 11 Dec '02

11 Dec '02

> I am building a SDL binding on MacOS X (but the same problem should > appears on Windows). It defines it's own main function in a > libSDLmain.a. > > But I can't get ghc not to generate a main when linking with > -lSDLmain, > which is the option that is indicated to get the main function that > make SDL usable. > > when I link write : > > ghc -o test Main.hs libSDLmain.a , ghc doesn't generate a main as it > can see there is a main in libSDLmain. And my test programs works. > > but when I write > > ghc -o test Main.hs -lSDLmain, ghc creates its own main, and > it doesn't work. Could you give more details? What is the error message? GHC doesn't generate main, there's a main function in libHSrts.a which is linked in last, so that you can override it with your own. You should probably use -no-hs-main, too, otherwise the linker will require that Main.main exists in the Haskell code. Cheers, Simon

2 1

Re: Constructors in GHC (fwd)
by Hal Daume III 11 Dec '02

11 Dec '02

...this seemed not to make it to the mailing list (ghc-users(a)haskell.org isn't valid)... -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume ---------- Forwarded message ---------- Date: Wed, 11 Dec 2002 08:33:50 -0800 (PST) From: Hal Daume III <hdaume(a)isi.edu> To: Simon Peyton-Jones <simonpj(a)microsoft.com> Cc: ghc-users(a)haskell.org, Kirsten Chevalier <krc(a)uclink.berkeley.edu> Subject: Re: Constructors in GHC Hi, It finally makes sense now :) > We could make this more consistent in two ways. Alternative (A): One > way would be to make it clearer that $wMkT was the real constructor: > > data T = $wMkT Int Int > MkT p = case p of (x,y) -> $wMkT x y > f x y = $wMkT x y > g t = case t of $wMkT x y -> x > > Alternative (B): The other alternative would be to make the original > Haskell constructors into the $w things: > > data T = MkT Int Int > $wMkT p = case p of (x,y) -> MkT x y > f x y = MkT x y > g t = case t of MkT x y -> x As someone using external core, I can resoundly say: I don't really care :). I would probably prefer (B), as you seem to, but it's not a strong preference.

1 0

Constructors in GHC
by Simon Peyton-Jones 11 Dec '02

11 Dec '02

This message is to air a possible change in the way GHC handles constructors. Before I make the change I want to check that it isn't going to mess anyone up. There's some background in http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/the-beast/data-types.h tml Consider the following data T = MkT !(Int,Int) f x y = MkT (x,y) g (MkT (x,y)) = x If you compile this with -funbox-strict-fields, GHC will unbox the strict pair, to give effectively this data T = MkT Int Int f x y = MkT x y g t = case t of MkT x y -> x Rather than find all the applications of MkT, it actually *defines* MkT like this MkT p = case p of (x,y) -> $wMkT x y where $wMkT is the "real" constructor. So the "real" data type is data T = $wMkT Int Int and MkT is just a "wrapper function". However in Core-language case expressions we still print 'MkT': g t = case t of MkT a b -> ... even though the "real" constructor is $wMkT. (On the face of it, MkT a b isn't even well typed.) This is a bit of a mess, especially when we print External Core. Then we get data T = MkT Int Int MkT p = case p of (x,y) -> $wMkT x y f x y = $wMkT x y g t = case t of MkT x y -> x Strange! MkT looks like the constructor for T, but is also given a definition; and $wMkT doesn't seem to be defined at all. This gives rise to difficulties when reading External Core back in. We could make this more consistent in two ways. Alternative (A): One way would be to make it clearer that $wMkT was the real constructor: data T = $wMkT Int Int MkT p = case p of (x,y) -> $wMkT x y f x y = $wMkT x y g t = case t of $wMkT x y -> x This is consistent, but it makes External Core a bit funny. (The real constructors are always $w things.) Alternative (B): The other alternative would be to make the original Haskell constructors into the $w things: data T = MkT Int Int $wMkT p = case p of (x,y) -> MkT x y f x y = MkT x y g t = case t of MkT x y -> x This makes Core (and External Core) nice and consistent, with traditional upper-case constructors, but MkT now has a different type than in the original program. We'd need to take care when printing type errors etc that we didn't print $wMkT when the programmer expected MkT. (That isn't too hard.) Personally, I'm inclined to alternative (B). Do any of you have an opinion? Especially folk using External Core? Simon

2 1

RE: -hidir separation of search/output paths
by Simon Marlow 11 Dec '02

11 Dec '02

> Oops, one more request which I almost forgot: -hidir currently > specifies both where to search for .hi files, and where to output > hi files. It would be good to split up the two operations into > two distinct options; e.g. use -hidir to search for interface > files, and a new option such as -ohidir to specify where to > output new interface files. > > This is very useful if you're trying to build stuff (with --make) > outside of the source tree: you could write > > "-i$src/SomeLibrary" to tell GHC to find the .hs files in > a directory named $src/SomeLibrary, > > "-hidir$build/SomeLibrary" to find the .hi files in > a directory named > $build/SomeLibrary, and > > "-ohidir ." to tell GHC to output any .hi files to the > current directory Urk! I'm really not sure that we need yet another option that further complicates the behaviour. You don't say whether you're using --make/GHCi or "one-shot" (ghc -c) mode. This makes a difference to the search behaviour: the former searches for source files, whereas the latter searches for interface files along the search path. One-shot mode tends to be more flexible with respect to the naming of files, so if you want to separate your source files from your interface files or give the source files non-standard names, then one-shot is usually the way to go. If you have pre-built libraries that you don't want to recompile, the proper way is to make it into a package. GHC maintains recompilation information within a package only, and assumes that all packages except the "home" package are fully up to date. Cheers, Simon I think I should try to write down a precise description of GHC's file searching behaviour so we can discuss changes more easily...

1 0

RE: Proposals for changes to searching behaviour
by Simon Marlow 11 Dec '02

11 Dec '02

> The suggested changes sound hard to understand and to implement > consistently in all compilers. I lean towards leaving the spec as it > is. Hmm, I'm not sure why you say these changes are hard to understand. Which part(s) in particular do you find difficult? Hugs already implements the first suggestion. > IIRC, the current Hugs semantics is a complex balancing act intended > to achieve backward compatability and implement module paths at the > same time. I'd prefer to see everyone switch over to the new way so > that we can drop old features. Johan and I discussed the current search semantics when it was implemented in Hugs, so that we could make GHC(i) and Hugs agree. I believe they currently agree on all but the point I made in my first suggestion. There were two features in Hugs that could be considered "backwards compatibility": Hugs allowed a module M to be placed in the file M (no extension), and Hugs allowed an import declaration to give a filename rather than a module name. I thought both these features were gone, but I just checked and the first seems to be still present in the Hugs Nov 2002 release. Cheers, Simon

1 0