- Hugs-Bugs - Haskell.org

Segfault
by Michal Safranek 04 Jun '02

04 Jun '02

{- Story: I had 'Functional programming' exam today ... (which I totally screwed up) After returning to campus I tried to verify some of my results in hugs-Dec2001 The goal was implementing 'cons' parser to parse either '[1,2,3,...]' or '1:2:3:...:[...]' My example didn't worked (what a surprise :( ). I tried to play with hugs ... and made little mistake in my code ... instead of 'cons = numbers >>= (\x -> enumlist >>= (\y -> return (x ++ y)))' I wrote: 'cons = numbers >>= (\x -> listterm >>= (\y -> return (x ++ y)))' ... complete program and result can be found below ... (I'm sending this here because it seems strange getting segfault to me ...) Sincerely, Wejn PS: Please keep in mind this code was written by total beginner (=me) ... -- Michal Safranek <wejn(at)svamberk.net> (svamberk.net's Linux section, fi.muni.cz student, linuxfan) >>> Bored? Want hours of entertainment? <<< >>> Just set the initdefault to 6! <<< -} import ParseLib listterm :: Parser [Int] listterm = cons `chainr1` ops [(symbol "++", (++))] enumlist :: Parser [Int] enumlist = bracket (symbol "[") (sepby int (symbol ",")) (symbol "]") cons :: Parser [Int] -- cons = ...??... numbers :: Parser [Int] numbers = sepby int (symbol ":") cons = numbers >>= (\x -> listterm >>= (\y -> return (x ++ y))) {- -- it really should be: cons = enumlist +++ (numbers >>= (\x -> symbol ":" >> listterm >>= (\y -> return (x ++ y)))) -- (just in case you're interested) -} {- Hugs session for: /usr/local/share/hugs/lib/Prelude.hs /usr/local/share/hugs/lib/Char.hs /usr/local/share/hugs/lib/Monad.hs /usr/local/share/hugs/lib/hugs/ParseLib.hs a.hs Type :? for help Main> papply listterm "1:2:3:[]" Segmentation fault -}

1 0

Next Hugs release?
by Alastair Reid 03 Jun '02

03 Jun '02

Fellow Hugs Hackers, When do we think the next Hugs release will be? We've accumulated a bunch of small but useful bugfixes (mostly due to Sigbjorn I think), I see some moves towards the new hierarchial libraries and (partly in support of that), I hope to have the full/current ffi spec implemented soon (I got started on it but got distracted by family stuff). It seems like this would be worth formally releasing. IIRC, the preferred time for a release is about a month before classes start up again in the US - or late July/ early August. Does this feel like a date we can realistically push for (i.e., finish current projects and get enough people to play with a prerelease that we find any major showstoppers)? -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

3 2

RE: Here goes nothing..
by Simon Marlow 03 Jun '02

03 Jun '02

> "C.Reinke" <C.Reinke(a)ukc.ac.uk> writes: > > > > > Thanks for reporting this; now fixed. > > > > > > --sigbjorn > > > > Thanks for fixing; > > as usual, I'm impressed by this efficiency!-) > > > > fyi, the fix implements what the Report prescribes, but I > don't agree with it -- getLine ought not raise an exception > on EOF when having read in a partial line. As is, you will lose > input if it isn't terminated by a newline. Not too cool. FWIW, GHC implements the "sensible" semantics for getLine, i.e. it returns the partial line first, then raises EOF if getLine is called again. I guess I didn't read the report carefully enough :-) Cheers, Simon

1 0

WARNING. You tried to send a potential virus or unauthorised code
by alert＠notification.messagelabs.com 03 Jun '02

03 Jun '02

The MessageLabs SkyScan Anti-Virus service discovered a possible virus or unauthorised code (such as a joke program or trojan) in an email sent by you. The email has now been quarantined and was not delivered. Please read the whole of this email carefully. It explains what has happened to your email, which suspected virus has been caught and what to do if you need help addressing the problem. To help identify the quarantined email: The message sender was mail(a)fur-alle.com hugs-bugs(a)haskell.org The message recipients were beckyr(a)risoftsystems.com The message title was Celebrities The message date was (empty) The virus or unauthorised code identified in the email is ##==>>>> VIRUS POSSIBLE IN FILE: "./718166_2MAUDIO-X-WAV_CTGallery.pif" ##==>>>> VIRUS ID: CVDL W32/Klez-G ##==>>>> Number of files read: 2 ##==>>>> Number of possible virus infections: 1 Some viruses forge the sender address. For more information please visit the link to the virus FAQ's at the bottom of this page. The message was diverted into the virus holding pen on mail server server-2.tower-15.messagelabs.com (pen id 718166_1023101480) and will be held for 30 days before being destroyed Corporate Users: If you sent the email from a corporate network, you should first contact your local IT Helpdesk or System Administrator for advice. They will be able to help you disinfect your workstation. If you would like further information on how to subscribe to MessageLabs SkyScan AV service, a proactive anti-virus service working around the clock, around the globe, please complete our enquiry form. Personal or Home users: If you sent the email from a personal or home account, you will need to disinfect your computer yourself. Please contact your anti-virus software vendor for support. You may like to read the virus FAQ's at: http://www.messagelabs.com/page.asp?id=628 which will answer most virus related questions. ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________

1 0

asin returns nan.0
by Adrian Kubala 31 May '02

31 May '02

