Ever since upgrading to 6.12.1, I've been getting a new warning. I
compile with --make, e.g. (clipping out irrelevant stuff):
ghc-6.12.1 -threaded -W -debug -package ghc --make \
-main-is App.Main App/Main.hs \
-o build/seq
If I remove all imports to a module
Ever since upgrading to 6.12.1, I've been getting a new warning. I
Manually wiping out a bunch of .hi files causes recompilation and the
warning goes away.
you need to do it. different ghc versions aren't compatible on .hi/.o
files format/contents
Oh, it's not a 6.10 vs. 6.12 thing, I
On Thu, Mar 18, 2010 at 7:43 AM, Louis Wasserman
wasserman.lo...@gmail.com wrote:
Oh, god, so much to respond to...heh.
You did request feedback back there, didn't you :P
As does Python. In Python, though, the PQ implementation is not a built-in
class in the default namespace (as are dict and
On Sun, May 30, 2010 at 5:15 PM, Antoine Latter aslat...@gmail.com wrote:
Hi GHC,
Is there a reason that Foreign.Marshall.Array.allocaArray calls into
allocaBytes instead of allocaBytesAligned? Since alloca needs the
alignment, wouldn't allocaArray also need it?
I'm not too up on how memory
Here's the ticket:
http://hackage.haskell.org/trac/ghc/ticket/2917
Lennart's patch added allocaBytesAligned to Foreign.Marshal.Alloc, but we'll
have to do a library proposal to add that.
If you can reproduce the assertion failure, please submit a bug report.
Unfortunately this assertion
I've been trying to profile my program and having some trouble. I
imagine other people have stumbled across these same issues, so
hopefully I can benefit from someone else's experience. In return, if
I can figure out some of these things, I'll put it up at
locking up. Has anyone else seen this? Any tips on how to
troubleshoot where it's getting stuck, doing what? If it sounds like
a ghc bug I can try to trim down the size and submit a ticket. GHC
6.12.1 on OSX.
Please submit a ticket, and try 6.12.3 if you can (we did fix some deadlock
On Sat, Jun 19, 2010 at 6:00 PM, Felipe Lessa felipe.le...@gmail.com wrote:
On Sat, Jun 19, 2010 at 08:38:52PM +0200, Christian Höner zu Siederdissen
wrote:
But the more important thing is, that it makes extending module
functionality a pain (eg. if a constructor is not exported using (..)).
On Sat, Jun 19, 2010 at 8:46 AM, Claus Reinke claus.rei...@talk21.com wrote:
I put the simple version at
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=26329#a26329
This one displays much better performance with DList + Writer.Strict
than List + StrictWriter so I guess it's not too surprising.
Right, I wouldn't use DList for this. Here's an alternative I use:
data AList a = ANil | ASing a | Append (AList a) (AList a)
lenA :: AList a - Int
lenA ANil = 0
lenA (ASing _) = 1
lenA (Append l r) = lenA l + lenA r
appendA ANil r = r
appendA l ANil = l
appendA l r =
Indeed, though I don't think this is the case, because I get lots of
lag even when no logs are written.
In the part you deleted I mentioned one source of lag that does
not disappear when no logs are written, and a way of using
profiling cost centers to track down other sources (the ones
I
On Thu, Jul 8, 2010 at 3:25 PM, J. Garrett Morris jgmor...@cs.pdx.edu wrote:
Hello everyone,
I'm currently in the process of wrapping a C API, and I've run across
an interesting possibility. Basically, the C API exposes non-blocking
versions of some potentially long-running operations, and
So I was planning to pass a StorableVector to C. StorableVector uses
ForeignPtrs to manage its memory, so it should just be a pointer pass.
I happily wrote up a reference counting scheme so I could attach
decref to the finalizer and have haskell and C cooperate about when to
delete the pointer.
On Mon, Jul 12, 2010 at 12:54 PM, Edward Z. Yang ezy...@mit.edu wrote:
Excerpts from Evan Laforge's message of Mon Jul 12 14:56:11 -0400 2010:
But I'm not convinced that's actually enough because the C code is
still running outside of a withForeignPtr. I would have to do
something really
The easiest thing to do is copy the contents to a regular area of memory not
managed by a Storable Vector. This'll be much less painful because it's just
a
normal free (not a recursive one, which can get hairy).
Yeah, that's definitely the safest and simplest. But the copying
defeats the
On Mon, Jul 12, 2010 at 1:53 PM, Edward Z. Yang ezy...@mit.edu wrote:
Excerpts from Evan Laforge's message of Mon Jul 12 16:43:45 -0400 2010:
Yeah, that's definitely the safest and simplest. But the copying
defeats the purpose of passing a pointer in the first place, which was
to not have to
On Mon, Jul 12, 2010 at 6:54 PM, John Meacham j...@repetae.net wrote:
Hi, is a StablePtr what you are after?
Indeed, it looks like StablePtr will get me what I want. It's a
little less convenient than FunPtr because I'm already doing some
finalization of FunPtrs and I can reuse the same
On Mon, Sep 6, 2010 at 12:37 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Mitar, and others
Yes, I've spent most of the last month working on the new type checker, and
unless there's a major hiccup it'll be in GHC 7.0. We'll produce a release
candidate just before ICFP.
Ohh, how
So a long time ago (I think when 6.10 first came out, the problem
didn't happen with the previous version, and I think 6.10 changed how
the FFI used alignment) I filed a ghc ticket about a gc assertion
failure. Unfortunately it was so hard to reproduce and reduce to a
manageable example that I
On Tue, Sep 28, 2010 at 8:18 AM, Ian Lynagh ig...@earth.li wrote:
On Mon, Sep 27, 2010 at 11:55:51AM -0700, Evan Laforge wrote:
There are some issues with the .pkg installer under OS X:
Installers shouldn't be deleting the old version!
This has been a long-standing bug of the OS X installer
I created
http://hackage.haskell.org/trac/ghc/ticket/4354 and attached the
patch.
We now have a mixture of
org.haskell.ghc
and
org.haskell.GHC
Is that deliberate, or should I lowercase them all?
Not deliberate. I updated the patch in my client to lowercase them
all. Haven't
I've pushed patches to do this, and also added the full GHC version and
arch (i386/x86_64) to the framework version number.
One annoyance is that if you have 7.1.20101023-i386 installed, then
7.1.20101022-i386 won't actually install any files (Console's log gave
something to the effect of
On Mon, Mar 21, 2011 at 9:59 AM, Tim Docker t...@dockerz.net wrote:
My question on the ghc heap profiler on stack overflow:
http://stackoverflow.com/questions/5306717/how-should-i-interpret-the-output-of-the-ghc-heap-profiler
remains unanswered :-( Perhaps that's not the best forum. Is there
I've found ghc's cyclic import error to be rather confusing, and I
finally took the time to understand why. Here's an example:
Module imports form a cycle for modules:
Cmd.Cmd (./Cmd/Cmd.hs)
imports: Perform.Midi.Instrument Instrument.MidiDb Instrument.Db
Perform.Midi.Instrument
So I just upgraded to 7, and on compiling I got:
/var/folders/++/+++c0U++6+0++4RjPqRgNE++8+c/-Tmp-/ghc88373_0/ghc88373_1.s:43:0:
suffix or operands invalid for `push'
/var/folders/++/+++c0U++6+0++4RjPqRgNE++8+c/-Tmp-/ghc88373_0/ghc88373_1.s:47:0:
suffix or operands invalid for `push'
...
No, GHC compiles either for 32-bit or 64-bit, chosen when GHC is built. You
probably want to install the 32-bit version of GHC.
Ohh, so ghc always produces one kind, and no amount of -m flags will
change that? I see, I thought it was like gcc that just took a flag.
I'm not sure how this
So as everyone probably knows, ghc7 requires -rtsopts to enable +RTS
parsing. Apparently this makes it include various header files in
rts/ when linking, because after upgrading to ghc7 I suddenly got
syntax errors from headers there. Some investigation revealed that
the problems were use of
Is there a better way to link to c++?
Does it work with just -pgml, or do you need -pgmc too?
Wow, you're right. Just removing -pgmc solves the problem. For some
reason I just assumed pgmc was necessary if pgml was.
Thanks!
___
I've just noticed that getCPUTime is returning erratic results for me:
GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0
See
http://hackage.haskell.org/trac/ghc/ticket/4247
and
http://hackage.haskell.org/trac/ghc/ticket/4970
We ought to fix this in 7.0.4, since getCPUTime is pretty broken on OSX
64-bit right now, but the fix involves an API change (to Foreign.C.Types).
Ian - could we apply a fix that
|
| On Wed, Apr 13, 2011 at 11:44:33AM +0100, Simon Marlow wrote:
| On 09/04/2011 04:32, Evan Laforge wrote:
| I've found ghc's cyclic import error to be rather confusing, and I
| finally took the time to understand why. Here's an example:
|
| Module imports form a cycle for modules
So when I upgrade from 6.10 to 6.12 a LONG time ago, there was a bug
where hsc2hs would emit INCLUDE pragmas and ghc didn't like that. So
I hacked around it with an extra grep -v step in the Makefile. I
always meant to go fix it for real in hsc2hs and finally I came back
to that TODO item. I
On Sat, Jul 30, 2011 at 8:32 PM, Edward Z. Yang ezy...@mit.edu wrote:
This is supposed to get defined as a command line argument to the
preprocessor,
see compiler/main/DriverPipeline.hs. Are you saying you don't see it when you
run hsc2hs? Maybe someone else is calling a preprocessor but
On Sat, Jul 30, 2011 at 9:23 PM, Edward Z. Yang ezy...@mit.edu wrote:
No, I don't think this diagnosis is correct. hsc2hs is outputting
preprocessor
directives into hs files that GHC will then process. Inspect your .hs file,
Not for me it's not, it's putting preprocessor directives into a C
I'm just wondering if other GHC users see the errors I see.
Occasionally, a program will fail to link, with an error similar to
the following:
Linking build/test/RunTests ...
lUndefined symbols:
_UiziRulerC_dk8C, referenced from:
_skev_info in RulerC.o
ld: symbol(s) not found
collect2: ld
Just as an addendum, this just happened again, but I got new errors
this time. Make gave the usual:
Linking build/test/RunTests ...
Undefined symbols:
_UiziTrackC_d28LF, referenced from:
_s28UI_info in TrackC.o
_UiziRulerC_dk8C, referenced from:
_skev_info in RulerC.o
ld:
Can you save the state at some point when the error happen? Preferably when
using --make rather than GHCi. Just tar/zip the whole directory and send it
to us, with instructions to reproduce the error. What platform is this BTW?
Sure, I'll do that next time it comes up. It'll be a couple
On Sat, Jul 30, 2011 at 9:25 PM, Ian Lynagh ig...@earth.li wrote:
But I also think we may as well just remove most of these conditionals.
The GHC 4.09 tests can surely be removed, and likewise the GHC 6.3
tests. Personally I'd remove the GHC 6.10 test too, but perhaps that
will be more
Should I try to send a patch for the remove all backward compatibility
thing? Or one for the specific #include problem I've been having?
I've lost track of all the details here. But perhaps there's some
historical cruft lying around because hsc2hs used to call GHC to compile its
C files,
On Tue, Aug 9, 2011 at 4:36 AM, Ian Lynagh ig...@earth.li wrote:
On Mon, Aug 08, 2011 at 06:44:29PM -0700, Evan Laforge wrote:
So... remove it all?
I've done so.
Yay, thanks!
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
On Tue, Aug 23, 2011 at 10:24 AM, David Terei davidte...@gmail.com wrote:
I have a 16 core machine at work (with 48GB of ram, a perk of the job
:)). GHC can saturate them all. Can validate GHC in well under 10
minutes on it.
To wander a bit from the topic, when I first saw this I thought wow,
From what I remember someone tried to parallelize GHC but it turned
out to me tricky in practice. At the moment very trying to parallelize
Cabal which would allow us to build packages/modules in parallel using
ghc -c and let Cabal handle dependency management (including
preprocessing of .hsc
On Mon, Aug 29, 2011 at 1:50 PM, Max Bolingbroke
batterseapo...@hotmail.com wrote:
On 27 August 2011 09:00, Evan Laforge qdun...@gmail.com wrote:
Right, that's probably the one I mentioned. And I think he was trying
to parallelize ghc internally, so even compiling one file could
parallelize
Yes, the plan was to eventually have a parallel --make mode.
If that's the goal, wouldn't it be easier to start many ghcs?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
It's an interesting idea that I hadn't thought of. There would have to be
an atomic file system operation to commit a compiled module - getting that
right could be a bit tricky (compilation isn't deterministic, so the commit
has to be atomic).
I suppose you could just rename it into place
Ah, but you're measuring the startup time of ghc --make, which is not the
same as the work that each individual ghc would do if ghc were invoked
separately on each module, for two reasons:
Excellent, sign me up for this plan then :) ghc on a single file is very
quick.
It ''also'' demonstrated, to me, that qualified imports are horrible
when used on a large scale. It happened all the time, that'd I'd
import, say, 10 different data types all qualified. Typing map
(Foo.id . BarMu.thisField) and foo Bar.Zot{x=1,y=2} becomes tedious
and distracting, especially
Another place this problem has come up for me is in wanting to ensure
representation sharing for values constructed by data constructors which
don't make use of their type parameters. A trivial example would be sharing
the representation of Nothing between all the Maybe types, or sharing the
I've noticed a strange behaviour with ghc's -osuf flag:
% cat Test.hs
{-# LANGUAGE ForeignFunctionInterface #-}
module Test where
import Foreign
foreign import ccall wrapper c_callback :: Int - IO (FunPtr Int)
% ghc-7.0.3 -v -c -osuf .hs.o Test.hs
% ls
Tes_stub.hs.o Test.hsTest_stub.c
On Sat, Dec 24, 2011 at 9:35 PM, austin seipp a...@hacks.yi.org wrote:
Hello GHC hackers,
I have been trying the recent 7.4.1-rc1 release on my OSX Snow Leopard
machine. I am using the 64bit OSX .tar.bz. I used virthualenv/hsenv to
set up a virtual environment to test packages with the RC,
of the time. It seems random when it segfaults and when it runs. I
don't know if it's worth anything, but the gdb backtrace looks
similar:
(gdb) bt
#0 0x0001f6c930da in evacuate1 ()
#1 0x0001f6c98868 in scavenge_block1 ()
Previous frame inner to this frame (gdb could not unwind
In 7.4 we merge the stub object file into the main object file
automatically, so you don't have to worry about stub objects in your
Makefiles or whatever.
Nice, this is very convenient.
___
Glasgow-haskell-users mailing list
I told you so (^_^)
Unicode dot (∘) would be optimal, since that's what it's for. If to
type '∘' is awkward, then one can use (Control.Category.). We need
not (and, in my opinion, should not) define another operator.
Is ∘ (U+2218 RING OPERATOR)* in Prelude yet? We should propose that.**
But this is a more or less academic discussion, taking place on
ghc-users, nominally out of view of the general Haskell community,
right? So I don't need to intrude with mundane objections of
that nature.
True, true, there is that.
However, I think there's at least a little bit in the idea
I also wish to note that I have never been a member of the anything beyond
plain ASCII is fundamental evil set; if we're going to think that way, just
go back to BAUDOT and punched cards.
Well, it's similar to the 80 columns debate. You have to draw the
line somewhere. It's not about
I recently switched from ghc --make to a parallelized build system. I
was looking forward to faster builds, and while they are much faster
at figuring out what has to be rebuilt (which is most of the time for
a small rebuild, since ld dominates), compilation of the whole system
is either the same
One immediate problem I see with this is linking - 'ghc --make
Main.hs' is able to figure out what packages a program depends on,
while 'ghc Main.o ... -o Main' requires the user to specify them
manually with -package. So you'll either need to pass this information
back to the parent process,
On Wed, Jan 25, 2012 at 11:42 AM, Ryan Newton rrnew...@gmail.com wrote:
package list for me. The time is going to be dominated by linking,
which is single threaded anyway, so either way works.
What is the state of incremental linkers? I thought those existed now.
I think in some specific
I'm slightly surprised by this - in my experience parallel builds beat
--make as long as the parallelism is a factor of 2 or more. Is your
dependency graph very narrow, or do you have lots of very small modules?
I get full parallelism, 4 threads at once on a 2 core machine * 2
Unfortunately ghci still segfaults for me most times (the previous
release candidate did too). Anyone else seeing this? What should I
do to troubleshoot?
OS X 10.6.8, using GHC-7.4.0.20120126-x86_64.pkg
I'll try GHC-7.4.0.20120126-i386.pkg in a bit, but I probably do need
the 64 bit version,
So it embarrasses me to admit it, but I'm having the same problem I
always have when I install a new ghc, and that's cabal and cabal
install.
I downloaded the latest cabal-install from
http://hackage.haskell.org/package/cabal-install and that was a
mistake right off. After fiddling around I
I downloaded the latest cabal-install from
http://hackage.haskell.org/package/cabal-install and that was a
mistake right off.
Assuming you upgraded, you probably had an old version of
cabal-install. You should be able to keep using it for the time being.
The cabal binary picks up the GHC
On Sun, Jan 29, 2012 at 5:12 PM, Austin Seipp mad@gmail.com wrote:
I've done so, and have an RC2 bindist that doesn't have a segfaulting
GHCi. I suppose this build should be advocated to Snow Leopard users.
I currently need a place to put the bindist. I'm about to send an
email to
On Fri, Feb 10, 2012 at 10:59 AM, Austin Seipp mad@gmail.com wrote:
Sorry, I got caught up doing a few other things the past few days.
I'll make a binary of the 7.4.1 release later today and upload it to
my code.haskell.org account and report back here (the uploading will
take as long as
On Sun, Feb 12, 2012 at 3:05 PM, Evan Laforge qdun...@gmail.com wrote:
On Fri, Feb 10, 2012 at 10:59 AM, Austin Seipp mad@gmail.com wrote:
Sorry, I got caught up doing a few other things the past few days.
I'll make a binary of the 7.4.1 release later today and upload it to
my
Recently a change was made to hsc2hs to fix this ticket:
http://hackage.haskell.org/trac/ghc/ticket/2897
Unfortunately, the result is I (apparently) can't use it now. Here's
how that happens: The change was to remove the dependency on HsFFI.h.
However, the solution is to create a little
On Wed, Feb 15, 2012 at 11:17 AM, Eugene Crosser cros...@average.org wrote:
On 02/15/2012 09:59 PM, Evan Laforge wrote:
Unfortunately, the result is I (apparently) can't use it now. Here's
how that happens: The change was to remove the dependency on HsFFI.h.
Evan, *if* including HsFFI.h
Thanks for bringing this up. I've been having the same problem and was
thinking there was something wrong with my system. I have 3 main files and
one util that they all import. Every build recompiles every file, even if
there were no changes.
On Feb 15, 2012 8:39 PM, Conrad Parker
On Thu, Feb 16, 2012 at 3:45 AM, Simon Marlow marlo...@gmail.com wrote:
Will be fixed in 7.4.2:
http://hackage.haskell.org/trac/ghc/ticket/5878
Nice, thanks for the quick fix!
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
However, the GHC API doesn't provide a way to do this directly (I hadn't
really thought about this when I suggested the idea before, sorry). The GHC
API provides support for compiling multiple modules in the way that GHCi and
--make work; each module is added to the HPT as it is compiled.
Sure, except that if the server is to be used by multiple clients, you will
get clashes in the PIT when say two clients both try to compile a module
with the same name.
The PIT is indexed by Module, which is basically the pair
(package,modulename), and the package for the main program is
On Thu, Feb 16, 2012 at 4:27 AM, Simon Marlow marlo...@gmail.com wrote:
I'm not sure why you're using the C++ compiler from hsc2hs, and I don't
think that is guaranteed to work. But maybe we can fix it if there's a
legitimate reason to want it.
Well, consider if you're writing c++ along with
Is there something that changed in 7.4.1 that would cause it to decide
to interpret .hs files instead of loading their .o files? E.g.:
% ghc -c T.hs
% ghci
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ...
On Sun, Feb 19, 2012 at 10:52 PM, Brandon Allbery allber...@gmail.com wrote:
On Mon, Feb 20, 2012 at 01:46, Evan Laforge qdun...@gmail.com wrote:
Is there something that changed in 7.4.1 that would cause it to decide
to interpret .hs files instead of loading their .o files? E.g.:
I thought
On Mon, Feb 20, 2012 at 1:14 AM, Eugene Crosser cros...@average.org wrote:
On 02/20/2012 10:46 AM, Evan Laforge wrote:
Is there something that changed in 7.4.1 that would cause it to decide
to interpret .hs files instead of loading their .o files? E.g.:
I don't *know* but could this have
Indeed it was, I initially thought it wasn't because I wasn't using
flags for either, but then I remember ghci also picks up flags from
~/.ghci. Turns out I was using -fno-monomorphism-restriction because
that's convenient for ghci, but not compiling with that.
I guess in the case where an
On Sun, Feb 26, 2012 at 2:00 AM, wren ng thornton w...@freegeek.org wrote:
I haven't been following all the different proposals out there, but the ones
I did see before tuning-out all took the stance that for each given field
either (1) this field name is unique and always clashes, or (2) this
On Mon, Feb 27, 2012 at 9:56 AM, Yitzchak Gale g...@sefer.org wrote:
Evan Laforge wrote:
Is there something that changed in 7.4.1 that would cause it to decide
to interpret .hs files instead of loading their .o files? E.g.:
Brandon Allbery wrote:
I thought this was deliberate because
Thanks Evan, I've had a quick read through.
Thanks for reading and commenting!
It's a bit difficult to compare to the other proposals.
I can't see discussion of extracting higher-ranked functions and applying them
in polymorphic contexts. (This is SPJ's `rev` example.)
Putting h-r fields
On Tue, Feb 28, 2012 at 1:53 AM, Simon Marlow marlo...@gmail.com wrote:
I don't see how we could avoid including -D, since it might really affect
the source of the module that GHC eventually sees. We've never taken -D
into account before, and that was incorrect. I can't explain the behaviour
I just committed a fix for this:
http://hackage.haskell.org/trac/ghc/ticket/3217#comment:28
What do people think about getting this into 7.4.2? Strictly speaking it's
more than a bug fix, because it adds a new GHCi command (:seti) and some
extra functions to the GHC API, although I believe
There is a way around it: create a .h file containing #define MY_SETTING,
and have the Haskell code #include the .h file. The recompilation checker
does track .h files:
http://hackage.haskell.org/trac/ghc/ticket/3589
When you want to change the setting, just modify the .h file. Make sure
On Thu, Mar 22, 2012 at 6:49 AM, Ian Lynagh ig...@earth.li wrote:
Hi all,
Just a quick note to let you know about our release plans:
We plan to put out a GHC 7.4.2 release candidate around the end of the
March. The final release will probably not happen until around the end
of April.
Questions:
Would implementing this optimisation be a worthwhile/realistic GSoC project?
What are other potential ways to bring 'ghc -c' performance up to par
with 'ghc --make'?
I implemented a ghc server that runs several persistent ghcs, and
distributes compiles among them. It seemed to
On Mon, Apr 2, 2012 at 5:41 AM, Michael Snoyman mich...@snoyman.com wrote:
On Mon, Apr 2, 2012 at 3:38 PM, Alp Mestanogullari alpmes...@gmail.com
wrote:
Lesson learned: for next year, write a Haskell program that tells if a given
-cafe thread or reddit discussion is a April Fool's joke or
From what I can see the core of the disagreement is that some people
believe fromString will tempt misuse (i.e. using *easily* partial
functions, like XML validation), while others don't think it's that
likely. Indeed misusing IsString is worse than your average partial
function because of the
So if every value, when forced, can crash your program, possibly depending
on what type it's instantiated to, why are we so concerned about String
literals behaving like everything else?
Well, that was exactly my point. Some people think it's *more likely*
that people will write crashing
Thank you for the answer.
I'll be working on another project during the summer, but I'm still
interested in making interface files load faster.
The idea that I currently like the most is to make it possible to save
and load objects in the GHC heap format. That way, deserialisation
could be
The only reason I don't like using OverloadedStrings
for typing string literals as Text and ByteString
is that when you turn on OverloadedStrings, you turn
it on for all types, not just Text and ByteString.
I don't want to be forced to do that. Because
all other uses of OverloadedStrings
Would such an enhancement to Haddock be worthwhile or is it a bad idea?
Has such a proposal come up in the past already? Are there alternative
approaches to consider?
It would be even cooler to automatically figure them out from the
hackage history.
I recently stumbled across a document
On Tue, Feb 28, 2012 at 2:16 AM, Simon Marlow marlo...@gmail.com wrote:
Ok, I buy that it's useful to be able to do this. I suggest you make a
ticket and describe the problem. Is it possible you'd be able to make a
patch to fix it too?
So I finally got around to taking a look at this. Sorry
So I have something that looks similar to
http://hackage.haskell.org/trac/ghc/ticket/5252, namely, given these
two modules:
% cat Midi.hs
{-# OPTIONS_GHC -funbox-strict-fields #-}
module Midi (
WriteMessage(..)
, WriteDevice
-- TODO due ghc bug:
I'm using the GHC api to run a little REPL for my app. This involves
linking in some compiled C, and as long as it's in a library it's
fine, I just pass -lwhatever to parseDynamicFlags and it's happy.
However, I also have a plain .o file, and from poking at the ghci
source, it looks like that
On Thu, Sep 13, 2012 at 10:31 PM, Evan Laforge qdun...@gmail.com wrote:
I was just about to go verify this, but it looks like it just changed!
So maybe .o files can now be passed to parseStaticFlags? Or even
better, parseDynamicFlags?
Aha:
commit 61d41b90bde303d356540a8df44a2fffdd715aa5
On Fri, Sep 14, 2012 at 6:22 PM, Brandon Allbery allber...@gmail.com wrote:
On Fri, Sep 14, 2012 at 1:31 AM, Evan Laforge qdun...@gmail.com wrote:
Relatedly, I've noticed that OS X is forgiving when you don't link in
a needed object. It will let me run code, but if I call a function
that's
I don't totally understand how ghci loading would work. I assume that
for external packages it will go load x.so instead of x.a, but what
about local modules? I assume ghc -c is still going to produce .o
files, so does that mean ghci will have to interpret all local moules?
If so, is there a
On Mon, Jan 14, 2013 at 3:11 PM, Johan Tibell johan.tib...@gmail.com wrote:
On Mon, Jan 14, 2013 at 2:57 PM, Roman Cheplyaka r...@ro-che.info wrote:
It's described here:
http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers
We seem to be talking past each other. There's a specific problem
On Mon, Jan 14, 2013 at 3:28 PM, Johan Tibell johan.tib...@gmail.com wrote:
On Mon, Jan 14, 2013 at 3:18 PM, Evan Laforge qdun...@gmail.com wrote:
I assume it would change from doesn't compile to works if you add
the required import. It's the same as the FFI thing, right? If you
don't import
I made some strictifying changes and started getting this msg from ghc:
match_co: needs more cases
vector-0.10.0.1:Data.Vector.Generic.Mutable.MVector{tc r46}
(Sym (vector-0.10.0.1:Data.Vector.TFCo:R:MutableVector{tc r45}))
main:Util.TimeVectorStorable.Sample{tc r4e} y{tv a4lK}
I'm reluctant to add yet another opinion, but, oh what the heck:
For me, lenses basically already solve the record problem. The only
missing thing is to integrate them better with record declaration
syntax. Having to rely on TH and then write a makeLenses splice is
just too much friction to
1 - 100 of 166 matches
Mail list logo
