Re: ANNOUNCE: GHC vesrion 6.4.2
Are there any plans to release an OS X Intel version of this ?If not, has anyone has any success in getting the PowerPC version to run under Rosetta (complains about invalid intel instructions) ?-- Forwarded message --From: Simon Marlow < [EMAIL PROTECTED]>Date: Apr 19, 2006 1:52 AMSubject: ANNOUNCE: GHC vesrion 6.4.2To: glasgow-haskell-users@haskell.org, haskell@haskell.org =The (Interactive) Glasgow Haskell Compiler -- version 6.4.2 = The GHC Team is pleased to announce a new patchlevel release of GHC.This release contains a significant number of bugfixes relative to6.4.1, so we recommend upgrading. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC vesrion 6.4.2
Are there any plans to release an OS X Intel version of this ?If not, has anyone has any success in getting the PowerPC version to run under Rosetta (complains about invalid intel instructions) ? On 4/19/06, Simon Marlow <[EMAIL PROTECTED]> wrote: =The (Interactive) Glasgow Haskell Compiler -- version 6.4.2 =The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a significant number of bugfixes relative to6.4.1, so we recommend upgrading. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Building ghc stages - solved
Currently -fglasgow-exts implies -fth That is, you get Template Haskell if you specify -fglasgow-exts. The trouble is that if you don't know about TH, then the error messages can be deeply strange, as Marc found. Suggestion: if you want TH, you must specify -fth explicitly; -fglasgow-exts won't imply it. That way any messages about staging will only happen if you've explicitly asked for TH. Any objections? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Marc Weber | Sent: 18 April 2006 19:22 | To: glasgow-haskell-users@haskell.org | Subject: Re: Building ghc stages - solved | | On Mon, Apr 17, 2006 at 01:20:34PM +0200, Marc Weber wrote: | > GHC stage restriction: `view' | > is used in a top-level splice, and must be imported, not | > defined locally | | The solution was to change | where elemFromList = listToMaybe $ drop 1 $(dropWhile (/= view) $ (xs++[x])) | into : | where elemFromList = listToMaybe $ drop 1 $ (dropWhile (/= view) $ (xs++[x])) | ^ | | Really missleading error message ;) | | Marc | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 'while' loop on mutable arrays causes stack overflow
Hello Bulat, Bulat Ziganshin wrote: > the fastest way to calculate dot product is: > > dot :: STUArray s Int Double -> STUArray s Int Double -> ST s Double > dot x y = do > let (l,r) = bounds x > cycle sum i | sum `seq` i>r = return sum > cycle sum i = do xi <- readArray x i >yi <- readArray y i >cycle (sum+xi*yi) (i+1) > cycle 0 l That is a nice implementation. In fact, creating uninitialized arrays with newArray_ and then setting all its elements to some value using a function similar to this one is dramatically faster than creating initialized arrays with newArray. Gunnar. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: using ghc with make
Bulat Ziganshin wrote: i'm tried to say that there is no such dynamic beast as virtual functions in C++ I think you can use existential types to simulate virtual functions: -- 'a' is a stream of b's class StreamClass a b where get :: a -> IO b -- hide the particular 'a' to get any stream of b's data Stream b = forall a. StreamClass a b => Stream a -- a concrete 'a' data TextStream = ... instance StreamClass TextStream Char where get ... -- another concrete 'a' instance StreamClass MemoryStream Char where get ... -- concrete 'a' is hidden just as in C++ virtual dispatch useStream :: Stream b -> IO b useStream (Stream x) = get x -- because x satisfies StreamClass x b Regards, Brian. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: 'while' loop on mutable arrays causes stack overflow
Hello Gunnar, Thursday, April 20, 2006, 7:34:33 PM, you wrote: > Thanks a lot, it works now. I believed that writeSTRef would always > evaluate its arguments because ST is strict, but apparently I was > mistaken :) strict ST monad means that all operations inside it are performed immediately and not deferred until their side-effect is really required. but when you write something to STRef, this reference just saves closure that will calculate expression. to force evaluation of expression you need also to use '$!' or use unbozed references (that is not yet available, i plan to announce this lib several days later). the fastest way to calculate dot product is: dot :: STUArray s Int Double -> STUArray s Int Double -> ST s Double dot x y = do let (l,r) = bounds x cycle sum i | sum `seq` i>r = return sum cycle sum i = do xi <- readArray x i yi <- readArray y i cycle (sum+xi*yi) (i+1) cycle 0 l -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 'while' loop on mutable arrays causes stack overflow
On 4/20/06, Gunnar Kedenburg <[EMAIL PROTECTED]> wrote: > Hello, > > a friend and I were recently experimenting with mutable arrays. We tried > to implement a simple dot product on STUArrays using a 'while' loop. > Unfortunately, every implementation we produced caused a stack overflow. > Switching to other implementations of 'while' or to IOUArrays did not > help us. > > We were using ghc-6.4.1 on Linux x86, with gcc 3.3.6. It runs perfectly, > and is actually quite fast, when we increase the stack space. :) > > > import Control.Monad.ST > > import Data.STRef > > import Data.Array.ST > > import Control.Monad.Fix > > import Control.Monad > > > > while :: STRef s Bool -> ST s () -> ST s () > > while b c = readSTRef b >>= \v -> when v (c >> while b c) > > > > dot :: STUArray s Int Double -> STUArray s Int Double -> ST s Double > > dot x y = do > > let (l,r) = bounds x > > a <- newSTRef 0.0 > > e <- newSTRef l > > b <- newSTRef True > > while b (do > > ev <- readSTRef e > > av <- readSTRef a > > xe <- readArray x ev > > ye <- readArray y ev > > writeSTRef b (ev > writeSTRef e (ev+1) > > writeSTRef a (av+xe*ye)) > > readSTRef a > > > > main = do > >let d = runST (do > > x <- newArray (1, 100) 1.0 > > y <- newArray (1, 100) 2.0 > > dot x y) > >putStrLn $ show d > Implementing 'dot' without the 'while' loop and STRefs will make it shorter and faster, btw. -- Friendly, Lemmih ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: using ghc with make
Hello Simon, Thursday, April 20, 2006, 11:54:59 AM, you wrote: > Bulat Ziganshin wrote: >> 1) lazyGet/lazyPut. it's no problem to copy your implementation but i >> still don't understand how lazyGet should work - it share the same >> buffer pointer as one used in `get`. so `get` and consuming structure >> returned by lazyGet should interfere > lazyGet can only be used to read something that was written with > lazyPut. lazyPut writes the offset of the end of the serialised data at > the beginning, so that lazyGet can skip over it, and subsequent gets > start from the next item in the stream. the problem is what there is ONLY ONE read pointer, so it should be impossible to intersperse reading with `get` and consuming structure returned by `lazyGet`, either for BinMem or BinIO ... hmm, on the other side they don't interspersed because there is only one call to the unsafeInterleaveIO. closures returned by lazyGet just should be evaluated STRICTLY after all other `get` operation. and changing the `getAt` implementation to the following: getAt bh p = do p0 <- tellBin bh seekBin bh p a <- get bh seekBin bh p0 return a should omit even this restriction >> can you recommend me paper to read about using Haskell class system? well, how about this? > Overloading isn't all "resolved at compile time", most of the time > dictionaries of functions are passed around representing class predicates. i'm tried to say that there is no such dynamic beast as virtual functions in C++ -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 'while' loop on mutable arrays causes stack overflow
Hello Bulat, Bulat Ziganshin wrote: > it seems that you just construct huge unevaluated thunk. making things > stricter is a whole art, in this case try the following: > [...] Thanks a lot, it works now. I believed that writeSTRef would always evaluate its arguments because ST is strict, but apparently I was mistaken :) > i recommend you to use your `for` instead of your `while` - it's a much faster > and straightforward I agree. Gunnar ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC vesrion 6.4.2
Simon Marlow wrote: = The (Interactive) Glasgow Haskell Compiler -- version 6.4.2 = I notice that everything except the standalone Windows port is now available for download. How soon will this be avaliable? (No great rush, just interested :-) ) (The Visual Haskell port, while looking great, unfortunately has a restrictive Microsoft component of the license that prohibits use for commercial development so I can't use it unfortunately (unless someone can persuade Microsoft to delete their license component(!)) Looking forward to trying out 6.4.2, Regards, Brian. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC platforms
Hello Simon, Thursday, April 20, 2006, 5:17:55 PM, you wrote: > http://hackage.haskell.org/trac/ghc/wiki/Platforms > This replaces the section in the Building Guide that was becoming rather out > of date. for my libs, i just have wiki pages that contains "current" documentation and include up-to-date contents of corresponding wiki page into the archive when i release new version. may be it is the better way for the entire GHC docs? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 'while' loop on mutable arrays causes stack overflow
Hello Gunnar, Thursday, April 20, 2006, 4:29:29 PM, you wrote: > a friend and I were recently experimenting with mutable arrays. We tried > to implement a simple dot product on STUArrays using a 'while' loop. > Unfortunately, every implementation we produced caused a stack overflow. it seems that you just construct huge unevaluated thunk. making things stricter is a whole art, in this case try the following: >> writeSTRef b (ev> writeSTRef e (ev+1) >> writeSTRef a (av+xe*ye)) writeSTRef b $! (ev> for :: Int -> IO () -> IO () >> for 0 c = return () >> for n c = c >> for (n-1) c i recommend you to use your `for` instead of your `while` - it's a much faster and straightforward -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
no ghc-6.4.2 under solaris
Hi, my stage2 compiler under solaris is unusable. "gmake bootstrap3" does not terminate and even compiling the simplest file does not terminate: Christian -bash-3.00$ ghc -v --make hello.hs Glasgow Haskell Compiler, Version 6.4.2, for Haskell 98, compiled by GHC version 6.4.2 Using package config file: /local/home/maeder/ghc-6.4/lib/ghc-6.4.2/package.conf Using package config file: /home/maeder/.ghc/sparc-solaris2-6.4.2/package.conf Hsc static flags: -static *** Chasing dependencies: Chasing modules from: hello.hs Stable modules: *** Compiling Main ( hello.hs, interpreted ): compile: input file hello.hs *** Checking old interface for Main: Compiling Main ( hello.hs, hello.o ) *** Parser: *** Renamer/typechecker: [waited] ^C*** Deleting temp files Deleting: /tmp/ghc8103.hc Warning: deleting non-existent /tmp/ghc8103.hc ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC platforms
I've put up a wiki page listing the platforms that GHC supports and which features are supported on each platform: http://hackage.haskell.org/trac/ghc/wiki/Platforms I've no doubt made mistakes and there are a few empty boxes where I wasn't sure. Please improve the information here if you can. This replaces the section in the Building Guide that was becoming rather out of date. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: using ghc with make
On 20.04 12:06, Bulat Ziganshin wrote: > my Streams library mainly consists of two parts - Streams and > AltBinary. The streams part implements Handle-like interface > (including such functions as vGetChar, vGetByte, vPutBuf, vSeek and so > on) for various data sources - files, memory buffers, pipes, strings. > m/m files support is planned but now has just preliminary > implementation Having these as separate would be very nice. I think that a separately packaged AltBinary would be much easier to use for many people rather than force a dependency on the rest of Streams. - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
'while' loop on mutable arrays causes stack overflow
Hello, a friend and I were recently experimenting with mutable arrays. We tried to implement a simple dot product on STUArrays using a 'while' loop. Unfortunately, every implementation we produced caused a stack overflow. Switching to other implementations of 'while' or to IOUArrays did not help us. We were using ghc-6.4.1 on Linux x86, with gcc 3.3.6. It runs perfectly, and is actually quite fast, when we increase the stack space. :) > import Control.Monad.ST > import Data.STRef > import Data.Array.ST > import Control.Monad.Fix > import Control.Monad > > while :: STRef s Bool -> ST s () -> ST s () > while b c = readSTRef b >>= \v -> when v (c >> while b c) > > dot :: STUArray s Int Double -> STUArray s Int Double -> ST s Double > dot x y = do > let (l,r) = bounds x > a <- newSTRef 0.0 > e <- newSTRef l > b <- newSTRef True > while b (do > ev <- readSTRef e > av <- readSTRef a > xe <- readArray x ev > ye <- readArray y ev > writeSTRef b (ev writeSTRef e (ev+1) > writeSTRef a (av+xe*ye)) > readSTRef a > > main = do >let d = runST (do > x <- newArray (1, 100) 1.0 > y <- newArray (1, 100) 2.0 > dot x y) >putStrLn $ show d Unfortunately, I did not keep every 'while' implementation we tried, just this one: > while b c = fix (\d -> readSTRef b >>= > (\v -> if v then c >> d else return ())) We also changed the 'dot' code to use a 'for' loop instead, using IOUArrays in this case: > for :: Int -> IO () -> IO () > for 0 c = return () > for n c = c >> for (n-1) c Needless to say, it did not help. Any hints why the stack overflows would be greatly appreciated. Thanks, Gunnar. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.4.2 under solaris
Simon Marlow wrote: Christian Maeder wrote: Should it not be possible to build a binary distribution without documentation? Try make binary-dist Project=Ghc BINDIST_DOC_WAYS=html Thanks, this worked! C. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.2 under solaris
Volker Stolz wrote:
Now I'm confused...or is the patch reverted?
yes, sorry I've done:
-bash-3.00$ diff -u RtsUtils.c RtsUtils.c~
--- RtsUtils.c Wed Apr 19 13:15:29 2006
+++ RtsUtils.c~ Thu Jan 12 13:43:03 2006
@@ -187,7 +187,7 @@
if (now == 0) {
time(&now);
#if HAVE_CTIME_R
- ctime_r(&now, nowstr, 26);
+ ctime_r(&now, nowstr);
#else
strcpy(nowstr, ctime(&now));
#endif
where RtsUtils.c~ is the original file (left over by emacs)
Christian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.2 under solaris
Am 20. Apr 2006 um 11:19 CEST schrieb Christian Maeder: > Volker Stolz wrote: > >Without the 3rd arg is according to POSIX (check your Solaris man page). > >'buf' is required to be at least 26 bytes. > > You're right, but it does not compile without the 3rd argument! Maybe > this is due to gcc_4.0.3_s10 ? Should one simply rely on ctime? Now I'm confused...or is the patch reverted? It said: #if HAVE_CTIME_R - ctime_r(&now, nowstr, 26); + ctime_r(&now, nowstr); #else This has got nothing to do with GCC, it's only related to system headers. Quoth SunOS 5.9: SYNOPSIS #include char *ctime_r(const time_t *clock, char *buf, int buflen); ... POSIX cc [ flag... ] file... -D_POSIX_PTHREAD_SEMANTICS [ library... ] char *ctime_r(const time_t *clock, char *buf); >From my understanding of the patch above (*removing* the 3rd arg), I assumed that -D_POSIX_PTHREAD_SEMANTICS was set. It should probably be set like somewhere else (in libraries/bases/cbits/dirUtils.c), but I strongly suggest not doing this in the same (ie. through #define), but rather indeed setting it as a compiler flag. Otherwise, one of those days we'll get bitten by compiling something with skewed headers. Due to the plethora of variables in rts/Makefile, I'm a bit at a loss where to stick this in. -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.2 under solaris
Volker Stolz wrote: Without the 3rd arg is according to POSIX (check your Solaris man page). 'buf' is required to be at least 26 bytes. You're right, but it does not compile without the 3rd argument! Maybe this is due to gcc_4.0.3_s10 ? Should one simply rely on ctime? Cheers Christian man ctime_r char *ctime_r(const time_t *clock, char *buf, int buflen); The ctime_r() function has the same functionality as ctime() except that the caller must supply a buffer buf with length buflen to store the result; buf must be at least 26 bytes. The standard-conforming ctime_r() function does not take a buflen parameter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: using ghc with make
Hello John, Wednesday, April 19, 2006, 3:27:49 AM, you wrote: >> if that is due to the time of reading .hi files, my alternative Binary >> library should help in some future > Interesting, A big bottleneck big bottleneck? ;) > in jhc right now is reading the (quite > large) binary ho and hl files on startup. a few things I have wanted out > of a binary library are: > I was going to get around to writing this sometime, but perhaps there is > room for a collaborative project in there. Is your code available > somewhere bulat? http://freearc.narod.ru/Streams.tar.gz http://haskell.org/haskellwiki/Library/Streams but this doc don't contain info about Binary part that is now discussed. i attached to the letter my unfinished docs about this part of library now about your requirements: > * mmap based reading. my Streams library mainly consists of two parts - Streams and AltBinary. The streams part implements Handle-like interface (including such functions as vGetChar, vGetByte, vPutBuf, vSeek and so on) for various data sources - files, memory buffers, pipes, strings. m/m files support is planned but now has just preliminary implementation AltBinary part works via the Streams part. basically, it just implements various ways to convert data structure to the sequence of vPutByte operations (and vice versa), with support for lists, arrays and all other "simpler" datatypes that Haskell/GHC provides to us. Binary instances for other datatypes can be autogenerated via DrIFT or TH > * being able to jump over unneeded data, as in go directly to the 112th >record, or the third field in a data structure without having to >slurp through everything that came before it. what should be the user interface? the lib (its Streams part) supports vSeek/vTell operations. skipping to 112th record without knowing it's exact location will be impossible if each record can have different size the following things imho should not be a part of Binary library itself, but a higher-level client code > * the ability to create a hash of the structure of the underlying data >type, to verify you are reading data in the right format. you mean that using signature is not enough, or to be exact - that library should generate this signature itself? interesting. i think that for jhc (and potentially ghc) this should be implemented via DrIFT? > * extensible type-indexed sets (implemented hackily in Info.Binary in >jhc) by creating hash of structure we can reduce this task to just ordinary hash-like database? > * VSDB[1] style ACID updates as an option. > * VSDB style write-time optimized constant hash table. I don't mind >spending extra time when writing library files to speed up their >usage. i don't understand second thing. but anyway you already implemented VSDB database. you already has the way to autogenerate Binary instances. my lib can help by making serialization faster and providing uniform access to various media (files, buffers, m/m files). i can also work on hash-of-structure implementation using DrIFT or TH -- Best regards, Bulatmailto:[EMAIL PROTECTED]AltBinary library features: - interface compatibility with Binary library - compatibility both with Hugs and GHC, with GHC-specific speed optimizations - (de)serialization speed of 20-60 mb/sec on 1GHz CPU - support for byte-aligned and bit-aligned, low-endian and big-endian serialization using the same interface - free intermixing of text and binary i/o on the same handle - UTF8 encoding for strings, variable-length encoding for Int/Word/Integer (including encoding of list/array bounds) - fixed-size integral values use network byte order; any integral value can be saved with explicitly specified size using functions "putBits bh bits value" and "getBits bh bits" (putBit/putWord8...putWord64 is also supported for all integral types) - implementation of Binary interface for all Bounded Enum types - implementation of Binary interface for all array types - ability to serialize data to any Stream the following is the guide to using library, containing the following parts: 1. emulation of Binary interface 2. AltBinary interface 2.1 byte-aligned and bit-aligned streams 2.2 getBits/putBits; Binary instances for Bool, Maybe, Either 2.3 putWord8..putWord64; Binary instances for Int8..Word64; putWord##le 2.4 putBounded; Binary instances for Bounded Enum types 2.5 putUnsigned/putInteger/putLength; Binary instances for Int/Integer/Word 2.6 Binary instances for Char and String 2.7 lists support 2.8 arrays support 2.9 putGhcInteger and putByteArray - GHC-specific routines 2.10 defining Binary instances for custom serialization formats 3. Stream interface >1. emulation of Binary interface This library implements 2 interfaces: Binary and AltBinary. First interface allows to use this library as drop-in replacement for the well-known Binary and NewBinary libs. all you need to do is to replace "import Data.Binary" stateme
Re: 6.4.2 under solaris
Christian Maeder wrote: Simon Marlow wrote: --- ghc/rts/package.conf.inplaceThu Apr 13 15:49:49 2006 +++ ghc/rts/package.conf.inplace~ Wed Apr 12 19:44:55 2006 @@ -429,7 +429,6 @@ extra-libraries: "m" , "gmp" - , "rt" , "dl" Ok, does this help instead (compile stage1 with this change): *** DriverState.hs.~1.116.2.2.~2005-10-13 10:02:19.0 +0100 --- DriverState.hs2006-04-13 15:32:02.0 +0100 *** *** 418,423 --- 418,425 #if defined(freebsd_TARGET_OS) "-optc-pthread" , "-optl-pthread" + #elif defined(solaris_TARGET_OS) + "-optl-lrt" #endif ] ), This patch did not help. No optl option is added anywhere. Maybe "WayThreaded" is the wrong position? oops, it should be "solaris2_TARGET_OS", not "solaris_TARGET_OS" Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.4.2 under solaris
Christian Maeder wrote: Christian Maeder wrote: The files in the binary distribution are: ghc -> ghc-6.4.2 ghc-6.4.2 due to a missing dvips "make binary-dist" does not finish properly and does not create a ghc-6.4.2.sh (and other .sh) file(s). Should it not be possible to build a binary distribution without documentation? Try make binary-dist Project=Ghc BINDIST_DOC_WAYS=html Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: using ghc with make
Bulat Ziganshin wrote: 1) lazyGet/lazyPut. it's no problem to copy your implementation but i still don't understand how lazyGet should work - it share the same buffer pointer as one used in `get`. so `get` and consuming structure returned by lazyGet should interfere lazyGet can only be used to read something that was written with lazyPut. lazyPut writes the offset of the end of the serialised data at the beginning, so that lazyGet can skip over it, and subsequent gets start from the next item in the stream. btw, btw. Haskell type classes has many non-obvious peculiarities. for example, it was not easy for to understand that Haskell resolve all overloading at compile time but finds what overloaded function to call at runtime (well, i can't even describe this behavior). can you recommend me paper to read about using Haskell class system? I recommend compiling a few programs and investigating the Core with -ddump-ds and -ddump-simpl to find out what GHC really does. Overloading isn't all "resolved at compile time", most of the time dictionaries of functions are passed around representing class predicates. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: IORefs and garbage collection
Tomasz Zielonka wrote: On Wed, Apr 19, 2006 at 01:56:25PM +0400, Bulat Ziganshin wrote: generational GC (at least one used in GHC) is better suited for "functional" (immutable) data. this conception by itself based on that new allocated data can contain references to old ones but not vice versa. minor GC algorithms scans only new data, if they don't contain any references to some data cell (in new data), then all the heap don't contain references to this cell and it can be freed. most of the data in "normal" Haskell program are immutable so this works fine. But most of the data is also lazy, and laziness in GHC is implemented with mutation. I wonder how does GHC's GC handle thunk update. Thunks are a special case, because they only mutate once. We have a write barrier in the thunk update code. Not much has changed in this regard since Sansom's original generational GC for GHC: http://citeseer.ist.psu.edu/sansom93generational.html The GC has been replaced since then, and is now multi-generational rather than being fixed at 2 generations, amongst other things. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.2 under solaris
* Christian Maeder <[EMAIL PROTECTED]>: > I also had to adapt again the call of ctime_r in ghc/rts/RtsUtils.c > > #if HAVE_CTIME_R > - ctime_r(&now, nowstr, 26); > + ctime_r(&now, nowstr); > #else > > 26 is supposed to be the size of the buffer nowstr. Maybe 27 is also > fine? According to the man pages ctime_r is different under linux and > solaris. How should that be patched? Without the 3rd arg is according to POSIX (check your Solaris man page). 'buf' is required to be at least 26 bytes. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME "All the excitement lies in pattern matching." (SPJ et al.) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
