ghc for hp-ux 10.20 or 11
Has anyone ever succeeded in porting ghc to HP-UX 10.20 or later? Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Porting the GHC to GNU/Hurd
On 20 April 2005 17:34, Thomas Schwinge wrote: On Sun, Apr 10, 2005 at 10:39:08PM +0100, Simon Marlow wrote: On 10 April 2005 14:20, Thomas Schwinge wrote: Is someone aware of any efforts to port the GHC to GNU/Hurd? If not, I'd like to give that a try. No, and good luck! I should be able to get it going using .hc files from i386-linux. Correct? But where can I find these files or how can I create them myself? I was not (yet) able to find instructions about creating them in the porting guide and a web search also didn't reveal anything useful, yet. Just follow the instructions in section 10.2 of the Building Guide: http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.htm l#unregisterised-porting that tells you how to build the .hc files and bootstrap from them on the target machine. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Re[2]: garbage collection
On 20 April 2005 15:56, Bulat Ziganshin wrote: Tuesday, April 19, 2005, 4:15:53 PM, you wrote: 1) can you add disableGC and enableGC procedures? this can significantly improve performance in some cases Sure. I imagine you want to do this to avoid a major collection right at the peak of a residency spike. You probably only want to disable major collections though: it's safe for minor collections to happen. no, in that particular case i have very simple and fast algorithm, which allocates plenty of memory. minor GC's in such situation is just waste of time. so i want to do: disableGC result - eatMemory enableGC with a effect that all memory allocated in 'eatMemory' procedure will be garbage collected only after return from this procedure. currently i have this stats: INIT time0.01s ( 0.00s elapsed) MUT time0.57s ( 0.60s elapsed) GCtime1.41s ( 1.41s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time1.99s ( 2.01s elapsed) %GC time 70.8% (70.1% elapsed) Alloc rate171,249,142 bytes per MUT second Productivity 28.7% of total user, 28.4% of total elapsed as you see, it is very inefficient I see (I think). Unfortunately currently the size of the allocation area is fixed after a GC, so you'll have to change the code in the runtime to keep allocating more blocks for the nursery. I guess you're proposing using madvise(M_FREE) (or whatever the equivalent is on your favourite OS). This would certainly be a good idea if the program is swapping, but might impose an overhead when running in memory. I don't know, I haven't tried. i don't see resons why this can be slower. we will be a good citizens - return memory what is not used at current moment and reallocate memory when needed. It might be slower because it involves extra calls to the kernel to free/allocate memory, and the kernel has to update its page tables. I mentioned madvise() above: this is a compromise solution which involves telling the kernel that the data in memory is not relevant, but doesn't actually free the memory. The kernel is free to discard the pages if memory gets tight, without actually swapping them to disk. When the memory is faulted in again, it gets filled with zeros. This is ideal for copying GC: you madvise() the semispace you just copied from, because it contains junk. IIRC, madvise() is a BSD-ish interface, but other OSs probably have similar facilities. We could also consider really returning memory to the OS. This requires more work in the runtime, though. current implementation only allows memory usage to grow and that is not perfect too. imho it will be better to release unneeded memory after major GC and perform next major GC after allocating fixed amount of memory or, say, after doubling used memory area GHC has quite a sophisticated block-based storage manager. It's not obvious how to understand your comments in the context of GHC - I suggest you take a look at the source code. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: installing ghc without already having ghc
On 20 April 2005 15:13, Jessica Brennan wrote: ghc-6.4-host/libraries/readline NetBSD-2.0 0 # gmake boot ==fptools== gmake boot -r; in /devel/build/NetBSD/ghc/ghc-6.4-host/libraries/readline ../../ghc/utils/hsc2hs/hsc2hs-inplace -Iinclude -I. System/Console/Readline.hsc Readline.hsc: In function `main': Readline.hsc:677: error: `UNDO_DELETE' undeclared (first use in this function) Readline.hsc:677: error: (Each undeclared identifier is reported only once Readline.hsc:677: error: for each function it appears in.) Readline.hsc:678: error: `UNDO_INSERT' undeclared (first use in this function) Readline.hsc:679: error: `UNDO_BEGIN' undeclared (first use in this function) Readline.hsc:680: error: `UNDO_END' undeclared (first use in this function) Readline.hsc:1021: error: `MULT_MATCH' undeclared (first use in this function) Readline.hsc:1044: error: `SINGLE_MATCH' undeclared (first use in this function) gmake: *** [System/Console/Readline.hs] Error 1 I have tried this with readline-5.0 both shared and static versions though I prefer to use the static version. Can anyone with NetBSD help out here? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc for hp-ux 10.20 or 11
On Thursday 21 April 2005 11:38, Benjamin Franksen wrote: Has anyone ever succeeded in porting ghc to HP-UX 10.20 or later? Sidenote: The background is that I want to persuade people at work to switch from CVS to darcs. It would be a lot easier to do so if I could get darcs to compile under (at least) HP-UX 11. Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc for hp-ux 10.20 or 11
On 21 April 2005 11:56, Benjamin Franksen wrote: On Thursday 21 April 2005 11:38, Benjamin Franksen wrote: Has anyone ever succeeded in porting ghc to HP-UX 10.20 or later? Sidenote: The background is that I want to persuade people at work to switch from CVS to darcs. It would be a lot easier to do so if I could get darcs to compile under (at least) HP-UX 11. There are binaries for 4.08.2 that work on HP-UX (not sure which version, though). It's a 2-step bootstrap from 4.08.2: build 5.04.3, then use that to build 6.4. There are more recent binaries for Debian on HPPA, if that's any use. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Re[2]: garbage collection
On Thu, 2005-04-21 at 10:57 +0100, Simon Marlow wrote: I mentioned madvise() above: this is a compromise solution which involves telling the kernel that the data in memory is not relevant, but doesn't actually free the memory. The kernel is free to discard the pages if memory gets tight, without actually swapping them to disk. When the memory is faulted in again, it gets filled with zeros. This is ideal for copying GC: you madvise() the semispace you just copied from, because it contains junk. IIRC, madvise() is a BSD-ish interface, but other OSs probably have similar facilities. Linux and Solaris have this interface (Solaris with possibly different flags MADV_DONTNEED/MADV_FREE). And there is also a standardised posix_madvise() (that no-one seems to support!) That probably covers it for unixy(linux,solaris,*bsd,darwin) systems. Don't know about win32. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
limited-scope retry?
Suppose that a program using the Control.Concurrent.STM module had a producer/consumer setup - one thread writing to a channel, the other thread reading from the channel. It seems natural to want a function that the producer can call that will block until the consumer has finished consuming everything currently in the channel. The way I first tried implementing this was: -- types simplified for this example flush :: TChan () - STM () flush chan = do e - isEmptyTChan if not e then retry else return () Used in isolation, i.e. atomically $ writeTChan chan () atomically $ flush chan it works fine. However, when composed (atomically $ writeTChan chan () flush chan), it causes a race condition, usually resulting in deadlock, as the retry in flush replays the call to writeTChan as well. This situation begs for a way to limit the scope of retry, in which case flush would be: flush chan = limitRetry $ do e - isEmptyTChan if not e then retry else return () Abe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: limited-scope retry?
On Thu, Apr 21, 2005 at 10:47:27AM -0400, Abraham Egnor wrote: Used in isolation, i.e. atomically $ writeTChan chan () atomically $ flush chan it works fine. However, when composed (atomically $ writeTChan chan () flush chan), it causes a race condition, usually resulting in deadlock, as the retry in flush replays the call to writeTChan as well. As long as you are in this transaction nobody will get from chan the element you just put there. Before the transaction commits, for the outside world it's like you've never called writeTChan. But inside the transaction you see a chan with an element that you've just written there. So within this transaction the chan has no chance to be emptied (unless you emptied it yourself). No point in waiting. As you say, it works in isolation. Use it this way. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: limited-scope retry?
Hello Abraham, Thursday, April 21, 2005, 6:47:27 PM, you wrote: AE Suppose that a program using the Control.Concurrent.STM module had a AE producer/consumer setup - one thread writing to a channel, the other AE thread reading from the channel. It seems natural to want a function AE that the producer can call that will block until the consumer has AE finished consuming everything currently in the channel. i think this is a bad programming technique. it's better to use another discipline of managing queue. for example, in my program i just allocate fixed number of buffers and use them to send data over channel. as a result, channel can't contaion more than this nu,ber of elements. if you will say more about your GOAL, not particular decision you made, may be i can suppose you better solution -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
building guide
Hello GHC, where i can find building guide in the html/pdf/... any other form readable by windows/IE? -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Cabal as shiped with ghc...
...has package version 1.0, but the current darcs repo (and the home page) says latest version is 0.6. May I assume that the 1.0 versioning is accidental (i.e. wrong)? Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
big FFI bug in x86_64
ghc 6.4 x86_64 appears to be interpreting foreign import foo as importing the value of foo rather than the address of foo. I wrote a test case that demonstrates this problem here http://repetae.net/john/ghc-bug.tar.gz correct output: ;./foo () 0x080774f0 0x080774f4 0xdeadbeef incorrect output: ;./foo () 0xdeadbeef 0xdeadbeef zsh: segmentation fault (core dumped) ./foo This is a pretty major bug. I don't know how the libraries are even working. John -- John Meacham - repetae.netjohn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Linking shared libraries
I know that ghc cannot produce shared libraries on all systems, but what about just linking existing ones (i.e. for ffi code)? Is there a secret command line switch for that, or do I have to use the C linker? Is there an option in cabal that I have been missing that could help me? Cheers Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Edison Libraries in ghc 6.4
G'day all. On 20 April 2005 01:46, [EMAIL PROTECTED] wrote: Would it help if I cabalised it? Quoting Simon Marlow [EMAIL PROTECTED]: Sure! Which raises the question: How? I understand that Ross had a smallish tutorial. Anyone know where I can find it? Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
