> - The sources for a module A.B.C would be allowed to be placed
> in either A.B.C.hs or A/B/C.hs relative to one of the directories
> in the search path. Currently only A/B/C.hs is allowed.
>
> This is an easy change to make, and I believe Hugs already does
> it this way.
Soun
Hello,
I am doing a small binding to SDL lib. It needs on some platforms to
have a C main function.
So I make a C main that call Haskell initialisation, Haskell main and
call shutdownHaskell.
It works fine with ghc.
When linking with ghci I have an error :
> ghci -package SDL
[...]
Loadin
Hi,
I'm wondering what needs to be done in order to use ticky-ticky profiling --
section 5.7 in the Users' Guide says:
"To be able to use ticky-ticky profiling, you will need to have built
appropriate libraries and things when you made the system. See ?Customising
what libraries to build,? i
> It's all bad once that VPATH word gets mentioned ;).
Granted!
But other work-arounds can be even worse!
And again, if an implementor for some reason thinks he or she could benefit
from using a mechanism like VPATH, it's good if that's not too painful.
/Henrik
--
Henrik Nilsson
Yale Universi
Thanks to the amazing work by Wolfgang Thaller on GHC for Mac OS
X, it was trivial to port the RuntimeLoader to work on Mac OS
X (or Darwin, if you want to be pedantic).
The runtime loader enables a GHC program to load object files
(.o) at runtime and load functions in them, much like how you ca
On Mon, Dec 09, 2002 at 12:03:10PM -0500, [EMAIL PROTECTED] wrote:
> If, say, a library consists of the top-level module "A.B.C" and
> a bunch of internal components "A.B.C.M1", "A.B.C.M2", etc.,
> I can't see why I should not be allowed to put them all in one
> directory.
I think that's the sel
Hi Peter,
> Now, since ghc -M does such a great job at gobbling up the
> dependencies, I wonder if it was not possible to extend its
> functionality a little bit so that it also determines the .o files
> that are required to link a Main program. I could imagine something
> like an -optdep-Main and
> > Keine Berechtigung == No authorization (according to babel
> fish). You
> > wouldn't perchance be trying to configure in a tree you don't have
> > write access to, would you?
>
> Yes, since ownership changed I don't have write permission.
> But I could
> reproduce the original output belo
Hi Andre,
> I like this idea, especially if this is currently the way Hugs
> does it. It's great for smaller projects.
Yes, we believe Hugs does allow "A.B.C.hs" as well as "A/B/C.hs".
Ultimately, I think it is actually going to quite important that the
different Haskell tools provoide reasonab
Folks,
after using ghc --make happily in a project for a while I am switching
to using Makefiles since I have a number of Main programs in the same
directory that share a lot of modules.
Now, since ghc -M does such a great job at gobbling up the
dependencies, I wonder if it was not possible to ex
Simon Marlow wrote:
That's strange, configure is supposed to emit the error only if
config.guess fails.
maeder@davinci -> ./config.guess
./config.guess: line 844: dummy-5901.c: Keine Berechtigung
./config.guess: line 1: dummy-5901.c: Keine Berechtigung
./config.guess: line 1105: dummy-5901.c: Ke
> > That's strange, configure is supposed to emit the error only if
> > config.guess fails.
>
> maeder@davinci -> ./config.guess
> ./config.guess: line 844: dummy-5901.c: Keine Berechtigung
> ./config.guess: line 1: dummy-5901.c: Keine Berechtigung
> ./config.guess: line 1105: dummy-5901.c: Kein
Simon Marlow wrote:
Simon Marlow wrote:
when installing ghc and hugs under SuSE linux 8.1 I got
"configure: error: can not guess host type; you must specify one"
It worked after I added "--host=i386-linux"
[ redirected to [EMAIL PROTECTED] ]
What does config.guess return on your system?
i
> Simon Marlow wrote:
> > when installing ghc and hugs under SuSE linux 8.1 I got
> >
> > "configure: error: can not guess host type; you must specify one"
> >
> > It worked after I added "--host=i386-linux"
> >
> >
> > [ redirected to [EMAIL PROTECTED] ]
> >
> > What does config.guess return
Hi Lauri,
> Since the problem is often that your program/library has a managable
> depth, but it is _located_ very deep in the hierarchy (eg. User.*
> modules if you have a long and complicated domain), then how about
> allowing A.B/C.hs for module A.B.C? Then you don't need to have a
> long, most
Hi,
>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].'
>
>In contrast to the previous suggestion, this would actually save
>some trips to
Simon Marlow wrote:
when installing ghc and hugs under SuSE linux 8.1 I got
"configure: error: can not guess host type; you must specify one"
It worked after I added "--host=i386-linux"
[ redirected to [EMAIL PROTECTED] ]
What does config.guess return on your system?
i686-pc-linux-gnu
Chri
> when installing ghc and hugs under SuSE linux 8.1 I got
>
> "configure: error: can not guess host type; you must specify one"
>
> It worked after I added "--host=i386-linux"
[ redirected to [EMAIL PROTECTED] ]
What does config.guess return on your system?
Cheers,
Simon
__
On Mon, Dec 09, 2002 at 12:40:18PM -, Simon Marlow wrote:
> - The sources for a module A.B.C would be allowed to be placed
> in either A.B.C.hs or A/B/C.hs relative to one of the directories
> in the search path. Currently only A/B/C.hs is allowed.
>
> This is an easy change to
On Mon, Dec 09, 2002 at 12:40:18PM -, Simon Marlow wrote:
> - The sources for a module A.B.C would be allowed to be placed
> in either A.B.C.hs or A/B/C.hs relative to one of the directories
> in the search path. Currently only A/B/C.hs is allowed.
> Please let us know if either of
Hi Folks,
Henrik Nillson & I have been discussing the current behaviour of GHC
when searching for modules, particularly in combination with
hierarchical modules, and have identified two ways in which things might
be made more flexible.
The current situation forces you to put sources in a director
21 matches
Mail list logo
