- Glasgow-haskell-users

RE: RFC: hyperlinks in Haddock docs
by Simon Marlow 01 Feb '05

01 Feb '05

On 01 February 2005 12:48, Ketil Malde wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> There are some problems with the existing approach. It doesn't cope >> well with instances: instances might refer to types/classes not below >> the current module in the hierarchy. Also you might import an entity >> from a "hidden" module, but actually want to hyperlink to another >> module > >> Thoughts? Better ideas? > > If it turns out to be difficult to determine where to link, one option > could be to link to a separate table on the same page, listing the > candidates? Hmm, I'm not sure that would be practical. Lots of entities are exported from more than one place, especially Prelude entities. You'd have a table on almost every single page listing Bool, Maybe, Int, etc. You could link to the index, I suppose - that lists all the places you can get a particular entity. I'm not sure you want to make two clicks to follow a link every time though. Cheers, Simon

2 1

ghc HEAD 'make html' problems
by Peter Simons 01 Feb '05

01 Feb '05

I can't build the library's Haddock documentation anymore: the process fails claiming that Control/Arrow-raw.hs would be missing. I've had this problem for a while now. Does anybody else see this? Peter

2 1

RE: recursive group context bug?
by Simon Peyton-Jones 28 Jan '05

28 Jan '05

The Report says that the functions of a mutually recursive group must all have the same context. It's a bit of a funny rule, and it's more restrictive than absolutely necessary, but that's what Haskell says. I could work to lift the restriction in GHC, but it only seems to come up in toy programs, never in real ones. So it's low (very low) priority at the moment. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Keean Schupke | Sent: 17 January 2005 13:52 | To: Carsten Schultz | Cc: Simon Marlow; glasgow-haskell-users(a)haskell.org | Subject: Re: recursive group context bug? | | This must be a bug then, because the following works! | | y :: Num a => a | y = fromIntegral (y::Int) | | >A simpler example might be: | > | > x :: Int | > x = y | > | > y :: Num a => a | > y = fromIntegral x | > | >I have not studied the report to see if this should be legal. | > | > | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Problem with DB and Char size (2)
by Bayley, Alistair 28 Jan '05

28 Jan '05

<promotional-plug> Actually... there is a "native" Oracle driver, or rather, one that uses the OCI. It's usable, but certainly not complete. http://cvs.sourceforge.net/viewcvs.py/haskell-libs/libs/takusen/src/ However, I've only tested it with bog-standard ASCII Cstrings (my NLS_LANG setting specifies WE8ISO8859P1), so I've no idea how well it works with Unicode. </promotional-plug> Have you tried fiddling with your NLS_LANG environment variable? This determines the charset your data is converted to when sent from the DBMS to the client. You can set it either in a .bat script (just for that session), or modify the registry setting in: HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\HOME0 What's it currently set to? Alistair. > -----Original Message----- > From: Santoemma Enrico [mailto:enrico.santoemma@beta80group.it] > Sent: 27 January 2005 16:49 > To: Krasimir Angelov > Cc: glasgow-haskell-users(a)haskell.org > Subject: R: Problem with DB and Char size (2) > > This is exactly what happens: > (btw, the same thing happens in Python, so the trouble must > be in the Oracle odbc driver. But this is also what happens > today to any Haskell business application which connects to > Oracle, as - to my knowledge - there is no native Oracle > driver for Haskell) > > ... > stmt0 <- query c $ "select 'Ã' as TEST from dual" > stmt1 <- query c $ "select '" ++ chr(195):chr(131):[] ++ "' > as TEST from dual" > stmt2a<- query c $ "select '" ++ [chr(195*256 + 131)] ++ "' > as TEST from dual" > stmt2b<- query c $ "select '" ++ [chr(131)] ++ "' as TEST from dual" > stmt3 <- query c $ "select chr(195*256 + 131) as TEST from dual" > ... > > after execution on a UTF-8 Oracle9i instance: > 0: "TEST", "\195\131" > 1: "TEST", "\195\131\198\146" > 2a: "TEST", "\198\146" > 2b: "TEST", "\198\146" > 3: "TEST", "\195\131" > > 0 is the reference: UTF-8 encoding of an A with a tilde on the top. > 1 is UTF-8 encoding (by Oracle) of an already encoded UTF-8 string > 2a and 2b show that the high byte is stripped: \198\146 is > the UTF-8 encoding of chr(131) > 3 is the only (almost useless) workaround I've found. > > Of course, with 3 byte chars things get even more confused. > > Enrico > > > > -----Messaggio originale----- > Da: Krasimir Angelov [mailto:kr.angelov@gmail.com] > Inviato: giovedì 27 gennaio 2005 15.41 > A: glasgow-haskell-users(a)haskell.org > Oggetto: Re: Problem with DB and Char size (2) > > > On Thu, 27 Jan 2005 06:34:40 -0800, John Meacham > <john(a)repetae.net> wrote: > > On Thu, Jan 27, 2005 at 04:23:52PM +0200, Krasimir Angelov wrote: > > > HSQL uses withCString internally. withCString strips the > higher order > > > bytes from Char. > > > > You should be able to replace withCString with > withUTF8String from my > > CWStringBasic module, which you can get from here: > > http://repetae.net/john/recent/src/HsLocale/CWStringBasic.hs > > > > and is part of my bigger HsLocale project > http://repetae.net/john/recent/out/HsLocale.html > > but just that one file should be enough if all you need is UTF8. > > John > > Santoemma Enrico said that Oracle ODBC driver expects UCS-2 instead of > UTF-8 so this will not help. > > Krasimir ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

