January 2005 - Glasgow-haskell-users

RE: runInteractiveProcess is broken
by Simon Marlow 18 May '05

18 May '05

I can't repeat this, it works here: *Main> test1 ExitSuccess *Main> test2 Just ExitSuccess (after changing /usr/bin/sleep to /bin/sleep). The only thing I can think of is that you somehow have a SIGCHLD handler that calls wait(), but I don't see where that can be happening. GHC doesn't have any other mechanism for calling wait(), so I don't understand how the zombies are disappearing before waitForProcess is called. Maybe run it through strace and send us the output? Cheers, Simon On 26 October 2004 19:00, Peter Simons wrote: > Neither of these functions returns the return code of the > external process as promised: > > import System.IO hiding ( catch, try ) > import System.Process > import Control.Concurrent > > sleep :: Int -> IO () > sleep n = threadDelay (abs(n) * 1000000) > > test1 :: IO () > test1 = do > (_,_,_, pid) <- runInteractiveProcess "/usr/bin/sleep" ["1"] > Nothing Nothing sleep 5 > rc <- waitForProcess pid > print rc > > -- *Main> test1 > -- *** Exception: waitForProcess: does not exist (No child > processes) > > test2 :: IO () > test2 = do > (_,_,_, pid) <- runInteractiveProcess "/usr/bin/sleep" ["1"] > Nothing Nothing sleep 5 > rc <- getProcessExitCode pid > print rc > > -- *Main> test2 > -- Nothing > > I'm using the ghc from CVS-HEAD on Linux/x86. > > Peter > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

RE: Dynamic loading problem
by Simon Marlow 18 Feb '05

18 Feb '05

On 30 April 2004 11:26, Duncan Coutts wrote: > Could someone remind me what the remaining issues are in getting ghc > to build Haskell modules/packaged into unix .so shared libraries? > > As I recall it seems to nearly work. Andre Pang got them to load and > function but it was a bit fragile and the rts would complain after a > short while: > http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg03923.h tml It might be possible to do this, but only if you want to do dlopen()-style linking at runtime. Linking a haskell binary against Haskell .so libraries still isn't possible - I had another look at this recently, and although one of the obstacles has been removed, there are others (details available on request). Any remaining issues to do with dlopen()ing a Haskell .so library are probably to do with CAFs. The dynamically loaded code needs to call newDynCAF() instead of newCAF() in a CAF's entry code - this is normally arranged by the RTS linker, but for a .so you'll have to do it some other way, like getting the compiler to emit the different call, or doing some CPP magic (but only for -fvia-C). Any reasonable patches to implement this will be incorporated. Oh, and strictly speaking we should run the __stginit_Foo() function from each dynamically loaded module. But the RTS linker still doesn't do this. Cheers, Simon

4 3

Restricted Types and Infinite Loops
by Simon David Foster 18 Feb '05

18 Feb '05

Hi, (I've attached the full code for this problem) First I'll explain the problem description, I have two class ClassA and ClassB, the former has two parameters and the latter has one. The second parameter of ClassA is constrained by ClassB. class ClassB a where class ClassB b => ClassA a b where Because I wish to effectively pass the context of ClassA around, I need to create a pair of dictionary types (as in Restricted Data Types in Haskell, Hughes 99), one to represent ClassA (DictClassA) and one to represent ClassB (DictClassB). DictClassA also contains a term of type DictClassB since ClassA is a subclass of ClassB. I should then be able to call all the functions of ClassB via the appropriate term of DictClassA, like so (assuming we want to use func2); *Test> func2D (classBD (dict::DictClassA Int String)) "hello" "bye" So far so good, but now suppose I want Class A to have the further constraint class (Data (DictClassA a) b, ClassB b) => ClassA a b where (so as to make ClassA a subclass of Data) If we now try and do *Test> func2D (classBD (dict::DictClassA Int String)) "hello" We go into an infinite loop. Why? The expression still type-checks ok and I can't see what it is trying to do. All the functions of ClassA can be accessed ok, but not ClassB. *Test> funcD ((dict::DictClassA Int String)) "hello" 5 "hello" Is it something to do with ClassB only having one parameter? I'm running GHC 20041231. -Si. -- Simon David Foster <s.d.f(a)btinternet.com>

3 6

RE: Process library and signals
by Simon Marlow 02 Feb '05

02 Feb '05

On 27 October 2004 15:08, Glynn Clements wrote: > Simon Marlow wrote: > >> So basically you're saying that if runProcess is to be used in a >> system()-like way, that is the parent is going to wait synchronously >> for the child, then the parent should be ignoring SIGQUIT/SIGINT. >> On the other hand, if runProcess is going to be used in a >> popen()-like way, then the parent should not be ignoring >> SIGQUIT/SIGINT. > > Exactly. > >> The current >> interface doesn't allow for controlling the behaviour in this way. > > Yep. > >> So the current signal handling in runProcess is wrong, and should >> probably be removed. What should we have instead? We could >> implement the system()-like signal handling for System.Cmd.system >> only, perhaps. > > Well, probably for system and rawSystem. I've now fixed system and rawSystem to do something more appropriate on POSIX systems: they now disable SIGINT and SIGQUIT in the parent, and reset these signals to SIG_DFL in the child. This isn't completely correct, but it's better than before. runProcess and friends don't do any signal handling. I think this covers most of the useful situations. If you want to do the same thing in both parent and child, or handle in the parent and SIG_DFL in the child: use runProcess. If you want to ignore in the parent and SIG_DFL in the child: use System.Cmd.{system,rawSystem}. To handle in the parent and ignore in the child: unfortunately not directly supported. I realise this doesn't address the library design issues you raised, but as you pointed out there doesn't seem to be a good platform-independent solution here. Cheers, Simon

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