al
> algorithms in GHC.
>
> Greetings,
> Joachim
>
> Am Sonntag, den 04.12.2016, 20:04 + schrieb David Turner:
> > Nod nod.
> >
> > amazonka-ec2 has a particularly painful module containing just a
> > couple of hundred type definitions and associated instance
Nod nod.
amazonka-ec2 has a particularly painful module containing just a couple of
hundred type definitions and associated instances and stuff. None of the
types is enormous. There's an issue open on GitHub[1] where I've guessed at
some possible better ways of splitting the types up to make GHC's
Hi,
You can alter the content of a GitHub PR after its initial creation. The
semantics of a PR is "please merge my branch named B into your repo" where
the branch B is a mutable pointer to a commit.
A workflow I've used a few times is to craft a nice sequence of commits for
review and, once accep
One tiny amendment to a comment(!) in the non-normative(!) code in Phase 3:
data WindowsFilePath = WFP ByteArray# -- UTF16 data
If a Windows file path is valid UTF-16 then it is displayed as such in the
GUI, but if not it's still a legal file path. It really is just wchar_t[]
data:
data Windows
Hi,
I think it'd be more robust to handle normalisation when converting from
String/Text to FilePath (and combining things with () and so on) rather
than in the underlying representation.
It's absolutely crucial that you can ask the OS for a filename (which it
gives you as a sequence of bytes) an
s 'fail' but doesn't handle ⊥.
On 11 June 2015 at 16:28, Wolfgang Jeltsch wrote:
> Are you sure that desugaring works this way? If yes, this should be
> considered a bug and be fixed, I would say. It is very illogical.
>
> All the best,
> Wolfgang
>
> Am Donn
AIUI the point about ⊥ and (⊥, ⊥) being different doesn't matter here:
a bind for a single-constructor datatype never desugars in a way that
uses fail (which isn't to say that it can't be undefined)
For instance:
runErrorT (do { (_,_) <- return undefined; return () } :: ErrorT String IO ())
thro
Excellent, thanks!
On 3 Jun 2015 7:58 pm, "Edward Z. Yang" wrote:
> The ordering is guaranteed, because full synchronization is used
> when threads migrate. (It goes something like, a capability with
> a full run queue grabs all idle capabilities, distributes its
> threads to those capabilities,
; context switch,
> they are guarantee.
> But I think that it would not guarantee the full case.
>
>
> I feel that order issues are very difficult.
> I think order issues can be safely solved by explicit notation,
> like explicit memory barrier notation, STM,...
>
>
>
Hi,
If I make a sequence of FFI calls (on a single Haskell thread) but
which end up being called from different OS threads, is there any kind
of ordering guarantee given? More specifically, is there a full memory
barrier at the point where a Haskell thread migrates to a new OS
thread?
Many thanks
Turns out this was already a known issue:
https://ghc.haskell.org/trac/ghc/ticket/9762 and a fix is now on the
way for 7.10.1. In the meantime, adding -fomit-interface-pragmas works
for me.
Thanks,
David
On 19 December 2014 at 21:58, David Turner
wrote:
> Ok, I've open
Ok, I've opened https://ghc.haskell.org/trac/ghc/ticket/9909
I won't be able to repro on HEAD in the near future, I'm afraid.
Many thanks,
On 19 December 2014 at 21:32, Edward Z. Yang wrote:
> Sounds like a bug. File a ticket? If you can see if you can
> repro on GHC HEAD that would also be hel
Hi,
I'm getting the following error message when compiling a Yesod
application (which uses Template Haskell rather a lot) with -fhpc:
/usr/bin/ld: ./Foundation.dyn_o: relocation R_X86_64_PC32 against
undefined symbol `_hpc_tickboxes_Settings_hpc' can not be used when
making a shared object; recom
13 matches
Mail list logo
