Re: Registering packages

2004-10-01 Thread gaufridus
Thank you, Simon!

I did not get a wxHaskell install.  wxHaskell is a zip file, not an
executable or a Windows installation file.  The directions at the site
are clear about simply unzipping it and running the
wxhaskell-register.bat file.

You are absolutely right about the environment variable.  The batch
file expected an environment variable named WINDIR, but it did not
automatically exist on my computer (it is really named SYSTEMROOT).
Instead of changing the bat file, I simply added the WINDIR
environment variiable and then ran the batch file.  (From the command
prompt: SET WINDIR=C:\WINNT)

Excellent!  I typed in the first example at the quick start at the
site, and it ran just fine.  I can now compile any of the samples
easily and run them.  I am impressed with GHC, wxWindows, and
extremely grateful for your help.

Thank you,
   -- Geoff

On Mon, 27 Sep 2004 14:20:19 +0100, Simon wrote:

Looks like wxHaskell needs to set an environment variable when
installing the package, but because you did it by hand you didn't have
this environment variable set.

Why didn't the normal wxHaskell install work for you?

Cheers,
   Simon

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: BeOS port

2004-10-01 Thread Waldemar Kornewald
Waldemar Kornewald wrote:
In my Linux build there is a file Arrow.hs, but in my BeOS build this 
file (and all others) are missing. How are these files generated and why 
are they not generated in BeOS?
Please forget this. Those files exist on both systems, but unfortunately 
they are not built.

Someone told me on #haskell that he had the same problems when building 
on a threaded system (which BeOS is). Is that a general GHC problem?

Bye,
Waldemar Kornewald
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: BeOS port

2004-10-01 Thread Waldemar Kornewald
Donald Bruce Stewart wrote:
Why do you not offer .hc packages of different builds (FreeBSD and/or
Linux)? I could use them as a very good starting point. Or could 
anyone
please create a zip with those files generated from such a build?



 They aren't portable. You'll need to generate your own (using config.h
 from the target machine) following the instructions on the building
 section of the manual.

 It should be quite possible :)

Maybe, but I always (Linux+BeOS) get errors that some .o file could not 
be created.
Something like:
Make: could not create target Control/Arrow.o ... Stop.
I do not have the correct message.
How are the .hs files generated and why are they not generated in BeOS 
and Linux?

Now, compiling in the ghc folder starts correctly and I get errors about 
 missing itimer (can I safely disable that or should I add an emulator 
for it?) and mmap. Will the libraries be compiled after that?

I saw comments about BeOS in the code. Did someone try to port it already?
Thank you.
Bye,
Waldemar Kornewald
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


RE: Is there a non-blocking version of hGetArray?

2004-10-01 Thread Simon Marlow
On 01 October 2004 08:45, Peter Simons wrote:

 I am a happy user of hGetBufNonBlocking, but I have come to
 realize that mutable arrays are nicer to work with than
 pointers, so I have considered using hGetArray instead. I
 do, however, depend on the fact that the function returns as
 soon as it has read data -- even if less than requested --,
 like hGetBufNonBlocking does.
 
 Is there currently a way to achieve this?

Not currently, but I could probably implement the equivalent
(hGetArrayNonBlocking).

 Am I right assuming that hGetBuf and hGetArray do not differ
 much performance-wise?

Hopefully not.

 One of the reasons I am curious about using mutable arrays
 is because of Data.Array.Base.unsafeRead, which seems to be
 a *lot* faster than accessing the memory through a pointer.
 Is there anything comparable for pointer access?

I'm surprised if pointer access to memory is slower than unsafeRead.
Could you post some code that we can peer at?

Cheers,
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Is there a non-blocking version of hGetArray?

2004-10-01 Thread Peter Simons
Simon Marlow writes:

  Not currently, but I could probably implement the
  equivalent (hGetArrayNonBlocking).

If that were possible, I'd greatly appreciate it.


  I'm surprised if pointer access to memory is slower than
  unsafeRead. Could you post some code that we can peer at?

Not right now, sorry. It's just a suspicion I have, but I
haven't broken down the functions enough to be certain (or
to post an isolated test case). But I will look at this
further and let you know about it, once I have more
evidence. :-)

Thanks for helping, Simon.

Peter

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: symbol __stg_split_marker' is already defined

