There is a difference between hugs and ghc in how they treat imports with the
'(..)' notation. Here's my example:
module CTree(
--other stuff
Const(..)
) where
import ATree (Const)
--const has constructors CInt, CChar, CStr
under hugs this module exports CInt, CChar, CStr
The pretty printing module 'Pretty' in the text package does not export the
($+$) operator. The documentation says it does (and it certianly should).
I'm using ghc 5.02.1
Duncan
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
On 2002.02.18 00:43:48 + Sigbjorn Finne wrote:
Strange, the following compiles just fine with
5.02.1 on a Win2k box:
module Foo where { import Pretty ; x y = y Pretty.$+$ y }
Yep, your quite right. I discovered my problem was to do with search paths.
I had a Pretty.hs from the CTK, a
Is this a known TH bug?
import Language.Haskell.THSyntax
foo e = $( [| e |] )
$ ghc -fglasgow-exts AlternateTH.hs
ghc-6.2: panic! (the `impossible' happened, GHC version 6.2):
nameModule e {- v a8 -}
Please report it as a compiler bug to [EMAIL PROTECTED],
or
On Wed, 2004-02-04 at 09:51, Simon Peyton-Jones wrote:
Yes, it's a known bug. You need the HEAD, I'm afraid, where it's been
fixed for some time.
Ok, trying to build from cvs...
I (think I've) followed the instuctions at
http://haskell.org/ghc/docs/latest/html/building/sec-cvs.html#CVS-FIRST
Hi,
I noticed that the 6.3 version of the PprLib.hs is not fully implemented
so pretty printing some things calls Prelude.undefined.
With the other monadic version of the HughesPJ combinators you can just
wrap them using liftM or similar but that doesn't work out so well for
punctuate as the
In ghc 6.2 and 6.3 (CVS as of early March) evaluating the following in
ghci gives an impossible happened error.
do {d - runQ $ [| let foo = bar where bar = 3 in foo |]; print d}
The bit that causes the problem is the where in the declaration context
introduced by the let.
ghci-6.2 says:
I'm using the new abstract names of TH2 in ghc 6.3 (CVS early March)
I'm generating code that looks like this:
let foo_1 = e1
foo_2 = e2
in e3
I'm using
name - newName foo
to generate these names (foo_1, foo_2 etc) however when I splice this
code in ghc complains as if I'd written
let
http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/Function-Attributes.html
The gcc manual says:
malloc
The malloc attribute is used to tell the compiler that a
function may be treated as if it were the malloc function. The
compiler assumes that calls to malloc result in
In the past month or two a few convenience functions from
Language.Haskell.TH.Lib seem to have been dropped from the export list
for Language.Haskell.TH. This is in ghc cvs HEAD.
Just wondering if this was an oversight or if there was a reason.
The ones I noticed are: forallT, listT, infixC
Compile the following module:
main = interact id
ghc-6.2.1 Test.hs -o test
./test
^C
test: internal error: main thread has been GC'd
Please report this as a bug to [EMAIL PROTECTED],
or http://www.sourceforge.net/projects/ghc/
So you run the program, it does nothing as expected. You hit
This is fairly low priority:
Language.Haskell.THSyntax e - runQ [| Control.Exception.assert |]
ghc-6.3: panic! (the `impossible' happened, GHC version 6.3):
DsMeta.repLiteral: trying to represent exotic literal
GenexTest.hs:319:40-45#
Please report it as a compiler bug to [EMAIL
There do not seem to be Lift instance declarations for tuples:
:t lift (3::Int,4::Int)
No instance for (Lift (Int, Int))
arising from use of `lift' at No locn
They are easy to add (up to a fixed size)
instance (Lift a, Lift b) = Lift (a,b)
lift (a,b) = tupE [lift a, lift b]
It would be
Suppose we have
ModuleA.hs (and .o)
exports funcA :: Something - ExpQ
ModuleB.hs (and .o)
has definition
funcB = $(funcA something)
Now if we edit the implementation (but not the signature) of funcA in
ModuleA.hs and run
$ ghc -fth --make ModuleB
then ModuleA is recomplied but ModuleB is not.
On Thu, 2004-05-27 at 11:06, Simon Peyton-Jones wrote:
A crude but simple story could be:
with -fth, switch off fine-grain dependency tracking
instead just use the modification dates on the files
Would that be better?
Too much recompilation is better than too little in that at
Here's another low priority TH buglet:
Prelude ''[]
GHC.Base.[] --works as expected
Prelude '[]
interactive:1:1: parse error on input `['
There is a similar parsing problem for these names:
() (,) (,,) etc
All of these work when you use ''() to get the name of the type.
While we're on
ghc makes it's own type checker monad TcM an instance of the Quasi class
(which is rather cunning), however this means that if the user calls the
Monad function 'fail' then the internal TcM fail method gets called.
This monad (IOEnv) was never meant to fail (see
ghc/compiler/utils/IOEnv.hs/) so
On Wed, 2004-06-23 at 01:13, Duncan Coutts wrote:
ghc makes it's own type checker monad TcM an instance of the Quasi class
(which is rather cunning), however this means that if the user calls the
Monad function 'fail' then the internal TcM fail method gets called.
This monad (IOEnv) was never
Hi,
This was posted to the Haskell list earlier,
http://www.haskell.org//pipermail/haskell/2004-June/014286.html
but just to record what appears to be a typechecker bug.
I have a function with this type:
buildUArray' :: (Ix i, MArray (array s) a (ST s)) =
(i,i) - (i - a) - ST s
Hi,
Sorry this is a rather complicated bug report but I think I've tracked
it down, please bear with me. :-)
It involves C code, FFI and optimisations (all seem to be required).
Nice.
The problem shows up as a double value loosing precision when it is sent
to C land and back. It's because ghc
On Sat, 2004-08-07 at 18:52, Duncan Coutts wrote:
Attached is a small collection of modules which exhibit the problem.
If I make the test case much smaller, the problem goes away. It's not
too complicated code though. Some imports were hacked around and a few
bits commented out to get it out
Hi,
Further to this bug report:
http://www.haskell.org//pipermail/glasgow-haskell-bugs/2004-November/004454.html
http://sourceforge.net/tracker/?func=detailatid=108032aid=1071030group_id=8032
Gour has done some further investigation:
http://bugs.gentoo.org/show_bug.cgi?id=70982#c10
The main
On Fri, 2005-01-07 at 19:52 +, Duncan Coutts wrote:
However when building some files, eg
gtk/Graphics/UI/Gtk/Abstract/Object.hs
ghc does not look in the right places for .hi files.
I think I figured out what was happening, so let me retract my bug
report and instead ask for some friendly
So I think probably a module like Graphics.UI.Gtk.Foo is importing
and re-exporting from Graphics.UI.Gtk.Signals. Because, and only
because, the file Signals.hi is in the directory Graphics/UI/Gtk,
the import works.
Aha! I see now. GHC 6.4 has an improvement here:
$ cat A.hs
Hi,
On all Unix platforms except Darwin, ghc-pkg calls:
ld -r -x -o HSfoo.o --whole-archive libHSfoo.a
See:
ghc/utils/ghc-pkg/Main.hs, function autoBuildGHCiLib
This works for the GNU linker. For the Solaris linker (which takes the
name ld, GNU ld gets gld if it's installed) this does not work.
Hi,
In ghc 6.4 using -M mode it appears to be stricter when parsing the
files looking for dependencies. In particular importing things with '#'
suffixes eg:
import GHC.Really.Really.Internal.Dont.Touch (unsafeNastyThing#)
did not require the -fglasgow-exts option. In ghc 6.4 it does require
On Fri, 2005-03-04 at 10:49 +, Simon Marlow wrote:
However then it does not look at the {-# OPTIONS -fglasgow-exts #-}
pragma at the top of the file.
Strange... it works for me. ghc -M now uses the same machinery as
--make when calculating the dependency graph, so {-# OPTIONS #-}
Hi,
This sort of code runs very slowly when compared to the equivalent in C:
{-# OPTIONS -fglasgow-exts #-}
module Main where
import Data.Array.MArray
import Data.Array.IO
data Pos = Pos !Int !Int
deriving (Eq, Ord, Ix)
main = test1
test1 :: IO ()
test1 = do
(arr ::
On Mon, 2005-03-14 at 13:41 +, Duncan Coutts wrote:
Hi,
This sort of code runs very slowly when compared to the equivalent in C:
[snip]
BTW These timings were for ghc 6.2.2
My version of ghc 6.3 (CVS from about a month or two ago) gave slightly
beter timings on both loop version.
My
On Tue, 2005-03-15 at 01:39 +0100, Josef Svenningsson wrote:
Hi,
On Mon, 14 Mar 2005 13:41:06 +, Duncan Coutts
[EMAIL PROTECTED] wrote:
This sort of code runs very slowly when compared to the equivalent in C:
I'm afraid the kind of array processing code you posted will always
On Tue, 2005-03-15 at 02:06 +0100, Lemmih wrote:
We can make it a little faster by not doing bound checks:
test4 :: IO ()
test4 = do
(arr :: IOUArray Int Bool) - newArray_ (0,100*100-1)
doFromTo 0 $ \_ -
doFromTo 0 99 $ \y -
doFromTo 0 99 $ \x -
On Tue, 2005-04-05 at 23:34 +0100, Simon Marlow wrote:
Well it turns out that we had another package installed that depends
on the util package (cabal-0.5 as it happens) and that package is
exposed by default. It seems that this implicitly exposes the util
package.
This is the right
On Fri, 2005-06-03 at 09:22 +0100, Simon Marlow wrote:
On 02 June 2005 16:48, Duncan Coutts wrote:
I have a program which runs to completion on windows in about 90Mb of
heap space. Ie the following works ok:
prog.exe +RTS -M90m -RTS
However if I use the -H option to reserve
On Mon, 2005-06-13 at 16:06 +0100, Simon Marlow wrote:
This is fixed in newer versions of Cabal.
However, you are heading for problems here. When you install a package
P that includes a module M, you prevent the user from having any modules
called M unless they say '-hide-package P' (see
On Wed, 2005-06-15 at 13:15 +0100, Simon Marlow wrote:
But remember that any exposed dependent package of P effectively
exposes package P anyway. So it's not the case that you can install
an unexposed package and assume that it'll all be ok. Any package
installed later can come along and
On Wed, 2005-06-15 at 14:47 +0100, Simon Marlow wrote:
On 15 June 2005 13:49, Duncan Coutts wrote:
I think the bug in this case is the fact that the modules are
considered to be part your program even though they are never
imported (directly or indirectly) or even any modules from
All,
The :tags for ghci feature that recently went into cvs:
http://www.haskell.org/pipermail/cvs-ghc/2005-June/025436.html
means that unfortunately saying:
:t blah
now complains that :t is ambiguous because it could be :tags or :type.
I think this may upset people! :-) People are very used
On Mon, 2005-07-25 at 11:53 +0100, Simon Marlow wrote:
On 25 July 2005 02:25, Duncan Coutts wrote:
The :tags for ghci feature that recently went into cvs:
http://www.haskell.org/pipermail/cvs-ghc/2005-June/025436.html
means that unfortunately saying:
t blah
now complains
All,
With our current 6.4.1 snapshot 20050819, we have problems building when
we've got more than over version of cabal registered.
That is we build it using ghc 6.4 and we have cabal-1.0 and cabal-1.1.2
installed. Then it complains that multiple packages match -package
cabal.
It also has
if there is no Cabal, 1 cabal or 2+ Cabal versions
installed. Andres's disclamer is that it might make some gentoo-specific
assumptions.
Duncan
On 24 August 2005 14:42, Duncan Coutts wrote:
With our current 6.4.1 snapshot 20050819, we have problems building
when we've got more than over version
extraGHCiLibraries over extraLibraries for GHCi
Duncan Coutts [EMAIL PROTECTED]**20051130121139] {
hunk ./ghc/compiler/ghci/Linker.lhs 759
-let libs = Packages.hsLibraries pkg ++ Packages.extraLibraries
pkg
- ++ [ lib | '-':'l':lib - Packages.ldOptions
pkg
On Fri, 2005-12-02 at 11:06 +, Simon Marlow wrote:
On 30 November 2005 12:29, Duncan Coutts wrote:
Attached is a simple code change to allow packages to specify a
different list of extra libraries to link with when using the ghci
and dlopen/LoadLibrary compared to when using
On Fri, 2005-12-09 at 15:04 +0100, Sven Panne wrote:
Am Mittwoch, 7. Dezember 2005 12:21 schrieb Duncan Coutts:
On Fri, 2005-12-02 at 11:06 +, Simon Marlow wrote:
On 30 November 2005 12:29, Duncan Coutts wrote:
Attached is a simple code change to allow packages to specify
As some are aware some Wash modules cause ghc to take a very large
amount of memory. It also generates very large C and assembler files
(the .raw_s file for one module is nearly 50Mb). So unsurprisingly it
also makes gcc take a very large amount of memory.
Unfortunately for people with weaker
On Mon, 2006-03-13 at 12:47 +, Simon Marlow wrote:
Am I right in thinking that ghc's rts can free memory back to the system
when the heap pressure reduces (at least if it's doing a compacting GC)?
No, not at the moment. One thing we planned to do but never got around
to is to use
I built yesterday's ghc-6.4.2 snapshot (2006/03/23) and had a problem
building the docs.
I used XMLDocWays=html in my mk/build.mk
I was building with make -j2.
I am using:
libxslt-1.1.15
libxml-1.8.17
docbook-xsl-stylesheets-1.68.1
Here's the tail of the build log:
First of all I'd like to note that a registerised build of ghc-6.4.1
Just Workstm. I didn't need any special hacks. This is excellent.
This registerised ghc build was able to successfully recompile itself.
It took about 2 hours (dual cpu Itanium 2 @ 900MHz, make -j4 - thanks to
certain Gentoo
On Sat, 2006-03-25 at 21:29 +, Duncan Coutts wrote:
If anyone wants to look into it, I could narrow down the threshold of
the -funfolding-use-threshold flag at which the bug is triggered and
compare the assembly output.
I found the threshold is 14-15. With -funfolding-use-threshold14
pressure is too high and
try re-compiling with less aggressive optimisations/inlining.
Feel free to ask if you want clarification on any of this.
Thanks very much.
Duncan
On Sat, Mar 25, 2006 at 07:15:04PM +, Duncan Coutts wrote:
On Sat, 2006-03-25 at 17:17 +, Duncan Coutts wrote
Hi Simon,
On Mon, 2006-03-27 at 10:29 +0100, Simon Marlow wrote:
Thanks for the analysis Duncan. Would you mind submitting a ticket for
this?
What does the crash look like in gdb? Does it look like it has jumped
into the middle of nowhere, or is it a crash in some actual code that
you
More on the porting theme,
We've had an unregisterised alpha port in gentoo for some time and two
of our alpha devs with an interest in ghc decided to try to get the
registerised build working.
They started by turning off the mangler and trying to get the register
bit working. This is ghc-6.4.1.
On Tue, 2006-03-28 at 14:52 +0100, Simon Marlow wrote:
I find the divmoddi_internal_er a bit suspicious. Things often go
wrong when gcc is using its builtin functions - you might try
-fno-builtin to gcc.
We tried that and it made no difference.
We did some more investigation and tried
On Tue, 2006-03-28 at 19:06 +0100, Duncan Coutts wrote:
On Tue, 2006-03-28 at 14:52 +0100, Simon Marlow wrote:
I find the divmoddi_internal_er a bit suspicious. Things often go
wrong when gcc is using its builtin functions - you might try
-fno-builtin to gcc.
We tried
On Tue, 2006-03-28 at 19:06 +0100, Duncan Coutts wrote:
register void *_procedure __asm__($27);
#define JMP_(cont) \
do { _procedure = (void *)(cont); \
__DISCARD__(); \
goto *_procedure
On Wed, 2006-03-29 at 03:37 +0100, Duncan Coutts wrote:
Well the full build finished and appears to work. We're going to try
again with what I think is a better fix than just picking another fixed
register. Instead of fixing a register we could let gcc pick any
suitable register by use
On Thu, 2006-03-30 at 20:23 +0100, Duncan Coutts wrote:
Things are very slowly becoming clearer...
We compiled a little module with the stage1 compiler. So we get
registerised output assembly. It is using machine registers and making
tail calls. We've looked through the assembly but we can't
On Fri, 2006-03-31 at 11:43 +0100, Simon Marlow wrote:
Duncan Coutts wrote:
What would you recommend is the bat way for us to verify that each bit
of the registerised build is working? If we turn everything on including
the mangler and it breaks where do we start debugging?
I usually
On Tue, 2006-05-02 at 08:56 -0700, Steve Dekorte wrote:
% darcs annotate slice
darcs: internal error: evacuate: strange closure type 14402
Please report this as a bug to glasgow-haskell-bugs@haskell.org,
or http://www.sourceforge.net/projects/ghc/
Would you mind answering a few more
On Tue, 2006-05-23 at 11:52 +0200, Christian Maeder wrote:
Christian Maeder wrote:
I'm currently running the ghc-regression test (with stage1/ghc-inplace),
but that does not look good (although it does not hang)
here is the frustrating summary:
OVERALL SUMMARY for test run started at
Hi Simon,
I think some recent patch has made some of my fusion rules stop
matching.
the test case is:
foo = B.map (+1) . B.filter (/=0)
with ghc 6.4.2 and with older versions of ghc-6.5 (May 26th):
5 RuleFired
2 int2Word#
2 narrow8Word#
1 strTransformerBi/strTransformerBi
with
On Wed, 2006-07-19 at 20:24 +0100, Duncan Coutts wrote:
with my recent ghc 6.5 (Jul 24th) that strTransformer rule no longer
fires.
Sorry, that should have read July the 4th, not 24th!
Duncan
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell
On Sat, 2006-07-29 at 01:29 +0100, Neil Mitchell wrote:
Hi,
main = do
forkIO $ print yes
print done
Compiled without -threaded, on 6.2.2 gives
yes
done
on 6.4.2
done
Seems the semantics of forkIO in this case has changed completely?
Actually what changed is whether all
On Sun, 2006-07-23 at 18:09 +0200, Volker Wysk wrote:
Hello
When compiling a module, which contains foreign import directives, via C,
the C compiler needs to be passed a -I. argument, otherwise the include
file mentioned there won't be found.
You can do this manually with an -I.
I'm totally confused by the space profiling. Let me explain.
Here's a simple log file processing program. It prints the 10 most
frequently occurring lines in a file.
import Data.List
import qualified Data.Map as Map
import qualified Data.ByteString.Lazy.Char8 as BS
main = BS.interact
$
This doesn't have the effect I expected:
loop xs =
case blah of
One thing - ... loop
The other - ... realloc ...
where
{-# NOINLINE realloc #-}
realloc = do
something
loop ...
My intention here was that the loop would not contain the code for
realloc and that
On Wed, 2006-08-16 at 17:45 +0100, Frederik Eaton wrote:
Hi,
I've been thinking that it would be nice if I could give ghci on the
command line a list of commands to run initially when it starts. This
way, I could make shell aliases to invoke ghci with project-specific
configurations, with
On Tue, 2006-10-17 at 12:15 +0200, Christian Maeder wrote:
Duncan Coutts schrieb:
So ghc -split-objs works now with either -optc-mcpu=v8 or
-opta-mcpu=v9 (or even -opta-mcpu=ultrasparc).
Where should I place what so that my stage1 inplace-compiler works
without SplitObjs=NO in mk
Christian,
I've reported this bug here:
http://hackage.haskell.org/trac/ghc/ticket/951
Please add any further info you think necessary.
Duncan
On Wed, 2006-10-18 at 11:21 +0200, Christian Maeder wrote:
Duncan Coutts schrieb:
Try SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc
On Mon, 2007-04-02 at 12:05 +0100, Ross Paterson wrote:
On Mon, Apr 02, 2007 at 10:48:11AM -, GHC wrote:
[http://www.makegamegold.com World Of Warcraftwow
gold][http://www.makegamegold.com/default.asp?cateid=6 wow
gold][http://www.makegamegold.com/default.asp?cateid=6 gold wow
So
On Wed, 2007-04-04 at 00:01 +0100, Frederik Eaton wrote:
Hello,
This is a bit lame but I don't know where to find the information...
I am wondering if ghci is OK to use with threads now. It seems to work
but I have written down in some of my source code that a certain
function won't work
On Wed, 2007-05-09 at 03:42 +0100, Frederik Eaton wrote:
Hello,
I found that the distribution at this URL
http://haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown-linux.tar.bz2
failed to install. There were lots of no such file or directory
errors during 'cp' invocations I think. The
On Sat, 2007-06-23 at 12:08 +0400, Serge D. Mechveliani wrote:
Dear GHC developers,
Recently I submitted a bug report #1452 for ghc-6.6.1
of undefined references at the stage of linking executable,
and also of ignoring un-existing module import.
Now I discovered the following strange
On Tue, 2007-07-17 at 15:49 -0400, Scot Drysdale wrote:
I am preparing to teach a course this fall from Paul Hudak's _The
Haskell School of Expression_. In running Picture.lhs, one of the
example programs form the book, I am getting strange graphics
behavior. I load the program using
On Thu, 2007-07-26 at 23:51 -0700, Sean Johnson wrote:
Hi Everyone,
Is there some way to install Visual Haskell with VS2005, Express?
Perhaps some workaround or hack?
I believe that free version of VS is specifically designed not to allow
any plugins, you have to pay for the the full version
On Fri, 2007-08-17 at 11:33 +0100, Malcolm Wallace wrote:
Duncan Coutts [EMAIL PROTECTED] wrote:
Is it still possible to upgrade an older version of Cabal (e.g.
supplied with ghc-6.2) to the latest version, using only the older
version of Cabal itself?
We've never supported
On Wed, 2007-10-17 at 11:51 -0700, Don Stewart wrote:
mechvel:
Dear GHC developers,
Has -O any meaning in ghc-6.8.1-candidate ?
I build docon under ghc-6.8.1-candidate under -O and
with skipping it (the line of -O commented out in docon.cabal).
And it installs the
On Fri, 2007-10-19 at 10:42 +0100, Simon Peyton-Jones wrote:
| In general the users should never have to modify the .cabal file. For
| the common settings that we expect the user to want to control Cabal
| provides configure flags.
|
| The idea is that instead of having to find the
On Fri, 2007-10-19 at 11:34 +0400, Serge D. Mechveliani wrote:
Currently, my DoCon application has the file docon.cabal,
with the field
ghc-options: many options
...
-O
+RTS -M400m -RTS
-- -prof
--
On Thu, 2007-10-18 at 11:02 +0400, Serge D. Mechveliani wrote:
On Oct 17, 2007, Don Stewart and Duncan Coutts wrote:
[..]
By default cabal uses ghc -O to build projects, so you won't see any
difference if you comment it out of the cabal file. You will however
if you explicitly
On Fri, 2007-10-19 at 10:54 -0300, Isaac Dupree wrote:
How can user who does not modify Cabal file choose between all three of
-O0, -O and -O2?
They cannot. Cabal currently only support a binary notion of
optimisations. So it's either -O0 or -O.
(Not knowing about profiling,) What if user
On Sat, 2007-10-20 at 11:13 -0400, Isaac Dupree wrote:
Duncan Coutts wrote:
Which is why we have ghc-options, nhc98-options etc in the .cabal files.
No, none of the above is true (or I miscommunicated) : they are
supported in the following way of --programname-option. User
On Sun, 2008-01-20 at 16:08 +, Frederik Eaton wrote:
Hello,
I can't use Cabal on some of my projects, for various reasons that
I've discussed here earlier...
BTW, just so we do not loose track of those reasons could you double
check that all the problems and limitations you reported
On Sun, 2008-01-20 at 17:37 +, Frederik Eaton wrote:
Hi Duncan,
Thanks, --gen-pkg-config works.
I don't know if Cabal will ever be suitable for me - I prefer to be
able to build specific targets, and to track dependencies to minimize
build time, and there is a tool for this called
On Sun, 2008-02-24 at 13:38 +, Frederik Eaton wrote:
Hello,
ghc-pkg.bin has been using up most of the CPU for over 3 minutes, is
this a known bug?
Perhaps you have cyclic packages? I recall a bug being fixed to do with
that recently, but the current versions would still have the
On Wed, 2008-07-23 at 17:27 +, GHC wrote:
#1479: Merge GHC's hsc2hs with http://darcs.haskell.org/hsc2hs
-+--
Reporter: igloo| Owner: igloo
Type: task | Status: closed
Priority:
On Mon, 2009-03-16 at 16:36 +, Neil Mitchell wrote:
system cp foo foo.bup deleteFile foo
If I Ctrl+C during the cp did I just delete my one copy of foo?
On Windows, Ctrl-C will unblock a blocked system call. e.g. read() returns
with zero. Apparently system foo also returns as
On Fri, 2009-04-24 at 15:04 -0700, Sigbjorn Finne wrote:
There's a couple of things that are odd here:
* base.cabal files have kernel32 and msvcrt as extra-libraries. This
is clearly not required when doing invocations via ld(1), and causes
considerable mischief, so it'd be good if there
On Mon, 2009-06-01 at 20:05 +0200, Sven Panne wrote:
[ Reprise of an old GHCi problem, GHC HQ read on please... ]
Am Mittwoch, 20. Mai 2009 09:24:14 schrieb Matthijs Kooijman:
I've been playing around with GLUT (latest version from hackage, on Debian)
a bit yesterday and am having some
On Tue, 2009-09-22 at 17:13 +0200, S. Doaitse Swierstra wrote:
I am trying to run happstack on my Mac, but unfortunately I am getting
error messages as described in:
http://code.google.com/p/happstack/issues/detail?id=88
The cure seems to be to downgrade to network-2.2.0.1, but
89 matches
Mail list logo
