Thanks!
Turns out I actually needed an `Ord` instance for `(TyCon, [TyCon])`, which
made using `UniqFM` rather difficult, but it wasn't hard to work around the
issue by using nonDetCmpUnique function from the `Unique` module. For a
side project, I think it's good enough..
Cheers,
-Levent.
On
eal movement can be made on either of these issues
> without editing GHC itself. I don't see what a purely-external library
> could do.
>
> * Yes yes yes, lots lots lots of pattern synonyms.
>
> Does this clarify anything?
>
> Richard
>
> On Dec 9, 2015, at 12:28
quidHaskell
when you had similar problems. That definitely is a great approach as well,
though I don't have the luxury of an academic research team to pursue that
line of thought. (LiquidHaskell rocks by the way; I'm a real fan.)
-Levent.
On Fri, Dec 11, 2015 at 3:13 PM, Eric Seidel <e...@s
y for a more public announcement:
http://github.com/LeventErkok/sbvPlugin/
-Levent.
On Fri, Dec 11, 2015 at 4:01 PM, Eric Seidel <e...@seidel.io> wrote:
> On Fri, Dec 11, 2015, at 15:28, Levent Erkok wrote:
> > My "hidden agenda" is to liberate the SBV library to
Would it be appropriate for us to start putting together this
> shim? As Simon says in (
> https://ghc.haskell.org/trac/ghc/ticket/11081#comment:5) we can go a long
> ways with a plethora of pattern synonyms.
>
>
> On Tue, Dec 8, 2015 at 9:51 PM, Levent Erkok <erk
a ticket. I can advise if anyone wants to take it up.
>
>
>
> Simon
>
>
>
> *From:* Levent Erkok [mailto:erk...@gmail.com]
> *Sent:* 08 December 2015 03:32
>
> *To:* Simon Peyton Jones <simo...@microsoft.com>
> *Cc:* Eric Seidel <e...@seidel.io>; omer
I just came across https://ghc.haskell.org/trac/ghc/ticket/11081, and the
corresponding wiki-page:
https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective
I think this is a terrific idea. In the past, I've tried both TH and
haskell-src-exts to do relatively simple things, but ended-up
ng their ExportFlag set, even though they are not exported
> in the source-code sense.
>
> We should probably use a different term for ExportFlag, like
> KeepAlive.
>
> From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Levent Erkok
> Sent: 06 December 2015 20
; If it's "dead" in this sense, it's already removed from ModGuts, no?
>
> Yes, if it’s dead it’s gone. That’s not too surprising, is it?
>
> So you need a way to keep it alive. Maybe we need a pragma for that. Or how
> would you like to signal it in the source co
: your plugin could add a pass right at the start, which marks
> everything you want as keep-alive.
>
> S
>
> From: Levent Erkok [mailto:erk...@gmail.com]
> Sent: 07 December 2015 12:42
> To: Simon Peyton Jones <simo...@microsoft.com>
> Cc: Eric Seidel <e..
[mailto:e...@seidel.io]
> | Sent: 07 December 2015 15:44
> | To: Simon Peyton Jones <simo...@microsoft.com>
> | Cc: Levent Erkok <erk...@gmail.com>; omeraga...@gmail.com;
> | ezy...@mit.edu; ghc-devs@haskell.org
> | Subject: Re: Plugins: Accessing unexported bind
> GHC should only drop un-exported bindings from the ModGuts if they're
> also unused, ie *dead code*.
>
> The only way I know to get around this is to use the bindings somewhere,
> or just export them.
>
> On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
> > Hello,
> >
There's a function for that:
https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-Stack.html#v:showCallStack
On Sun, Dec 6, 2015 at 8:43 PM, Richard Eisenberg wrote:
> Hi devs,
>
> I wish to use the new CallStack feature to track call sites of a function.
> I want my
Hello,
The mg_binds field of the ModGuts seem to only contain the bindings that
are exported from the module being compiled.
I guess GHC must be running user-plugins after it drops the bindings that
are not exported, which makes perfect sense for most use cases. However,
I'm working on a plugin
Thanks Simon.. I tried the 'hscTarget df == HscInterpreted' check, and it
works perfectly well.
-Levent.
On Fri, Dec 4, 2015 at 12:34 AM, Simon Marlow <marlo...@gmail.com> wrote:
> On 24/11/2015 07:37, Levent Erkok wrote:
>
>> I'm working on a plugin, and would like to be ab
How about `GHC.Environment.getFullArgs` which includes “—interactive” when
> you’re in GHCi?
>
>
> > On 24 Nov 2015, at 09:37, Levent Erkok <erk...@gmail.com> wrote:
> >
> > I'm working on a plugin, and would like to be able to tell if it's GHC
> or GHCi that's running.
> >
> >
I'm working on a plugin, and would like to be able to tell if it's GHC or
GHCi that's running.
I tried:
df <- getDynFlags
let isGHCi = ghcMode df == CompManager
Alas, while that correctly tells apart "ghci" from "ghc -c", it also
returns True when ghc is called without the "-c"
s://github.com/NixOS/patchelf/blob/master/README
>
> On Mon, 31 Aug 2015 01:50 Levent Erkok <erk...@gmail.com> wrote:
>
>> Thanks Aycan. The LD_PRELOAD solution did indeed work. I didn't know
>> about that facility before, so I'm pleasantly surprised.
>>
>>
; so I
gave up fairly quickly. If it was a machine I had root access to then I'd
have given it more time; but with only user-level access, I didn't pursue
anything further.
On Sun, Aug 30, 2015 at 2:49 AM, Tuncer Ayaz <tuncer.a...@gmail.com> wrote:
> On Sat, Aug 29, 2015 at 10:41 PM, Lev
Hello all,
I've been having a lot of trouble installing the binary-distro's on a SuSE
machine. Unfortunately, I don't have root privileges and thus my options
are rather limited.
The problem seem to boil down to the use of the function
pthread_setname_np. It appears the problem was noted before,
trials
if needed. In the meantime, I'm still looking for a binary-linux-distro
that doesn't require the set_threadname_np functionality, if anyone can
point me in that direction.
Thanks,
-Levent.
On Sat, Aug 29, 2015 at 3:23 PM, Kosyrev Serge _deepf...@feelingofgreen.ru
wrote:
Levent Erkok
I agree with Iavor on this one. I use Haskell professionally as well, and
I'm actually quite fond of what it leaves out in terms of both syntax and
semantics, as opposed to what it adds. Whether it's pragma protected or
not, I just don't see the point of complicating the language with such a
So, it appears that the one ending with 21 is the likely correct result; as
opposed to 22.
Is this an issue with some underlying library (glibc etc.); or an issue
with GHC itself?
On Sat, Jul 12, 2014 at 8:03 PM, GHC ghc-devs@haskell.org wrote:
#9304: Floating point woes; Different behavior
23 matches
Mail list logo