gfindtype type
by Jim Apple 27 Jan '05

27 Jan '05

Why is gfindtype :: (Data x, Data y) => x -> Maybe y and not gfindtype :: (Data x, Typeable y) => x -> Maybe y ? Jim Apple

3 4

Problem with DB and Char size
by Santoemma Enrico 27 Jan '05

27 Jan '05

I have a problem with strings and unicode chars, when writing slq statements on Oracle ODBC driver through HSQL. I'm writing here because I suspect that a fix could come from writing 8 bit strings, if it is possible somehow. I'm sorry, the problem is very deep into it's context, and I know it's not easy to follow The problem is: Oracle ODBC driver expects, at least under Windows, UCS-2 strings. Then, if the DB is set to UTF-8, it converts the string into UTF-8. I'm using HSQL to access ODBC. I have UTF-8 bytes, coming from an UTF-8 source (a web browser), and I

2 1

R: Problem with DB and Char size (2)
by Santoemma Enrico 27 Jan '05

27 Jan '05

This is exactly what happens: (btw, the same thing happens in Python, so the trouble must be in the Oracle odbc driver. But this is also what happens today to any Haskell business application which connects to Oracle, as - to my knowledge - there is no native Oracle driver for Haskell) ... stmt0 <- query c $ "select 'Ã' as TEST from dual" stmt1 <- query c $ "select '" ++ chr(195):chr(131):[] ++ "' as TEST from dual" stmt2a<- query c $ "select '" ++ [chr(195*256 + 131)] ++ "' as TEST from dual" stmt2b<- query c $ "select '" ++ [chr(131)] ++ "' as TEST from dual" stmt3 <- query c $ "select chr(195*256 + 131) as TEST from dual" ... after execution on a UTF-8 Oracle9i instance: 0: "TEST", "\195\131" 1: "TEST", "\195\131\198\146" 2a: "TEST", "\198\146" 2b: "TEST", "\198\146" 3: "TEST", "\195\131" 0 is the reference: UTF-8 encoding of an A with a tilde on the top. 1 is UTF-8 encoding (by Oracle) of an already encoded UTF-8 string 2a and 2b show that the high byte is stripped: \198\146 is the UTF-8 encoding of chr(131) 3 is the only (almost useless) workaround I've found. Of course, with 3 byte chars things get even more confused. Enrico -----Messaggio originale----- Da: Krasimir Angelov [mailto:kr.angelov@gmail.com] Inviato: giovedì 27 gennaio 2005 15.41 A: glasgow-haskell-users(a)haskell.org Oggetto: Re: Problem with DB and Char size (2) On Thu, 27 Jan 2005 06:34:40 -0800, John Meacham <john(a)repetae.net> wrote: > On Thu, Jan 27, 2005 at 04:23:52PM +0200, Krasimir Angelov wrote: > > HSQL uses withCString internally. withCString strips the higher order > > bytes from Char. > > You should be able to replace withCString with withUTF8String from my > CWStringBasic module, which you can get from here: > http://repetae.net/john/recent/src/HsLocale/CWStringBasic.hs > > and is part of my bigger HsLocale project http://repetae.net/john/recent/out/HsLocale.html > but just that one file should be enough if all you need is UTF8. > John Santoemma Enrico said that Oracle ODBC driver expects UCS-2 instead of UTF-8 so this will not help. Krasimir _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Problem with DB and Char size (2)
by Santoemma Enrico 27 Jan '05

