Subject: [GHC] #660: binary snapshot install crashes on ps docs - msg#00119
List: lang.haskell.glasgow.bugs
#660: binary snapshot install crashes on ps docs
-----------------------------------------------+----------------------------
Reporter: Chuck Adams <cja987@xxxxxxxxx> | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.4.2
Component: Build System | Version: 6.4.1
Severity: normal | Keywords:
Os: Unknown | Difficulty: Easy (1 hr)
Architecture: Unknown |
-----------------------------------------------+----------------------------
Reported by
The lack of ps documentation in the snapshot builds causes 'make
install' to exit ungracefully. Granted it's the last step so it's
harmless, but it looks like things failed.
To wit:
{{{
if test -d share/html ; then cp -r share/html/*
/biztools/pkg/ghc-6.5.20060105/share/ghc-6.5.20060105/html ; fi
for i in share/*.ps; do \
cp $i /biztools/pkg/ghc-6.5.20060105/share/ghc-6.5.20060105 ; \
done
cp: cannot stat `share/*.ps': No such file or directory
make: *** [install-docs] Error 1
}}}
--
Ticket URL: <
http://cvs.haskell.org/trac/ghc/ticket/660>
GHC <
http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@xxxxxxxxxxx
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Was this page helpful?
Thread at a glance:
Previous Message by Date:
click to view message preview
Re: [GHC] #647: Socket bug on Mac OS X, with patch
#647: Socket bug on Mac OS X, with patch
----------------------------------+-----------------------------------------
Reporter: gwright@xxxxxxxxxxx | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: libraries/network | Version: 6.4.1
Severity: normal | Resolution:
Keywords: "OS X" Sockets | Os: MacOS X
Difficulty: Easy (1 hr) | Architecture: powerpc
----------------------------------+-----------------------------------------
Comment (by vs@xxxxxxxxx):
Looking at sockaddr, sa_len looks like to be the culprit since it isn't
initialized and thus a likely candidate to contain bogus values. The other
members of the structure should all get initialized explicitly.
Could you try initializing this field with the proper length?
Other applications explicitly test the presence of sa_len, but I doubt
that GHC runs no OSes that do not have this member anyway.
Volker
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/647>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@xxxxxxxxxxx
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Next Message by Date:
click to view message preview
Re: [GHC] #659: Code bloat for instances of empty classes
#659: Code bloat for instances of empty classes
--------------------------+-------------------------------------------------
Reporter: wolfgang | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.6
Component: Compiler | Version: 6.4.1
Severity: trivial | Resolution:
Keywords: | Os: Multiple
Difficulty: Easy (1 hr) | Architecture: Multiple
--------------------------+-------------------------------------------------
Changes (by simonmar):
* milestone: => 6.6
--
Ticket URL: <http://cvs.haskell.org/trac/ghc/ticket/659>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@xxxxxxxxxxx
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Previous Message by Thread:
click to view message preview
[GHC] #659: Code bloat for instances of empty classes
#659: Code bloat for instances of empty classes
-------------------------+--------------------------------------------------
Reporter: wolfgang | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.4.1
Severity: trivial | Keywords:
Os: Multiple | Difficulty: Easy (1 hr)
Architecture: Multiple |
-------------------------+--------------------------------------------------
TcInstDcls has a special case for empty classes that leads to a seemingly
unnecessary increase in code size. Comments refer to CCallable and
CReturnable, so I think this is just a leftover; removing it didn't cause
any crashes for me, but a Wizard who knows the code should have a short
glance at it first.
{{{
Index: ghc/compiler/typecheck/TcInstDcls.lhs
===================================================================
RCS file: /home/cvs/root/fptools/ghc/compiler/typecheck/TcInstDcls.lhs,v
retrieving revision 1.182
diff -u -r1.182 TcInstDcls.lhs
--- ghc/compiler/typecheck/TcInstDcls.lhs 6 Jan 2006 16:30:19 -0000
1.182
+++ ghc/compiler/typecheck/TcInstDcls.lhs 17 Jan 2006 02:18:19 -0000
@@ -395,18 +395,6 @@
-- See Note [Inline dfuns] below
dict_rhs
- | null scs_and_meths
- = -- Blatant special case for CCallable, CReturnable
- -- If the dictionary is empty then we should never
- -- select anything from it, so we make its RHS just
- -- emit an error message. This in turn means that we
don't
- -- mention the constructor, which doesn't exist for
CCallable, CReturnable
- -- Hardly beautiful, but only three extra lines.
- nlHsApp (noLoc $ TyApp (nlHsVar rUNTIME_ERROR_ID)
- [idType this_dict_id])
- (nlHsLit (HsStringPrim (mkFastString msg)))
-
- | otherwise -- The common case
= mkHsConApp dict_constr inst_tys' (map HsVar scs_and_meths)
-- We don't produce a binding for the dict_constr; instead
we
-- rely on the simplifier to unfold this saturated
application
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/659>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@xxxxxxxxxxx
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Next Message by Thread:
click to view message preview
Re: ghci module list
Frederik Eaton wrote:
Ghci still seems to be erasing the "list of current imported modules"
(I'm sorry I don't know what to call it) whenever I load a file;
sometimes this even means removing the module corresponding to the
just-loaded file from that list...
*Fu.Vector> :load "Boost.hs"
...
Ok, modules loaded: Fu.Vector, Fu.Prepose, Boost.
*Fu.Vector> :m + Boost
*Fu.Vector Boost> :load "Boost.hs"
...
Ok, modules loaded: Fu.Vector, Fu.Prepose, Boost.
*Fu.Vector> -- after the load command, Boost is missing
On an aside, I was wondering about the feasibility of having some sort
of feature resembling Octave's (and probably Matlab's) "function
files" implementation, in which modified files are automatically
reloaded by the interpreter. I guess a timestamp check could happen
for each loaded module before ghci executes each new piece of
command-line input. I wonder how useful people think this would be.
$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 6.5.20051208
Since you're using HEAD, perhaps you could try this again? I believe
the behaviuor should be better now.
Cheers,
Simon