Re: BeOS port
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? Those errors are coming from the runtime system in ghc/rts. Both functions are used in fairly important spots in the runtime system: mmap is used to allocate memory for the Haskell program - the memory has to be allocated to multiples of 1MB; you'll need to find some way to do that on BeOS. The itimer is used for supporting multiple threads in Haskell code; you might get away with disabling that until you try to run multithreaded code, but something definitely needs to be done about this to get a proper BeOS port. Once you're through that, it'll compile the compiler proper in ghc/compiler, is quite likely to just work (unless there are problems with the build system). Then that compiler will be used to compile the libraries, and you'll probably encounter some more problems because of functions missing from BeOS there. I saw comments about BeOS in the code. Did someone try to port it already? No, I don't know of any attempts. I didn't even find any reference to BeOS in the sources outside config.guess/config.sub and of course ghc/rts/gmp, which is just an old version of the GNU MP library. GNU MP has probably(hopefully) been ported to BeOS. Grüße, Wolfgang ___ 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
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
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
Re: symbol __stg_split_marker' is already defined
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
symbol __stg_split_marker' is already defined
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? 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.) 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: BeOS port
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? Not that I know of. You'll need to supply more information about what phase of bootstrapping you are up to, and what error messages are produced. -- Don ___ 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?
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: Using packages in ghci
On 01 October 2004 10:37, Adrian Hey wrote:
> 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?
Looks fine - GHCi is supposed to look in the directories in import_dirs
for .hi files. What does ghci -v tell you?
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?
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: BeOS port
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: BeOS port
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: Registering packages
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
Using packages in ghci
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
Is there a non-blocking version of hGetArray?
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
