Re: New Windows I/O manager in GHC 8.12

[Mikhail Glushenkov]

Hi Tamar,

Congratulations on getting WinIO merged, this is a really impressive effort.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cabal woes

[Mikhail Glushenkov]

Hi,

On Mon, 15 Apr 2019 at 23:56, Simon Peyton Jones via ghc-devs
 wrote:
>
> That’s a tremendously helpful summary, thank you Iavor.  And Michail’s 
> summary was also very helpful.
>
>
>
> Most of this is doubtless well-known to habitual cabal users, but it might be 
> useful to explain the user model, in a way that covers these points, 
> somewhere close to the Cabal home page.

If anyone reading this is interested in helping out with website and
documentation, we'll gladly accept PRs.

Documentation for Cabal lives at
https://github.com/haskell/cabal/tree/master/Cabal/doc and the website
sources are at https://github.com/haskell/cabal-website/ (see also the
feature/next branch).
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cabal woes

[Mikhail Glushenkov]

Hi Brandon,

On Mon, 15 Apr 2019 at 23:46, Brandon Allbery  wrote:
>
> Mikhail, the use case not addressed here is people who are used to v1-style 
> and want to keep using it — and possibly aren't in a great position to rewire 
> their setup to fit how v2 thinks. Personally, I have situations where I use 
> v2 and others where v1 works better.

Sure, that's why we kept v1-* set of commands for now, and also have
implemented 'v2-install --lib' (which would have worked for Simon if
not for the #5990 issue).
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cabal woes

[Mikhail Glushenkov]

Hello Simon,

On Mon, 15 Apr 2019 at 23:14, Simon Peyton Jones via ghc-devs
 wrote:
>
> It is terribly mysterious that “cabal install hspec” doesn’t, well, install 
> hspec.

In the cabal v2-* model [1] installing libraries globally is no longer
the recommended mode of operation, which is why you now need to pass
--lib to 'install' to do that.

There are now better alternatives for most use cases of 'install --lib':

* For just trying out some set of libraries in REPL, you can use
`cabal new-repl --build-depends=foo,bar,baz` outside of a project
instead of ghci. [2] If you have .ghc.environment file generation
turned on, you can also use plain ghci inside your project, and it
will pick up the project context. [3]
* For running Haskell scripts that expect extra libraries in the
global package DB you can use `#! cabal` instead of `#! runghc`. [4]

> It must surely be a bug that “cabal install –lib hspec” simply crashes.

This is a bug that we haven't fixed yet [5]. Should've just worked.


[1] https://cabal.readthedocs.io/en/latest/nix-local-build-overview.html
[2] https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-v2-repl
[3] 
https://cabal.readthedocs.io/en/latest/nix-local-build.html#cfg-field-write-ghc-environment-files
[4] https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-v2-run
[5] https://github.com/haskell/cabal/issues/5990
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Mikhail Glushenkov]

Hi *,

On Fri, 5 Apr 2019 at 12:09, Matthew Pickering
 wrote:
>
> [...]
>
> Therefore, it seems the correct course of action is to stop cabal
> generating the environment files by default. If user's still want to
> use them then they are easy to enable globally via a configuration
> setting.
>
> This can be achieved by adding the following to your "~/.cabal/config" file:
>
> write-ghc-environment-files: always

Please also note that this can be set per-project in the
'cabal.project' file. This is what we (Scrive AB) use to make ghcid
work out of the box for everyone in the team.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC's Fall 2018 HCAR submission

[Mikhail Glushenkov]

Hello Simon,

On Mon, 12 Nov 2018 at 10:14, Simon Peyton Jones via ghc-devs
 wrote:
>
> Ben
>
> What's the deadline for this?

Nov 4, according to Mihai Maruseac's original e-mail [1]. Though this
month's edition hasn't been published yet.

[1] https://mail.haskell.org/pipermail/haskell-cafe/2018-October/130071.html
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC DevOps Group] Fwd: Release policies

[Mikhail Glushenkov]

Hi Mathieu,

On 15 December 2017 at 08:41, Boespflug, Mathieu  wrote:
> In principle, every single
> Hackage package out there, which all have a Setup.hs script.

Also, the build-type: Simple packages (which are the vast majority on
Hackage) are not affected at all, because they all use a default
built-in setup script.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC DevOps Group] Fwd: Release policies

[Mikhail Glushenkov]

Hi Mathieu,

