- Glasgow-haskell-users

Database library?
by Bryn Keller 16 Oct '02

16 Oct '02

Does anyone have a GHC-friendly library for accessing databases, specifically Oracle and MSSQL? I noticed Hasql on the Haskell libraries page, but it seems rather in the beginning stages, and I was hoping for native DB connections rather than ODBC ones. How are others handling database access? Thanks, Bryn

2 1

GHCI parse bug?
by Bryn Keller 16 Oct '02

16 Oct '02

Prelude> let f = \x->\y->\z->x (map (+ y) z) <interactive>:1: parse error on input `->\' Prelude> let f = \x-> \y-> \z-> x (map (+ y) z) Prelude> Are the spaces really necessary, or is this a bug? Thanks, Bryn

2 2

Sexletter
by Titty 16 Oct '02

16 Oct '02

http://adultcity.biz/area/hardcore/grandetopa/index.htm Il portale per adulti con migliaia di filmati e foto web-cam, chat, annunci, fotoannunci scambio-coppie IL MEGLIO DEL WEB!!! Bellissime ragazze ti aspettano davanti alle loro web-cam... http://adultcity.biz/area/hardcore/grandetopa/index.htm VORRESTI ESSERE DALL'ALTRA PARTE PER ASSISTERE AD UNO SPOGLIARELLO SOLTANTO PER TE?!? Per non ricevere pi� e-mail scrivi a: writeln(a)virgilio.it

1 0

3 KASIM VE B�Z
by Gen� Parti 15 Oct '02

15 Oct '02

1 0

RE: Hierarchical modules and compilation output redirection
by Martin Norbäck 15 Oct '02

15 Oct '02

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

1 0

RE: No GHC support for a week
by Simon Marlow 15 Oct '02

15 Oct '02

I'm still having trouble reproducing this heapCensus crash. <plea> If *anyone* has a program which generates this heapCensus failure, regardless of whether it's reliably repeatable or not, please send me the code. I'd love to get this one nailed before 5.04.2. </plea> Cheers, Simon > -----Original Message----- > From: Hal Daume III [mailto:hdaume@ISI.EDU] > Sent: 02 October 2002 15:51 > To: Ketil Z. Malde > Cc: Simon Marlow; glasgow-haskell-users(a)haskell.org > Subject: Re: No GHC support for a week > > > Ketil, > > Simon and I have been tracking down this bug for some time now. A few > days ago I was finally able to come up with a often > repeatable, relatively > short example (enough qualifiers? :P). Last I talked to him, > Simon was > getting it running in gdb, but because of how the moon was aligned > yesterday (or something), it was refusing to fall over. > > If you have a short program which demonstrates the same > problem, I'm sure > Simon would love to get a copy... > > - Hal > > -- > Hal Daume III > > "Computer science is no more about computers | hdaume(a)isi.edu > than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume > > On 2 Oct 2002, Ketil Z. Malde wrote: > > > "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > > > GHC support will be intermittent at best for the next > week or so, as > > > Simon & I are both heading out to Pittsburgh for ICFP and > the Haskell > > > workshop. Catch you all later... > > > > And here I recently started using GHC 5.04 from the provided RH7.2 > > packages, and getting occasional "heapCensus" errors. Relatively > > rare, difficult to reproduce, rerunning on the same data usually > > works. > > > > (I was going to forward another question about a heap usage > problem I > > had, but it turned out it was just a question of applying a bit more > > strictness in the right place. :-) > > > > -kzm > > -- > > If I haven't seen further, it is by standing in the > footprints of giants > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users(a)haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > >

1 0

RE: Hierarchical modules and compilation output redirection
by Simon Marlow 15 Oct '02

15 Oct '02

> 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. Perhaps -odir should append the full module name as a directory (i.e. the default behaviour would be a special case where -odir is "."). > 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. 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? Cheers, Simon

1 0

Hierarchical modules and compilation output redirection
by Martin Norbäck 15 Oct '02

15 Oct '02

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

2 1

RE: ghc --make and static libraries
by Simon Marlow 15 Oct '02

15 Oct '02

> 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. Thanks, I've fixed this to do The Right Thing, I think. Cheers, Simon

1 0

RE: IO security
by Simon Marlow 14 Oct '02

14 Oct '02

> I'm looking for secure compile and run-time methods to ensure > automatically that Haskell modules cannot perform particular > IO operations. Therefore, I've got some questions that might > be interesting for other people using GHC as well. > > o There are functions like "unsafePerformIO". How many of these > unsafe functions exist and what are their names? Is there > a possibility to tell GHC to reject programs in which > such functions occur? Concerning, e.g., the rewrite-rule system, > how can we prevent that these functions are applied by > some trick, invisible by an automatic inspection of the > source code? > > o Is the function "print" secure in the sense that all stuff > it produces is restricted to go to stdout, even if strange > sequences of control characters appear? > > o Is there a way to tell the GHC run-time system to block > file operations or system calls coming from the > application program, while permitting input/output > via stdin/stdout? Security of a Haskell program is an interesting research area in itself. I suspect the folks at Galois Connections have something to say on the topic. My opinion would be that trying to approach the problem as you have, namely identifying the "unsafe" features and removing them, is likely to be difficult or impossible to verify. A better approach might be to start from a clean slate (ie. remove the IO monad altogether) and incrementally add in safe features separately. Cheers, Simon

1 0