December 2002 - Glasgow-haskell-users

Re: Glasgow-haskell-users digest, Vol 1 #672 - 1 msg
by George Russell 16 Dec '02

16 Dec '02

glasgow-haskell-users-request(a)haskell.org wrote: [snip] > I've been experimenting with making an asynchronous IO library. At the > moment it uses Haskell threads but the idea is that it could be > transparently extended to use system AIO. I think what you are really asking for is asynchronous events, a la Reppy. I don't like to blow my own trumpet (well, I do actually), but I've already implemented these in Haskell, see the paper in ICFP 2001. Of course John Reppy got there first with PML/CML. > > http://charlesstreet22.force9.co.uk/~duncan/projects/aio/AIO.hs > > My question is if there is an effecient way to block / wait on multiple > MVars. takeMVar & readMVar can wait on one MVar. The puspose is to be > able get the reults of a list of AIO operations, in the order in which > they complete. Not at the moment. Also I'm not sure such a thing could usefully be added without more or less adding events anyway. It's not enough to have takeOneMVar :: [MVar a] -> IO a which looks for the next a, because pretty soon someone is going to want you to implement data MVarActionPair a = forall b . MVarActionPair (MVar b) (b -> IO a) takeOneMVar' :: [MVarActionPair a] This I suppose could be done without too much trouble, but then you run into problems because the supplier of events has no way of knowing if these events are actually being picked up or not, something that can be very important. To solve this problem in general you need Reppy-style higher-order events. So you might as well have implemented those from the beginning anyway. Also I am very much opposed to loading extra burdens onto the implementors of MVar's unless we can be reasonably sure that MVars won't get slower as a result. MVars are an excellent low-level abstraction; it's better to build more complicated things on top of MVars as required. Good luck, George Russell

1 0

RE: -no-hs-main behaviour
by Simon Marlow 16 Dec '02

16 Dec '02

> On Tue, Dec 10, 2002 at 10:35:22AM -0000, Simon Marlow wrote: > > > Even if you do need to use --make or GHCi, then I think you > can still > > specify all the source files on the command line. > > While on the subject of GHC's build options, can we change the > behaviour of -no-hs-main when it's used with --make? > > Currently, if you use --make and GHC finds a main function, it > will attempt to link all the modules together to produce an > executable -- even if you specify -no-hs-main. > > Is it possible to modify the behaviour so that if --make > -no-hs-main is specified, GHC won't perform the link if it finds > a main function? I think we should probably just have a -no-link option rather than overload the behaviour of the -no-hs-main option. Cheers, Simon

2 1

waiting on multiple MVars
by Duncan Coutts 14 Dec '02

14 Dec '02

Hi all, I've been experimenting with making an asynchronous IO library. At the moment it uses Haskell threads but the idea is that it could be transparently extended to use system AIO. http://charlesstreet22.force9.co.uk/~duncan/projects/aio/AIO.hs My question is if there is an effecient way to block / wait on multiple MVars. takeMVar & readMVar can wait on one MVar. The puspose is to be able get the reults of a list of AIO operations, in the order in which they complete. You could iterate through the list and tryTakeMVar, or spawn a thread to block on each one and then write into a central MVar or Channel. The latter is the approach that I am currently using. the reason you can't simply set them up to all write to a single MVar in the first place is that it is desirable to be able to have the same AIO operation be synchronised by multiple readers / clients. Is there a better way to do this? Or would it need a new MVar / scheduler primitive? Duncan

1 0

Porting mips-sgi-irix65 [help]
by Rafael Martínez Torres 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 Why these special types (33,17) crash ? Where is the info-type stored ? Is IRIX closure representation-allignment faulty (char vs int )? -------------------------..........----------------...........--------- | | | | info-pointer | pointer-words | non-pointer words | | | -------------------------..........-----------------...........--------- Any suggestions to go on hacking ....

1 0

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