osdir.com
mailing list archive

Subject: [GHC] #660: binary snapshot install crashes on ps docs - msg#00119

List: lang.haskell.glasgow.bugs

Date: Prev Next Index Thread: Prev Next Index
#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?
Yes No
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
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by