Re: sizeFM type
David Roundy [EMAIL PROTECTED] writes: I'd say that rather than returning an Integer, we'd be better off just using a 64 bit Int on 64 platforms. | 7.19.2. GHC's interpretation of undefined behaviour in Haskell 98 | | This section documents GHC's take on various issues that are left | undefined or implementation specific in Haskell 98. | | Sized integral types | |In GHC the Int type follows the size of an address on the host |architecture; in other words it holds 32 bits on a 32-bit |machine, and 64-bits on a 64-bit machine. Looks like a reasonable way to go about it. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: sizeFM type
Sun and Dell both sell 64-bit boxes. But the core question is why have two different types at all? This issue is timely because I just got an error in code that looks vaguely like: h-openFile foo AppendMode pos - hFileSize h hPutStr $ show something hClose h content - readFile foo return $ take pos content This code produces an error because (madness!): hFileSize::Handle - IO Integer take::forall a. Int - [a]-[a] I have to assume conversion between files and lists is not all that rare even in beginner code. Note: I don't really care whether everything is 64bit Int or Integer. I just find having to care about this point in such trivial code ridiculous. And re sizeFM, I would note that Google has more than 2^31 pages indexed in memory. -Alex- _ S. Alexander Jacobson mailto:[EMAIL PROTECTED] tel:917-770-6565 http://alexjacobson.com On Sun, 25 Apr 2004, David Roundy wrote: On Sun, Apr 25, 2004 at 03:20:42PM -0400, S. Alexander Jacobson wrote: QUESTION: I read in a newspaper that in l981 you said '640K of memory should be enough for anybody.' What did you mean when you said this? ANSWER: I've said some stupid things and some wrong things, but not that. No one involved in computers would ever say that a certain amount of memory is enough for all time. http://www.wired.com/news/print/0,1294,1484,00.html Dell's Poweredge servers address up to 32GB of memory today! There are already 5.7 billion people on the planet (2^31) and 741 million phone lines. In my mind, there is NO QUESTION that 2^31 keys is a reasonable size for a FiniteMap or will be in the very very near future. On the other hand, since they are still 32 bit computers, any given application can still only access 4G of memory. This issue will only be a problem on 64 bit platforms which have a 32 bit Int. Moreover, it is not clear that the CPU/memory overhead of returning Integer rather than Int for sizeFM is sufficiently high to be worth bothering the programmer about. I'd say that rather than returning an Integer, we'd be better off just using a 64 bit Int on 64 platforms. -- David Roundy http://www.abridgegame.org ___ 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: Safe use of unsafeCoerce?
On 24 April 2004 17:38, Duncan Coutts wrote: All, I'm after advice on whether the following example is a safe use of unsafeCoerce, and if it is safe, if it's worth it. In summary, if the following is ok: castFooToBar :: Ptr Foo - Ptr Bar castFooToBar = castPtr then is the following ok? newtype Foo' = Foo' (Ptr Foo) newtype Bar' = Bar' (Ptr Bar) castFooToBar' :: Foo' - Bar' castFooToBar' = unsafeCoerce If the runtime representation of Foo' and Bar' is the same, then this is safe. In this case the runtime representation is the same, so you're ok. However, it might not always be a good idea, because the compiler's optimiser gets a bit stuck when it sees an unsafeCoerce. I'd like to be a bit more specific, but I'm not sure I can remember the specific example. On the other hand, Happy makes extensive use of unsafeCoerce in its generated code (when you use -c), so in some cases the benefits can definitely outweigh the costs. Here's the context/motivation: [ snip ] toGObject :: GObjectClass o = o - GObject toGObject = unsafeCoerce fromGObject :: GObjectClass o = GObject - o fromGObject = unsafeCoerce So, the point is we can remove entirely the class dictionary that otherwise has to be carried round for every object and the upcasting downcasting functions no longer need to do slow dictionary lookups when all they are really doing is casting C pointers. So is it a) safe? b) kosher? I think so. On the other hand, you might want to look at using the trick that wxHaskell uses for encoding the widget hierarchy, which also has zero runtime cost. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: sizeFM type
On 26 April 2004 02:49, S. Alexander Jacobson wrote: Sun and Dell both sell 64-bit boxes. But the core question is why have two different types at all? This issue is timely because I just got an error in code that looks vaguely like: h-openFile foo AppendMode pos - hFileSize h hPutStr $ show something hClose h content - readFile foo return $ take pos content This code produces an error because (madness!): hFileSize::Handle - IO Integer take::forall a. Int - [a]-[a] I have to assume conversion between files and lists is not all that rare even in beginner code. Note: I don't really care whether everything is 64bit Int or Integer. I just find having to care about this point in such trivial code ridiculous. Probably if the take function were being designed today, there would be no question about whether it should take Int or Integer. Back then, the Integer overhead was high enough to worry about, and lots of benchmark programs used take/drop. Nowadays, we can't really change the type of take without breaking just about every Haskell program. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: sizeFM type
On Mon, 26 Apr 2004, Simon Marlow wrote: Probably if the take function were being designed today, there would be no question about whether it should take Int or Integer. Back then, the Integer overhead was high enough to worry about, and lots of benchmark programs used take/drop. Nowadays, we can't really change the type of take without breaking just about every Haskell program. Ok, but the whole library hierarchy is pretty new, right? There is no reason for Data.FiniteMap.sizeFM to be Int. Moreover take and drop in Data.List could be redefined to take Integer without breakage etc. Aside: Is there truly a substantive amount of code that would break if this was switched? Doesn't type inference mean that most code would switch just fine? -Alex- _ S. Alexander Jacobson mailto:[EMAIL PROTECTED] tel:917-770-6565 http://alexjacobson.com ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Safe use of unsafeCoerce?
On Mon, 2004-04-26 at 15:42, Alastair Reid wrote: I'm after advice on whether the following example is a safe use of unsafeCoerce, and if it is safe, if it's worth it. It looks like it is safe but it feels like using a sledgehammer to crack a nut ... in the presence of small children/ curious animals/ two left thumbs/ etc. so you have to take great care that none of them are near the nut each time you pull that sledgehammer out. Given the function castFooToBar (which you tell us is safe), there's a number of obvious typesafe ways of writing this code, why not do so? [I accept that there could be some reasons I just didn't see you mention any.] In the context of the Gtk class hierarchy, we do currently have a type safe way of doing it (wrapBar.castForiegnPtr.unwrapFoo), but I'm trying to eliminate the class dictionary overhead. I'm open to other suggestions. Duncan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
UTF-8 encode/decode libraries.
I am writing some utilities to deal with UTF-8 encoded text files (not source). Currently, I'm just reading in the UTF-8 directly, and things work reasonably well, since my parse tokens are ASCII, they are easy to parse. However, the character type seems perfectly happy with larger values for each character. Is anyone aware of any Haskell libraries for doing UTF-8 decoding and encoding? If not, I'll write something simple. Thanks, Dave Brown ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 encode/decode libraries.
On Mon, 2004-04-26 at 18:49, David Brown wrote: Is anyone aware of any Haskell libraries for doing UTF-8 decoding and encoding? If not, I'll write something simple. The gtk2hs library uses the following functions internally. Credit to Axel Simon I believe unless he swiped them from somewhere too. -- Convert Unicode characters to UTF-8. -- toUTF :: String - String toUTF [] = [] toUTF (x:xs) | ord x=0x007F = x:toUTF xs | ord x=0x07FF = chr (0xC0 .|. ((ord x `shift` (-6)) .. 0x1F)): chr (0x80 .|. (ord x .. 0x3F)): toUTF xs | otherwise = chr (0xE0 .|. ((ord x `shift` (-12)) .. 0x0F)): chr (0x80 .|. ((ord x `shift` (-6)) .. 0x3F)): chr (0x80 .|. (ord x .. 0x3F)): toUTF xs -- Convert UTF-8 to Unicode. -- fromUTF :: String - String fromUTF [] = [] fromUTF (all@(x:xs)) | ord x=0x7F = x:fromUTF xs | ord x=0xBF = err | ord x=0xDF = twoBytes all | ord x=0xEF = threeBytes all | otherwise = err where twoBytes (x1:x2:xs) = chr (((ord x1 .. 0x1F) `shift` 6) .|. (ord x2 .. 0x3F)):fromUTF xs twoBytes _ = error fromUTF: illegal two byte sequence threeBytes (x1:x2:x3:xs) = chr (((ord x1 .. 0x0F) `shift` 12) .|. ((ord x2 .. 0x3F) `shift` 6) .|. (ord x3 .. 0x3F)):fromUTF xs threeBytes _ = error fromUTF: illegal three byte sequence err = error fromUTF: illegal UTF-8 character Duncan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 encode/decode libraries.
Duncan Coutts wrote: On Mon, 2004-04-26 at 18:49, David Brown wrote: [...] toUTF :: String - String Hmmm, String - [Word8] would be nicer... fromUTF :: String - String ... and here: [Word8] - String or [Word8] - Maybe String. Furthermore, UTF-8 is not restricted to a maximum of 3 bytes per character, here an excerpt from man utf8 on my SuSE Linux: * UTF-8 encoded UCS characters may be up to six bytes long, however the Unicode standard specifies no characters above 0x10, so Unicode characters can only be up to four bytes long in UTF-8. IIRC we discussed encoders/decoders quite some time ago on the libraries mailing list, but nothing really happened, which is a pity. We should strive for something more general than UTF-8 - UCS/Unicode, there are quite a few more widely used encodings, e.g. GSM 03.38, etc. Any takers? Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
problems building the GHC as a package
Hi folks, I'm having a little problem when building the GHC as a package. I've set the option 'BuildPackageGHC=YES' in the build.mk file and done the usual steps to build the GHC under windows (including the './configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc'). But I'm getting the following error in the middle of the build process: --- (cd .libs rm -f libgmp.la ln -s ../libgmp.la libgmp.la) make[5]: Leaving directory `/home/legionario_k/fptools/ghc/rts/gmp' make[4]: Leaving directory `/home/legionario_k/fptools/ghc/rts/gmp' ../../ghc/compiler/ghc-inplace -optc-mno-cygwin -optc-O -optc-Wall -optc-W -optc-Wstrict-p missing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc- -DCOMPILING_RTS -optc-Iwin32 -optc-fomit-frame-pointer -H32m -O0 -W -fno-warn-unused-match Adjustor.c -o Adjustor.o exec: C:/haskell/cygwin/home/legionario_k/fptools/ghc/compiler/: not found make[2]: *** [Adjustor.o] Error 127 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/legionario_k/fptools/ghc' make: *** [build] Error 1 -- any sugestions? Cheers, - | Mauro La-Salette C. L. de Araújo | | Undergraduating Computer Science Student | | mscla at cin.ufpe.br | | http://www.cin.ufpe.br/~mscla| - If this is true, building software will always be hard. There is inherently no silver bullet. (F.P.Brooks) ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 encode/decode libraries.
On Mon, Apr 26, 2004 at 08:33:38PM +0200, Sven Panne wrote: Duncan Coutts wrote: On Mon, 2004-04-26 at 18:49, David Brown wrote: [...] toUTF :: String - String Hmmm, String - [Word8] would be nicer... fromUTF :: String - String ... and here: [Word8] - String or [Word8] - Maybe String. Except that I would then have to come up with my own IO routines to read and write UTF data. With both sides as string, it is easy to just filter input and output of files. Dave ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.2.1
simonmar: The (Interactive) Glasgow Haskell Compiler -- version 6.2.1 We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 6.2.1. As usual for patchlevel releases, this is mainly a bugfix release and should not break any code that was working with the previous major release (6.2). OpenBSD i386, sparc and amd64 GHC is in the OpenBSD ports tree as lang/ghc. To install from source, update your ports tree to -current, and say cd /usr/ports/lang/ghc make install. Cheers, Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