Here's the relevant code: areaPgram a b c = (fst b * snd c) - (snd b * fst c) + (fst a * snd b) - (snd a * fst b) + (snd a * fst c) - (fst a * snd c) norm ((x1, y1), (x2, y2)) = sqrt ((x1 - x2)^2 + (y1 - y2)^2) angle a b c = asin (areaPgram a b c / (norm (b, a) * norm (b, c))) ... Main> angle (1,0) (0,1) (1,2) nan.0 The problem appears to be in the "norm". Other test cases I could think of to try worked fine... I'm mystified. How can I work around this??? -Adrian

3 3

Re: Here goes nothing..
by C.Reinke 30 May '02

30 May '02

> This problem is with runhugs not Hugs, right? Makes no difference, really. For instance, I sometimes "script" Hugs by piping commands and input into it (very useful to get all that browsing/info support from within your favorite editor, without having to extend/dll-convert/re-distribute hugs server;-): > $ cat > /tmp/foo.hs > main = getLine >>= print > $ echo "main" | hugs /tmp/foo.hs $ echo ":browse" | hugs /tmp/foo.hs $ echo 'print "hello world!"' | hugs Which reminds me: would it be difficult to separate hugs into a dll and an executable which just calls (renamed) main in the dll? Vim permits calling functions in dlls. Or is there any portable way to send Hugs into the background and have access to its stdin and stdout (the obvious named pipes won't work in windows, afaik)? Claus

2 1

Re: Here goes nothing..
by C.Reinke 30 May '02

30 May '02

> fyi, the fix implements what the Report prescribes, but I > don't agree with it -- getLine ought not raise an exception > on EOF when having read in a partial line. As is, you will lose > input if it isn't terminated by a newline. Not too cool. Oops. I didn't notice that. In fact, I'm tempted to see that as an oversight in the example implementation in the Prelude, which uses getChar without catching exceptions. But you're right, the Prelude given in the Report functions as a spec, so the current Report requires this odd behaviour. Not cool indeed. > > Btw, is there a way to indicate end-of-input in Hugs? > > Yes, you can (by being EOT-savvy): > > getLine :: IO [Char] .. > Whether or not this should be done by Prelude-provided functions > like 'getLine', 'interact' and 'getContents' is worth giving some thought. > There is a risk of introducing breakage though, as binary data read > in via stdin will then be interpreted in unintended ways. Wouldn't it be better to have the Hugs prompt (or readline?) translate into EOF, instead of making getLine and friends EOT-aware? That would also avoid the breakage. Or would that need a separate thread for the evaluator? Why does EOF arrive as EOT in the first place (the Hugs main loop itself exits on CTRL-D under unix, but not under windows, so there is some OS-dependency leaking in)? How do the shells make it work properly (even cygwin's bash under windows)? Sadly, it's been a long time since I looked into this kind of things.. Claus

1 0

Your message to Hugs-Users awaits moderator approval
by hugs-users-admin＠haskell.org 30 May '02

30 May '02

Your mail to 'Hugs-Users' with the subject Cellpadding Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 135391 bytes but there's a limit of 40 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision.

1 0

Re: Here goes nothing..
by C.Reinke 30 May '02

30 May '02

> Thanks for reporting this; now fixed. > > --sigbjorn Thanks for fixing; as usual, I'm impressed by this efficiency!-) Btw, is there a way to indicate end-of-input in Hugs? In typical shells, that would be CTRL-D, and makes things like the "cat >script" work at the prompt (and it doesn't end the shell if there is a nested process waiting for input). Claus

2 1

A Bug in Time?
by Dominic Steinitz 30 May '02

30 May '02

Hugs has a bug in Time. I would expect toUTCTime and toCalendarTime to be inverses of toClockTime (modulo the IO monad). toCalendarTime :: ClockTime -> IO CalendarTime toUTCTime :: ClockTime -> CalendarTime toClockTime :: CalendarTime -> ClockTime module Main(main) where import Time main = putStrLn "Hello" test :: Integer -> IO () test x = (toCalendarTime . toClockTime . f $ x) >>= putStrLn . show f x = CalendarTime{ctYear=2002, ctMonth=May, ctDay=30, ctHour=10, ctMin=27, ctSec=11, ctPicosec=x, ctWDay=Thursday, ctYDay=149, ctTZName="BST", ctTZ=3600, ctIsDST=True} GHC gives: Main> test 1 CalendarTime{ctYear=2002,ctMonth=May,ctDay=30,ctHour=10,ctMin=27,ctSec=11,ct Picose c=1,ctWDay=Thursday,ctYDay=149,ctTZName="BST",ctTZ=3600,ctIsDST=True} Main> test 2 CalendarTime{ctYear=2002,ctMonth=May,ctDay=30,ctHour=10,ctMin=27,ctSec=11,ct Picose c=2,ctWDay=Thursday,ctYDay=149,ctTZName="BST",ctTZ=3600,ctIsDST=True} Hugs gives Main> test 1 CalendarTime{ctYear=2002,ctMonth=May,ctDay=30,ctHour=10,ctMin=27,ctSec=11,ct Picose c=0,ctWDay=Thursday,ctYDay=149,ctTZName="BST",ctTZ=3600,ctIsDST=True} Main> test 2 CalendarTime{ctYear=2002,ctMonth=May,ctDay=30,ctHour=10,ctMin=27,ctSec=11,ct Picose c=0,ctWDay=Thursday,ctYDay=149,ctTZName="BST",ctTZ=3600,ctIsDST=True} Dominic Steinitz

1 0