On 15 December 2017 at 08:41, Boespflug, Mathieu  wrote:
> How many other
> users of Cabal-the-library are there? In principle, every single
> Hackage package out there, which all have a Setup.hs script.

This is not such a big deal now, because build-type: Custom packages
can declare the dependencies of the Setup script via the custom-setup
stanza. By default (when there's no custom-setup stanza), Cabal < 2 is
chosen.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Is Safe Haskell intended to allow segfaults?

[Mikhail Glushenkov]

Hi,

On 9 August 2016 at 01:32, David Terei  wrote:
> I imagine in Java, that I can construct an invalid pointer in foreign
> code, and then cause segfaults without the Java code having any
> issues. Just guessing at this, so very interested to know how it's
> prevented if I can't.

Yes, this can be done with JNI, see e.g. [1]. Additionally, by using
sun.misc.Unsafe [2], one can cause segfaults even from pure Java.

[1] https://www.cs.princeton.edu/~appel/papers/safejni.pdf
[2] http://www.inf.usi.ch/faculty/lanza/Downloads/Mast2015a.pdf
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cabal status for GHC 8.0.1

[Mikhail Glushenkov]

Hi,

On 12 January 2016 at 17:50, Ben Gamari  wrote:
> Within what timeframe in particular do you think we'll
> be able to have a release tagged and (and ideally released)? Is late
> January possible?

Yes, I think it should be possible. In fact, all Cabal library changes
required by nix-local-build and hackage-security are already in. I
plan to merge some remaining open PRs and then create the 1.24 branch.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: OVERLAPPABLE/OVERLAPPING/OVERLAPS pragmas are confusing

[Mikhail Glushenkov]

Hi,

On 25 August 2015 at 14:18, Johan Tibell johan.tib...@gmail.com wrote:
 The proposed change to my library is here:
 https://github.com/tibbe/cassava/pull/95/files

 We remove the OverlappingInstances pragma and instead add an OVERLAPPABLE
 pragma like so:

 instance {-# OVERLAPPABLE #-} FromField a = FromField (Maybe a) where

 This causes clients of the library that previously compiled (e.g. the
 music-parts package) to no longer compile, due to a now lacking OVERLAPPING
 pragma in their code.

No, it's not quite like that. Client code can start to break when {-#
LANGUAGE OverlappingInstances #-} is removed, as happened with the
music-parts package. Adding an OVERLAPPABLE pragma to cassava's code
made that error go away.

Client code can usually work around the problem of missing
OVERLAPPABLE pragmas in the library by adding OVERLAPPING pragmas to
their instances. The reason I suggested bumping cassava's version is
that there may be some places in cassava that still need new pragmas
that I've overlooked.

If GHC had an option for detecting overlapping instances at definition
site, that'd help, I think, since then it'd be easier to find
instances that need new pragmas.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ANNOUNCE: GHC version 7.10.2

[Mikhail Glushenkov]

Hi,

On 29 July 2015 at 17:26, Ben Gamari b...@well-typed.com wrote:
 [...]
 The full release notes including a complete listing of the changes in
 this release can be found here,

   
 https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/release-7-10-2.html

This gives me error 404.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cabal and simultaneous installations of the same package

[Mikhail Glushenkov]

On 7 May 2015 at 22:34, Simon Peyton Jones simo...@microsoft.com wrote:
 Dear Cabal developers

 I guess everyone is busy, but I feel a bit stuck on knowing how to make
 progress on this thread.

Vishal Agrawal's GSoC proposal has been accepted. I guess we'll have
to wait and see what comes out of it now.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Native -XCPP Proposal

[Mikhail Glushenkov]

On 6 May 2015 at 14:25, Austin Seipp aus...@well-typed.com wrote:
   2) The lexing rules for C and Haskell simply are not the same in
 general.

One area where this is irritating is that it makes it impossible to
use Haskell multiline strings together with CPP.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: FYI: Cabal-1.22.1.0 has been released

[Mikhail Glushenkov]

On 22 February 2015 at 19:51, Ömer Sinan Ağacan omeraga...@gmail.com wrote:
 Where can we see the changelog?
 https://github.com/haskell/cabal/blob/master/Cabal/changelog - this
 file has not been updated.

It's a bugfix release.
Check out 
https://github.com/haskell/cabal/compare/Cabal-v1.22.0.0...Cabal-v1.22.1.1
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest cabal-install

[Mikhail Glushenkov]

Hi,

On 1 January 2015 at 19:00, George Colpitts george.colpi...@gmail.com wrote:
 Thanks, there seems to be dependency issues:

Try also adding '--allow-newer=bytestring,deepseq'.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Linker change in GHC 7.8 leads to widespread issues

[Mikhail Glushenkov]

Hi,

On 4 December 2014 at 17:50, Joachim Breitner m...@joachim-breitner.de wrote:

 in this case, can we get a fixed Cabal in 7.8.4?

This is up to whoever manages the release at GHC HQ, which I guess means Austin.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Linker change in GHC 7.8 leads to widespread issues

[Mikhail Glushenkov]

Hi,

On 4 December 2014 at 09:45, Joachim Breitner m...@joachim-breitner.de wrote:
 is the bug in Cabal or cabal-install?

It's in Cabal. So once the new point releases are out, the users will
need to run `cabal install cabal-install --constraint=Cabal 
1.20.0.2`.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Linker change in GHC 7.8 leads to widespread issues

[Mikhail Glushenkov]

Hi,

On 2 December 2014 at 22:06, Bryan O'Sullivan b...@serpentine.com wrote:
 Hi folks,

 It seems that something somewhere in linker-land changed in GHC 7.8 such
 that packages that include C components now need to be built with
 position-independent code on some platforms.

I've now fixed this issue in Cabal HEAD and also pushed the fix to
1.20 and 1.18 branches. 1.20 and 1.18 point releases should be out
soon.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: cabal sdist trouble with GHC from head

[Mikhail Glushenkov]

Hi,

On 30 October 2014 21:30, Sven Panne svenpa...@gmail.com wrote:
 2014-10-30 17:20 GMT+01:00 Austin Seipp aus...@well-typed.com:
 [...] So this just means that Cabal isn't necessarily *future compatible*
 with future GHCs - they may change the package format, etc. But it is
 backwards compatible with existing ones.

 OK, that's good to know. To be sure, I've just tested Cabal head + GHC
 7.8.3, and it works. But as I've mentioned already, there seems to be
 *no* Cabal version which works with GHC head:
 https://travis-ci.org/haskell-opengl/StateVar/builds/39533448 Is this
 known to the Cabal people?

Yes, I know that the Cabal test suite wasn't passing on GHC HEAD for some time.

Re: the next release - I think it'll be out at the same time with GHC 7.10.1.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: One-shot semantics in GHC event manager

[Mikhail Glushenkov]

Hi,

On 17 October 2014 16:27, Austin Seipp aus...@well-typed.com wrote:
 The catch with such a change is that there is no macro to determine
 whether we're using 7.8.3 or 7.8.4, so it's harder for users to figure
 things out (they have to use `MIN_VERSION_base` from Cabal). But maybe
 that doesn'tm atter too much. So, yes, I think it's doable, but that's
 a sticky bit.

Recent versions of Cabal (1.20+) define a MIN_TOOL_VERSION macro
similar to MIN_VERSION_.

So you can use '#if MIN_TOOL_VERSION_ghc(7,8,4)' to detect GHC 7.8.4.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: tar --help is failing on Solaris.

[Mikhail Glushenkov]

Hi Karel,

On 27 September 2014 20:19, Karel Gardas karel.gar...@centrum.cz wrote:

 [...]
 Could you be so kind and revert this patch or fix it to also work on
 Solaris? For Solaris the change should be easy, simply if you invoke
 Solaris' tar with --help, it'll fail with exit code 1 and help message
 printed into the stderr. If you are curious if it supports --format, then
 no.

Should be fixed now. Thanks for the heads-up!
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: HEADS UP: Running cabal install with the latest GHC

[Mikhail Glushenkov]

Hi,

On 13 August 2014 16:12, Johan Tibell johan.tib...@gmail.com wrote:
 I'm still aiming for another
 major release before 7.10? When's 7.10 scheduled before?

End of the year, I think.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: HEADS UP: Running cabal install with the latest GHC

[Mikhail Glushenkov]

Hi,

On 13 August 2014 16:22, Mikhail Glushenkov
the.dead.shall.r...@gmail.com wrote:
 End of the year, I think.

Correction: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1
says February 2015.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Release building for Windows

[Mikhail Glushenkov]

Hi,

On 4 August 2014 14:52, Sven Panne svenpa...@gmail.com wrote:
 Do you have an URL for this FAQ? I can't find it, and I can't remember
 what's wrong with --enable-split-objs. :-( What is the impact for
 people using large libraries (like OpenGL/OpenGLRaw/...) where you
 often use only a small part? Will you get a huge executable then? IIRC
 that's at least the case for Linux.

https://ghc.haskell.org/trac/ghc/wiki/GHC-7.8-FAQ

One of the problems is that split-objs is extremely slow, especially
on Windows. I had to disable split-objs for OpenGL-related libraries
when building the HP installer in the past because of this.

Randy also said that libraries built with split-objs don't work well
in ghci on Windows x64.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Removing GHC's dependency on Cabal

[Mikhail Glushenkov]

Hi,

On 24 July 2014 16:07, Joachim Breitner m...@joachim-breitner.de wrote:

 So while Duncan’s Proposal has no such dependency, in Simon’s proposal
 there is one. Will ghc-db’s interface be stable enough that the Cabal
 developers will be happy to build against a very old version of it?

Cabal's policy is to support versions of GHC that are up to 3 years
old, so I think this could be solved with a combination of #ifdefs and
automatic testing.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: ANNOUNCE: GHC 7.8.1 Release Candidate 2

[Mikhail Glushenkov]

Hello,

On 4 March 2014 09:17, José Pedro Magalhães j...@cs.uu.nl wrote:
 Hello,

 This GHC crashes whenever I try installing any package. (I guess this might
 be due to cabal-install, though.)

No, looks like a GHC issue.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Runtime error using LLVM bitcode execution

[Mikhail Glushenkov]

Hello Simon,

On 3 March 2014 09:39, Simon Marlow marlo...@gmail.com wrote:
 I believe the problem is that we can't represent the output of the mangler
 in LLVM's intermediate language as it stands.  Although I think it may now
 be possible to do this with LLVM 3.4:

 http://www.haskell.org/pipermail/ghc-devs/2013-September/002565.html

 GHC's code generator needs to be updated to take advantage of this.  Is
 anyone interested in looking into it?

IIUC, GHC can't take advantage of this yet, because global symbol
offsets [1] are not yet implemented. LLVM currently doesn't allow
arbitrary function prefix data, but requires prefix data to begin
with a sequence of bytes which decode to a sequence of machine
instructions, [...] which transfer control to the point immediately
succeeding the prefix data [2].

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061511.html
[2] http://llvm.org/docs/LangRef.html#prefix-data
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [PATCH] platformFromTriple: fix to recognize Solaris triple (i386-pc-solaris2.11)

[Mikhail Glushenkov]

Hi,

On Mon, Jan 13, 2014 at 11:38 PM, Herbert Valerio Riedel
hvrie...@gmail.com wrote:

 You'll need to persuade the Cabal devs to make the fix above available
 in a stable branch; if the fix makes it into a Cabal release in time for
 the final GHC 7.8 release, it will most likely be part of 7.8. However,
 I don't know if there's a concrete plan for a Cabal-1.18.1.3 release
 currently.

Johan is the final authority on this, but IIRC we wanted 1.18.1.2 to
be the final 1.18 release. I'll merge that fix into the 1.18 branch.

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: 7.8 Release Update

[Mikhail Glushenkov]

Hi,

On Mon, Sep 9, 2013 at 10:11 PM, Simon Marlow marlo...@gmail.com wrote:

 I think Kazu is saying that when he builds something with profiling using
 cabal-install, it fails because cabal-install tries to build a dynamic
 version too.  We don't want dyanmic/profiled libraries (there's no point,
 you can't load them into GHCi).  Perhaps this is something that needs fixing
 in cabal-install?

Aren't they needed when compiling libraries that are using Template
Haskell for profiling? The issue sounds like it could be TH-related.

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: 7.8 Release Update

[Mikhail Glushenkov]

Hi,

On Mon, Sep 9, 2013 at 11:21 PM, Edward Z. Yang ezy...@mit.edu wrote:
 Hello Mikhail,

 It is a known issue that Template Haskell does not work with profiling 
 (because
 GHCi and profiling do not work together, and TH uses GHCi's linker). [1] 
 Actually,
 with the new linker patches that are landing soon we are not too far off from
 having this work.

Thanks, that clears things up a bit.

Kazu (or someone else), can you please file a ticket on the Cabal bug
tracker [1] if you think that this a Cabal bug?

[1] https://github.com/haskell/cabal/issues/

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs