RE: GHC and Windows (DLL/FFI) woes

2005-10-24 Thread Simon Marlow
On 23 October 2005 19:00, Esa Ilari Vuokko wrote:

 I have been trying to build some Windows DLLs with
 GHC, and I have run into some misfeatures or maybe
 I have misunderstood how to use GHC.  Any help or
 advice would be appreciated. :)
 
 First of all, I can't get ghc to generate stubs from
 foreign export in anywhere else than next to original
 source, which is sort of annoying.  I would like all
 the generated files to go quite a bit diffrent place than
 source directory.

We don't have a flag for that; perhaps we should.  Or perhaps there
should be a flag that says put all generated files here, that subsumes
-odir, -hidir, -hcdir and also coveres _stub.{c,h} files.

 Next, --make and --mk-dll don't seem to work together.
 Ok, what I do, is I just --make -no-link and then --mk-dll
 all the object files I find :)

That's true.  This is closer to working in 6.5, we should make it work
(if anyone's interested, this just means hooking up DriverPipeline.link
with DriverPipeline.doMkDLL in the right way).
 
 It seems that -i flag and compiling those _stub.c have
 following problem:  if path given in -i flag contains any
 /- or \-characters, i.e. any real subpaths, it seems to
 stop with something like:

\source\sunrise\haskell\haskell\..\debug\build\haskell\plugin-hs-test/d:
:
 createDirectory: invalid argument (Invalid argument)
 It seems a bit random what is the supposed filename
 part of the path, typically it contains drive letter and few
 colons, it doesn't seem totally random data.

Could you give me a detailed description of the problem: the exact
command line, and the error message that is produced.  Thanks.

Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Segfaulting programs with GHC 6.4.1

2005-10-24 Thread John Goerzen
On Mon, Oct 24, 2005 at 10:53:48AM +0100, Simon Marlow wrote:
 Hi John,
 
 Thanks for trying to narrow this down.  At this stage it looks like some
 kind of heap corruption.  Can you reproduce it on more than one machine?

Yes, though it is not nearly as easy.  I cannot really explain that.
I suspect it could have something to do with the order of data coming
from the DB (it's unordered) or system load or something else along
those lines.

Here's another odd thing: the binaries built on the two systems are not
quite identical, even though, as far as I can tell, everything about the
build environment is identical (Debian sid).  One is a few K larger than
the other, and I can't figure out why.

Both are fairly new, nice workstations from HP.  I've had no trouble
like this with any other program on either, and this isn't the first
task like this either place.

Also, it seems that the binary produced on one is more prone to crash
than that produced on the other.  But it could be my imagination.

 (we have to rule out hardware failure, it's happened before and can cost
 a lot of debugging time).
 
 I'll need to reproduce it here.  Can you give me a set of instructions
 to get me up to the right point?

Here goes.  Reminder, my test environment is Linux x86, ghc 6.4.1:

1. Install PostgreSQL 8.0.  You can get this with most Linux distros,
   or from www.postgreql.org.

2. As your PostgreSQL user (usually you may need to su to postgres),
   run:

   createuser smarlow
   createdb smarlow
   createlang plpgsql smarlow

   (In this and following steps, replace smarlow with your Linux
   username, if it's not smarlow)

3. Download http://www.complete.org/~jgoerzen/dump.bz2 (7.7MB)

4. Back as your normal smarlow user, run:

   bzcat dump.bz2 | sed 's/ jgoerzen/ smarlow/'  dump.sql
  (spaces and quotes are important there; unpacks to 190MB)
   psql -f dump.sql -U smarlow smarlow

   There will be four errors at the beginning that you can ignore.
   (must be owner of schema public, 2x permission denied for language
   c, must be superuser to create procedural language)

   This will probably take a few minutes to run.  I think it will take
   up about 500MB of disk space once loaded.

5. Install prerequisites.  You will need HSQL 1.6 and the HSQL
   PostgreSQL module, plus MissingH 0.12.1
   from
   http://http.us.debian.org/debian/pool/main/m/missingh/missingh_0.12.1.tar.gz
   .  Both are cabalized.

6. Now, get the code.  darcs get http://darcs.complete.org/gopherbot

   ghc --make -o setup Setup.lhs
   ./setup configure
   ./setup build

7. Create the directory /home/jgoerzen/tree/gopher-arch on your system,
   making sure that your smarlow user has read access to it.

   (The data stored in the DB, as well as a config, references that path
   for now.  Sorry.)

8. Adjust these settings in your postgresql.conf, making sure to remove
   the existing values, if any:

   shared_buffers = 3000
   sort_mem = 4000
   maintenance_work_mem = 96000
   work_mem = 64000
   fsync = off 
   checkpoint_segments = 12
   effective_cache_size = 8000

   And then restart the PostgreSQL server.

9. Now run dist/build/gopherbot.

   You should see it start to download documents, and crash after a few
   minutes.

   If you have trouble connecting, 
   adjust the first empty string on line 42 of DB.hs to match 
   unix_socket_directory in your postgresql.conf.

   The settings made in step 8 make PostgreSQL much faster.
   Without them, it is hard to make the program crash.

   The program will use about 500MB RAM while running.

   It will take about 10 minutes to get up to speed.  (It takes a bit to
   load its worklist from PostgreSQL, and to eliminate some dead hosts.)

   After that, it'll start up quicker, and run fast.

I'll also keep trying to gather data here.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Default name of target executable

2005-10-24 Thread Tomasz Zielonka
On 10/14/05, Tomasz Zielonka [EMAIL PROTECTED] wrote:
 On 10/14/05, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
  HEAD definitely.   We don't change the specification of STABLE, only fix
  bugs.

 Great, I have the initial implementation, but I'll try to make it
 prettier.

Here is the patch.

Some notes:
- I am not sure if it's OK to modify Session in this place.
  Perhaps my code should be called from
  DriverPipeline.staticLink, but it has no access to
  module graph, and I didn't want to make such a
  big change
- I wanted to add .exe suffix on Windows, but if I think that
  GHC relies on mingw32 tools to add it when necessary.
- There is some documentatin in separate_compilation.xml.
  I wrote about the ability to put Main in file other than Main.hs,
  but I couldn't find documentation for this feature. Tell me if there
  are other places where this feature should be mentioned.
- I didn't check that docs are properly generated after my
  changes. Besides, the language can be incorrect.

Best regards
Tomasz


patch
Description: Binary data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Default name of target executable

2005-10-24 Thread Tomasz Zielonka
On 10/24/05, Tomasz Zielonka [EMAIL PROTECTED] wrote:
 Here is the patch.

Again, with a small bugfix in docs.

Best regards
Tomasz


patch
Description: Binary data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users