; And from the answers I'm assuming you believe it is the GC that is
> most likely causing these spikes. I've never profiled Haskell code, so
> I'm not used to seeing what the effects of the GC actually are.
>
> On 28 September 2015 at 19:31, John Lato wrote:
>
Try Greg's recommendations first. If you still need to do more
investigation, I'd recommend that you look at some samples with either
threadscope or dumping the eventlog to text. I really like
ghc-events-analyze, but it doesn't provide quite the same level of detail.
You may also want to dump som
On 21:23, Fri, Jan 23, 2015 Evan Laforge wrote:
On Sat, Jan 24, 2015 at 2:38 AM, John Lato wrote:
> I agree that mixing template haskell with -prof can be tricky. It's
easier if you turn
> off dynamic linking entirely.
But that's the thing, I do turn of dynamic linking becau
I agree that mixing template haskell with -prof can be tricky. It's easier
if you turn off dynamic linking entirely.
As for multi-line string literals, I also think that an explicit syntax
would be nice. Until then, I usually use:
unlines
[ "Line 1"
, "Line 2"
]
which end
Ah, just took a look. I think my suggestion is unlikely to be correct.
On 08:40, Tue, Dec 23, 2014 John Lato wrote:
> Can't try your code now, but have you tried using threadscope? Just a
> thought, but maybe the garbage collection is blocked waiting for a thread
Can't try your code now, but have you tried using threadscope? Just a
thought, but maybe the garbage collection is blocked waiting for a thread
to finish.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mai
The blocked on black hole message is very suspicious. It means that thread
7 is blocked waiting for another thread to evaluate a thunk. But in this
case, it's thread 7 that created that thunk and is supposed to be doing the
evaluating. This is some evidence that Gregory's theory is correct and
y
e cores available!). I expect even with -N4 you'll
> still
> >>> see
> >>>> occasional delays (perhaps <5% of calls).
> >>>>
> >>>> We've solved our problem with judicious use of `forkOn`, but that
> won't
>
>
> > On Thu, Oct 30, 2014 at 8:02 AM, Michael Jones
> wrote:
> >
> > > John,
> > >
> > > Adding -C0.005 makes it much better. Using -C0.001 makes it behave more
> > > like -N4.
> > >
> > > Thanks. This saves my proje
eed to deploy on a single core Atom
> and was stuck.
>
> Mike
>
> On Oct 29, 2014, at 5:12 PM, John Lato wrote:
>
> By any chance do the delays get shorter if you run your program with `+RTS
> -C0.005` ? If so, I suspect you're having a problem very similar to one
&
By any chance do the delays get shorter if you run your program with `+RTS
-C0.005` ? If so, I suspect you're having a problem very similar to one
that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8 for some
reason), involving possible misbehavior of the thread scheduler.
On Wed, Oct 29,
The value 708 is correct. From the user's guide,
http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#c-pre-processor
:
_GLASGOW_HASKELL__
For version x.y.z of GHC, the value of __GLASGOW_HASKELL__ is the integer
xyy (if y is a single digit, then a leading zero is added, so
On May 24, 2014 11:48 AM, "Simon Marlow" wrote:
>
> On 19/05/2014 13:51, harry wrote:
>>
>> harry wrote
>>>
>>> I need to build GHC 7.8 so that Template Haskell will work without
shared
>>> libraries (due to a shortage of space).
>>>
>>> I understand that this can be done by turning off DYNAMIC_GH
;
> On Wed, May 14, 2014 at 7:02 PM, John Lato wrote:
>
>> I would have expected this would have affected a lot users, but as I
>> haven't heard many complaints (and nobody else said anything here!) maybe
>> the impact is smaller than I thought.
>>
>
> I
le indeed, and we should support it. I doubt the feature will land
> in 7.8.3 (depending on the timeline for that release), but I'll get to it
> eventually. (Or, if you feel this is more critical in the larger picture,
> shout more loudly on the ticket and perhaps I can squeeze it
Not by anything I've tried yet, no.
On Tue, May 13, 2014 at 10:40 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:
> can you get the deriving to work on
> a newtype instance MVector s Foo =
> ?
>
>
> On Tue, May 13, 2014 at 9:39 PM, John Lato wrote:
&
Hello,
Prior to ghc-7.8, it was possible to do this:
> module M where
>
> import qualified Data.Vector.Generic.Base as G
> import qualified Data.Vector.Generic.Mutable as M
> import Data.Vector.Unboxed.Base -- provides MVector and Vector
>
> newtype Foo = Foo Int deriving (Eq, Show, Num,
> M.
Hi Simon,
Thanks very much for this response. I believe you're correct; ghc -e
'System.Environment.getEnvironment' segfaults with my ghc build.
John
On Tue, Apr 29, 2014 at 10:36 AM, Simon Marlow wrote:
> On 25/04/2014 02:15, John Lato wrote:
>
>> Hello,
>>
2014 at 9:47 AM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:
> @john, what version of cabal-install were you using? (i realize you're
> probably using the right one, but worth asking :) )
>
>
> On Fri, Apr 25, 2014 at 12:25 PM, John Lato wrote:
>
>&
On Apr 25, 2014 5:36 AM, "Bertram Felgenhauer" <
bertram.felgenha...@googlemail.com> wrote:
>
> John Lato wrote:
> > I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled (on
64-bit
> > linux). I downloaded the source tarball, added
> >
>
Hello,
I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled (on 64-bit
linux). I downloaded the source tarball, added
DYNAMIC_GHC_PROGRAMS = NO
to mk/build.mk, and did ./configure && ./make.
ghc builds and everything seems to work (cabal installed a bunch of
packages, ghci seems to w
d data type contexts being needed in the language for bang
patterns. :(
>
> -Edward
>
> On Apr 1, 2014, at 5:26 PM, John Lato wrote:
>
>> Hi Edward,
>>
>> Yes, I'm aware of that. However, I thought Dan's proposal especially
droll given that changing seq t
;
> -Edward
>
>
> On Tue, Apr 1, 2014 at 9:17 AM, John Lato wrote:
>
>> I think this is a great idea and should become a top priority. I would
>> probably start by switching to a type-class-based seq, after which perhaps
>> the next step forward would become more
I think this is a great idea and should become a top priority. I would
probably start by switching to a type-class-based seq, after which perhaps
the next step forward would become more clear.
John L.
On Apr 1, 2014 2:54 AM, "Dan Doel" wrote:
> In the past year or two, there have been multiple p
On Jan 23, 2014 1:28 AM, "Simon Marlow" wrote:
>
> On 23/01/14 03:52, John Lato wrote:
>
>> However, these are all rather obviously fixable as part of the build
>> system. For me, the worst problems have to do with cleaning. If you're
>> usi
On Wed, Jan 22, 2014 at 12:25 AM, Simon Marlow wrote:
> On 05/01/2014 23:48, John Lato wrote:
>
>> (FYI, I expect I'm the source of the suggestion that ghc -M is broken)
>>
>> First, just to clarify, I don't think ghc -M is obviously broken.
>> Rather,
On Sun, Jan 5, 2014 at 3:54 PM, Erik de Castro Lopo wrote:
> John Lato wrote:
>
> > ghc --make doesn't allow building several binaries in one run, however if
> > you use cabal all the separate runs will use a shared build directory, so
> > subsequent builds will be
(FYI, I expect I'm the source of the suggestion that ghc -M is broken)
First, just to clarify, I don't think ghc -M is obviously broken. Rather,
I think it's broken in subtle, unobvious ways, such that trying to develop
a make-based project with ghc -M will fail at various times in a
non-obvious
One point I'm getting from this discussion is that perhaps not much time
has been spent considering these issues in ghc backends. If so, it's
probably a good thing to work through it now.
For myself, I guess the only option I have now is to measure using
loadLoadBarrier and see if it's better or w
Hi Edward,
Thanks very much for this reply, it answers a lot of questions I'd had.
I'd hoped that ordering would be preserved through C--, but c'est la vie.
Optimizing compilers are ever the bane of concurrent algorithms!
stg/SMP.h does define a loadLoadBarrier, which is exposed in Ryan Newton'
arantee I'm concerned about; I guess I'm not
entirely sure I believe that it's implemented properly (although I have no
reason to believe it's wrong either). Perhaps I'm just overly paranoid.
John Lato
On Fri, Dec 20, 2013 at 9:05 AM, Carter Schonwald <
carter.schonw...@
Hello,
I'm working on a lock-free algorithm that's meant to be used in a
concurrent setting, and I've run into a possible issue.
The crux of the matter is that a particular function needs to perform the
following:
> x <- MVector.read vec ix
> position <- readIORef posRef
and the algorithm is on
;
>
> Simon
>
>
>
> *From:* John Lato [mailto:jwl...@gmail.com]
> *Sent:* 11 November 2013 17:29
> *To:* Simon Peyton-Jones
> *Cc:* glasgow-haskell-users@haskell.org; Akio Takano
> *Subject:* RE: Giving function a larger arity
>
>
>
> Originally I thought P
Originally I thought Plan B would make more sense, but if Plan A were
implemented could this one-shot type annotation be unified with the state
hack? I'm envisioning something like RULES, where if the type matches ghc
knows it's a one-shot lambda.
I think it would be better to not do any analysis
+1 to the original proposal and Edward's suggestion of emitting a warning.
I've occasionally wanted this behavior from IncoherentInstances as well.
On Mon, Jul 29, 2013 at 3:01 PM, Edward Kmett wrote:
> I'll probably never use it, but I can't see any real problems with the
> proposal. In many w
On Thu, Mar 21, 2013 at 8:08 AM, Ian Lynagh wrote:
>
> We've had long discussions about snapshot releases, and the tricky part
> is that while we would like people to be able to try out new GHC
> features, we don't want to add to the burden of library maintainers by
> requiring them to update the
While I'm notionally in favor of decoupling API-breaking changes from
non-API breaking changes, there are two major difficulties: GHC.Prim and
Template Haskell. Should a non-API-breaking change mean that GHC.Prim is
immutable? If so, this greatly restricts GHC's development. If not, it
means that
I agree with Ian. Mid-February is very soon, and there's a lot of stuff
that seems to just be coming in now. That doesn't leave much time for
testing to get 7.8 out in sync with the platform.
Although my perspective is a bit colored by the last release. Testing the
7.6.1 RC took several weeks f
>
> I'd be curious to understand the change too, though per se pinned memory (a
> la storable or or bytestring) will by definition cause memory fragmentation
> in a gc'd lang as a rule, (or at least one like Haskell).
> -Carter
>
> On Thu, Sep 20, 2012 at 8:59 PM,
Hello,
We've noticed that some applications exhibit significantly worse
memory usage when compiled with ghc-7.6.1 compared to ghc-7.4, leading
to out of memory errors in some cases. Running one app with +RTS -s,
I see this:
ghc-7.4
525,451,699,736 bytes allocated in the heap
53,404,833,048 by
> From: Brandon Allbery
>
> On Sat, Aug 18, 2012 at 9:10 PM, Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> meaning: flags for treating it as a warning vs as an error? (pardon, i'm
>> over thinking ambiguity in phrasing).
>> if thats the desired difference, that sounds good to me!
>
Hello,
One of the issues I've noticed with ghc-7.6 is that a number of
packages fail due to problematic import statements. For example, any
module which uses
> import Prelude hiding (catch)
now fails to build with the error
Module `Prelude' does not export `catch'
Of course fixing this ex
Thanks very much for this information. My observations match your
recommendations, insofar as I can test them.
Cheers,
John
On Mon, Jun 25, 2012 at 11:42 PM, Simon Marlow wrote:
> On 19/06/12 02:32, John Lato wrote:
>>
>> Thanks for the suggestions. I'll try them and re
2012 at 8:49 AM, Ben Lippmeier wrote:
>
> On 19/06/2012, at 24:48 , Tyson Whitehead wrote:
>
>> On June 18, 2012 04:20:51 John Lato wrote:
>>> Given this, can anyone suggest any likely causes of this issue, or
>>> anything I might want to look for? Also, should I be co
Hello,
I have a program that is intermittently experiencing performance
issues that I believe are related to parallel GC, and I was hoping to
get some advice on how I might improve it. Essentially, any given
execution is either slow or fast (the same executable, without
recompiling), most often s
m pretty sure somebody else on this list already mentioned.
Perhaps a pragma like "DefaultString Data.Text.Text", which would mean
that string literals would be treated as the provided monomorphic
type, on a per-module basis?
John Lato
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> From: Evan Laforge
>
> On Wed, Jan 25, 2012 at 11:42 AM, Ryan Newton 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
> From: Heka Treep
> Subject: Re: Is it true that an exception is always terminates the
> thread?
> To: "Edward Z. Yang"
> Cc: glasgow-haskell-users
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 2012/1/23, Edward Z. Yang :
>> Excerpts from Heka Treep's message
I agree the OS scheduler is likely to contribute to our different
observations. I'll try to test with ghc-7.4-rc1 tonight to see if I
get similar results to 7.2.1.
If you want to see some code I'll post it, although I doubt it's
necessary. I would appreciate it if you (or someone else in the kno
Hi Simon,
I'm not certain that your explanation matches what I observed.
All of my tests were done on a 4-core machine, executing with "+RTS
-N", which should be the same as "+RTS -N4" I believe.
With 1 Haskell thread (the main thread) and 4 process threads (via
pthreads), I saw a significant pe
ting the intersection).
>
Is it easy to check, out of those 344, how many would build if the
dependency on haskell98 were removed? I suspect it's not needed for the
majority of cases.
+1 for Plan A, but interested in mitigating the negative consequences.
(Bas, your link doesn't work f
Hello,
I recently tried to build ghc on OS X Snow Leopard as 64-bit with shared
library support. I had to self-compile gmp and modify mk/build.mk (I later
saw that Edward Amsden blogged about the same experience,
http://blog.edwardamsden.com/2011/04/howto-install-ghc-703-on-os-x-64-bit.html),
and
Minor update, here's how I would handle this problem (using uu-parsinglib
and the latest ListLike, mostly untested):
import Data.ListLike (fromString, CharString (..))
import Text.ParserCombinators.UU
import Text.ParserCombinators.UU.BasicInstances
import Text.ParserCombinators.UU.Utils
-- chang
Hi Tim,
Sorry I can't tell you more about slop (I know less than you at this point),
but I do see the problem. You're reading each line from a Handle as a
String (bad), then creating ByteStrings from that string with BS.pack
(really bad). You want to read a ByteString (or Data.Text, or other com
>
> Subject: building ghc-7.1.20110125 under Mac OS X
>
> hi list.
>
> i have to build ghc-7.1.20110125 under mac os x, so i grabbed the stable
> snapshot. Everything builds fine but the resulting compiler has problems
> with ld. It passes gcc flags to ld like "-march=-i686". Any ideas?
>
> BTW wh
> using a 32-bit 6.10.4 compiled on Leopard. Reports of trouble building the
> 7.0.1 release candidates using a 32-bit bootstrap compiler would be
> especially
> useful.
>
> Best Wishes,
> Greg
>
>
> On 11/9/10 12:48 PM, Brian Bloniarz wrote:
> > On 11/09/201
Hello,
I was wondering if there is a status report anywhere of progress towards
making ghc compile 64-bit on Snow Leopard. There are a few trac tickets
that seem related:
4263: http://hackage.haskell.org/trac/ghc/ticket/4163
2965: (not sure, trac says the database is locked when I try to look at
>
> From: Simon Michael
>
> On 11/2/10 10:20 AM, John Lato wrote:
> > Since Apple seems disinclined to fix the system's libiconv, and macports
> projects refuse to use it, the only real
> > solution is to use either HP without macports or the macports GHC without
On Wed, Nov 3, 2010 at 9:55 AM, Christian Maeder
wrote:
> Am 02.11.2010 18:03, schrieb Thorkil Naur:
> > Hello,
> >
> > On Tue, Nov 02, 2010 at 01:03:04PM +0100, Christian Maeder wrote:
> >> ...
> >> Are there better workarounds?
> >
> > I am not sure about that, I assume that you have looked at
>
>
> From: Christian Maeder
>
> Am 02.11.2010 11:48, schrieb Christian Maeder:
> > Hi,
> >
> > after installing
> >
> http://lambda.galois.com/hp-tmp/2010.2.0.0/haskell-platform-2010.2.0.0.i386.dmg
> > and various more libraries using cabal, we get the following linker
> > error below.
> >
> > A si
On Thu, May 20, 2010 at 1:42 PM, Brandon S. Allbery KF8NH
wrote:
> On May 20, 2010, at 08:29 , John Lato wrote:
>>
>> On Thu, May 20, 2010 at 1:07 PM, Brandon S. Allbery KF8NH
>> wrote:
>>>
>>> On May 20, 2010, at 06:23 , Simon Marlow wrote:
>>
On Thu, May 20, 2010 at 1:07 PM, Brandon S. Allbery KF8NH
wrote:
> On May 20, 2010, at 06:23 , Simon Marlow wrote:
>>
>> On 18/05/2010 17:48, John Lato wrote:
>>>>
>>>> From: Simon Marlow
>>>>>
>>>>> But currently there is
> From: Simon Marlow
>>
>
>> But currently there is one problem with "GhcShared=YES": with this
>> option, the stage-2 compiler gets linked dynamically but the
>> corresponding inplace shell wrapper does not set (DY)LD_LIBRARY_PATH,
>> thus ./inplace/bin/ghc-stage2 doesn't run at all. I could work
> From: Roman Leshchinskiy
Following on this discussion, I have an algorithm that currently uses
BLAS to do the heavy work. I'd like to try to get it working with DPH
or Repa, although my prior attempts have been less than successful.
I have a vector of vectors where each element depends upon
-Original Message-
> | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
> | users-boun...@haskell.org] On Behalf Of John Lato
> | Sent: 13 April 2010 16:15
> | To: Mozhgan kabiri
> | Cc: glasgow-haskell-users@haskell.org
> | Subject: Re: Can't
> From: Mozhgan kabiri
>
> Hi,
>
> I am trying to install Criterion package, but I keep getting an error and I
> can't figure it out why it is like this !!
>
> mozh...@mozhgan-kch:~$ cabal install Criterion
> Resolving dependencies...
> Configuring vector-algorithms-0.3...
> Preprocessing library
> From: Christian H?ner zu Siederdissen
>
> Hi,
>
> I am thinking about how to easily generate instances for a class. Each
> instance is a tuple with 1 or more elements. In addition there is a
> second tuple with the same number of elements but different type. This
> means getting longer and longer
On Thu, Oct 29, 2009 at 8:37 AM, Philip K.F.
wrote:
> Dear GHCers,
>
>
> On Wed, 2009-10-28 at 12:14 +0000, John Lato wrote:
>> >> This had me confused for a while, but I think I've worked out what's
>> >> happening. (+) is polymorphic, ...
>&
> From: Isaac Dupree
> David Menendez wrote:
>> On Sun, Oct 25, 2009 at 1:37 PM, Isaac Dupree
>> wrote:
>>> David Menendez wrote:
The expected type is what the context wants (it's *ex*ternal). The
inferred type is what the expression itself has (it's *in*ternal).
So inferring
ss-precision and the results are the same. The only other
> | compiler flags in use are -O2 and --make. Is this expected behavior
> | or a possible bug? I believe the value with -fno-pre-inlining is
> | correct (and runs about 30% faster too).
> |
> | This was done on an OSX 10.5 Macboo
make a self-contained test case, do make a Trac ticket for it.
>
> Are you using the FFI?
>
> All very odd.
>
> Simon
>
> | -Original Message-
> | From: glasgow-haskell-users-boun...@haskell.org
> [mailto:glasgow-haskell-users-
> | boun...@haskell.org] On Behalf
ected behavior
or a possible bug? I believe the value with -fno-pre-inlining is
correct (and runs about 30% faster too).
This was done on an OSX 10.5 Macbook with GHC-6.10.3. I could check
this on some other systems if it would be helpful.
Sincerely,
John
>From the perspective of someone who doesn't use GADT's much, I find
(B) to be more clear.
John Lato
> SPJ wrote:
>
> Question for everyone:
>
> * are (A) and (B) the only choices?
> * do you agree (B) is best
>
___
Yes, this does help, thank you. I didn't know you could generate
specialized instances. In fact, I was so sure that this was some
arcane feature I immediately went to the GHC User Guide because I
didn't believe it was documented.
I immediately stumbled upon Section 8.13.9.
Thanks to everyone wh
INSTANCE
>
> Does that make sense?
>
> Simon
>
> | -Original Message-
> | From: Neil Mitchell [mailto:[EMAIL PROTECTED]
> | Sent: 28 November 2008 09:48
> | To: Simon Peyton-Jones
> | Cc: John Lato; glasgow-haskell-users@haskell.org; Don Stewart
> | Subject:
> On Monday 24 November 2008 23:15, Barney Stratford wrote:
>> There's good news and bad news. The good news is that the compilation of
>> my shiny almost-new GHC is complete. The bad news is, it won't link.
>> It's grumbling about
>>
>> ld:
>> /System/Fink/src/fink.build/ghc-6.8.2-1/ghc-6.8.2/rts/
On Sat, Nov 22, 2008 at 6:55 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> jwlato:
>
> Is this , since it is in IO code, a -fno-state-hack scenario?
> Simon wrote recently about when and why -fno-state-hack would be
> needed, if you want to follow that up.
>
> -- Don
>
Unfortunately, -fno-state-ha
On Wed, Nov 19, 2008 at 4:17 PM, Simon Peyton-Jones
<[EMAIL PROTECTED]> wrote:
> | I'm compiling with -O2 -Wall. After looking at the Core output, I
> | think I've found the key difference. A function that is bound in a
> | "where" statement is different between the monolithic and split
> | sourc
On Sat, Nov 15, 2008 at 10:09 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> jwlato:
>> Hello,
>>
>> I have a problem with a package I'm working on, and I don't have any
>> idea how to sort out the current problem.
>>
>> One part of my package is in one monolithic module, without an export
>> list, w
Hello,
I have a problem with a package I'm working on, and I don't have any
idea how to sort out the current problem.
One part of my package is in one monolithic module, without an export
list, which works fine. However, when I've started to separate out
certain functions into another module, an
80 matches
Mail list logo
