2014-10-23 22:49 GMT+02:00 Luite Stegeman :
> If stability/segfaults are a major factor in choosing to communicate with
> the GHCi program, rather than using GHC as a library, then this really
> should be addressed directly. Has anyone done investigation of the
> situations that make ghc-mod/ghc-s
Sorry I'm a bit late to the party, I'm a bit snowed under with some GHCJS
refactoring work and the things I really need to do before the 7.10 merge
window closes.
I think that exposing GHC's front end functionality through the library
would be a good idea. Unfortunately it adds the haskeline depen
2014-10-22 3:20 GMT+02:00 Carter Schonwald :
> i'm pretty sure they're usable in ghci... i think theres just certain flags
> that need to be invoked for one reason or another, but I could be wrong (and
> i've not tried in a while)
I just gave a few OpenGL/GLUT examples a try with the 2014.2.0.0
pl
i'm pretty sure they're usable in ghci... i think theres just certain flags
that need to be invoked for one reason or another, but I could be wrong
(and i've not tried in a while)
On Tue, Oct 21, 2014 at 2:58 PM, George Colpitts
wrote:
> Along the lines of making GHCi better it would be very nic
Along the lines of making GHCi better it would be very nice if we could use
SDL, OpenGL etc in GHCi.
Is there a characterization of the libraries that we can't use in ghci?
As you know this has been a problem for years. Is there an open bug about
it?
I know there was some hope that dynamic linki
different versions will be considered to have *different* types (albeit
with the same name)
On Mon, Oct 20, 2014 at 2:27 PM, Christopher Allen
wrote:
> Sorry to bother everybody, but where is this documented? What happens if
> incompatible versions pass data between each other?
>
> On Mon, Oct
Christopher Allen writes:
> Sorry to bother everybody, but where is this documented? What happens if
> incompatible versions pass data between each other?
>
I would hope this would manifest as a type error.
Cheers,
- Ben
pgpfrATN2ZiHY.pgp
Description: PGP signature
__
Sorry to bother everybody, but where is this documented? What happens if
incompatible versions pass data between each other?
On Mon, Oct 20, 2014 at 1:22 PM, Edward Z. Yang wrote:
> Excerpts from Eric Seidel's message of 2014-10-20 09:32:41 -0700:
> > I read recently that Rust has some sort of s
Excerpts from Eric Seidel's message of 2014-10-20 09:32:41 -0700:
> I read recently that Rust has some sort of symbol-mangling in place to allow
> multiple versions of the same library to co-exist within a single build.
>
> How feasible would it be to add this feature to GHC? At a first glance it
Sure, but how often does the API deal with types that aren't defined by `ghc`
or `base`? ByteString is one case I can think of, if you want to muck about
with FastStrings without the overhead of Strings.
> On Oct 20, 2014, at 09:59, Brandon Allbery wrote:
>
> On Mon, Oct 20, 2014 at 12:32 PM,
On Mon, Oct 20, 2014 at 12:32 PM, Eric Seidel wrote:
> How feasible would it be to add this feature to GHC? At a first glance it
> seems like it would help substantially
Only until you need to hand off data between them, sadly.
--
brandon s allbery kf8nh sine nom
> On Oct 20, 2014, at 09:14, Ben Gamari wrote:
>
> Simon Peyton Jones writes:
>
>> Christopher
>>
>> You are doing very cool things. Thank you.
>>
>> What I’m puzzled about is this: the GHC API *is* a programmatic
>> interface to GHC. Why not just use it?
>
> One issue that sometimes bite
Simon Peyton Jones writes:
> Christopher
>
> You are doing very cool things. Thank you.
>
> What I’m puzzled about is this: the GHC API *is* a programmatic
> interface to GHC. Why not just use it?
One issue that sometimes bites me when trying to compile against GHC is
that of dependencies. Whe
Christopher
You are doing very cool things. Thank you.
What I’m puzzled about is this: the GHC API *is* a programmatic interface to
GHC. Why not just use it?
I can think of some reasons:
· It’s not very clear just what’s in the GHC API and what isn’t, since
you have access to all of
On 18 October 2014 22:36, Herbert Valerio Riedel wrote:
Yeah, it's quite convenient to hack on GHCi that way as it's just an
> ordinary Cabal package (so it doesn't require to setup a GHC source-tree
> and wrangle with the GHC build-system), if you're lucky enough (which is
> most of the time) th
On 2014-10-18 at 19:59:24 +0200, Christopher Done wrote:
[...]
> Herbert doesn't have time to hack on it, but was encouraging about
> continuing with ghci-ng.
Yeah, it's quite convenient to hack on GHCi that way as it's just an
ordinary Cabal package (so it doesn't require to setup a GHC source-
From: Christopher Done
Subject: Re: Making GHCi awesomer?
Date: Sat, 18 Oct 2014 19:59:24 +0200
> I haven't used ghc-mod enough to have a crash happen to me. I couldn't get
> it to work the times I'd tried it and others make this complaint. Whereas
> GHCi works for ever
On 18 October 2014 19:28, Daniel Gröber wrote:
> Do you have any examples of such projects, I've never seen any
> complaints about ghc-mod doing this.
>
I haven't used ghc-mod enough to have a crash happen to me. I couldn't get
it to work the times I'd tried it and others make this complaint. Wh
On 18 October 2014 19:05, Mateusz Kowalczyk wrote:
> Sounds interesting. My only request/comment is that I hope whatever
> conclusion you come to, the library part of it will be usable just as
> much (or even more) as the executable: if we can talk to the library
> natively then that's much easie
From: Mateusz Kowalczyk
Subject: Re: Making GHCi awesomer?
Date: Sat, 18 Oct 2014 18:05:49 +0100
> Sounds interesting. My only request/comment is that I hope whatever
> conclusion you come to, the library part of it will be usable just as
> much (or even more) as the executable: if we
From: Christopher Done
Subject: Making GHCi awesomer?
Date: Sat, 18 Oct 2014 17:48:48 +0200
>1. The first problem with this is that every three projects will
>segfault or panic when trying to load in a project that GHCi will
>load in happily. [...] People have similar complaints of GH
On 10/18/2014 04:48 PM, Christopher Done wrote:
> Good evening,
>
> So I’ve been working on Haskell user-facing tooling in general for
> some years. By that I mean the level of Emacs talking with Haskell
> tools.
>
> [snip]
>
> You’ve seen some of these features in GHC Mod, in hdevtools, in the
I think there is currently a more general interest in this, and the ghc-mod
guys are thinking on similar lines, see
https://github.com/kazu-yamamoto/ghc-mod/issues/349
Alan
On Sat, Oct 18, 2014 at 5:48 PM, Christopher Done
wrote:
> Good evening,
>
> So I’ve been working on Haskell user-facing t
23 matches
Mail list logo
