March 2003 - Hugs-Users

import chasing in hugs vs. runhugs
by Gregory Wright 29 Mar '03

29 Mar '03

Hi, I've written a port file for hugs under Mac OS X using the darwinports infrastructure. The port seems to work fine. I'm adding an option to automatically load the School of Expression graphics files, and while testing I noticed something I don't understand. I'd like to know if it's a bug, or which manual page I should RTF. I've modified the SOE graphics build so it builds under OS X with no trouble, using Apple's X11. When I run the suggested tests using runhugs, some work OK, but others fail: bash> runhugs -Pgraphics-2.0.4/lib/x11: graphics-2.0.4/test/Tests.hs runhugs: compileExpr: invalid module The only modules that Tests.hs imports are GraphicsUtils (found in the -P path) and Exception. In this case, the Exception module isn't found. What's odd is that if I run the same thing interactively, hugs -Pgraphics-2.0.4/lib/x11: graphics-2.0.4/test/Tests.hs all of the modules are found successfully and I can run the tests. If this is a known problem I can just annotate the port with a warning. Thanks for your help. Best Wishes, Greg Wright

1 0

hi
by mariah carrey 28 Mar '03

28 Mar '03

1 0

Is it bug?
by Serguey Zefirov 23 Mar '03

23 Mar '03

Hello hugs-bugs-request, Sunday, March 23, 2003, 4:25:54 AM, you wrote: The following program: ------------------------------------ module StringSolver( fixedp, freep, connstr, solvestrings ) where -- start end length needed data ConnStr = ConnStr Int Int Double type V3 = (Double,Double,Double) data Point = FixedP V3 -- point that cannot move | FreeP V3 -- point that we compute. deriving Show connstr = ConnStr fixedp = FixedP freep = FreeP step = 0.01 deltasq = d*d where d = step verysmall = 0.000000000000001 sub3v (x,y,z) (x',y',z') = (x-x',y-y',z-z') add3v (x,y,z) (x',y',z') = (x+x',y+y',z+z') mul3vsc (x,y,z) sc = (x*sc,y*sc,z*sc) inprod (x,y,z) (x',y',z') = x*x'+y*y'+z*z' distsq a b = let d=sub3v a b in inprod d d dist a b = sqrt $ distsq a b lenv3 = dist (0,0,0) normv3 a = let d = lenv3 a n = 1/sqrt(d) in if d<verysmall then a else mul3vsc a n normv3step a = mul3vsc (normv3 a) (2*step) -- We simply calculate force vectors, normalize them -- into step length and then just add computed displacement. -- if for all points offset is less than delta we stop -- and return given points. otherwise we proceed further. solvestrings points strings = let (points',forces,deltas) = displace points strings dists = map lenv3 deltas smalldists = map (<=deltasq) dists close = and smalldists in (points,points',forces,smalldists): if close then [] else solvestrings points' strings displace points strings = let sforces = stringforces strings points deltas = force points 0 sforces in (zipWith disppoint points deltas,sforces,deltas) disppoint p@(FixedP c) delta = p disppoint (FreeP c) delta = FreeP (add3v c delta) pointtov3 (FixedP c) = c pointtov3 (FreeP c) = c stringforces [] _ = [] stringforces ((ConnStr start end needlen):ss) points = let sp = pointtov3 $ points !! start ep = pointtov3 $ points !! end len = dist sp ep -- force vector is from start point to end point v = sub3v ep sp vlen = lenv3 v normmul = (vlen-needlen)/needlen force = mul3vsc (normv3step v) normmul in (start,end,force):stringforces ss points force [] _ _ = [] force (p:ps) n sforces = let forces [] = [] forces ((start,end,v):sfs) | start==n = v:forces sfs | end==n = (mul3vsc v (-1)):forces sfs | otherwise = forces sfs f = foldl add3v (0,0,0) (forces sforces) in f:force ps (n+1) sforces a = 10.0 tpoints = [ fixedp (a,0,0), fixedp (0,a,0), fixedp (-a,0,0), fixedp (0,-a,0), freep (a,a,1) ] tstrlen = a*sqrt 2 tstrings = [ connstr 0 1 tstrlen, connstr 1 2 tstrlen, connstr 2 3 tstrlen, connstr 3 0 tstrlen, connstr 0 4 tstrlen, connstr 1 4 tstrlen, connstr 2 4 tstrlen, connstr 3 4 tstrlen ] test = ptest $ solvestrings tpoints tstrings ptest [] = return () ptest (p:ps) = do putStrLn $ show p ptest ps ------------------------------------ gives "Garbage collection fails to reclaim sufficient space." when loaded into Hugs Nov 2002 and asked to run "test". I think it shouldn't do that. -- Best regards, Serguey thesz na mail tochka ru (na == at, tochka == dot)

2 1

RE: Problem with hierarchical libraries in Hugs compared to ghc/nhc98
by Simon Marlow 22 Mar '03

22 Mar '03

> Actually, Simon understood me perfectly. I don't see any value in the > dotted version. There's two uses of dots in filenames: > > 1) As just another character - like including a ', @, $ or whatever in > a filename. > > I'd disallow all of these since they're not legal Haskell module > names so they don't fit into the hierarchical naming scheme. > > 2) Part of either . (current directory) or .. (parent directory). > > I'd disallow these because they aren't needed now we have > hierarchical libraries. I don't quite follow you. The issue as I see it is whether a module A.B.C can be placed in a file A.B.C.hs, or whether it has to be named A/B/C.hs (substitute / for the local directory separator). IIRC some people wanted to be able to do this - I suppose it might be useful to avoid deep/sparse directory structures. > Note that the ghc-users discussion would have a quite different > semantics from what Hugs has. Hugs semantics is to simultaneously > try to interpret filenames two ways: first relative to the current > directory, and second relative to the search path. How is that different from adding the current directory to the search path? (which is what GHC does by default). > The proposed > semantics is to either treat it as relative to the current > directory if it contains a leading dot or to treat it as relative > to the search path otherwise. by "current directory" you mean "directory in which the current module resides?" (i.e. not the same as the meaning of "."). Cheers, Simon