2004-10-01 Thread Donald Bruce Stewart
jgoerzen:
 Hi,
 
 I am trying to build ghc 6.2.1 for AIX.  I successfully bootstrapped an
 unregisterised ghc-inplace from an i386 Linux box today.
 
 I am now trying to build a real ghc on AIX.  I've had endless trouble,
 and finally decided to put this in mk/build.mk:
 
 GhcUnregisterised = YES
 GhcWithNativeCodeGen = NO
 GhcWithInterpreter = NO
 
 That made things run much smoother.  In fact, it made it to libraries/base.
 Now I get this:
 
 rm -f GHC/Base.o; if [ ! -d GHC/Base_split ]; then mkdir GHC/Base_split; else /o
 pt/freeware/bin/find GHC/Base_split -name '*.o' -print | xargs rm -f __rm_food;
 fi;
 ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include
 HsBase.h -funbox-strict-fields -package-name base -O -Rghc-timing  -split-objs
   -c GHC/Base.lhs -o GHC/Base.o  -ohi GHC/Base.hi
 /tmp/ghc82602.hc:2593: warning: this decimal constant is unsigned only in ISO C9
 0
 /tmp/ghc82602.s: Assembler messages:
 /tmp/ghc82602.s:128: Error: symbol `__stg_split_marker' is already defined
 /tmp/ghc82602.s:287: Error: symbol `__stg_split_marker' is already defined
 /tmp/ghc82602.s:448: Error: symbol `__stg_split_marker' is already defined
 
 And about a hundred more.  Ideas?

Try turning of split objs. They don't work on all platforms.  Add:
 
SplitObjs = NO

 Oh, BTW, I had to put a script named gcc on my path.  It says this:
 
 exec /usr/local/bin/gcc -mpowerpc -maix32 -mminimal-toc $@
 
 Otherwise, it trips all over itself whenever it encounters assembly (it's
 a powerpc cpu but gcc generates power code by default).  And the link fails
 (toc overflow -- mminimal-toc fixes that.)

Good idea.

 The system:
 
 AIX 5.1L
 PowerPC64 CPU (running in 32-bit mode)
 GCC 3.3.2
 GHC 6.2.1
 
 Thanks,
 
 John Goerzen
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: AIX 5.1L Build of GHC 6.2.1

2004-10-01 Thread Donald Bruce Stewart
jgoerzen:
 Hello,
 
 Whew!  This was the toughest bootstrap I've done in a long time.  Thanks
 to help from people here, I have built a working GHC 6.2.1 for
 AIX5.1L.  (The last GHC I could find for AIX was GHC 2.09!)

Congratulations :)

-- Don
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


AIX 5.1L Build of GHC 6.2.1

2004-10-01 Thread John Goerzen
Hello,

Whew!  This was the toughest bootstrap I've done in a long time.  Thanks
to help from people here, I have built a working GHC 6.2.1 for
AIX5.1L.  (The last GHC I could find for AIX was GHC 2.09!)

Find it at:

gopher://quux.org/1/devel/AIX/ghc
or http://quux.org/devel/AIX/ghc for the gopher-impaired

I have posted the binary distribution generated by the make system as
well as a tarball containing my fully built source tree.  There's also a
info file describing how I finally made it work.

Thanks very much to everyone on these two lists that provided hints
along the way.  I appreciate it!

For the curious, this was bootstrapped from Debian on x86.  It is built
for PowerPC using gcc 3.3.2.

Please feel free to post either or both of these on the GHC download
page.  (Is there someone specific I should contact about that?)

These are unregisterized builds.  Porting the registerized system and
interpreter are beyond my expertise, and things I don't need, but maybe
this will provide a start for someone else to do that.

(Please note: the binary dist has uploaded to the site but my build tree
is still uploading as I type this, so please give it about an hour
before you try to download that, or you'll get a partial file.)

-- 
John Goerzen
Author, Foundations of Python Network Programming
http://www.amazon.com/exec/obidos/tg/detail/-/1590593715

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Is there a non-blocking version of hGetArray?

2004-10-01 Thread Peter Simons
Hi,

I am a happy user of hGetBufNonBlocking, but I have come to
realize that mutable arrays are nicer to work with than
pointers, so I have considered using hGetArray instead. I
do, however, depend on the fact that the function returns as
soon as it has read data -- even if less than requested --,
like hGetBufNonBlocking does.

Is there currently a way to achieve this?

Am I right assuming that hGetBuf and hGetArray do not differ
much performance-wise?

One of the reasons I am curious about using mutable arrays
is because of Data.Array.Base.unsafeRead, which seems to be
a *lot* faster than accessing the memory through a pointer.
Is there anything comparable for pointer access?

Peter

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Using packages in ghci

2004-10-01 Thread Adrian Hey
Hello,

Where does ghci look for .hi files from packages? (I doesn't seem to
be the same place as ghc). AFAICT it expects to find them relative to
the current directory, and I can only get it to work by cding to
the appropriate directory *before* invoking ghci (doing this from
within ghci seems to really mess things up).

But I guess this isn't what's supposed to happen because this
solution will only work with one package.

My package entry looks like this..

Package
   {name = Data.Tree.AVL,
auto = True,
import_dirs = [/home/adrian/HaskellLibs/Data.Tree.AVL/pkg],
source_dirs = [],
library_dirs = [/home/adrian/HaskellLibs/Data.Tree.AVL/pkg],
hs_libraries = [Data.Tree.AVL],
extra_libraries = [],
include_dirs = [],
c_includes = [],
package_deps = [base, Data.COrdering],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts = [],
framework_dirs = [],
extra_frameworks = []}

Is there something missing here?

Thanks
--
Adrian Hey

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users