Re: hGetBuf (or something related) broken for 6.2 with sockets
On Thu, Dec 18, 2003 at 09:53:50PM +0100, Tomasz Zielonka wrote: On Thu, Dec 18, 2003 at 07:44:58PM +0100, George Russell wrote: It seems to work when I change hGetBuf to hGetBufNonBlocking. The name is a bit misleading - the action _does_ wait for some data, but it doesn't wait for all requested bytes. I've made a mistake here. hGetBuf waits for filling the whole Handle's reading buffer (or reaching EOF), even if the buffer contains enough data to satisfy the request. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: hGetBuf (or something related) broken for 6.2 with sockets
On Thu, Dec 18, 2003 at 09:53:50PM +0100, Tomasz Zielonka wrote: On Thu, Dec 18, 2003 at 07:44:58PM +0100, George Russell wrote: It seems to work when I change hGetBuf to hGetBufNonBlocking. The name is a bit misleading - the action _does_ wait for some data, but it doesn't wait for all requested bytes. I've made a mistake here. hGetBuf waits for filling the whole Handle's reading buffer (or reaching EOF), even if the buffer contains enough data to satisfy the request. I'm a bit lost. Do things work as you expect, or not? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: repeated import warning
Done! Simon Foo.hs: Warning: `isJust' is imported more than once: imported from Maybe at Foo.hs:4:16-21 imported from Maybe at Foo.hs:3:23-28 imported from Maybe at Foo.hs:3:16-21 | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Serge D. Mechveliani | Sent: 18 November 2003 13:36 | To: [EMAIL PROTECTED] | Subject: repeated import warning | | Dear GHC developers, | | What about compiler's warning of repeated import of items? | For the large import lists this may be useful, | and ghc-6.01 seems to lack this: | | -- | module T where | import Maybe (isJust, isJust) | f = isJust | -- | | ghc -c T.hs | | | - | Serge Mechveliani | [EMAIL PROTECTED] | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hGetBuf (or something related) broken for 6.2 with sockets
On Fri, Dec 19, 2003 at 10:26:02AM -, Simon Marlow wrote: On Thu, Dec 18, 2003 at 09:53:50PM +0100, Tomasz Zielonka wrote: On Thu, Dec 18, 2003 at 07:44:58PM +0100, George Russell wrote: It seems to work when I change hGetBuf to hGetBufNonBlocking. The name is a bit misleading - the action _does_ wait for some data, but it doesn't wait for all requested bytes. I've made a mistake here. hGetBuf waits for filling the whole Handle's reading buffer (or reaching EOF), even if the buffer contains enough data to satisfy the request. I'm a bit lost. Do things work as you expect, or not? Well, I think that it would be better if hGetBuf didn't block if all requested data was already in buffer, but I don't insist on it. However this change of semantics can brake existing programs. In my programs I rather use Data.Array.IO.hGetArray. I was only trying to help George. I am sorry if I only made things more complicated :) Cheers, Simon Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Possible unboxed tuples bug.
It's a bug. Now fixed. Test is should_compile/tc174 Thanks for finding it Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Sean Seefried | Sent: 30 November 2003 04:01 | To: [EMAIL PROTECTED] | Subject: Possible unboxed tuples bug. | | | Yesterday while I was mucking around in GHCi I discovered the following | anomaly. (The same holds for compiled code.) | | I typed | | :t (# 2, 3 #) | | and got back | | (# 2, 3 #) :: forall t t1. (Num t, Num t1) = (# t, t1 #) | | But when I typed | | :t (# 2, 3 #) :: (# Int, Int #) | | I got the following | | Illegal unboxed tuple type as function argument: (# Int, Int #) | In an expression type signature: (# Int, Int #) | In the type signature of the expression: (# 2, 3 #) :: (# Int, Int | #) | In the definition of `it': it = (# 2, 3 #) :: (# Int, Int #) | | | Is this correct behaviour? | | Sean | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hGetBuf (or something related) broken for 6.2 with sockets
On Fri, Dec 19, 2003 at 11:39:28AM +0100, Tomasz Zielonka wrote: Well, I think that it would be better if hGetBuf didn't block if all requested data was already in buffer, but I don't insist on it. However this change of semantics can brake existing programs. I am mixing things again: The change of hGetBuf's semantics happened between GHC 6.0 and 6.2. I thinks the semantics in 6.0 is more intuitive. Now we have hGetBufNonBlocking with the old semantics of hGetBuf. Wouldn't it be better to have hGetBuf with old semantics and hGetBufBlocking with the new one? This way we wouldn't break existing programs. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: hGetBuf (or something related) broken for 6.2 with sockets
On Fri, Dec 19, 2003 at 11:39:28AM +0100, Tomasz Zielonka wrote: Well, I think that it would be better if hGetBuf didn't block if all requested data was already in buffer, but I don't insist on it. However this change of semantics can brake existing programs. I am mixing things again: The change of hGetBuf's semantics happened between GHC 6.0 and 6.2. I thinks the semantics in 6.0 is more intuitive. Now we have hGetBufNonBlocking with the old semantics of hGetBuf. Wouldn't it be better to have hGetBuf with old semantics and hGetBufBlocking with the new one? This way we wouldn't break existing programs. hGetBuf isn't supposed to have different semantics, although its implementation changed considerably to optimise the case for small reads. It's possible I made a mistake, I'm looking into it right now. BTW George: there are plenty of 6.1.xxx snapshots available - these are the 6.2 prereleases. We don't snapshot along the STABLE branch at the moment; no real deep reason, we'd just have to figure out a version numbering scheme, and this might upset various scripts that expect to parse the GHC version number. Since you have to build from source anyway, why not download the sources from CVS? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hGetBuf (or something related) broken for 6.2 with sockets
Simon Marlow wrote (snipped): BTW George: there are plenty of 6.1.xxx snapshots available - these are the 6.2 prereleases. There are, but no recent ones. What I would like to have had is a 6.2-epsilon version, not 6.1 and a bit. We don't snapshot along the STABLE branch at the moment; no real deep reason, we'd just have to figure out a version numbering scheme, and this might upset various scripts that expect to parse the GHC version number. Since you have to build from source anyway, why not download the sources from CVS? The problem with downloading things direct from CVS is that I don't expect people to run substantial tests before checking things into CVS. (We don't on our CVS server.) Of course I don't expect a snapshot release to have the same reliability as a real release, but at least snapshot releases seem to compile and succeed in compiling themselves. Anyway Simon, is there a workaround to the sockets problem I posted or not? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-860413 ] ghci TH symbol lookup fails if package not already loaded
Bugs item #860413, was opened at 2003-12-15 15:50
Message generated for change (Comment added) made by simonpj
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=860413group_id=8032
Category: Compiler
Group: 6.0.1
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Duncan Coutts (duncan_coutts)
Assigned to: Nobody/Anonymous (nobody)
Summary: ghci TH symbol lookup fails if package not already loaded
Initial Comment:
in ghci -fglasgow-exts,
if I type:
:t $( [| Language.Haskell.THSyntax.app |] )
ghc-6.0.1: panic! (the `impossible' happened, GHC
version 6.0.1):
Desugar: lookup:
LanguageziHaskellziTHSyntax.var {- v 03F -}
Please report it as a compiler bug to
[EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
This is even if the module I had loaded imported
Language.Haskell.THSyntax
On the other hand doing
$( [| Language.Haskell.THSyntax.app |] )
works find (it links in haskell-src). Then after that,
doing
:t $( [| Language.Haskell.THSyntax.app |] )
works fine too.
The problem seems to be that the :t command doesn't
trigger on-demand package loading (at least in
combination with TH).
I got this problem on ghc 6.0.1 and a cvs version that
claimed it was 6.1 (built in mid spetember).
--
Comment By: Simon Peyton Jones (simonpj)
Date: 2003-12-19 12:12
Message:
Logged In: YES
user_id=50165
This is indeed a bug in 6.2.
But it works ok in the HEAD; and I'm not going to fix the
branch.
Simon
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=860413group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: To show or not to show french accents
Hello, What I don't understand is why you want show for this. As I mentioned earlier, to output strings and get accented characters, all you have to do is to output the string with putStr, and voilà, les signes diacritiques. Sometimes, I want to do cheap and dirty test programs that shows data structures involving some strings. Again, the cheap and dirty way to do this is to derive the data structure from Show using the deriving keyword. But then, you are sometimes barely able to just read the outputed string. Therefore I have to redefine show myself ... Which is a lot less cheap and a lot more dirty. The problem is that if you are reading single bytes, 233 is not necessarily é. It might be 'shch' if you are in Russia, What the byte should represents is not relevant here. All I wanted to point out, is that it is easier to read a character as a one byte (or two) instead of 4 and translate 4 characters into a numerical value, NO MATTER WHAT THE BYTE IS SUPPOSED TO REPRESENT. This was to answer an opposition that was maintaining that show was meant to be Read. I simply answered that that was not a valid argument. arithmetic right). Since Haskell specifies unicode, if you are operating in a Russian locale that's what ought to happen. I naively tought that unicode would solve these kind of problems. But yet we're stucked with these pesky 7 bits ... Regards, Francis Girard LE CONQUET France Selon Jon Fairbairn [EMAIL PROTECTED]: On 2003-12-18 at 16:40+0100 [EMAIL PROTECTED] wrote: Good evening, OK. I don't know Haskell enough to argue. But I can't resist pointing out that reading a single byte having the value 233 (that is 'é') The problem is that if you are reading single bytes, 233 is not necessarily é. It might be 'shch' if you are in Russia, or iota if you are in Greece. While it's (almost) completely reasonable to expect 233 to display as é in Western Europe, it's completely unreasonable to hold that expectation across borders. is certainly simpler than reading the four characters \233, parse it, and translate it into a single byte but it isn't a single byte internally. Indeed, if you are in Russia you could reasonably expect reading a single byte 233 to be converted to the internal code 1257 (if I got the arithmetic right). Since Haskell specifies unicode, if you are operating in a Russian locale that's what ought to happen. What I don't understand is why you want show for this. As I mentioned earlier, to output strings and get accented characters, all you have to do is to output the string with putStr, and voilà, les signes diacritiques. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ 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: 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
rmartine: 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 Ah! Yes. Thanks , dons... Let's try the registerised version !!! I'm working on it :) -- Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: To show or not to show french accents
This discussion is getting a little out of hand ;-) An instance of Show should (but doessn't have to): - generate a rendering of its argument as a String that (a) follows the Haskell lexical syntax, and (b) with an appropriate instance of Read can reconstruct the original value. - generate human-parseable output as far as possible. there are numerous holes and points to discuss here, but that would be more on-topic for the Haskell mailing list. The issue here is whether show on characters should render non-ASCII characters using an escape sequence. Doing so is clearly fine, because it is still in the Haskell lexical syntax, but it would also be fine (and possibly better) to render any character that is allowed unescape in the lexical syntax, literally (i.e. any character that is in 'graphic' or 'space' in the lexical syntax). Nevertheless, Haskell 98 specifies the use of escapes for characters 127, so our hands are tied anyway. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.2 compilation problems
This is ghc-6.2, trying to built it with ghc-6.2: $ ./configure --with-x --enable-threaded-rts --enable-objectio --enable-hopengl = [...] ==fptools== make all -wr; in /home/cm/Desktop/ghc-6.2/libraries/ObjectIO makefile:60: warning: overriding commands for target `HSobjectio.o' ../../mk/package.mk:196: warning: ignoring old commands for target `HSobjectio.o' rm -f Graphics/UI/ObjectIO/StdIOBasic.o; if [ ! -d Graphics/UI/ObjectIO/StdIOBasic_split ]; then mkdir Graphics/UI/ObjectIO/StdIOBasic_split; else /usr/bin/find Graphics/UI/ObjectIO/StdIOBasic_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -Iinclude -package-name objectio -O -Rghc-timing -package base -split-objs-c Graphics/UI/ObjectIO/StdIOBasic.hs -o Graphics/UI/ObjectIO/StdIOBasic.o -ohi Graphics/UI/ObjectIO/StdIOBasic.hi ghc: 119188216 bytes, 15 GCs, 1557314/3067356 avg/max bytes residency (2 samples), 19M in use, 0.00 INIT (0.00 elapsed), 0.78 MUT (3.73 elapsed), 0.20 GC (0.19 elapsed) :ghc (cd Graphics/UI/ObjectIO/ /usr/bin/ld -r -x -o StdIOBasic.o StdIOBasic_split/*.o); rm -f Graphics/UI/ObjectIO/OS/Cutil_12.o; if [ ! -d Graphics/UI/ObjectIO/OS/Cutil_12_split ]; then mkdir Graphics/UI/ObjectIO/OS/Cutil_12_split; else /usr/bin/find Graphics/UI/ObjectIO/OS/Cutil_12_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -Iinclude -package-name objectio -O -Rghc-timing -package base -split-objs-c Graphics/UI/ObjectIO/OS/Cutil_12.hs -o Graphics/UI/ObjectIO/OS/Cutil_12.o -ohi Graphics/UI/ObjectIO/OS/Cutil_12.hi Graphics/UI/ObjectIO/OS/Cutil_12.hs:40: parse error on input ``' ghc: 3034668 bytes, 2 GCs, 47328/47328 avg/max bytes residency (1 samples), 5M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (0.02 elapsed), 0.01 GC (0.01 elapsed) :ghc make[2]: *** [Graphics/UI/ObjectIO/OS/Cutil_12.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/cm/Desktop/ghc-6.2/libraries' make: *** [build] Error 1 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC and UNICODE...
Whilst I appreciate the topic of show is not directly related to GHC, what I would like to know is how to handle UNICODE properly... If I assume I have a good unicode terminal, so stdin and stdout are in unicode format, and all my text files are in unicode, how do I deal with this properly in GHC... what is the current state of affairs? Regards, Keean. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and UNICODE...
On Fri, Dec 19, 2003 at 04:51:50PM +, MR K P SCHUPKE wrote: Whilst I appreciate the topic of show is not directly related to GHC, what I would like to know is how to handle UNICODE properly... If I assume I have a good unicode terminal, so stdin and stdout are in unicode format, and all my text files are in unicode, how do I deal with this properly in GHC... what is the current state of affairs? I use unicode quite regularly with GHC. The only way in which unicode is lacking, is in the default I/O implementation in the standard libraries. There is nothing about the compiler itself that inherently limits unicode support. All that is needed is to replace or augment the standard IO code, a task which is often necisarry for other reasons when working on large projects anyway. here are a number of things I have done to make unicode easier to deal with: 1. written the CWString library (now a part of the FFI) which lets you call arbitrary C functions doing all the proper character set conversion stuff. 2. used UTF8.hs to wrap the various routines in IO. works great as long as your system uses utf8. (which many do) 3. modified daan's PPrint to be able to handle arbitrary character widths independent of the number of characters. this is useful when encoding things in a charset which doesn't have a 1-1 character to screen cell guarentee. (accents, CJK languages, etc..) and is also incidentlly very useful for doing things like embedding arbitrary escape sequences (colors) into pretty printed layout without affecting the PP algorithm. something I have wanted to do is modify Alex so that turns into the regular expression 0xe2 0x88 0x80 (and so forth) so that ghc (whose lexer is generated from alex) can simply accept utf8 input. John -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.2
rmartine: 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 Ah! Yes. Thanks , dons... Let's try the registerised version !!! I'm working on it :) -- Don ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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
Re: To show or not to show french accents
Lets assume I get a unicode terminal, and I am reading and writing from unicode files, how does Haskell (or more specifically GHC cope with this)? (PS: I am not a member of haskell-cafe mailing list, so please CC me in to any replies in this thread)... Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