27 Jan '05

Oops... I hit the wrong key, sending a partial post. Sorry :) Again: I have a problem with strings and unicode chars, when writing slq statements on Oracle ODBC driver through HSQL. I'm writing here because I suspect that a fix could come from writing 8 bit strings, if it is possible somehow. I'm sorry, the problem is very deep into it's context, and I know it's not easy to follow the reasoning. These are the facts: - I execute an SQL statement, an INSERT, where some values come from a web browser, and are UTF-8 encoded - Oracle ODBC expects UCS-2, so it converts the values into UTF-8, of course scrambling the data - when I convert, in Haskell, UTF-8 to UCS-2, I see that someone (perhaps HSQL) strips one byte from the two Char's bytes, so again Oracle receives bad data As I haven't found how to force the driver not to strip the byte, and also I don't like to convert data two times, I'd try to send 8 bit strings, but don't know how. Is Word8 a solution? If it is, what is the contstructor?, as w = W8# 1 doesn't compile. I'm weak on low level Haskell. Where do I find references? On the Report? Thanks, Enrico

4 4

RE: profiling usage
by Simon Marlow 26 Jan '05

26 Jan '05

On 26 January 2005 09:13, Serge D. Mechveliani wrote: > The indentation in the profiling report or in the source program? In the profiling report. > The report prints some function names not from the beginning of the > line ... > Maybe, you can give a simple example of a program with SCC when the > center is printed twice? For I do not understand this point. eg. f x = x * 2 g x = f x main = print (f 3 + g 3) here f is called both from main and from g, and will appear twice in the profile. > Now I replaced SCC with -auto-all, and it gives a report which > looks satisfactory. > The first part > lpo TermComp 29.9 47.0 > relates Prelude1 13.1 1.5 > ... > is helpful all right. > But I also need to know how many times there was called a certain > function f, no matter from where it is called and whether it > occurs in the first part of the report. I search for `f' in > the large second part of the report. And find the two (often many) > lines (with different indentation): > > f Module1 10 20 ... > ... > f Module1 121 30 ... > > So, `f' was entered 20 times from one point and 30 times from another, > and 50 times in total. Right? Yes. Simon

1 0

profiling usage
by Serge D. Mechveliani 26 Jan '05

26 Jan '05

Dear GHC experts, I have another question about the profiling usage in ghc-6.2.2. I thank "Simon Marlow" <simonmar(a)microsoft.com> for the explanations. We wrote >> There was set a single point of {-# SCC "isReducibleAtTop" #-}. >> Why the report prints the two different lines for it? > You removed the indentation, which was there to indicate the call > nesting. A cost centre that appears more than once indicates that it > was called in two places in your program (or called with two different > lexical call stacks, to be precise). The indentation in the profiling report or in the source program? The report prints some function names not from the beginning of the line ... Maybe, you can give a simple example of a program with SCC when the center is printed twice? For I do not understand this point. Now I replaced SCC with -auto-all, and it gives a report which looks satisfactory. The first part lpo TermComp 29.9 47.0 relates Prelude1 13.1 1.5 ... is helpful all right. But I also need to know how many times there was called a certain function f, no matter from where it is called and whether it occurs in the first part of the report. I search for `f' in the large second part of the report. And find the two (often many) lines (with different indentation): f Module1 10 20 ... ... f Module1 121 30 ... So, `f' was entered 20 times from one point and 30 times from another, and 50 times in total. Right? Thank you in advance for the explanation. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0