Re: [GHC] #4510: No links will be generated to these packages:base-4.3.0.0

[Claus Reinke]

#4510: No  links will be generated to these packages: base-4.3.0.0
-+--
   Reporter:  claus |Owner:  igloo
   Type:  bug   |   Status:  infoneeded
   Priority:  high  |Milestone:  7.2.1
  Component:  Compiler  |  Version:  7.0.1
   Keywords:| Testcase:
  Blockedby:|   Difficulty:
 Os:  Windows   | Blocking:
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--


Hi,

I can't reach trac at the moment (first database lock error,
then no response to login), so replying here.


Comment:

Claus, having fixed your installation, are you still able to reproduce
this?


Who says I have?-) Sadly, I still can't afford to spend time
on my Haskell interests, so I had to wait this one out. There
were some other doc-related problems with interim ghc
releases, so I didn't try again.

However, I've tried the following just now:

1. installed Haskell Platform 2011.2.0.0 and looked at the
   docs:

   Does not look good at all, all the extralibs docs seem
   missing (including mtl, apparently our testcase for this
   ticket) - apparently, they also have problems with the
   docs, but have either not noticed or not reported them?

2. installed ghc-7.0.3. Apart from the newest ghc release,
   this also gives me a current haddock (version 2.9.2),
   and I am using the new cabal-install (0.10.2/1.10.1.0)
   from the HP installation instead of the old one that
   broke my installation.

   Ran our testcase (cabal install mtl), and that looked
   much better (links to ffi-1.0, rts-1.0 missing, but that
   is standard, iirc).

I suggest cross-checking with the HP guys, especially the
windows release builder (they are working on an update
for ghc 7.0.3 anyway).

Docs tend to be the first thing to break when anything
gets reorganized (and that tends to happen whenever
nothing urgent needs fixing;-) - it would make sense
to have a few minimum tests on the ghc side (in
addition to the test suite that the HP still doesn't have):

   - no broken links in installer result
   - installing a cabal package like mtl with docs on top
   of ghc installer should work (no errors, correct
   location in ghc-pkg database, no missing links)

Once that is in place, this ticket could be closed (can't
test more thoroughly atm - sorry).

Claus



___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2602: Haddock not installed properly

[Claus Reinke]

haddock also does not seem to generate cross-package references
correctly; some of them it warns about (second example below), some
it just inserts wrongly, using $httptopdir/doc/libraries/ (first example below).

Claus

-- after installing haddocked syb-utils:
$ grep -A2 IntSet /cygdrive/c/Program\ 
Files/Haskell/doc/syb-utils-0.0.2008.9.22/html/Data-Generics
-GPS.html
build IntSets of TypeRep keys, both for the domains of traversals and
for substructure types; then several short-circuiting decisions can be
based on fast intersection tests with the same IntSet).


--

keys combined with IntSets or IntMaps can be used to speed up

other generic programming problems as well, including typecase and
extensible records libraries.
--

= 
--

= 

In the output below, note that haddock is supplied with

   
--read-interface=$httptopdir/doc/libraries/syb,C:\ghc\ghc-6.11.20080925/doc/libraries/syb\syb.haddock

but still can't find Data.Generics.Basics in syb, and always seems to use
the $httptopdir/doc/libraries/ for crosslinks.

$ runhaskell Setup.hs haddock --verbose
Creating dist\build\tmp (and its parents)
Creating dist\doc\html\syb-utils (and its parents)
Preprocessing library syb-utils-0.0.2008.9.22...
Running Haddock for syb-utils-0.0.2008.9.22...
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: rts-1.0
C:\ghc\ghc-6.11.20080925\bin\haddock.exe --ghc-version
C:\ghc\ghc-6.11.20080925\bin\ghc.exe --print-libdir
Creating dist\build (and its parents)
Creating dist\build\autogen (and its parents)
Preprocessing library syb-utils-0.0.2008.9.22...
C:\ghc\ghc-6.11.20080925\bin\haddock.exe --html --odir=dist\doc\html\syb-utils 
--title=syb-utils-0.0
.2008.9.22: Modifications and Additions to Data.Generics/Syb 
--dump-interface=dist\doc\html\syb-util
s\syb-utils.haddock 
--prologue=dist\syb-utils-0.0.2008.9.22-haddock-prolog3380.txt --optghc=-package
-name --optghc=syb-utils-0.0.2008.9.22 
--read-interface=$httptopdir/doc/libraries/Cabal,C:\ghc\ghc-6
.11.20080925/doc/libraries/Cabal\Cabal.haddock 
--read-interface=$httptopdir/doc/libraries/Win32,C:\g
hc\ghc-6.11.20080925/doc/libraries/Win32\Win32.haddock 
--read-interface=$httptopdir/doc/libraries/ar
ray,C:\ghc\ghc-6.11.20080925/doc/libraries/array\array.haddock 
--read-interface=$httptopdir/doc/libr
aries/base,C:\ghc\ghc-6.11.20080925/doc/libraries/base\base.haddock 
--read-interface=$httptopdir/doc
/libraries/bytestring,C:\ghc\ghc-6.11.20080925/doc/libraries/bytestring\bytestring.haddock
 --read-in
terface=$httptopdir/doc/libraries/containers,C:\ghc\ghc-6.11.20080925/doc/libraries/containers\conta
iners.haddock 
--read-interface=$httptopdir/doc/libraries/directory,C:\ghc\ghc-6.11.20080925/doc/libr
aries/directory\directory.haddock 
--read-interface=$httptopdir/doc/libraries/filepath,C:\ghc\ghc-6.1
1.20080925/doc/libraries/filepath\filepath.haddock 
--read-interface=$httptopdir/doc/libraries/ghc,C:
\ghc\ghc-6.11.20080925/doc/libraries/ghc\ghc.haddock 
--read-interface=$httptopdir/doc/libraries/ghc-
prim,C:\ghc\ghc-6.11.20080925/doc/libraries/ghc-prim\ghc-prim.haddock 
--read-interface=$httptopdir/d
oc/libraries/haskell98,C:\ghc\ghc-6.11.20080925/doc/libraries/haskell98\haskell98.haddock
 --read-int
erface=$httptopdir/doc/libraries/hpc,C:\ghc\ghc-6.11.20080925/doc/libraries/hpc\hpc.haddock
 --read-i
nterface=$httptopdir/doc/libraries/integer,C:\ghc\ghc-6.11.20080925/doc/libraries/integer\integer.ha
ddock 
--read-interface=$httptopdir/doc/libraries/old-locale,C:\ghc\ghc-6.11.20080925/doc/libraries/o
ld-locale\old-locale.haddock 
--read-interface=$httptopdir/doc/libraries/old-time,C:\ghc\ghc-6.11.200
80925/doc/libraries/old-time\old-time.haddock 
--read-interface=$httptopdir/doc/libraries/packedstrin
g,C:\ghc\ghc-6.11.20080925/doc/libraries/packedstring\packedstring.haddock 
--read-interface=$httptop
dir/doc/libraries/pretty,C:\ghc\ghc-6.11.20080925/doc/libraries/pretty\pretty.haddock
 --read-interfa
ce=$httptopdir/doc/libraries/process,C:\ghc\ghc-6.11.20080925/doc/libraries/process\process.haddock
--read-interface=$httptopdir/doc/libraries/random,C:\ghc\ghc-6.11.20080925/doc/libraries/random\rand
om.haddock 
--read-interface=$httptopdir/doc/libraries/syb,C:\ghc\ghc-6.11.20080925/doc/libraries/syb
\syb.haddock 
--read-interface=$httptopdir/doc/libraries/template-haskell,C:\ghc\ghc-6.11.20080925/do
c/libraries/template-haskell\template-haskell.haddock 
-BC:\ghc\ghc-6.11.20080925 --optghc=-hide-all-
packages --optghc=-package --optghc=base-4.0.0.0 --optghc=-package 
--optghc=containers-0.2.0.0 --opt
ghc=-package --optghc=ghc-6.11.20080925 --optghc=-package --optghc=syb-0.1.0.0 
--optghc=-i --optghc=
-i. --optghc=-idist\build\autogen --optghc=-idist\build --optghc=-optP-include 
--optghc=-optPdist\bu
ild\autogen\cabal_macros.h --optghc=-odir --optghc=dist\build --optghc=-hidir 
--optghc=dist\build --
optghc=-XExistentialQuantification --optghc=-XRankNTypes 
--optghc=-XScopedTypeVariables --optghc=-XD
eriv

Re: [GHC] #2602: Haddock not installed properly

[Claus Reinke]