4 4

irg.ssu.ac.kr
by Jane Brooks 13 Mar '03

13 Mar '03

Hi, I thought you might be interested in getting in-depth knowledge about your web audience and web traffic patterns in a reliable and cost-effective way. Stop Guessing - Start Knowing! - CoolStats measures web site traffic and online behavior of your visitors. - CoolStats will help you understand how to optimize your site to meet the needs of your visitors. - You get access to detailed, real-time statistical analysis of your web pages - 24 hours a day. Click at http://www.coolstats.com/viewdemo/index.html to view Online Demo. - CoolStats is the ultimate real-time tracking solution for small and mid-sized businesses. - 100% accuracy by measuring activity at the client, not via server based log files. - The fee of $19.95 is minimal compared to what it would cost you to run a tracking service yourself! Why CoolStats? - no programming to do - no servers to maintain - no software applications to install Special Offer! Now Only $19.95/month (Usual Price/$29.95). Click at http://p1j2m3a4.pdhost.com/pdsvr/www/r?1000014621.1726.15.uR2RMI3eEJVzj9 to Sign Up now! "We needed to make business sense out of our web visitor behavior - CoolStats delivers first-class graphical reports that help us continuously improve and optimize our website to match the requirements of our target audience." BRYAN KASHILIN, BOSTON Click at http://www.coolstats.com/product/customerref.html to check what other customers say about us! For more information about our website tracking services, please visit our website or contact me directly at the below email. I look forward to hearing from you soon. Best regards, Jane Brooks CoolStats Support Email: jane_brooks(a)coolstats.com http://www.coolstats.com Don't be the last one to know! ----------------------------------------------------------------------- This message has been brought to hugs-users(a)haskell.org. If you do not wish to receive anymore emails, please follow the opt-out instruction below. We apologize for any inconvenience. http://p1j2m3a4.pdhost.com/pdsvr/www/r?1000014621.1726.3.e+ahYXPM0USZr8

1 0

RE: Problem with hierarchical libraries in Hugs compared to ghc/nhc98
by Simon Marlow 13 Mar '03

13 Mar '03

> Better yet, drop the support for interpreting the '.' as anything but > a hierarchial module namespace separator. That is, use this: > > > [ d ++ mod2dir nm ++ e | d <- dirs, e <- hugsSuffixes ] > > The last release rightly supported both old and new style names. > We're already committed to dropping the non-hierarchial libraries > in future releases. Let's drop non-hierarchial names too. I'm curious why you want to do that: in recent discussions on glasgow-haskell-users one or two people spoke up in favour of allowing the dotted version, and I was seriously considering adding it to GHC. I can't remember all the reasons off the top of my head though. Cheers, Simon

3 2

Problem with hierarchical libraries in Hugs compared to ghc/nhc98
by Olaf Chitil 12 Mar '03

