Re: ANNOUNCE: GHC version 6.2
On Fri, 19 Dec 2003, Donald Bruce Stewart wrote: This is an unregisterised build, with profiling libs, no docs and no GHCi. The mips64 port requires an external libgmp. This should come installed with the freeware packages for Irix. - And set your LD_LIBRARY_PATH variable properly: export LD_LIBRARY_PATH=/usr/freeware/lib64:$LD_LIBRARY_PATH Warning: 64 ABI is not default ABI on gcc-3.X . If you install locally either gmp or gcc directly form source tar balls (e.g on $HOME) , becare of export LD_LIBRARY_PATH=$HOME/lib:$HOME/lib/mabi\=64:$LD_LIBRARY_PATH Thanks , dons... Let's try the registerised version !!! ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.2
On Fri, 19 Dec 2003, Donald Bruce Stewart wrote: This is an unregisterised build, with profiling libs, no docs and no GHCi. The mips64 port requires an external libgmp. This should come installed with the freeware packages for Irix. - And set your LD_LIBRARY_PATH variable properly: export LD_LIBRARY_PATH=/usr/freeware/lib64:$LD_LIBRARY_PATH Warning: 64 ABI is not default ABI on gcc-3.X . If you install locally either gmp or gcc directly form source tar balls (e.g on $HOME) , becare of export LD_LIBRARY_PATH=$HOME/lib:$HOME/lib/mabi\=64:$LD_LIBRARY_PATH Thanks , dons... Let's try the registerised version !!! ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Foreign Function Interface (FFI)
HI: Reading Haskell 98 FFI report, one question arised: Imported and declared a foreign function , via foreign import ccall foo:: IO(CInt) Is it guaranteed to be executed in atomic way ? I mean , should it block the whole STG system ? Idea: To implement a monitor , in a external context , and threads around him to access it, bypassing the Mvar paramter-pass among them... ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Foreign Function Interface (FFI)
Well, similar ideas have been brought up before, and I'm a bit sceptical: *) Why should we introduce a feature at the language level for solving a problem that is already solved by MVars? You can write your own combinators to reduce the hassle of using MVars to a minimum. Firstly, thanks for your answer: I'm re-writting a Haskell-Maple library from Hans Wolfgang Loidl, basically adopting Haskell Posix Libraries and re-arranging concurrency issues around a Posix Pipe. I cannot send a URL since the code is a bit unreadable, but it works... * From Haskell-Sequential, you don't neeed Mvars, since there are not forkIO'ds threads. * From a Haskell-Concurrent point of view, this is just to free the final Maple-Eden library user to consider concurrency uses, as the final signature should be: mapleEval :: String - [MapleObject] - MapleObject instead of mapleEval :: Mvar - String - [MapleObject] - MapleObject However, this is not key... Programmer could make the effort for that. * The key problem arises now: We are programming on a Haskell-dialect parallel language, Eden, whose implementation extends that of Gph. There you have a Distributed Memory Model, each process ( process= set of Concurrent threads inside a processor-element) has its own heap,stack... Hence, every locally process has its own Mvar-state, and cannot be shared with other process-threads... It would have only sense on local heap, but you are not garanteed to run your process locally ( rather it will be remote ). That is because we need the external context monitor. Yes, we are forcing the language, I know... After all : import Concurrent newEmptyMVar :: IO(Mvar a) foreign import cgetMonitorMvar :: IO(Mvar a) are safely close under a monad , aren't they (*)? (*) Strictly speaking, we are storing/grabing (StablePtr a) to avoid the effect of the Garbage Collector *) Why would we want all external calls to be serialized? In most circumstances, I'd like more granularity than that. Yes, I agree with you,but just to get the effect of a monitor, on a mutex region. Of course, it is not for large computations, just a little while What exactly do you have in mind? Cheers, Also you. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Transient compilations on CVS code
Hi: I'm a newbie on using CVS but some time ago I decided to compile against the code on the CVS repository. I'm interested on 6.3 version. Recently I found this problem, after making autoheader,autoconf: ghc/include: make boot mkDerivedConstants.c:34 'StgTickyInfo' undeclared (first use of this function) is this a transient problem to be solved or I'm doing something wrong ? And three weeks ago, on the configure script, I was asked to download the alex tool, when on older versions (from tar.gz) this was not necessary ... Thanks... ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mips-sgi-irix bootstrapping
On Sat, 11 Oct 2003, Donald Bruce Stewart wrote: As a final note on this bug, the core dumps disappear on mips-sgi-irix if I start from the beginning with 64bit code, i.e. mips64-sgi-irix. By setting -mabi=64 in CFLAGS, longs become 8 bytes, and bugs disappear. No need for my hack of tricking gmp into using 32 bit mips asm. This solves the package.conf bug, the __decodeFloat bug and the gmp div bug that mips people have encountered. After edting by hand the configure script, to accept the mips64-sgi-irix platform, I got the next failure gcc -x c GHC/IOBase.hc -o GHC/IOBase.o -c -O -DNO_REGS -DUSE_MINIINTERPRETER -D__GLASGOW_HASKELL__=600 -O -DNO_REGS -DUSE_MINIINTERPRETER -I/usr/users/eden/scratch/6.0.1/ghc-6.0.1/ghc/includes -I/usr/users/eden/scratch/6.0.1/ghc-6.0.1/libraries/base/include -I/usr/users/eden/scratch/6.0.1/ghc-6.0.1/libraries/unix/include -mabi=64-I. `echo | sed 's/^$/-DSTOLEN_X86_REGS=4/'` gcc -x c GHC/Int.hc -o GHC/Int.o -c -O -DNO_REGS -DUSE_MINIINTERPRETER -D__GLASGOW_HASKELL__=600 -O -DNO_REGS -DUSE_MINIINTERPRETER -I/usr/users/eden/scratch/6.0.1/ghc-6.0.1/ghc/includes -I/usr/users/eden/scratch/6.0.1/ghc-6.0.1/libraries/base/include -I/usr/users/eden/scratch/6.0.1/ghc-6.0.1/libraries/unix/include -mabi=64-I. `echo | sed 's/^$/-DSTOLEN_X86_REGS=4/'` GHC/Int.hc: In function `sbsy_ret': GHC/Int.hc:3093: `int64ToIntegerzh_fast' undeclared (first use in this function) GHC/Int.hc:3093: (Each undeclared identifier is reported only once GHC/Int.hc:3093: for each function it appears in.) GHC/Int.hc: In function `sbst_ret': GHC/Int.hc:3170: `int64ToIntegerzh_fast' undeclared (first use in this function) gmake[1]: *** [GHC/Int.o] Error 1 gmake: *** [all] Error 1 gmake: Leaving directory `/scratch/users/eden/6.0.1/ghc-6.0.1/libraries' So we'll see how far we get using 64 bits right from the start on this funny Irix thing. -- Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stg_ap_v_ret porting crash: solved?
On Fri, 26 Sep 2003, Rafael Martinez Torres wrote:
I enabled the flags -g
Sorry , the previous mail was incomplete. send button fired.
GhcRtsHcOpts= -g -optc-DDEBUG
GhcRtsCcOpts= -g
This is my session with gdb , ghc-6.0.1 and mips-sgi-irix65.
I thinks this has nothing to do with the gmp library, but with
StgPrimFloat.c , line 250
DEbugging with gdb on a multithread RTS seems not easy . When the program
crash - I ask - is there any thread other than evaluator one present
at RTS ?
I don't understand very much on RTS internals, but, I guess a simple
Hello World thread may not deal with decodeFloat operations
May be the compiler gcc-3.0 is faulty for big binaries, due to MULTIGOT
linker, as gcc-2.95 was , and pointers are out of control. I will try
gcc-3.2 then ..
Cheers.
bash-2.05a$ !gdb
gdb ghc/compiler/stage1/ghc-6.0.1
(gdb) set args -B./ -hello.hs
(gdb) break main
Breakpoint 1 at 0x1155242c: file Main.c, line 56.
(gdb) run
Starting program:
/scratch/users/eden/6.0.1/ghc-6.0.1-mips/ghc/compiler/stage1/ghc-6.0.1 -B./
hello.hs
Breakpoint 1, main (argc=3, argv=0x7fff2e84) at Main.c:56
56 startupHaskell(argc,argv,__stginit_Main);
(gdb) n
108 status = rts_mainLazyIO((HaskellObj)mainIO_closure, NULL);
(gdb) s
rts_mainLazyIO (p=0x116b3620, ret=0x0) at SchedAPI.h:54
54 createIOThread(nat stack_size, StgClosure *closure) {
(gdb) n
59t = createThread(stack_size);
..
..
..
428 scheduleThread(tso);
(gdb) n
429 return waitThread(tso, ret);
(gdb) n
waitThread (tso=0x41c, ret=0x116b3620) at Schedule.c:2276
2276{
(gdb) n
2280 m = stgMallocBytes(sizeof(StgMainThread), waitThread);
(gdb) n
2281 m-tso = tso;
(gdb) n
..
..
..
(gdb) n
2291 main_threads = m;
(gdb) n
2297 stat = waitThread_(m);
(gdb) n
0x1153c0e8 in waitThread ()
Current language: auto; currently asm
(gdb) s
Single stepping until exit from function waitThread,
which has no line number information.
0x1153b164 in updateStablePtrTable ()
(gdb) n
Single stepping until exit from function updateStablePtrTable,
which has no line number information.
Program received signal SIGSEGV, Segmentation fault.
__decodeFloat (man=0x7fff2d00, exp=0x7fff2d10, flt=66.641) at StgPrimFloat.c:250
250 if (sign 0)
Current language: auto; currently c
(gdb) quit
The program is running. Exit anyway? (y or n) y
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stg_ap_v_ret porting crash: solved?
On Fri, 12 Sep 2003, Simon Marlow wrote:
--
../../ghc/utils/ghc-pkg/ghc-pkg-inplace --update-package
package.conf.inplace
/usr/users/eden/scratch/ghc-6.0.1/ghc/driver/package.conf.inpl
ace: parse error in package config file
gmake[1]: *** [../../ghc/driver/stamp-pkg-conf-base] Error 1
gmake: *** [boot] Error 1
Have you done 'make boot' in ghc/driver?
mips-sgi-irix65:
1.- OK. The distrib/hc-build migth not handle the dependencies soundly.
Now I build on the target T as in the host H:
cd hslibs/ gmake boot gmake
cd ghcgmake boot gmake
The touch config.h patch seems to solve the stg_ap_v_ret bug...
2.- Now the problem seems to be another one:
bash-2.05$ ghc/compiler/ghc-inplace hello.hs
crash, and tracing the core it seems a problem having to do with gmp
software:
bash-2.05a$ gdb ghc-6.0.1 core
# 0x1153a208 in __decodeFloat ()
if I apply the -v flag, then
bash-2.05$ ghc/compiler/ghc-inplace -v hello.hs
bash-2.05a$ gdb ghc-6.0.1 core
# 0x11554ae4 in __gmpn_tdiv_qr / ( qp=0x454ed518 ...)
Any idea ?
3) Simon M. : For the time beeing this is the patch you can integrate
safely into the CVS repository . I have read-only permissions. There is no
doubt on it.--- MBlock.c.ori2003-09-18 09:42:10.0 +0200
+++ MBlock.c2003-09-18 09:42:44.0 +0200
@@ -97,6 +97,12 @@
ret = mmap(addr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
close(fd);
}
+#elif irix_TARGET_OS
+{
+ int fd = open(/dev/zero,O_RDONLY);
+ ret = mmap(addr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
+ close(fd);
+}
#elif hpux_TARGET_OS
ret = mmap(addr, size, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Porting GHC to powerpc-unknown-linux
On Sat, 6 Sep 2003, Donald Bruce Stewart wrote: simonmar: I was a bit too soon reporting the sparc-sun-solaris2, two attempts have died with stg_ap_v_ret. Same result sparc-*-openbsd. Also with mips-sgi-irix65 . An attempt died with stg_ap_v_ret . I'm trying to follow Ian's stepsbut please, report any change you can make on the doc Bootstraping GHC from hc-files. Cheers. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Porting GHC to powerpc-unknown-linux
On Thu, 4 Sep 2003, Simon Marlow wrote: +-+++ | HOST| TARGET| Unregisterised bootstrap | +-+++ | i386-*-openbsd | i386-*-openbsd | YES | | | i386-*-freebsd | YES | | | i386-*-linux | YES | | | i386-*-solaris2| YES | | | sparc-sun-solaris2 | YES | | | sparc-sun-openbsd | in-progress | | | m68k-apple-netbsd | in-progress | | | mips-sgi-irix65| in-progress | ||| | | alpha-dec-osf3 | dies on host with: | | || cc1: Invalid option `ieee' | +-+++ I cannot miss this interesting thread , working with mips-sgi-irix65. Could you release a (transient) ghc-6.01-unreg-hc.tar.gz ? If not, Donald, please send it to me privately... However, I will try to make cross-porting from i386-*-linux. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Porting GHC to powerpc-unknown-linux
On Thu, 4 Sep 2003, Rafael Martinez Torres wrote: Could you release a (transient) ghc-6.01-unreg-hc.tar.gz ? Sorry, I read the doc, and I understood the unreg (.hc) tar is built on host with a particular target config.h . I have to build it , hence. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Posix library ,Concurrent Haskell and Haskell IO sub-system
On Thu, 10 Jul 2003, Volker Stolz wrote: In local.glasgow-haskell-users, you wrote: I use the Posix library since I have to communicate via a pipe with another UNIX process. Therefore I have to use fdRead :: Fd - ByteCount - IO (String,ByteCount) Why do you have to use an Fd? A regular handle should be sufficient. Where do you get the Fd from? createPipe :: IO (Fd,Fd) (Unkown alternatives) Did you consider lifting the Fd back to a Handle? How ? Only known intToFd :: Int - Fd fdToInt :: Fd - Int If you really need to read exactly ByteCount bytes, you could go the hard way and set the handle to unbuffered IO and call hGetChar n times. OK. What about ? threadReadWait :: Int - IO() Should I convert a Handle into a Int ? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Posix library ,Concurrent Haskell and Haskell IO sub-system
On Fri, 11 Jul 2003, Volker Stolz wrote: createPipe :: IO (Fd,Fd) (Unkown alternatives) I suppose you have to pass this descriptor to another process through fork()? Rigth. (piper,pipew) - createPipe mpid - forkProcess case mpid of Nothing - do --child nobytes - fdWrite pipew stringToSend Just pid - do --parent (string,nobytes) - fdRead piper stringReceived maxBytes There's System.Posix.IO.fdToHandle :: Fd - IO Handle What about ? threadReadWait :: Int - IO() Should I convert a Handle into a Int ? I suppose there is System.Posix.IO.handleToFd :: Handle - IO (Fd) and then ... (piper,pipew) - createPipe piperHandle - fdToHandle(piper) threadWaitRead ( fdToInt(handleToFd(piperHandle)) ) message - hGetLine piperHandle --or whatever. ... Yes, that should work, too, but you won't know how many bytes are available. You could use or adapt one of the *MayBlock-ellipses from Foreign.C.Error together with threadWaitRead, but that's making things even more ugly. Volker OK. Don't worry. Thank you very much. Very usefull. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Posix library ,Concurrent Haskell and Haskell IO sub-system
I use the Posix library since I have to communicate via a pipe with another UNIX process. Therefore I have to use fdRead :: Fd - ByteCount - IO (String,ByteCount) The problem is that fdRead , as a non Haskell-IO sub-system function, seems to block the entire STG system. The rest of the other threads are blocked too. BTW, String stands for non-printable bytes I can be sent for a system, '\0' included ? Alternatives: 1 .- Polling. Sleep and ask. You have to use the setFdOption fd NonblockingRead True fdReadNonBlockingSTG :: Fd - Int - IO (String,ByteCount) fdReadNonBlockingSTG mypipe nobytes = do (string,nobytesread) - fdRead mypipe nobytes if (nobytesread == -1) then do threadDelay 1 fdReadNonBlockingSTG mypipe nobytes else return (string,nobytesread) myprogram :: IO () ... setFdOption mypipe NonBlockingRead True (a,b) - fdReadNonBlockingSTG mypipe 2 ... Problem: As you see, 1000 es an arbitrary constant maybe too short, may be too long and this affects throughput. 2.- Desired approach === Ideally I would like to use the threadWaitRead :: Int - IO() from Concurrent Haskell as ... -- setFdOption mypipe NonBlockingRead True -- should be called? threadWaitRead (fdToInt mypipe) (string,nobytes) - fdRead mypipe 2 ... But... QUESTIONS == A ) is the GHC-RTS ready to dispatch the signal send by the O.S on a Posix Fd and make threadWaitRead to run as expected ? The Posix library doc warns: intToFd :: Int - Fd -- use with care fdToInt :: Fd - Int -- ditto B) Other approaches, like Handles... Is it possible to convert a Fd into a Handle or bypassing it to the RTS another way ?... ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: passing a Handle to a C function
By the way, this questions is some bit close on that with Subject: Posix library, Concurrent Haskell and ... I have just send ... Let's read both... By Using Posix library I did not need any more to pass file descriptors into C code (may be your case is different) On Thu, 10 Jul 2003, Volker Stolz wrote: In local.glasgow-haskell-users, you wrote: For Unix, use Posix.handleToFd to get a descriptor, then fdopen() (in C, or write a foreign import) to get a FILE*. Also, don't forget about synchronisation issues between the C and Haskell interfaces to the descriptor (e.g. buffering). this is true o flush for writing At GHC-5.02 Posix does not implement it.. o and nonBlocking for reading. (see given message on this) After the 'handleToFd', there shouldn't be any issues of interference because the handle becomes unusable in Haskell-land. Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc on alpha-linux?
On Mon, 7 Jul 2003, Ketil Z. Malde wrote: Simon Peyton-Jones [EMAIL PROTECTED] writes: Ken Shan was making good progress on an Alpha port of GHC. Ken, could you update us on the status? Courtesy of the good people at SGI, I have now access to an SGI Altix (8 Itanium processors, and lots of RAM that I Really Need). So, I'm very interested in any information on how to get current GHCs running on 64bit architectures. I was trying 32 bits on Origin (instead of Altix) , but maybe this link can help you to boostrap a 4.08.2 on sgi platforms... mips-sgi-irix65 htpp://segovia.sip.ucm.es/~rmartine I'm interested on keeping contact with SGI porters. Thanks. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