[using email instead of haddock trac, which still doesn't send notifications]

The haddock package still has the wrong paths, though:

   $ /cygdrive/c/ghc/ghc-6.11.20080925/bin/ghc-pkg describe haddock | grep ghc
   import-dirs: d:/fptools/ghc/ghc-6.11.20080925\haddock-2.2.2
   library-dirs: d:/fptools/ghc/ghc-6.11.20080925\haddock-2.2.2
   extra-ghci-libraries:
directory-1.0.0.2 filepath-1.1.0.1 ghc-6.11.20080925
   haddock-html: d:/fptools/ghc/ghc-6.11.20080925/doc

(pointing to build, rather than install directories)

Claus

- Original Message - 
From: "GHC" <[EMAIL PROTECTED]>

Cc: 
Sent: Thursday, September 25, 2008 12:41 PM
Subject: Re: [GHC] #2602: Haddock not installed properly



#2602: Haddock not installed properly
--+-
Reporter:  NeilMitchell  |  Owner: 
Type:  bug   | Status:  closed 
Priority:  normal|  Milestone: 
Component:  Compiler  |Version:  6.9
Severity:  normal| Resolution:  fixed  
Keywords:| Difficulty:  Unknown

Testcase:|   Architecture:  Unknown
  Os:  Unknown   |  
--+-

Changes (by igloo):

 * status:  new => closed
 * difficulty:  => Unknown
 * resolution:  => fixed

Comment:

Thanks for the report; now fixed.

--
Ticket URL: 
GHC 
The Glasgow Haskell Compiler







___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2305: GHC does not care __RENAME macro

[Claus Reinke]

I've augmented the Using-the-FFI page too.  I hope I got it right.

http://haskell.org/haskellwiki/GHC/Using_the_FFI#Importing_C_functions_that_turn_out_to_be_CPP_macros


hmm. and what if the CPP/C status of a function fluctuates
(different OS/library versions/..)? does the simple binding
then become an exorcise is autoconf? mingw, e.g., has had
a habit of being different there at times.

CPP is part of C (well, it was a long time ago, at least),
and those wrappers look like something that could and
should be automated, like other wrappers in the FFI.

perhaps ghc feeding those foreign imports to gcc, when
in doubt, and linking in the result?

claus


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

ghci ':browse *' does not list items in source order

[Claus Reinke]

[trac seems unreachable at the moment, hence good old email]

while trying to write a test for an extension of :browse, i encountered
an issue with the existing functionality: the order of names is not stable,
making it difficult to write meaningful tests for :browse. 


a reduced test case & output are appended below, showing that
output order is affected by prior usage, in both 6.6.1 and HEAD.

i would prefer for the items to appear in source order, but at the
point :browse gets a hand on them, source location information
might not be available; sorting by Name would be random due to
uniqueIds, and lexicographic sorting would be confusing to users
(spreading related items all over the alphabet, instead of keeping
the order in which they appear in source and documentation). 


is there a way to keep the items in source order, within each
module (modules themselves could be sorted lexicographically)?

claus

--- testing :browse
$ cat y.hs
import Prelude()
import Data.Maybe(catMaybes,mapMaybe)

$ cat .ghci
:t Data.Maybe.mapMaybe

$ ghcii.sh --version
The Glorious Glasgow Haskell Compilation System, version 6.6.1

$ /cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace --interactive --version
The Glorious Glasgow Haskell Compilation System, version 6.9.20071019

$ (echo :l y.hs;echo :browse '*Main') | ghcii.sh -v0
Data.Maybe.mapMaybe :: (a -> Maybe b) -> [a] -> [b]
mapMaybe :: (a -> Data.Maybe.Maybe b) -> [a] -> [b]
catMaybes :: [Data.Maybe.Maybe a] -> [a]

$ (echo :l y.hs;echo :browse '*Main') | ghcii.sh -v0 -ignore-dot-ghci
catMaybes :: [Data.Maybe.Maybe a] -> [a]
mapMaybe :: (a -> Data.Maybe.Maybe b) -> [a] -> [b]

$ (echo :l y.hs;echo :browse '*Main') | 
/cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace --inter
active  -v0
Data.Maybe.mapMaybe :: (a -> Maybe b) -> [a] -> [b]
mapMaybe :: (a -> Data.Maybe.Maybe b) -> [a] -> [b]
catMaybes :: [Data.Maybe.Maybe a] -> [a]

$ (echo :l y.hs;echo :browse '*Main') | 
/cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace --inter
active  -v0 -ignore-dot-ghci
catMaybes :: [Data.Maybe.Maybe a] -> [a]
mapMaybe :: (a -> Data.Maybe.Maybe b) -> [a] -> [b]


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

curiosity, bug, or just dead code?

[Claus Reinke]

consider this module, which is accepted by ghci-6.6.1:

   module T where
   import qualified Prelude as T(length)
   import Prelude(length)
   length = 0

there is no way to refer to either length, as both 'length' 
and 'T.length' are ambiguous (ghci complains on uses 
of either name). but is it a bug?


then again, everything is implicitly exported, and there are 
two possible 'T.length'.. (hugs [20051031] complains 
about conflicting exports, on loading T).


now for the good part:

   module Q where
   import T
   main = print T.length

loads fine, and running main returns 0.

   Ok, modules loaded: Q, T.
   *Q> main
   0

so this must be a bug, right? or a matter of interpretation?

not everything is exported implicitly: imported items, whether 
unqualified or qualified and renamed to share the current 
module as qualifier are not exported by default. and changing 


   module T where

to 


   module T(module T) where

leads to conflicting export errors on load in ghci.

currently, i think ghci is right, and hugs is wrong (note that
my hugs is rather old, though), but it wasn't what i expected.

claus


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

bug in :browse (Re: ghci :browse! and type of class methods ([GHC] #1617))

[Claus Reinke]

more trouble with class method types: as a workaround for :browse!, 
i'm using GHC.exprType, even though that is a rather roundabout way

of getting a type for a name. is there really no way of just printing the
TyThing for a class method id correctly?

note that things are going wrong in this area even without my patch.
consider this module
--
{-# OPTIONS_GHC -fglasgow-exts #-}
module Main where
class C a b where
 c1 :: Num b => a -> b
 c2 :: (Num b,Show b) => a -> b
 c3 :: forall a. a -> b
--

and this ghci-6.6.1 session for it:

   *Main> :b Main
   class C a b where
 c1 :: (Num b) => a -> b
 c2 :: (Num b, Show b) => a -> b
 c3 :: a -> b

   *Main> :t c3
   c3 :: (C a b) => a1 -> b

   *Main> :set -fglasgow-exts
   *Main> :b Main
   class C a b where
 c1 :: (Num b) => a -> b
 c2 :: (Num b, Show b) => a -> b
 c3 :: forall a. a -> b

apparently, the printing of C uses dropForAlls on c3, without
considering scope issues, so the output of that first browse is
simply wrong. also, i wonder how the ghci-session can be in
*Main without having -fglasgow-exts set? these issues are still
with us in today's head.

claus


| class C a where c :: (Num b) => a -> b
| c :: C a -> forall b. (Num b) => a -> b

I think the right thing here is to change Type.dropForAlls, 
so that it drops for-alls nested to the right of arrows.  Then 
you'd get   c :: (C a, Num b) => a -> b


yes, that makes sense. but i'm wary of those type-manipulating
functions, as they only operate on the structure of the types,
not seeming to look at scopes. what if the inner forall shadows
a type variable binding from the outer forall? or, if i want to
lift the inner forall outwards, what if the inner forall captures
a type variable in the context? do i really have to do all this
myself, just to print out the type associated with a name?


| class C a where c :: forall b. (Num b) => a -> b
| c :: forall a. (C a) => forall b. (Num b) => a -> b

This *really is* c's type, so it's only honest to say so.


shouldn't the correct type be something that would be 
valid source code as well?


   c :: forall a, b. (C a, Num b) => a -> b

the type shouldn't distinguish between class methods and
other overloaded functions, should it?

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: ghci :browse! and type of class methods ([GHC] #1617)

[Claus Reinke]

About the it/output thing, I don't know. Can you be more explicit 
about what your question is?


i was worried about using a different method of implementing what
seemed to be the same thing. Simon M cleared up that 'it' is slightly
more complex, due to type dependencies.


Concerning class methods...

| *Main> :b! Control.Monad
| fail :: Monad m -> forall a. String -> m a

I can't explain why this does not print as (Monad m) => ...
I'll try applying your patch when I have a clean build to hand.


thanks, that is my main question about this part. perhaps
i'm just using the wrong printTyThing variant? or there is
a variant missing in the GHC API.


| class C a where c :: (Num b) => a -> b
| c :: C a -> forall b. (Num b) => a -> b

I think the right thing here is to change Type.dropForAlls, 
so that it drops for-alls nested to the right of arrows.  Then 
you'd get   c :: (C a, Num b) => a -> b


yes, that makes sense. but i'm wary of those type-manipulating
functions, as they only operate on the structure of the types,
not seeming to look at scopes. what if the inner forall shadows
a type variable binding from the outer forall? or, if i want to
lift the inner forall outwards, what if the inner forall captures
a type variable in the context? do i really have to do all this
myself, just to print out the type associated with a name?


| class C a where c :: forall b. (Num b) => a -> b
| c :: forall a. (C a) => forall b. (Num b) => a -> b

This *really is* c's type, so it's only honest to say so.


shouldn't the correct type be something that would be 
valid source code as well?


   c :: forall a, b. (C a, Num b) => a -> b

the type shouldn't distinguish between class methods and
other overloaded functions, should it?

(I'm not sure why -fglasgow-exts switches on 
forall-printing; that seems odd.  


i'm only following :browse behaviour (comments say
that foralls are printed when the flags would allow them
to be used in source).

claus

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

ghci :browse! and type of class methods ([GHC] #1617)

[Claus Reinke]

i am trying to address part of #1617 (optionally restoring the old 
:browse, as :browse!, listing class methods and data constructors 
separately, not just in context). in principle, that is straightforward, 
but for the type of class methods - what function prints them correctly?


method types seem to reflect the implementation type (with the 
class dictionary treated separately) rather than the user type (with 
the class predicate being just one part of the context):


   *Main> :set -fglasgow-exts
   *Main> :b Control.Monad-- original
   class Monad m where
 (>>=) :: forall a b. m a -> (a -> m b) -> m b
 (>>) :: forall a b. m a -> m b -> m b
 return :: forall a. a -> m a
 fail :: forall a. String -> m a
   ..
   *Main> :b! Control.Monad-- added variant
   fail :: forall (m :: * -> *). (Monad m) => forall a. String -> m a
   (>>=) ::
 forall (m :: * -> *).
 (Monad m) =>
 forall a b. m a -> (a -> m b) -> m b
   (>>) ::
 forall (m :: * -> *). (Monad m) => forall a b. m a -> m b -> m b
   return :: forall (m :: * -> *). (Monad m) => forall a. a -> m a
   class Monad m where
 (>>=) :: forall a b. m a -> (a -> m b) -> m b
 (>>) :: forall a b. m a -> m b -> m b
 return :: forall a. a -> m a
 fail :: forall a. String -> m a
   ..

this doesn't look too bad, simply using pprTyThing instead of 
pprTyThingInContext, and not filtering out children.


however, things go wrong if i try not to show the foralls, by stripping the
outermost forall. first, there are actually two levels of forall, and second, 
the class appears as a parameter rather than context (i thought printing

was controlled by finding a predicate to the left of a function arrow, but
since Type is not in Show, i can't easily check the actual representation):

   *Main> :b! Control.Monad
   fail :: Monad m -> forall a. String -> m a
   (>>=) :: Monad m -> forall a b. m a -> (a -> m b) -> m b
   (>>) :: Monad m -> forall a b. m a -> m b -> m b
   return :: Monad m -> forall a. a -> m a
   class Monad m where
 (>>=) :: m a -> (a -> m b) -> m b
 (>>) :: m a -> m b -> m b
 return :: a -> m a
 fail :: String -> m a
   ..

also, if the class method has its own context, as in:

   class C a where  c :: Num b => a -> b

we get two levels of context, instead of a single merged context:

   *Main> :b! Main
   class C a where c :: (Num b) => a -> b
   c :: C a -> forall b. (Num b) => a -> b

   *Main> :set -fglasgow-exts

   *Main> :b! Main
   class C a where c :: forall b. (Num b) => a -> b
   c :: forall a. (C a) => forall b. (Num b) => a -> b

is there a proper way of printing those types? to identify class methods,
i can use GHC.isClassOpId_maybe, but then the only options i have
found so far are: use GHC.exprType (awkward), or re-assemble the
foralls and contexts at the front, using the various split type operations 
(awkward and potentially error-prone). there has to be a better way.


my patch history doesn't seem to go that far back, but how was this
handled before :browse started printing things in context only?

claus

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1278: filepath's makeRelative does not work for relativedirectories

[Claus Reinke]

One of the massive complications of a FilePath library is that Windows
has many syntaxes for drives - \?\\share\, \\share\, c:\, \ - etc - in
varying combinations of / and \ slashes with varying combinations of
meaning. Unix on the other hand has only one "drive" specifier, which
is /.


if i recall correctly, the old Apollo Domain/OS had network transparency
support, where files on any node in the local network could be addressed
simply as //nodeXYZ/local/path/here. that was a unix, although running
haskell on it might involve applying the tying-the-knot pattern to real time.

claus

--
the three laws of monadics:
1. A monad may not injure a human being or, through inaction, 
   allow a human being to come to harm. 
2. A monad must obey orders given it by human beings except 
   where such orders would conflict with the First Law. 
3. A monad must protect its own existence as long as such 
   protection does not conflict with the First or Second Law. 


(note how Asimov managed to predict the harmful interactions of
lazyness and monadic i/o, the use of monads for imperative programming,
and the self-preservation instinct of monads as a concept;-)

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: How about change prep-bin-dist-mingw's default enviroment up todate?

[Claus Reinke]

ps there has to be a less ugly way to get the doc path than this, though:
   ghc-pkg field base haddock-html | sed -e 's/^[^:]*: //' -e 
's/$topdir/echo `ghc --print-libdir`/e'


http://hackage.haskell.org/trac/ghc/ticket/937

This fix will be in 6.6.1.


great, thanks! 


that almost makes my suggestion for ghc --print-docdir obsolete.
perhaps the users guide should be a "documentation package", but 
then its html is not haddock-html, so --print-docdir is needed after all.


btw, is there a reason that --simple-output only applies to 'list'?
i had hoped it would apply to 'field', too, giving only the field value
(actually, it does seem to apply beyond 'list' in a recent head, but 
still not to 'field').


claus

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: How about change prep-bin-dist-mingw's default enviroment up todate?

[Claus Reinke]

The nightly builds are moving to BuildBot (in case you hadn't noticed).  We have 4 Windows builds 
in BuildBot: nightly HEAD/6.6 and fast HEAD/6.6.  Currently I'm not building any distributions 
from these builds, but I'd like to.


thanks for the update, Simon. there are many things i get out of the old 
nightly builds:

   1 is the current darcs version buildable on windows, or where does it go 
wrong?
   - this means that patchers can check whether they have broken the windows
   build, and hopefully go on to unbreak it quickly
   - this also means that i do only set out to build GHC from source when 
i'm
   confident that it should build successfully (with a darcs pull on 
the day after
   a successful nightly build)

   2 nightly snapshots, which i can download myself or, more importantly, ask 
others
   (who run into trouble with the official release but don't use darcs) to 
download

   3 a script (right in ghc's darcs repo) to build installer-free snapshots that
   correspond 1-1 to nightly snapshots and releases, replacing the installer
   by a simple bundling of files

the current BuildBot setup seems to cover only 1, so yes, please, reintegrate 
2&3
as well before stopping the old-style nightly builds.

Sigbjorn is running a Windows nightly build using the old nightly build scripts 
(http://darcs.haskell.org/nightly), and building a snapshot distribution which is uploaded to 
haskell.org.  The distribution is built using the prep-bin-dist-mingw script (see the nightly 
scripts).


http://darcs.haskell.org/ghc-nightly/bin/nightly-wrk

ah, thanks. that is the part of your scripts i was missing!-)

that is also the script responsible for the current failures in nightly builds, 
then?

Ian: I think http://hackage.haskell.org/trac/ghc/ticket/1093 might still be wrong, because the the 
prep-bin-dist-mingw script puts the docs in the "doc" subdirectory but doesn't update the 
haddock-html fields.


do i understand correctly that the current oddities are the result of scripts 
fighting
about where to copy things, but that, ideally, i should get the precise 
location of
installed haddocks by concatenating the results of ghc --print-libdir and
ghc-pkg field base haddock-html (after filtering out garbage like $topdir and
haddock-html:)?

claus

ps there has to be a less ugly way to get the doc path than this, though:
   ghc-pkg field base haddock-html | sed -e 's/^[^:]*: //' -e 's/$topdir/echo 
`ghc --print-libdir`/e'



___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: How about change prep-bin-dist-mingw's default enviroment up todate?

[Claus Reinke]

prep-bin-dist-mingw supports to bundle GHC Windows binary distribution
with cc1plus.exe, now.

But prep-bin-dist-mingw assumes that GHC is build by MinGQ version 3,


Does anyone know whether or not this script is still used? It looks like
it contains a number of out-of-date values, and doesn't seem to be
called by the Windows nightly builds. I don't know about the Windows
installer.


Sigbjorn would be the right person to ask, I guess?

as a windows user, i have very much depended on prep-bin-dist-mingw, whenever
i want to convert my inplace GHC into something resembling the snapshots/releases. 
i haven't done that for a while, because i tend to wait for the nightly builds to go 
through without hitches, but i'd certainly miss that feature.


and i thought that whoever intoduced the recent version-in-path changes hasn't 
gotten
around to updating the windows builds, which looked like the reason for the ongoing 
failures in the nightly builds since then:


    building compiler binary distribution... failed.
    canonicalizing mingw binary distribution tree... failed 
(ghc-6.7.20070312 not found).

but if you say it isn't used anymore, what is the current recommended way to
create an installer-free bundle of a working self-compiled GHC on windows,
and why does the distribution stage keep failing?

once upon a time, i suggested to extract the relevant information from the 
configure info, instead of the current hard-coded values/paths, but while it

is fairly easy to get info from GHC's configure

   http://www.haskell.org/pipermail/cvs-ghc/2005-May/025075.html

that idea was somewhat naive - the real problem are the changes in 
directory layout within gcc/mingw et al.


unless one can query gcc about its directory structure (??), the script
keeps having to be adapted by hand for different versions, which means
that someone has to decide that their build environment needs updating,
which isn't likely as long as it works, and that someone has to invest
time into figuring out what changes such an update implies for the script
(and i tend to dread updating my working system whenever someone 
updates the script, because by the time that change reaches me, i might 
update to a version of gcc/mingw with new problems/dependencies..).


but of course, there are new windows GHC users, and those who like
to keep their mingw/gcc uptodate, and that group doesn't like the old
values in the script.. perhaps one could accumulate known mingw/gcc
configurations, and make the script select the appropriate one based
on version info..

claus

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1205: ghci reports functions not in scope after loadinga .hs, if there is a .o present

[Claus Reinke]

it seems one can work around this issue by using -no-recomp (was this option
renamed, to -force-recomp, in newer ghcs?):

   $ ghc -e ":t hello" Main.hs
   hello :: [Char]

   $ ghc --make Main.hs
   Chasing modules from: Main.hs
   Compiling World( ./World.hs, ./World.o )
   Compiling Main ( Main.hs, Main.o )
   Linking ...

   $ ghc -e ":t hello" Main.hs

   :1:0: Not in scope: `hello'

   $ ghc -no-recomp -e ":t hello" Main.hs
   hello :: [Char]

so ghci -no-recomp behaves as one might expect ghci to behave (although this
prevents any use of compiled code in that session..).

claus

- Original Message - 
From: "Lennart Augustsson" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, March 07, 2007 8:01 PM
Subject: Re: [GHC] #1205: ghci reports functions not in scope after loadinga .hs, if there is a .o 
present



Personally, I find it very counter-intuitive that asking for Foo.hs  to be loaded actually loads 
Foo.o.  No matter how documented it is,  it seems odd.



On Mar 7, 2007, at 09:18 , GHC wrote:


#1205: ghci reports functions not in scope after loading a .hs, if  there is a 
.o
present
- 
+--

 Reporter:  guest|  Owner:
 Type:  feature request  | Status:  new
 Priority:  normal   |  Milestone:  _|_
Component:  GHCi |Version:  6.6
 Severity:  normal   | Resolution:
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  Unknown  |
- 
+--

Changes (by simonmar):

  * milestone:  => _|_
  * type:  bug => feature request

Comment:

 Personally I don't consider this a bug: the behaviour is clearly
 documented, and GHC tells you that it is loading the `.o` file in the
 output from `:load`.  The fact that `:load foo` is just shorthand for
 `:load foo.hs` is a good thing, IMO.

 If you want to force compilation, then `:!touch foo.hs` works  fine.  Given
 this, the argument that we should provide special support seems  weak, to
 me.  You can even define a macro, e.g.
 {{{
  :def interpret (\str -> return (":!touch " ++ str ++  "\n:load " + + str))
 }}}

 I'll leave this open as a feature request in case others want to  comment.
 If there's a concensus for a change, we can turn it into a task.

--
Ticket URL: 
GHC 
The Glasgow Haskell  Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs 


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1002: ghc-6.6 sometimes hangs under Solaris

[Claus Reinke]

#1002: ghc-6.6 sometimes hangs under Solaris
After compiling 643 modules (in 5 minutes) ghc-6.6 did not finish its
 batch job.
.. 

I have often seen problems like this with the Solaris linker.  (I
suspect it must have a super-linear algorithm for resolving symbol
references.)  The solution for me was to call the linker several times,
passing fewer object files to the linker at a time, e.g. using xargs.
Maybe the ghc pipeline driver needs to be taught how to do that?


this information is probably out of date by now, but there used to
be several bug reports pending for the Solaris linker, of the kind
"order of magnitude worse than gnu". there also were repeated
attempts to fix this in patches, so perhaps this is not the same
problem anymore. but you might want to give GNU ld a try, 
just in case:


http://haskell.org/haskellwiki/GHC/FAQ#Why_does_linking_take_so_long.3F

something like:

GCC_EXEC_PREFIX= ghc 

if those Solaris linker issues have been fixed, you might want
to update the GHC Faq (I'm not using Solaris at the moment).

if those linker issues are still around, and the GNU binutils
workaround still saves the day, perhaps that FAQ entry 
ought to be linked from "GHC on Solaris" section as well?


hth,
claus

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: the MPTC Dilemma (please solve)

[Claus Reinke]

[I suggest to keep follow-on discussions to the haskell prime list,
to avoid further copies]


continuing the list of odd cases in type class handling, here is a
small example where overlap resolution is not taken into account
when looking at FDs. 


actually, one needs to take both into account to arrive at the 
interpretation I favour:


- variables in the range of an FD can never influence instance
   selection if the variables in the domain of that FD are given
   (for, if they did, there'd be two instances with different range
   types for the same domain types -> FD violation)

- in other words, FDs not only tell us that some type relations
   are functional, they can be seen as roughly similar to what is 
   called mode declarations in logic programming: they tell us 
   with which input/output combinations a type relation may 
   be used


- for each FD a given constraint is subject to, the range types 
   should be ignored during instance selection: the domain types
   of the FD constitute the inputs and are sufficient to compute 
   unique FD range types as outputs of the type relation. the
   computed range types may then be compared with the range 
   types given in the original constraint to determine whether the

   constraint can be fulfilled or not

if we apply these ideas to the example I gave, instance resolution
for the "3 parameter, with FD"-version proceeds exactly as it
would for the "2 parameter"-version, using best-fit overlap
resolution to determine a unique 3rd parameter (range of FD)
from the first two (domain of FD).

this would seem similar to what we do at the function level:

   f a b | let res = True, a==b = res
   f a b | let res = False, otherwise = res

here, the implementation does not complain that f isn't functional
because we could instantiate {a=1,b=1,res=False} as well as 
{a=1,b=1,res=True} - instead it treats res as output only, a and b 
as input, and lets first-fit pattern matching resolve the overlap in 
the patterns. these rules describe a function because we say it does.


whereas, at the type class level, the implementations say "okay,
you said this is a type function, with two input and one output 
parameters, but if I ignore that for the moment, then overlap 
resolution doesn't kick in because of the different 3rd input 
parameter, and now there are two instances where there should 
only be one {TEQ a a T, TEQ a a F}; and if I now recall

that this should be a type function, I have to shout 'foul!'".

am I the only one who thinks this does not makes sense?-)

cheers,
claus


   {- both ghc and hugs accept without 3rd par and FD
  neither accepts with 3rd par and FD -}

   data T = T deriving Show
   data F = F deriving Show

   classTEQ a b {- tBool | a b -> tBool -} where teq :: a -> b -> Bool
   instance TEQ a a {- T-} where teq _ _ = True
   instance TEQ a b {- F-} where teq _ _ = False

   test = print (teq True 'c', teq True False)


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: the MPTC Dilemma (please solve)

[Claus Reinke]

continuing the list of odd cases in type class handling, here is a
small example where overlap resolution is not taken into account
when looking at FDs. 

context: both hugs and ghc resolve instance overlaps in favour 
of the most specific declaration.


so the following works in both ghc (darcs, 25022006) and 
hugs (minhugs 20051031):


   {- both ghc and hugs accept without 3rd par and FD
  neither accepts with 3rd par and FD -}

   data T = T deriving Show
   data F = F deriving Show

   classTEQ a b {- tBool | a b -> tBool -} where teq :: a -> b -> Bool
   instance TEQ a a {- T-} where teq _ _ = True
   instance TEQ a b {- F-} where teq _ _ = False

   test = print (teq True 'c', teq True False)

and both print "(False,True)", so best-fit overlap resolution entirely 
determines which instance to choose! 

now, if we uncomment the third class parameter, they both complain 
(as expected, though about different things).


however, if we also uncomment the functional dependency, to fix 
the ambiguity wrt the 3rd parameter, both complain that this FD 
is in conflict/inconsistent with the instances!


as far as i understand it, the potential inconsistency should have 
been eliminated by the best-fit overlap resolution, so I submit this

is a bug (and unlike the earlier example I submitted to hugs-bugs,
this fails with both hugs and ghc; and it is less open to alternative
interpretations, I hope).

cheers,
claus

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

too liberal handling of instance imports?

[Claus Reinke]

I was pretty sure this is a well-known and long-standing bug, but I 
can't find it in the sf bug tracker, and the user guide "Known bugs" 
section claims in 12.1.1.5 "None known", so I thought I'd ask here. 

The problem, as I recall it, is that ghc's import chasing collects 
instances as it follows dependencies, without respecting the 
actual import relationships between modules. For instance, the 
following compiles, but shouldn't (in my understanding, at least:-):

-
module A where 

f = print ((Left "hi" >>= Right) :: Either String String)
-
module B where

import Control.Monad.Error()
-
module Main where

import B 
import A

main = f
-

Could someone please confirm that this is a bug, not a mis-
understanding? Switching the order of imports in Main should
not have an impact on program correctness, but it does (win xp,
ghci 6.4.1; missing instance (Monad (Either String))). Similarly,
after a failed load (with flipped imports) in ghci, a simple 

:m +Control.Monad.Error
:m -Control.Monad.Error
:r

should not succeed, but it does.

In a larger program (think of A and B as independent sub-projects, 
from different vendors..), this is even harder to track (btw, can one 
infer the compilation order from ghc -M output? I was at a loss 
trying to find out why a certain module A was compiled at the time
it was, for one order of imports, but not for another - when the
compilation of A fails, the modules that caused A to be compiled
have yet to appear in the output.. ).

Cheers,
Claus


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: cvs head, winxp, make fails to make target `HSwin32.o', needed by `all'.

[Claus Reinke]

>| I'm trying to build todays cvs ghc on a winxp box, without trying
>| anything unusual. The build fails and I am rather lost in the
>| makefiles - any suggestions?
>
>I have not build hslibs/ myself for a long time. Is there some reason
>you want to?

none at all - just followed the building guide. section 2.2, for checkout,
which probably leads to it being compiled later because its there?

http://www.haskell.org/ghc/docs/latest/html/building/sec-cvs.html#cvs-first

cheers,
claus

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [ ghc-Bugs-1175454 ] System.system fails on windows98se, also disables ghci's :!

[Claus Reinke]

>If you look closely, you'll see that translate isn't applied to the
>argument to runCommand.  There's no double-translation going on, we just
>pass the command line directly to cmd.exe/command.com.

ah, sorry, I missed that extra-parameter backdoor, thanks!-)

>rawSystem needs to convert the [String] parameters into a single string
>for passing to CreateProcess.  I'm pretty sure that translate is doing
>the right thing here, at least if the target process is using the
>standard command-line parser from Microsoft's C runtime.

there doesn't appear to be a single standard. translate works most of
the time because there is a common untranslation of command-lines,
but the problem is that the current interface doesn't allow me to switch
off translation for rawSystem or runProcess, in those cases where it
doesn't work. and if command.com is one of those cases, that is an
important exception.

>It seems that command.com has non-standard command-line parsing, so it
>won't work with rawSystem.  In fact on Windows, runCommand is really
>more "raw" than rawSystem, because it does no translation.

runCommand doesn't do the waitForProcess, and it prefixes some command
interpreter, by its own logic. what I'm looking for is the "more raw" effect of
runCommand, but with the "no special effects" of rawSystem:-). In other 
words, *both* raw external process and raw, unprocessed parameters.

>The translation could be made to avoid using quotes in cases where
>quotes aren't necessary.  But you can't avoid quoting in general, so
>this wouldn't be a proper fix.

it wouldn't be a complete fix, but it would fix some bugs in the current
approach, where unnecessary quotes cause some progs to choke. Most 
of the time, I'd rather do the quoting myself, knowing what intermediate 
levels come into play, than have the api make a guess and get it wrong. 

Having translate exposed so that I can reuse the work you've put into 
figuring out the correct quoting for most windows apps is great, but it
seems I need the option of not using it.

>So I propose the following:
>
>  - we document that rawSystem doesn't work well if you're
>invoking command.com or cmd.exe on Windows: use runCommand
>insteead.

that doesn't quite work. runCommand has a different purpose. what is 
needed are versions of runProcess and rawSystem without translation.

e.g., you might want to call command.com from Haskell on your xp box 
without setting COMSPEC - for debugging purposes, or to test backwards
compatibility.

>  - we could provide a way to access runProcessWin32 directly,
>which gives you a more "raw" interface to CreateProcess
>on Windows (non-portable, of course).

there used to be a Win32 lib. it is useful to get access to such low-level,
system-specific functions, but I see no reason to have them in System,
which is meant to hide such things.

It isn't easy to come up with an alternative that respects the existing
APIs as the translation is currently embedded at the lowest level, with
some special casing and os-dependencies, but here's a suggestion 
(essentially move the translation into Process and make it optional):

- move translate to System.Process (identity for non-windows os),
export it there for convenience (note that the non-ghc branch
already moves it even higher, to System.Cmd)

- instead of the extra-parameter trick in runProcessX, implement
all variants of runProcessX without translation (I assume here
that things in Process.Internals are not meant to be called externally,
so we need to provide the choice at a higher level)

- provide runProcess', which is runProcess with a translation parameter,
to be applied to cmd+args before passing them to runProcessX

- implement runProcess as: runProcess' translate

- implement runCommand approximately as: findShell; runProcess' id

- implement system as before: runCommand; wait

- implement rawSystem as before: runProcess; wait

- provide rawSystem', which is rawSystem with a translation parameter:
rawSystem' translate ~~ runProcess' translate; wait
(so rawSystem could also be implemented as: rawSystem' translate)

[I'd be tempted to export findShell as well, so that one may check which
 command-line interpreter Haskell choses; just as one can check os]

>It'll break invoking programs other than command.com with rawSystem. 

In spite of my brute-force experiment, I wasn't suggesting to remove 
translate completely. many windows progs seem to do the corresponding 
untranslation, so it is very convenient to have translate, and default 
implementations of rawSystem/runProcess that use translate. 

the problem is that some progs don't follow those rules, and rawSystem 
as it stands doesn't cater for those, as it isn't modular enough (it bundles 
2 functions: calling an external process without going via a shell, and 
quoting parameters to pretend "raw" parameter passing). one could 
try to switch of quoting depending on the cmd, extending the ra

Re: [ ghc-Bugs-1175454 ] System.system fails on windows98se, also disables ghci's :!

[Claus Reinke]

>I can't fathom what's going on with rawSystem on your box.  Perhaps the Win98 
>version of command.com has different
quoting semantics, >which don't match what rawSystem is assuming.  I don't 
imagine I'll be able to make much progress on
that, but I'll be happy to incorporate a >fix if you can find one.

Let me see if I get the call-chain correct (System.-prefix omitted):

Cmd.rawSystem -> Process.runProcess ->
Process.Internals.runProcessWin32

Cmd.system -> Process.runCommand ->
Process.Internals.commandToProcess +
Process.Internals.runProcessWin32

The first thing I notice is that commandToProcess doesn't do
much (well, now it tries to find a command interpreter, but it does
no translation) - both variants go through runProcessWin32,
which calls Process.Internals.translate! Is that intended?? It
looks like a bug to attempt counter-translation for Cmd.system?

As far as I can see, that means that both system and rawSystem
will create command-lines rich with quotes, and as I mentioned,
command.com will choke on those.

Prelude> :m System.Process.Internals
Prelude System.Process.Internals> translate comspec
"\"C:\\WINDOWS\\COMMAND.COM\""
Prelude System.Process.Internals> translate "/c"
"\"/c\""
Prelude System.Process.Internals> translate "cd"
"\"cd\""
Prelude System.Process.Internals> translate "/c cd"
"\"/c cd\""
Prelude System.Process.Internals> :m -System.Process.Internals

Here is what happens with rawSystem:

Prelude> let rs = System.Cmd.rawSystem
Prelude> comspec <- System.Environment.getEnv "COMSPEC"
Prelude> comspec
"C:\\WINDOWS\\COMMAND.COM"
Prelude> rs comspec ["/c","cd"]
Angegebenes COMMAND-Verzeichnis ist falsch
Befehl oder Dateiname nicht gefunden.
Prelude> rs comspec ["/c cd"]
Angegebenes COMMAND-Verzeichnis ist falsch
D:\cygwin\home\unknown
Prelude>

And here are what I think are the corresponding calls in a
command.com shell - at least they evoke the same reactions:

C:\Windows>command.com /c "c:\windows\command.com" "/c" "cd"
Angegebenes COMMAND-Verzeichnis ist falsch
Befehl oder Dateiname nicht gefunden.

C:\Windows>command.com /c "c:\windows\command.com" "/c cd"
Angegebenes COMMAND-Verzeichnis ist falsch
C:\Windows

If this is correct, any fix would at least involve omitting the quotes
around the parameters if the command-line invokes command.com.

As an experiment, I created my own version of the rawSystem-chain,
replacing the call to translate for the args in runProcessWin32 with
a call to id, and that seems to be sufficient to solve this problem:

Compiling Main ( NewCmd.hs, interpreted )
Ok, modules loaded: Main.
*Main> rawSystem "command.com" ["/c","cd"]
D:\cygwin\home\unknown
*Main> comspec <- System.Environment.getEnv "COMSPEC"
*Main> rawSystem comspec ["/c","cd"]
D:\cygwin\home\unknown

*Main> System.Cmd.rawSystem comspec ["/c","cd"]
Angegebenes COMMAND-Verzeichnis ist falsch
Befehl oder Dateiname nicht gefunden.

*Main> rawSystem comspec ["/c cd"]
D:\cygwin\home\unknown
*Main> rawSystem comspec ["/c","echo %PATH%"]

c:\Programme\Hugs98;c:\Programme\GreenCard;c:\ghc\ghc-6.4\bin;D:\cygwin\usr\X11r

6\bin;c:\texmf\miktex\bin;d:\Software\jdk1.2.1\bin;D:\cygwin\usr\local\bin;D:\cy

gwin\bin;D:\cygwin\bin;c:\TEXMF\MIKTEX\BIN;c:\GHC\GHC-6.4\BIN;c:\WINDOWS;c:\WIND

OWS;c:\WINDOWS\COMMAND;c:\ADABAS\BIN;c:\PROGRAMME\ERL5.1\BIN;c:\PROGRA~1\ATT\GRA
PHVIZ\BIN;c:\ADABAS\PGM;c:\PROGRAMME\ERL5.1\BIN;D:\cygwin\usr\X11R6\bin

*Main> System.Cmd.rawSystem comspec ["/c","echo %PATH%"]
Angegebenes COMMAND-Verzeichnis ist falsch
Befehl oder Dateiname nicht gefunden.
*Main> System.Cmd.rawSystem comspec ["/c echo %PATH%"]
Angegebenes COMMAND-Verzeichnis ist falsch
"

whether this creates any other issues I don't know:-)

If you do have command.com somewhere on you system, please
also test Cmd.system with your patch and COMSPEC set to
command.com, as I suspect the quotes introduced in
runProcessWin32 will still cause it to fail?

Btw, the comment for commandToProcess refers to CreateProcess,
and claims that command-line translation is undesirable:

   On Windows, CreateProcess takes a single string for the command,
   which is later decomposed by cmd.exe.  In this case, we just want
   to prepend @\"c:\WINDOWS\CMD.EXE \/c\"@ to our command line.  The
   command-line translation that we normally do for arguments on
   Windows isn't required (or desirable) here.

>We'll definitely do something about the ctrl-C issues before 6.4.1.  No firm 
>release plans yet, but we'll keep you
posted.

Thanks. It would be good to have some working version of 6.4 on
windows, if only to convince maintainers of binary libs (like wxhaskell)
to release updates..

Cheers,
Claus

>
> Btw, I can produce the same effects within COMMAND.COM if I
> put parts of the command line in quotes (don't kno

Re: [ ghc-Bugs-1175454 ] System.system fails on windows98se, also disables ghci's :!

[Claus Reinke]

[don't want to reopen the ticket, don't like the mini comment field
on sf, and I no longer trust the handling of "\" on sf (see below);
so I'll reply here]

> I've fixed this, 6.4.1 should be better (though I can't test
> it, so I'd appreciate it if you would test a pre-release
> when the time comes).

Thanks. COMMAND.COM may still exist on newer windows
versions, which would allow you to do some testing by setting
%COMSPEC%? (ms/intel try to be backwards compatible with
their first abacus;)

But I'm looking forward to a first working windows release
candidate!-) when? and what about the ctrl-c horrors?

> I can use rawSystem to invoke cmd.exe /c here.  eg. this works:
>
>   rawSystem "c:\windows\system32\cmd.exe" ["/c", "dir"]

hey, who are you trying to fool now?-) the above isn't even legal Haskell!
[there are double backslashes in the sourceforge version, but not in
the ghc-bugs version? I keep staring at your email, but I still can't
believe this!]

Appended at the end is a recap of what happens on my windows98se
system. Note that with separate option, there's an error message and
no listing, and with option/parameter as a single element, the "dir" at
least gets executed, but the error message is still there. If that works for
you, without errors, it almost sounds as if rawSystem is cmd.exe-specific,
instead of command-interpreter-independent, as was the idea? Or at
least it doesn't cooperate with COMMAND.COM (perhaps the syscall
you use works differently on win98?..).

Btw, I can produce the same effects within COMMAND.COM if I
put parts of the command line in quotes (don't know whether that
is a misleading coincidence or a useful hint):

D:\cygwin\home\unknown>command.com /c cd
D:\cygwin\home\unknown

D:\cygwin\home\unknown>command.com "/c" "cd"
Angegebenes COMMAND-Verzeichnis ist falsch
Befehl oder Dateiname nicht gefunden.

D:\cygwin\home\unknown>command.com "/c cd"
Angegebenes COMMAND-Verzeichnis ist falsch
D:\cygwin\home\unknown

D:\cygwin\home\unknown>

Cheers,
Claus

$ ghci
   ___ ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |  GHC Interactive, version 6.4, for Haskell 98.
/ /_\\/ __  / /___| |  http://www.haskell.org/ghc/
\/\/ /_/\/|_|  Type :? for help.

Loading package base-1.0 ... linking ... done.
Prelude>
Prelude> System.Cmd.rawSystem "c:\windows\command.com" ["/c","dir"]
:1:26: lexical error in string/character literal
Prelude> System.Cmd.rawSystem "c:\\windows\\command.com" ["/c","dir"]
Angegebenes COMMAND-Verzeichnis ist falsch
Befehl oder Dateiname nicht gefunden.
Prelude> System.Cmd.rawSystem "c:\\windows\\command.com" ["/c dir"]
Angegebenes COMMAND-Verzeichnis ist falsch

 Datenträger in Laufwerk D: hat keine Bezeichnung
 Seriennummer des Datenträgers: 417D-08FC
 Verzeichnis von D:\cygwin\home\unknown

.  06.04.02  21:34 .
.. 06.04.02  21:34 ..
BASHRC~1   300  22.03.05  15:06 .bashrc
BASH_H~1 9.605  05.04.05   2:42 .bash_history
VIMINF~110.659  02.04.05  19:40 .viminfo
SSH~1  11.06.02   0:12 .ssh
CVSPAS~145  22.06.02  20:51 .cvspass
INDEX~1  HTM52.045  10.06.03  23:27 index.html
BASHRC~2   302  19.03.05  13:14 .bashrc~
GETNAME  PL140  24.09.03  14:27 getname.pl
EMACS~1  D 31.10.03  15:37 .emacs.d
_VIMINFO 8.430  29.05.04  16:26 _viminfo
FONTS~1  CAC 0  04.07.04  14:04 .fonts.cache-1
 9 Datei(en)81.526 Bytes
 4 Verzeichnis(se) 165.695.488 Bytes frei
Prelude>

Prelude> System.Cmd.rawSystem "c:\\windows\\command.com" ["/c echo %PATH%"]
Angegebenes COMMAND-Verzeichnis ist falsch
"


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

ghc-6-4-bld2.msi: html version of users_guide missing

[Claus Reinke]

the pdf version is there, but the link to the html version is dangling.

$ ls /c/ghc/ghc-6.4/doc/
ANNOUNCE  LICENSE  VERSION  object-io.ps
Cabal.ps  README   html users_guide.pdf

$ ls /c/ghc/ghc-6.4/doc/html/
Cabal  hslibs  index.html  libraries  object-io

$ fgrep users_guide /c/ghc/ghc-6.4/doc/html/index.html
  The User's Guide

cheers,
claus


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: win98, ctrl-c & System.system (was: Updated 6.4 Windows installer RC)

[Claus Reinke]

> There's no such thing as cmd.exe on Win9x, it's COMMAND.EXE/COM.

on my win98se system, there's no COMMAND.EXE, either, only
COMMAND.COM.

> Some System.Process.* code ought to be looking at the COMSPEC env
> variable and not hard-code the name of the command processor.  why the
> switch away from just using libc/msvcrt's system() for System.system?

agreed, on both counts. sounds like a case of "never change a winning
team", not. but I guess when one introduces a new framework for rawSystem,
one wants to keep only one way of doing things instead of two?

>However, I don't think COMMAND.EXE supports the /c switch...

don't know about that one, but COMMAND.COM does support it:

$ echo $COMSPEC
C:\WINDOWS\COMMAND.COM

$ /c/Windows/COMMAND.COM /c cd
C:\Windows\Desktop\haskell\monadification

in principle, this would make it possible to implement system on top of
rawSystem, but as I said, I can't see a way of passing the /c switch
through rawSystem without triggering error messages.

cheers,
claus



$ /c/Windows/COMMAND.COM


Microsoft(R) Windows 98
   (C)Copyright Microsoft Corp 1981-1999.

C:\Windows\Desktop\haskell\monadification>command /?
Startet eine weitere Kopie des Windows-Befehlsinterpreters.

COMMAND [[Laufwerk:]Pfad] [Gerät] [/E:n] [/L:] [/U:nnn] [/P] [/MSG]
   [/LOW] [/Y [/[C|K] Befehl]]
  [Laufwerk:]Pfad   Das Verzeichnis, das die Datei COMMAND.COM enthält.
  Gerät Das Gerät für die Befehlsein- und -ausgabe.
  /E:n  Legt die Umgebungsgröße auf n Bytes fest.
(n sollte im Bereich von 256 bis 32,768 liegen).
  /L:   Definiert die Länge des internen Puffers
(/P ebenfalls erforderlich).
( sollte im Bereich von 128 bis 1.024 liegen).
  /U:nnnDefiniert die Länge des Eingabepuffers
(/P ebenfalls erforderlich).
(nnn sollte im Bereich von 128 bis 255 liegen).
  /PInstalliert den neuen Befehlsinterpreter dauerhaft
(ohne Möglichkeit zum Beenden).
  /MSG  Speichert alle Fehlermeldungen im Arbeitsspeicher
(/P ebenfalls erforderlich).
  /LOW  Residente Daten werden im unteren Speicherbereich
untergebracht.
  /YFührt das mit /C oder /K angegebene
Stapelverarbeitungsprogramm schrittweise aus.
  /C Befehl Der Befehl wird ausgeführt und COMMAND.COM beendet.
  /K Befehl Der Befehl wird ausgeführt und COMMAND.COM nicht beendet.



___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: win98, ctrl-c & System.system (was: Updated 6.4 Windows installer RC)

[Claus Reinke]

>> -c issues
>Please file a(nother) bug, we'll try to improve things for 6.4.1.

I thought I did?-) or is this list deprecated in favour of sourceforge?

>Strange - command prompt windows should be nice and large and
>scrollable, mine are at least.  Cut-and-paste support is terrible, though. 

oh, they are, just not in windows 98. but c&p works even there.

>Works for me!  Remember that System.system is executing CMD.EXE, not
>Cygwin bash, so it'll probably have a different PATH and might not be
>able to find your Cygwin binaries.  Both System.system "dir", and
>System.system "c:/cygwin/bin/ls" work for me.

System.system used to pick up the current PATH from the cygwin
environment, which is a lot more comfortable. But as I mentioned,
it makes no difference if I use ghci directly, and try pure and absolute
windows paths, or "dir" - it seems as if it doesn't matter at all what 
command it is, nothing gets through. See also the ":!" issue,
for which, I assume, ghci uses System.system internally.

>Perhaps rawSystem is using the current PATH setting, which it inherited
>from the bash shell, whereas System.system is starting a new CMD.EXE
>which resets the PATH?  Try System.system "set PATH".

can't, see above. but that would be (a) counterintuitive behaviour,
and (b) a change from previous incarnations of System.system, IIRC.

It is good that at least one of the two works, and better than before
in terms of ExitCode, but .. WAIT A SEC, CMD.EXE ON WIN98???

ah yes, one should read error messages, I guess (see previous emails),
under bash:

Prelude> let system c = System.Cmd.rawSystem "bash" ["-c",c]
Prelude> system "pwd"
/home/unknown
Prelude> system "true" >>= print
ExitSuccess
Prelude> system "false" >>= print
ExitFailure 1

Prelude> let systemC c = System.Cmd.rawSystem "command.com" ["/c",c]
Prelude> systemC "cd"
Angegebenes COMMAND-Verzeichnis ist falsch
Befehl oder Dateiname nicht gefunden.

Prelude> let systemC c = System.Cmd.rawSystem "command.com" ["/c "++c]
Prelude> systemC "cd"
Angegebenes COMMAND-Verzeichnis ist falsch
D:\cygwin\home\unknown

I can't quite figure out how to pass the "/c" option to command.com
(it looks as if rawSystem passes some junk *in addition to* the parameters,
which confuses command.com, and apparently option and parameter
count as *a single* parameter to rawSystem), but this is a lot better than 
what System.system and ":!" do. It seems that someone dropped a 
windows 98 dependency when reimplementing System.system?-)

Prelude> System.Cmd.rawSystem "echo" ["/c","cd"]
/c cd

hmm, no visible junk there, so perhaps the "/c" is interpreted as the
path parameter instead of/as well as an option. over to you.

Cheers,
Claus


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: win98, ctrl-c & System.system (was: Updated 6.4 Windows installer RC)

[Claus Reinke]

> - System.system does not appear to work anymore? it
> can't seem to find any command.

probably the same issue: ":!" doesn't work anymore
(what's this runCommand anyway?).

without bash:

Prelude> :!cd
*** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does not exist (No such fi
le or directory)

under bash:

Prelude> :!pwd
*** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does not exist (No such fi
le or directory)

cheers,
claus


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

win98, ctrl-c & System.system (was: Updated 6.4 Windows installer RC)

[Claus Reinke]

> Yet another 6.4 installer, this time fixing issues regarding GHC
> use on Win9x / NT4 installations:
> http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-bld2.msi
> Unless some _really bad_ platform-specific bugs are reported against
> this one soon, that's the final 6.4 installer.

sorry to be complaining about issues with a pre-OS that, by all
rights, should be gone and forgotten, but I thought I'd at least
report such things as I find.

the new snapshot installs and runs fine on win98se, but someone
tries to be too clever about catching -C, it seems. not that
I particularly liked the old behaviour (dropping out of a ghci
session when interrupting a loop), but this is no improvement.

in the appended log, after ghci starts up, I just repeatedly type
-c, and though the bash prompt appears, ghci isn't
quite gone, and there appears to be some competition about
further inputs.. if I'm lucky, I get a complete command through
to bash, then type -c to be back in ghci-land for a moment, 
with similar problems to complete commands, but if I manage to
get an unclobbered :q through, things seem to return to
normal, at bash-level.

either keeping in ghci-level or dropping to bash-level would
be better than this mixture. I notice that this new catching of
-c seems to work as intended if I start ghci from the
start-menu, ie without cygwin bash, but that is very 
unconfigurable/uncomfortable on win98 (tiny window-size
without scrolling, in which I can't even see the complete
output of ":?".

while I was at win98-specific issues, I remembered the old
"System.system always returns ExitSuccess on ghc/win98"
(somewhat of a nuisance when you're trying to run a suite
of tests from within Haskell that involve external commands).
so I tried to check that, but:

Prelude> System.system "ls" >>= print
*** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does not exist (No such fi
le or directory)
Prelude> System.Cmd.rawSystem "ls" [] >>= print
_viminfo  getname.pl  index.html
ExitSuccess
Prelude> System.system "false" >>= print
*** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does not exist (No such fi
le or directory)
Prelude> System.Cmd.rawSystem "false" [] >>= print
ExitFailure 1

(this is from within bash; the effect is similar without
bash, after substituting some non-bash command that 
is in the normal %PATH%)

-

so, in brief:
- catching -c from ghci running under bash leads to 
trouble.
- System.system does not appear to work anymore? it
can't seem to find any command.
- System.Cmd.rawSystem does seem to solve that old
ExitCode problem, but why is it better at finding
commands than System.system? shouldn't it be
the other way round?

perhaps the first falls into "file bug report and live with it",
but it would be nice if someone could explain the second and
third for me?

cheers,
claus

-
$ uname -a
CYGWIN_98-4.10 vaio 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown unknown Cygwin


[EMAIL PROTECTED] ~
$ ghci
   ___ ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |  GHC Interactive, version 6.4, for Haskell 98.
/ /_\\/ __  / /___| |  http://www.haskell.org/ghc/
\/\/ /_/\/|_|  Type :? for help.

Loading package base-1.0 ... linking ... done.
Prelude>
Prelude> Prelude>

[EMAIL PROTECTED] ~
$ Prelude>

[EMAIL PROTECTED] ~
$ Prelude>

[EMAIL PROTECTED] ~
$
P
[EMAIL PROTECTED] ~
$ elude> Prelude> Prelude>


[EMAIL PROTECTED] ~
$ P
r
[EMAIL PROTECTED] ~el
$ de> Prelude>

[EMAIL PROTECTED] ~
$


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

building cvs head with cygwin/mingw: ghc-inplace tries to execute directory?

[Claus Reinke]

on windows xp sp2 with cygwin:

- installed latest alex,happy,haddock from binaries on Sven's page
(should this be mentioned in the building guide?
 http://www.aedion.de/haskell/ )

- installed ghc 6.4, using msi in download area

- fetched fresh copy of fptools from cvs, to c:/fptools/fptools

- followed build instructions for mingw-build

+ installed msys, but added glut
(you might want to mention this in 13.4; also, is there no
 way to use ghc's copy of mingw instead of a separate one?)
+ autoreconf
+ ./configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc
+ copied mk/build.mk.sample and added
'BuildPackageGHC=YES' in mk/build.mk
+ make 2>&1 | tee /make.log

myrtle$ tail -f make.log
creating libgmp.la
(cd .libs && rm -f libgmp.la && ln -s ../libgmp.la libgmp.la)
make[5]: Leaving directory `/cygdrive/c/fptools/fptools/ghc/rts/gmp'
make[4]: Leaving directory `/cygdrive/c/fptools/fptools/ghc/rts/gmp'
../../ghc/compiler/ghc-inplace -optc-mno-cygwin -optc-O -optc-Wall -optc-W 
-optc-Wstrict-prototypes -optc-Wmissing-proto
types -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return 
-optc-Wbad-function-cast -optc-I../includes -opt
c-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-Iwin32 
-optc-fomit-frame-pointer -H32m -O0 -W -fno-warn-unused-matches -
fwarn-unused-imports -O2 -static -I. -#include Prelude.h -#include Rts.h 
-#include RtsFlags.h -#include
RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h 
-#include Sanity.h -#include STM.h -#include
Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include 
ProfHeap.h -#include
LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c 
Adjustor.c -o Adjustor.o
exec: c:/fptools/fptools/ghc/compiler/: not found
make[2]: *** [Adjustor.o] Error 127
make[1]: *** [all] Error 1
make[1]: Leaving directory `/cygdrive/c/fptools/fptools/ghc'
make: *** [build] Error 1

I don't have access to the files at the moment (only redirected the make
log to a machine I can see), but it looks as if ghc-inplace simply tries to
execute a directory?

suggestions?
claus

ps: the mailing lists link on the ghc homepage no longer works
http://www.haskell.org/ghc/docs/latest/html/users_guide/introduction-ghc.html#MAILING-LISTS-GHC


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Text.ParserCombinators.Parsec requires -package text.

[Claus Reinke]

>> so you could add info about required packages in the object file,
>
>Yes, both of these are good ideas.  However, they both require noodling
>in object files of course, which is non-portable.  Or perhaps creative
>use of 'nm' or 'objdump' would do.
>
>In any case, I think we already arrived at a reasonable solution...

in case you need to revise your solution later: I was thinking of an
equivalent to the rcs ident command, ie a recognisable string pattern
in the object file, automatically created by ghc (here simulated by 
hand) - no non-portable trickery needed:

--
module M where
m_info = "$GHC compiled module: M; needs packages: base, wxhaskell$"
--

$ ghc -c M.hs

$ strings M.o | fgrep \$GHC
$GHC compiled module: M; needs packages: base, wxhaskell$

cheers,
claus


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Text.ParserCombinators.Parsec requires -package text.

[Claus Reinke]

>Just to expand on this a little: it's not clear that we could do this
>even if we wanted to.  Given an arbitrary .o file, we can't tell (a) if
>it is a compiled Haskell module and (b) if so, where its .hi file can be
>found.  We can make guesses, but there isn't a general solution.

the only .o files you're interested in are those you've created, no?

so you could add that information to the .o file - but the .hi file might
have disappeared.  however, the original question was about finding 
required packages in the linking step, with only some .o file at hand.

so you could add info about required packages in the object file,
say as the value of some hidden default symbol, or as an unresolved
reference to a hidden symbol provided by the package. if, in the first
case, the  symbol doesn't exist or if, in the 
second case, there's no reference to a  
symbol, you know its not one of your object files, so it shouldn't
depend on your packages, should it?

just trying to understand the problem,
claus


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

www access to ghc CVS gone?

[Claus Reinke]

http://www.haskell.org/ghc/

links to "CVS repository"
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/

which gives "Error 404 object not found"

claus

ps. http://cvs.haskell.org/ has general CVS accress info, but 
no links to the www interfaces for ghc, hugs, libraries, etc.
(assuming they still exist)


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Data instances in ghc 6.2.1?

[Claus Reinke]

>| [has there been any progress on the idea of having weekly or so
>|  windows snapshots of CVS GHC generated automatically?]
>PS Also you could just build GHC yourself!  It's not hard these days.

I don't doubt that in principle, and I'm happy to hear it (I'm sure a 
lot of work has gone into making it so). In practice, however:

- my trusty old notebook's spec: 

W98, PII 366MHz, 192Mb RAM, 6Gb Disk
this is fine for most apps and small development, but the only
free space on this generous disk is what I get by deleting other
stuff, and building largish things takes longer than downloading
them (e.g., a full HaRe build takes just under an hour, compared 
to a few minutes on a normal system) - no chance for GHC builds.

[yes, I know it's long overdue for replacement, and I look forward 
 to keeping more up-to-date with GHC afterwards; the point is that
 "low-spec" systems live long these days, and have a share of the
 market because everyone's latest-and-greatest will join them in 
 a few years; they are quite useful long after being shiny, so we 
 shouldn't take recent sytems and their specs for granted]

- I like to do stuff others can use, so even after I can build GHC,
that won't help those who can't or won't. So I look ahead for
things to come, but tend to stick to things that are here (or
readily available, which is why snapshots would help).

Cheers,
Claus

PS. I never was quite sure why Haskell systems need an installer
on Windows? There used to be Haskell libraries for accessing
the registry, so filetype-associations and Start menu entries
could be done optionally, by a little separate Haskell program, 
and since GHC doesn't do any localisation or PATH settings, 
the rest would mostly just be decompression and unpacking, 
right? Or is that too naive a view of things?-)


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Data instances in ghc 6.2.1?

[Claus Reinke]

Hi Ralf,

> the tuple instances did not make it into GHC 6.2 because of CVS 
> branching policy. GHC CVS HEAD compiles the example.
> And yes, SPJ approved recently that Language.Haskell.Syntax should 
> derive Data and Typeable.

okay, thanks (seems there's always a reason to look forward to the
next release, and the one after, and .. ;-). 

[has there been any progress on the idea of having weekly or so 
 windows snapshots of CVS GHC generated automatically?]

For context: I wanted to show people in the haskell tools thread

- how easy it is these days to write a Haskell program transformation
for instrumenting source code with asserts, e.g. to get location info
for heads of empty lists :-)
- why these lovely new tools won't be used because even without 
transformations they don't reproduce the source :-(

But as they can't use this in the current release anyway, I'll leave
it at that.

> But, I can't access cvs.haskell.org.

>From the mailing lists, I recall there was a problem with cvs a while
ago, after which people had to reestablish their access rights with 
whoever holds those.

Cheers,
Claus


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Data instances in ghc 6.2.1?

[Claus Reinke]

Shouldn't there be more instances of Data and friends?

I thought that tuples beyond size 2 were mentioned
here before ghc 6.2, but this silly example doesn't work
because of missing Data instance (it does work with d 
instead of d3):

import Data.Generics

-- file = "Tst.hs"

d  = (["hi","head"],("ho",(True,"head")))
d3 = (["hi","head"],"ho",(True,"head"))

main = print $ everywhere (id `extT` worker) d3
  where
worker "head" = "tail"
worker s = s

Since these instances claim to be derivable: shouldn't
that be done for the stuff in Language.Haskell.Syntax?

cheers,
claus

___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: ghc 6.2 gets confused about Main.hi reuse

[Claus Reinke]

>We've found the reason that 6.2 was failing in this way and fixed it in
>6.2.1.  It was indeed a bug.

Thanks.

>*However*, this doesn't change the fact that swapping in a new Main
>module is a dangerous thing to do: the recompilation system relies on
>the date of the source file to determine whether compilation is
>required, so if you use a new Main module without touching it first, the
>compiler might not recompile as it should.  

Funny, ever since I started to use Haskell, I've tended to work with several
smaller Main modules in one directory, usually for testing, debugging,
demoing, etc., rather than the need to produce several interfaces to the
same code base, as in this case - this must have been the first time that 
led to problems.

We'll keep removing the Main.hi between compilations, then, to avoid
"same timestamp" problems with touching the source.

>There are ways we might try to get around this problem.  Putting an md5
>signature of the source file in the .hi file is one way.  Using
>different .hi files for different source files is another, but we
>couldn't see a good way to do this when using the -hidir flag as in your
>example.

Different .hi for different .hs would be my preference, but if that is a
problem, one could simply put the source file name in the Main.hi file,
to keep the two connected?

Cheers,
Claus


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: ghc 6.2 gets confused about Main.hi reuse

[Claus Reinke]

>> The simplest approach would be to take the presence of -o as a
>> strong hint that there might be confusion about executables/Main
>> modules and thus to rename the Main.hi-file as well when -o is 
>> present.
>What you're really doing here is building a library that is subsequently
>used when building two separate executables.  The right thing to do is
>to build the executables with the objects in different places (the
>interface is really part of the object code).

I agree that the interface is part of the object code - that's why I'd prefer
for both to follow the same naming convention. I was trying to build the
executables in different places, using -o. That used to work, now it doesn't.

>I'm reluctant to change these rules in anything but small ways, because
>doing so inevitably breaks someone else's strange build system.  The
>problem is that there are lots of different scenarios under which the
>compiler has to do something reasonable and it's really hard (from
>experience!) to change things in a way that doesn't upset anyone.

Just for the record: I was reporting just such a breakage. But that's no
reason to introduce more trouble - just take the suggestion as such,
and decide whether or not it makes sense/would be an improvement.

>For instance, if I make -o change the location of the interface file for
>Main only, then don't I have to write special Makefile rules to take
>into account this special case or does it only apply to --make?  This
>sounds like a rather hacky special case to me.

Main _is_ special in that it is the only module not "required" to be
in a file of the same name. But I don't see the need for any special
cases? Ah, is it because -o not only applies to .o files and because
-ohi is not taken into account for locating old interfaces?

My suggestion would be to let the name of the interface file follow
the name of the object file, so if -o changes the name of one, it should
also change the name of the other. At the least, though, I'd expect to
be able to use -ohi in the same way as -o, so that I can force the effect
if it's not standard. But that's just a suggestion.

Cheers,
Claus

PS It just occurred to me that the new "-main-is" might be of help.
  And if it isn't, I can still remove Main.hi between compilations..


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: the woes of non-cvs haskellers

[Claus Reinke]

[hugs-bugs removed from cc, this seems focussed on GHC?]

> Towards the end of last year I started experimenting with modified "nightly"
> build scripts to build in one fell swoop ghc (and it's libraries), alex,
> happy, greencard and hdirect.

|Speaking from a GHC standpoint, your efforts were/are greatly
|appreciated.  Probably the reason that building GHC on Windows is "a hit
|and miss affair" is because we don't have the same level of constant
|testing that happens with the Linux port: having a nightly build report
|for the Windows build would help keep us aware of problems in the
|Windows world as they crop up.
|As far as packaging goes, it would definitely be useful if the output of
|the nightly build on Windows was an installable .msi - I think Sigbjorn
|has some tools to automate this process, but not sure if they're ready
|for prime time yet (Sigbjorn?).  If we had this, then the .msi could be
|published on the web along with the other development snapshots.

Speaking from a GHC binaries user's standpoint, this would seem to
provide more frequent synchs of binaries with CVS while at the same
time elevating the level of Windows testing to that of Linux, thus 
promising improvements for the official binary releases even if the 
snapshots themselves might occasionaly catch the repository in a 
non-optimal state ("nightly" being a local notion;).

Sounds like an outright win! If that could be realized, I'd have
less reason to be worried, I guess (I also guess MS couldn't be 
tempted to sponsor a Windows box for Haskell testing/builds?).

> | In other words, someone could go download
> | them, make a "Haskell tools, Spring 2004" CD, and be sure that
> | they actually work together while he/she's trying to learn Haskell.
> Unfortunately I'm unable to do this myself, but the above changes should
> make the task more automatable.

I wasn't suggesting that we sell Haskell tools CDs (though they might
make nice add-ons to Haskell textbooks?). It was just a figure of speech
to express a coherent and stable bundle of core Haskell software, but 
some Haskellers actually start by making a CD snapshot of Hugs/GHC
via a fast connection before digging into their finds at home.

Cheers,
Claus

___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: the woes of non-cvs haskellers

[Claus Reinke]

>It's been a rough ride in a few ways recently.  But let me try to
>explain our policy and why it's a good compromise, and hopefully this
>will shed some light on why there might be problems going from GHC 6.0.1
>to 6.2, for example.

just to clarify:

- I'm not complaining about your or anyone else's policy (well, not in 
this thread, anyway;-), especially when they're dictated by limited
resources, and so many good things are produced in spite of such
limitations!

- I'm aware of the LIP, but it has been a long time in the making,
probably because it tries to address lots of issues

- what I'm trying to point out is that the current situation shows that
there are some serious bugs in the system, even for the minimal
core (Haskell starter pack = Haskell implementation + some GUI lib)

- what I'm hoping is that there might be some small issues at the root,
and that addressing those would give us a less bumpy ride until
the LIP arrives at its goals

>We start a new *major* release every so often (eg. 6.2 is a major
>release).  It has new features, and might change the interfaces to
>libraries and tools.  At this point we branch the codebase.  We then do
>a number of patchlevel releases (6.2.1, 6.2.2 etc.) that fix bugs
>*only*: i.e. it's highly unlikely that these releases introduce new
>bugs, and they definitely don't change interfaces.  So those after
>stable binary releases can follow these patchlevels and get a
>monotonically improving experience :-)

Knowing that, I tend to avoid the first version of each new major 
release:), but this general scheme has at least two problems at the 
moment, and especially the assumption in the last sentence 
above is, unfortunately, no longer true:

1. patchlevel releases have a lag time of a month or more
even after "serious" bugs (remember that even trivialities like 
the winhugs problem look serious to beginners), suggesting 
that "just packaging up a patchlevel release" may not be as 
simple as perhaps it should be, even after the bugs are fixed.

As patchlevel releases tend to appear only for the latest 
major release, because of the lack of resources, developers 
have to move with the major releases.

2. developers of tool X have little control over what versions 
of other packages/tools/implementations users have installed:

- there are universities that only permit updates of the 
basic implementations between semesters/years, to 
provide stability

- there are always new enthusiastic Haskell users, who
naturally (try to) start from the latest set of versions

- users generally use more than one tool/library, so they
need to find a set of releases that works together

- new major releases often fix bugs for which there's no
simple work-around, so some developers depend on
the latest implementation to get their package working

- all developers suffer from lack of resources, so some
packages might be updated less frequently to the 
changes introduced with the latest implementations

Developers have to cater for what the installed base,
summed over all their users, dictates.

What makes the ride a bit bumpy at the moment is that there's
no stable set emerging among the updates, so everyone is
more or less forced to follow the latest developments in each
of the packages they or their users are concerned with.

As a tool developer, that means I'll get bug reports telling me
that my tool doesn't build with the latest version of X, so I can't
rest of my older stable version of X. As a Haskell promoter,
that means I'm having a really hard time recommending what to
download and install ("hugs, but don't use winhugs; ghc, but
not the latest version; HGL/wxHaskell, perhaps, but one may 
not work with hugs, the other possibly not with ghc, or do they,
and perhaps the versions and your system are important, hemm, 
let me check..").

It was the second role that alerted me to all the workarounds
and uncertainties I had grown used to but which I can't impose 
on a newcomer.

> We think this is a reasonable compromise and makes good 
> use of the resources we've got.

Generally, it works very well - indeed part of the problem is
that it's hard to keep up with you at times;)

Cheers,
Claus

>Also remember that certain features like TH are deemed experimental, and
>fixing their interfaces too soon would give us an undue maintenance
>burden.  If you use experimental features, be prepared to do some
>conditional compilation based on compiler versions.

The TH syntax leakage affected programs that never even used TH.
But that's yesterday's news


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: ghc 6.2 gets confused about Main.hi reuse

[Claus Reinke]

> >The -ohi flag lets you rename the interface file, or -hisuf is useful
> >for renaming a whole bunch of interface files if you want to build
> >modules in two different ways in the same directory.
> 
> We use -hidir/-odir to build for different platforms, so the only
> problem comes from ghc using hidir//Main.hi for
> both pfe.hs and pfe_client.hs. Executables and sources have
> different names, why not the interface files? Will try -ohi and
> see if that helps.

No, it doesn't (myghc--make is a slightly veiled call to ghc --make):

cd refactorer; ./myghc--make -o pfe -ohi pfe.hi pfe.hs 2>&1 | tee -a log.txt
c:\ghc\ghc-6.0.1\bin\ghc.exe: -ohi can only be used when compiling a single source 
file

The simplest approach would be to take the presence of -o as a
strong hint that there might be confusion about executables/Main
modules and thus to rename the Main.hi-file as well when -o is 
present.

Cheers,
Claus

___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

the woes of non-cvs haskellers

[Claus Reinke]

Dear all,

I'm getting more and more worried about Haskell users who 
depend on multiple Haskell packages and compilers, but don't 
want to follow the cvs developments for all of these packages. 
I have the feeling that Haskellers who rely on pre-packaged
binaries are not currently getting a good impression of the
state of the art.

To give just one concrete example, what packages do I 
recommend to someone wanting to learn a bit of Haskell, and 
do some graphics and perhaps windowing, on Windows?

- Hugs (Winhugs bug in current binary release, so better avoid
that and use plain Hugs?)
- HGL (does it work with latest Hugs/GHC, or do I need older 
versions? which ones?)
- GHC (current binary release seems to have serious probs on 
some Windows versions; has also seen some rapid 
development breakage recently, e.g., TH syntax, forcing 
other packages to play catch-up just to get working again)
- wxHaskell (works with ghc-6.0.1, will it work with 6.2? what about 
Hugs? what about ghc-6.4?)
- some generic text-editor (but on Windows98, the way that .hs
files are associated with Hugs/GHC cannot be modified in
the standard dialogues, as they can for other associations, 
so how do I associate .hs files with an editor? I wouldn't 
want to recommend some beginner editing the registry for 
that purpose..)

The issues are usually small, but there are many of them, each
package has its own, and all too often the response is "fixed in 
CVS, will be in next release".  

Of course, the next release is a while a away and by that time, 
there'll be a different set of small issues plagueing the next set 
of binary releases. So, just getting someone started requires
careful investigation/testing and some thinking (instead of: 
"just download and install the latest Haskell starters set").

A modular way to fix this would be to have at least once-a-month
patch updates of binary packages, so that one would never be
more than a month away from the fixed versions (instead of having
to wait for the next releases of everything).

A broader approach would be to try and show a united Haskell 
tools front to the general Haskeller: Identify a core set of Haskell
tools (the above four would be my initial suggestion), and make
sure that the latest binary releases for these are always in synch
with each other. In other words, someone could go download 
them, make a "Haskell tools, Spring 2004" CD, and be sure that 
they actually work together while he/she's trying to learn Haskell.

Both GHC and Hugs have had release candidate testing in the
past, but experience and mailing list archives show that there's 
always a number of issues that are only detected after the 
binary releases. On Windows at least, it seems that everyone
is relying on Sigbjorn to do all the packaging - couldn't the 
creation of updated installers be automated (or Haskellised), 
so that he'd only have to be bothered for the initial packaging, 
not for patchlevel updates?

There are similar issues for Haskellers needing a larger set of 
tools and libraries, but those will hopefully be addressed by 
the library infrastructure project in the long run, so I'm just 
asking about the state of the core tools here.

Opinions?
Claus


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: ghc 6.2 gets confused about Main.hi reuse

[Claus Reinke]

>The -ohi flag lets you rename the interface file, or -hisuf is useful
>for renaming a whole bunch of interface files if you want to build
>modules in two different ways in the same directory.

We use -hidir/-odir to build for different platforms, so the only
problem comes from ghc using hidir//Main.hi for
both pfe.hs and pfe_client.hs. Executables and sources have
different names, why not the interface files? Will try -ohi and
see if that helps.

>I can't say exactly what caused the error you're seeing, but the root
>cause is clearly that the compiler is finding Main.hi from the previous
>build and attempting to use it to determine whether Main needs to be
>rebuilt.  The solution is "don't do that" :-)  

Don't do what?-) Compile more than one executable in the same
directory? That'd be a rather harsh limitation, wouldn't it?

The real question is why a build that goes through without a
hitch in ghc-6.0.1 suddenly fails in ghc-6.2. 

As it happens, this aspect of our build also worked in ghc-5.04.2, 
but of course that build broke in ghc-6.0.1 because of the Template 
Haskell syntax intrusion bug.. So, every time a new ghc comes out,
we have to modify our build, and not because of deprecated
feature warnings, either!-(

>GHC can't tell that the Main.hi was from a different build - 
>presumably the source file was Main.hs in both cases?.

No, different sources, different executables, just some 
shared imports. It's the current HaRe snapshot (works
with ghc-6.0.1, needs fix with ghc-6.2).

Cheers,
Claus


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: ghc 6.0.1 win98 System.system too successful?

[Claus Reinke]

> On Windows, Hugs' implementation of System.system always returns ExitSuccess 
> because the Windows routine it calls doesn't return a useful exit status.

Thanks, I hadn't noticed before, but you're right: Hugs suffers from the same bug.

> My very vague memory from looking into this some years back was that DOS 
> programs don't have a consistently interpreted exit status the way Unix 
> programs do and use some kind of out-of-band communication to indicate 
> failure to the caller.

Assuming this is the cause of the bug, shouldn't ghc's/hugs' implementation
of System.system on Windows98 make use of this out-of-band communication
(which would then seem to be the standard usage pattern on this platform), in 
order to provide a more useful exit status in our Haskell programs?

Cheers,
Claus

___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

ghc 6.0.1 win98 System.system too successful?

[Claus Reinke]

Shouldn't this return something other than ExitSuccess, occasionally?
Cheers,
Claus

PS. the first error message says "command not found"
PPS. this is from within cygwin's bash

$ ghci
   ___ ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |  GHC Interactive, version 6.0.1, for Haskell 98.
/ /_\\/ __  / /___| |  http://www.haskell.org/ghc/
\/\/ /_/\/|_|  Type :? for help.

Loading package base ... linking ... done.
Prelude>
Prelude> System.system "fail" >>= print
Befehl oder Dateiname nicht gefunden.
ExitSuccess
Prelude> System.system "diff ClassIn1.hs ClassIn1_TokOut.hs" >>= print
7c7
< class Reversable a where
---
> class MyReversable a where
11c11
< instance Reversable [a] where
---
> instance MyReversable [a] where
ExitSuccess
Prelude>


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

getProtocolNumber garbage (was: Network on Win98: failed - socket - no error ??)

[Claus Reinke]

okay, after giving myself a day to recover from the frustration,
I've given it fresh try today, and can at last report the source 
of the problem and a workaround (thanks to Sigbjorn for helping
me to narrow down the source). I leave precise location of the 
bug and proper fix to the experts:-)

ghc's 'getProtocolNumber "tcp"' returns garbage on my win98 box
(ghc-5.04.2, perhaps a marshalling problem??).

perl's version gives me: 6
ghc's version gives me: 1398538246

Putting in the more sensible value explicitly makes the program
work as expected, so winsock was really quite right to report 

WSAEAFNOSUPPORT 10047
Address family not supported by protocol family,

just that I didn't expect the error to be with the parameters.. 
(and my hacked-up error-reporting didn't include the 
erroneous values themselves..). 


On the topic of libraries: although ghc doesn't value binary compatibility
as high as its user's do;-) I would expect the libraries to develop faster than
ghc's binary incompatibilities in the near future (or is this unreasonable?).

So it would really be useful to have regular binary snapshots of the libaries,
built to work with(*) the latest binary release of GHC, but distributed separately. 
When the current libraries can no longer be built for the latest GHC release, it's
a sure sign that a new one is needed..

(*) note that this might well be different from "built with", as long as the ghc 
modifications needed do not compromise binary compatibility.

>A word of caution here.  Parts of the libraries, especially base/GHC/*,
>may be GHC-version-specific.  We do not put lots of ifdefs in the
>library sources to cope with different GHC versions, because they are
>expected to be built with the GHC from the same tree.  
>So, it may work, but it may not.

The usual cvs-rule is not to check in things that don't compile, so even
without lots of ifdefs, it would be useful to have a simple text file for
each package, stating the version of GHC/Hugc/nhc with which it was
compiled (and wether or not it compiles with the latest binary release?).

Btw, does the web interface to the cvs-tree give me an easy way to see 
the precise source versions wich make up the latest binary release? I find
it difficult to check whether there have been any changes relevant to my
problems. A good start would be to have the tag for the latest binary release
as the selected diff target by default?

Finally cheerful again,
Claus


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Network on Win98: failed - socket - no error ??

[Claus Reinke]

> Something's up with your WinSock setup on that machine,
> I suspect -- works fine on the Win98 box I tested it on.

That's a useful reference point, thanks! It also means that the 
program I want to use it for will work on win98 boxes, even if not
yet on mine. I'm also hunting on the web, but while similar problems
do not seem unknown, the few suggested "cures" are not very
encouraging so far. And while I'm grasping at straws: which port 
number did you use?

> You may want to investigate whether the 'identical' client
> written in C (or some such) behaves as expected on that
> box..

good idea (although I thought this library was pretty close
to the foreign metal anyway?). the standard client/server-example 
from the perlipc man page appears to work (they use PF_INET
as well as AF_INET, but one is defined in terms of the other).
Hmm, that means it isn't my machine..  (unless perl is clever as 
usual; oh, and that was a cygwin perl, but still..)

> The HEAD version of the 'network' package tidies up the
> propagation of WinSock errors. It also drops the need for
> the user to remember to use withSocketsDo.

Thanks, that was quick. Have updated my libraries tree, but
don't build ghc from source (no space left here..). How do I
build libraries/network with my installed ghc-5.04 (?? have
there been any socket-relevant fixes since then, checking
with 5.04.2 [which resets my filetype settings for .hs].. no)? 

The building guide asks for a mingw-gcc to be specified for 
configure, so I simply tried specifying the one in the ghc-5.04 
directory, which causes configure to fail (gcc can't create files 
or so).

Well, we'll see..

Thanks for the help,
Claus


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Network on Win98: failed - socket - no error ??

[Claus Reinke]

[moved from ghc-users]

I'm still not sure what I'm doing wrong in using the Network library,
(inserting WSAGetLastError after the socket call returns 10047 -
address family not supported by protocol family; better than "no error",
but what do I do about it? modified source attached for reference),
but the handling of errors in Network now definitely looks like a bug to me:

When the implementation is based on WinSock, functions should not check
for errno, but for WSAGetLastError, especially so if control-flow depends on
the result..

Cheers,
Claus


WSAEAFNOSUPPORT 10047
Address family not supported by protocol family.
An address incompatible with the requested protocol was used. All sockets are created 
with an
associated address family (that is, AF_INET for Internet Protocols) and a generic 
protocol type
(that is, SOCK_STREAM). This error is returned if an incorrect protocol is explicitly 
requested in
the socket call, or if an address of the wrong family is used for a socket, for 
example, in sendto.


> Still looking for inspirations on this one. I'm not at all sure I interpret the chain
> of indirections in the CVS sources correctly, but Network.Socket uses
> throwErrnoIfMinus1Retry, which does indeed try to use errno to figure out
> what went wrong. Is that redirected anywhere for windows?
>
> Because, in their infinite wisdom, the designers of Windows Sockets have
> decided that errno isn't the way:
>
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/error_codes_errno_h
> _errno_and_wsagetlasterror_2.asp
>
> Platform SDK: Windows Sockets 2
>
> Error Codes - errno, h_errno and WSAGetLastError
>
> Error codes set by Windows Sockets are not made available through the errno 
> variable.
> Additionally, for the getXbyY class of functions, error codes are not made available 
> through the
> h_errno variable. Instead, error codes are accessed by using the WSAGetLastError 
> function. This
> function is provided in Windows Sockets as a precursor (and eventually an alias) for 
> the
Microsoft®
> Windows® function GetLastError. This is intended to provide a reliable way for a 
> thread in a
> multithreaded process to obtain per-thread error information.
> ...
>
> Just trying to make sure that I'm worrying about the "right" error message..
>
> Cheers,
> Claus
>
>
> - Original Message -
> From: "Claus Reinke" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, March 03, 2003 12:14 PM
> Subject: Network on Win98: failed - socket - no error ??
>
>
> > I'm playing with the Network library (the recommended portable way?) and
> > have a surprising problem with a simple client/server example. As the same
> > program works fine on Solaris and Win2k, I suspect its a standard "feature"
> > and someone here with more network programming experience might be
> > able to enlighten me?
> >
> > - Server: listenOn port, then accept handle and enter loop, echoing from
> > handle to stdout
> > - Client: connectTo "localhost" port, then enter loop echoing from
> > stdin to handle
> >
> > Both programs work on Solaris and Win2k, but fail on Win98, with:
> >
> > Fail: failed
> > Action: socket
> > Reason: No error
> >
> > which would be merely amusing, I guess, if I knew what it meant, and
> > what to do about it?
> >
> > Cheers,
> > Claus



Client.hs
Description: Binary data

Re: Directory.doesDirectoryExist inconsistency

[Claus Reinke]

| > That would take care of the incompatibility here, but
| > it's a slippery slope.  Should Haskell provide you with
| > a platform-independent view of filenames and file systems?

Just because that wouldn't be practical doesn't mean it wouldn't be the
right thing to do (and vice versa, unfortunately). As I mentioned to
Sigbjorn earlier, I'd like to see Haskell, as a higher-level language,
being better at protecting programmers from details they don't want to
see, even if other languages don't do this. Ghc's graceful handling
of \ and / in paths is a nice example.

I assumed from Sigbjorn's response that the system call implementing
doesDirectoryExist is not the only one suffering from this or other
unwanted "features", so he wasn't against fixing this but pointed out
that just fixing this one wouldn't be a clean overall solution. 

For starters, it would be nice to have a list of such portability
issues, so that it'd be easier to avoid them (or at least to spot them
later), and posted at haskell.org, so that Haskellers refer to it when
writing code. When I was still a C programmer, seeing such a list of
things to avoid in portable software was quite helpful, and now I'm more
and more running into non-portable tricks in Haskell programs..

To ensure portability not only across ghc on different OSs, but also
across different Haskell implementations on different OSs, any
compatibility fixes should probably be shared between Haskell
implementations as well, so perhaps this is an issues for the libraries?

| For example, I think that Haskell 98 library functions should have
| particular care applied to them and I think that the trailing "/"
| problem should be eliminated.  Allowable cross platform variations 
| should be documented in the standard.

Agreed.

>This is exactly my position too.   Yes, it's a slippery slope, but so is
>all of life.  We should strive to conceal gratuitous differences where
>they are easy to conceal, but without ever pretending that the Win32 and
>Unix are identical.  

Okay. I assume that the reason mingw itself doesn't provide even such
"shallow" compatibility wrappers is that they don't want to introduce
extra libraries? Otherwise one could try to lobby them..

As for the specific problem at hand, it seems that a trailing slash in
doesDirectoryExist is always an error, no? So, Haskell implementations
should either deal with it gracefully (as currently on unixes, or by
removing trailing slashes on windows) or report the error (if no entry,
check for trailing slash), not fail silently (as currently on windows)..

In my case, I don't have control about the path parameters to
doesDirectoryExist, so I redirect calls via a trivial wrapper that removes
trailing slashes. But there's no reason why this code should be in
this application.

Cheers,
Claus

--
Haskell Communities and Activities Report (November 2002 edition)
All contributions are due in by the end of October!
http://www.haskell.org/communities/



___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Directory.doesDirectoryExist inconsistency

[Claus Reinke]

I've just been chasing a portability problem, where a largish third-party
program works fine on our suns (ghc-5.02.3), but chokes under
cygwin/windows (ghc-5.04). Comes down to an inconsistency in the
handling of (trailing?) slashes in Directory.doesDirectoryExist (see
a and b below).

Consequence: under cygwin, the program doesn't see the existing directory,
tries to create it, and fails (error message doesn't seem to include the file
name, btw).

Cheers,
Claus

$ uname -a
CYGWIN_98-4.10 VAIO 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown

$ ghci
   ___ ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |  GHC Interactive, version 5.04, for Haskell 98.
/ /_\\/ __  / /___| |  http://www.haskell.org/ghc/
\/\/ /_/\/|_|  Type :? for help.

Loading package base ... linking ... done.
Loading package haskell98 ... linking ... done.
Prelude>
Prelude> Directory.doesDirectoryExist "u" >>= print
False
Prelude> Directory.createDirectory "u"
Prelude> Directory.doesDirectoryExist "u" >>= print
True
Prelude> Directory.doesDirectoryExist "u/" >>= print  -- (a)
note this one, compare with b
False
Prelude> Directory.doesDirectoryExist "u\\" >>= print
False
Prelude> :q
Leaving GHCi.

> uname -a
SunOS myrtle 5.8 Generic_108528-16 sun4u sparc SUNW,Ultra-4
> ghci
   ___ ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |  GHC Interactive, version 5.02.3, for Haskell 98.
/ /_\\/ __  / /___| |  http://www.haskell.org/ghc/
\/\/ /_/\/|_|  Type :? for help.

Loading package std ... linking ... done.
Prelude> Directory.doesDirectoryExist "u" >>= print
False
Prelude> Directory.createDirectory "u"
Prelude> Directory.doesDirectoryExist "u" >>= print
True
Prelude> Directory.doesDirectoryExist "u/" >>= print-- (b) note
this one, compare with a
True
Prelude> Directory.doesDirectoryExist "u\\" >>= print
False
Prelude> :q
Leaving GHCi.



___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Cygwin path support for ghc under Windows?

[Claus Reinke]

> When I look at the Win32-specific portion of the Makefile, it appears
> that the *only* reason that I can't write one simple, portable GNU make
> Makefile that would work on Linux and Windows is because ghc only
> understands the Windows-style path name convention (with '\' as the path
> seperator, and ':' for drive letters).  All of the other Cygwin tools
> understand both the Windows-style and Cygwin/POSIX-style path names.

(You might still have the problem for the Java-side of your software?)

Anyway, perhaps "cygpath" could help you to factor out any filepath
translations? It solved a similar problem with some of the Java-based
tools in nhc98..

Claus

--
$ cygpath --help
Usage: cygpath [-p|--path] (-u|--unix)|(-w|--windows [-s|--short-name]) filename

  -a|--absolute output absolute path
  -c|--close handle close handle (for use in captured process)
  -f|--file fileread file for path information
  -u|--unix print Unix form of filename
  -w|--windows  print Windows form of filename
  -s|--short-name   print Windows short form of filename
  -W|--windir   print `Windows' directory
  -S|--sysdir   print `system' directory
  -p|--path filename argument is a path
  -i|--ignore   ignore missing argument

$ cygpath -wa .
D:\cygwin\home\Standard





___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Redundancy in implicit parameter error messages

[Claus Reinke]

>Your wish is my command.   (At least when I'm flying transatlantic.)

Is there a map of places, routes, and means of transport which played
a role in the history of ghc development?-)

Just curious,
Claus


___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Heap overflow is not catched

[Claus Reinke]

> > 1. A thread is either resource-aware or abstracts away the details
> > and difficulties of resource management.
> > 2. If resource availablity is high, both kinds of threads can allocate
> > (in case of memory: implicitly, as usual in functional programs).
> > 3. If resource availability is low,
> > - resource-aware threads receive an asynchronous exception, 
> >but may then proceed to allocate as before 
> >(until the resource is actually exhausted)
> > - resource-unaware threads block on allocation attempts
 
> Which resource-aware threads will receive the exeption?

All. As the name suggests, resource-aware threads are those that
have registered an interest in details related to the resource. 
Registering interest could be implicit in setting up an exception
handler of appropriate type, but would probably better be done 
by an explicit operation:

-- input: which resources we are interested in
-- result: which resources we could not register for,
--usually empty?
registerInterest :: [ResourceId] -> IO [ResourceId]
 
> How a handler thread can ensure that it has freed enough memory to
> unblock threads that are blocked, or that to get an exception again
> instead of reaching a hard limit and crashing?

I suggested a new resource-check operation for this. Perhaps:

data ResourceId = Memory | ..
data ResourceStatus = Ok | Low | NotAvailable

checkStatus :: ResourceId -> IO ResourceStatus

(in case of Memory, there won't be a chance to observe NotAvailable..;
to accomodate other resources and to facilitate preventive measures,
ResourceStatus should probably be refined, but adding a percentage
parameter of type Int to Ok, and perhaps to Low, should really be 
enough)

Resource-aware threads could occasionally monitor the status of
resources and steer other threads accordingly to avoid reaching the
(soft) limit (transition from Ok to Low) and the disruption caused
by this event. But if it should be reached, they will enter their 
exception handlers for more drastic measures. The basic 
handler-loop would be:

1. do something to reduce resource allocation 
(both now and in future - the latter might require preparing a 
reconfiguration of the thread system to employ a modified 
algorithm; just crossing your fingers and trying again will 
probably not do)
2. check resource status
3. repeat from 1. until good enough to continue
4. continue in modified configuration, with new handlers

Given the nature of lazy evaluation, it will in any case be tricky to
write exception handlers that do not cause inadvertent memory 
allocation themselves..

Claus

Re: Heap overflow is not catched

[Claus Reinke]

> Must it be so complicated? I hope that something sensible will be
> possible with rules that are simple and easy to understand...

:-) sorry for posting the suggestion before reducing it to its full
simplicity. But as I mentioned, the implementation (or semantic
rules) should be a lot simpler than the textual description, which
included motivation and justification. Let's see:

1. A thread is either resource-aware or abstracts away the details
and difficulties of resource management.
2. If resource availablity is high, both kinds of threads can allocate
(in case of memory: implicitly, as usual in functional programs).
3. If resource availability is low,
- resource-aware threads receive an asynchronous exception, 
   but may then proceed to allocate as before 
   (until the resource is actually exhausted)
- resource-unaware threads block on allocation attempts

That's it! Not that complicated, is it? Now, whether this is 
something sensible, that's another question..

Claus

PS The rationale can be simplified, too:
- resource-unaware threads use simplified code, assuming
   infinite resources, so they don't know what to do near
   resource limits. 
==> get them out of harm's way
   - resource-aware threads use simplified code, too, but they
  know how to handle resource shortages, via exception
  handlers. 
==> warn them at the soft limit, but let them proceed
   - resource-aware threads may be able to get the system 
  out of the critical state, so resource-unaware threads
  need not be terminated. 
==> block them until everything is back to normal

Re: Heap overflow is not catched

[Claus Reinke]

From: Simon Marlow <[EMAIL PROTECTED]>
> Yes, I know: heap overflow is somewhat trickier than stack overflow.  If
the
> stack overflows, at least you know that by raising an exception you're
going
> to reduce the size of the stack, the same isn't true of heap overflow, so
> you need some kind of "soft limit" after which the exception is thrown.

I don't think the problem can be dealt with by exceptions alone. Unless
every thread receives the exception (which would complicate programs),
the threads that do receive it need a little help from the scheduler so that
they can try to clean up without interference from the remaining threads.

Resource exhaustion is critical information. When the limit is reached,
every
thread allocating from the same "resource pool" (i.e., not on another
machine)
has to react or be acted on. Any thread that does not receive the exception
has to be terminated (suspension might be enough, though) if it attempts to
claim further resources before the crisis has been resolved.

For illustration, consider several limits:

soft 2: dear software , we are going to run out of
 soon. Could you please look into this?

soft 1: to all software :  is low.
Do something, or I'll do something.

hard 0:  unavailable, all further requests for it fail.

hard -1: no further progress possible. clean up system for restart.

For soft 2, it might suffice to throw an exception only to a manager thread
(main by default), but when soft 1 is reached, no thread that is unaware of
the problem should be allowed to contribute to it. It's a soft version of
hard 0, so I would try to suspend any thread (in the current resource pool)
that tries to allocate (the resource in question) without being aware that
the pool is in soft 1 for that resource.

> And which thread should get the exception?  All of them?  Just the one
that
> was allocating at the time?  The main thread?  (this reminds me of one of
> the great open questions in OS design: if you run out of memory, which
> process do you kill?).  Perhaps a thread should have to register in order
to
> receive the heapOverflow exception, or maybe you should install a "heap
> overflow handler", like a signal handler.  Comments?

With the explanation given above, I would say: the whole system of threads
should get the exception, but that doesn't necessarily mean that each and
every thread gets it (and with soft limits, you don't need to kill any
process,
just change the environment so that problematic processes kill themselves) .
Rather, when resource R in pool P is low, the threads can be grouped into

- manager threads:
receive exception, try to deal with it
- affected non-manager threads:
don't get exception, try to allocate R in P
- neutral threads:
don't get exception, don't use R in P

Neutral threads don't interfere and can be kept active, probably even
running (it is tempting to allocate all other resources - such as processor
time - to problem resolution instead of sharing them with neutral threads,
but I don't know whether that would be wise: if my browser runs out of
memory, I don't want the rest of my system to stall until the browser has
solved its problem).

As soon as a neutral thread becomes affected, it should be suspended.

Manager threads continue to run up to hard 0, and if they can make
further progress without allocating R in P, they may run up to hard -1.
If they manage to resolve the crisis, suspended affected threads will
wake up without specific actions, and if all managers fail before
resolving the crisis, the runtime system has to clean up.

How can a manager thread resolve the crisis?
Mainly by terminating threads (it can start with those that can be
restarted without starting the whole computation from scratch),
perhaps restarting them later, in a less resource-hungry mode.
Note that suspended threads in CH are interruptible by default, so
that even threads blocking on resource R in P can be terminated by
thowing them an appropriate exception. Another option is to shift
resources at CH level (such as emptying input MVars or filling
output MVars) in order to suspend or restrain resource hungry
threads until later.

When is later?
Manager threads need a way to find out when their job is done!
This could be a `resource available'-exception, but an explicit
status enquiry is probably easier to handle.

The implementation might be simpler that it looks at first sight:
the RTS knows which resources are low, but it also needs to know
which threads are aware of this (keeping a list of threads that have
received the corresponding exception). Then, during a crisis,
it can grant allocation requests from crisis-aware threads and
suspend all others (giving priority to managers without even
knowing about the concept). When everything is blocked, the
RTS has to act anyway, and resource pools are given implicitly
by "running in the same RTS instance". Status enquiries for
resources seem to be new, but unproblematic, and w

Re: Question about Haskell-Direct

[Claus Reinke]

>Sigbjorn writes:
>Shane Stephens <[EMAIL PROTECTED]> writes:
>>..
>> What I want to know is - what would be the best way to run a haskell
>> function as a method in a Java class?  (And how would I do this...)
>
>an alltogether Fine Idea this - the Java Native Interface (JNI) would
>be one way to go, accessing Haskell code via a native method.

Yes, but the direct solution depends on Haskell being callable from the
outside world. Unless the HaskellDirect docs have already been updated,
Shane might want to look at 

  "Calling hell from heaven and heaven from hell"
  http://research.microsoft.com/Users/simonpj/#comserve

for a discussion of some of the issues involved.

>Wrapping the Haskell code up inside a COM component is another way
>(ok, I'm partially showing my colours here :) Employing CORBA is
>yet another.

Java->COM->Haskell is probably closer to being implemented than
Java->CORBA->Haskell? Currently, this would still be specific to
Microsoft platforms because the Java->COM part isn't standard, but it
might be an acceptable interim solution if you only want to play with
your ideas on a Windows system.

>Claus Reinke has done quite a bit of work on integrating Haskell
>with Java through the JNI, see http://www.cs.nott.ac.uk/~czr/JNI/
>I might be wrong about this, but the emphasis is there to use Java
>from Haskell, and not the other way around. 

You are right about the emphasis. There is an indirect way to use a
Haskell->JNI->Java connection for calling Haskell from Java (the York
group described a similar approach for calling Haskell from C using
GreenCard

  http://www.cs.york.ac.uk/fp/nhc13/CcallingHaskell.html ), 
  
but with the FFI for GHC and Hugs relatively close to implementation, I
haven't explore that option yet.

>In any case, there's bound to be lots of useful info/code in there to
>either build on or use.

I hope so (although the web page should have more of the references
given in the paper).  There have been quite a lot of "rearrangements"
regarding Hugs and GHC recently, and I haven't been unaffected by this.
Basically, I haven't been able to work on the software this year, i.e.,
the state is still very much as described in

  "Towards a Haskell/Java connection"
  Implementation of Functional Languages, IFL'98, London, September 1998 
  (the post-workshop proceedings have still not appeared, but you can
  contact me if you want a preprint of the paper),

which is not bad, but not nearly as good as I would like it to be.
Fortunately, noone has complained yet, and I have a personal interest to
continue the work. I recall only two problems with Haskell/JNI itself:

 - no finalizers for JNI object references (no real problem thanks to
   GreenCard, but there were some unclear points in the JNI spec; will 
   add them as soon as I get back to the software)
 - some minor, but annoying incompatibilities between GreenCard for
   Hugs and for GHC (I focussed on Hugs, but I think Sigbjorn did
   some more work on GreenCard for GHC before retiring from his FFI
   developer role, so perhaps I should look at this again..)

So you should be able to use Haskell/JNI for doing Java graphics from
Hugs if you don't need callbacks (it would take some more effort to get
around the current callback problem, or some patience until the problem
is solved properly). 

The real problem is that Java facilities never come in small pieces
(even the 2D API documentation has quite a few pages, lots of methods
and dependencies..). The last thing I started to work on was thus a way
to generate the necessary glue code for using a Java class via
Haskell/JNI automatically from the class file (a kind of GreenCard for
Java to make calling Java from Haskell via Haskell/JNI more
convenient:-). A base version of this didn't seem difficult, but I have
yet to find the time to continue working on it..

In brief, we agree on the idea, and some of what we want is already
there, but it will take some more time before the various parts (Haskell
FFI, HaskellDirect for GHC/Hugs, Haskell/JNI, etc.) work together to
make interoperation between Haskell and Java convenient for programmers.
Encouragement from potential users is always welcome.

Claus

PS. Since the question came on a ghc list (why bugs?-), I gave GHC or
Hugs specific answers. If the question was about Haskell and Java in
general, David Wakeling's work is also worth looking at, even though
he didn't focus on cross-language calls:

  http://www.dcs.exeter.ac.uk/~david/research/java.htm