12 Mar '03

When trying to make our Haskell tracer Hat work with Hugs (November 2002) I noticed that * Hugs' implementation of hierarchical libraries differs from those of ghc and nhc98, and * Hugs' implementation choice makes it more restrictive than ghc/nhc98 A simple example: There is module B in file B.hs There is module Test.B in file Test/B.hs There is module Test.A in file Test/A.hs Module Test.A contains "import B". When compiling module Test.A both nhc98 and ghc imports module B from file B.hs. In contrast, Hugs imports module Test.B from file Test/B.hs and then stops with an error, because the module name is wrong. The simple reason why Hugs behaves so is that when searching a module it *always* searches the current directory (* where the import was demanded *) first. Only afterwards the paths set with the -P option are searched. I know that we generally try to avoid specifying filename and directory issues. However, this is not really a filename issue, but a problem of relative and absolute module names (wrt possibly several hierarchies). An "import B" in module Test.A could mean either module B or module Test.B. I suggest that the absolute module name takes precedence, because otherwise there is no way to import module B from module Test.A, whereas you can always import module Test.B from module Test.A by saying "import Test.B". I admit that this has the slight disadvantage that moving a set of modules into the hierarchical library will require not only changing all module names at the top but also in every import declaration, to not inadvertedly import the wrong module. So in the end this suggests that we should not allow relative module names at all. Note that this proposal still allows the current directory (of Hugs or in which the compiler was started) to be the root of the hierarchy that is searched first. In fact, this is probably the desirable default behaviour. Currently the hierarchical library proposal http://www.haskell.org/~simonmar/libraries/libraries.html does not say much about the semantics of the hierarchical module names. It really should. I'd very much like to hear other people's opinion on this (especially the Hugs maintainers'). The current behaviour of Hugs makes it impossible for Hat to work with Hugs. Hat creates a shadow hierarchy of transformed libraries: the transformed variant of Prelude is Hat.Prelude, the transformed variant of Control.Arrow is Hat.Control.Arrow etc. Nearly all of the transformed modules import both Prelude and Hat.Prelude ... Olaf -- OLAF CHITIL, Dept. of Computer Science, The University of York, York YO10 5DD, UK. URL: http://www.cs.york.ac.uk/~olaf/ Tel: +44 1904 434756; Fax: +44 1904 432767

3 7

Kontakt Lenste yeni yil firsati 1 Kutu Lens 35 Milyon USTELIK ADRESE TESLIM KACIRMAYIN_______6357474__
by hugs-users 09 Mar '03

09 Mar '03

En ucuz lensler icin lutfen tiklayin. Bir telefonla adrese teslim. http://www.akdenizgoz.com Akdeniz Goz Merkezi Fevzipaþa No:73 Fatih 0 212 635 74 74 Listeden cikmak icin remove(a)akdenizgoz.com adresine bos mail gonderiniz

1 0

RE: Problem with hierarchical libraries in Hugs compared to ghc/nhc98
by Simon Marlow 07 Mar '03

07 Mar '03

> Currently the hierarchical library proposal > http://www.haskell.org/~simonmar/libraries/libraries.html > does not say much about the semantics of the hierarchical > module names. > It really should. I'm open to suggestions - in fact I thought the semantics were fairly clear, but perhaps not? Or do you mean that the document should say more about file names and searching policies? (that would be difficult without getting compiler-specific). Cheers, Simon

1 0

Re: Parsec: GHC /= Hugs?
by Ross Paterson 06 Mar '03

06 Mar '03

[moving from haskell to hugs-users] On Wed, Mar 05, 2003 at 02:31:35PM +0100, Markus.Schnell(a)infineon.com wrote: > > Try the November release of Hugs with the +N option. > > Well, now Hugs and ghc show the same behaviour for my program: > they don't parse my doc, even with the same error. You did ask for compatibility :-) Johannes Waldmann's suggestion may be relevant: : "brackets is now called angles, while squares is now called brackets." : see http://www.cs.uu.nl/~daan/parsec.html > But the +N does not work: it says > "New hierarchical libraries not found along search path; ignoring +N > toggle." I'm guessing that you're explicitly overriding the -P parameter. The trick here is to say ";newdir", so it adds your new directory to the standard ones (which are different between -N and +N). (I think -- I don't know about the Windows interface.) You want the search path to be something like {Hugs}\libraries;{Hugs}\oldlib;{Hugs}\lib\win32 with any other directories added on the end.

4 4