Re: Using lzip instead of xz for distributed tarballs

[Vanessa McHale]

Would it be plausible to distribute both? That way users would not have to 
install lzip.

Cheers,
Vanessa McHale

> On Jan 20, 2020, at 4:15 PM, Ben Gamari  wrote:
> 
> Vanessa McHale  writes:
> 
>> Hello all,
>> 
>> 
>> GHC is distributed as .tar.xz tarballs; I assume this is because it
>> produces small tarballs. However, xz is ill-suited for archiving due to
>> its lack of error recovery. Moreover, lzip produces smaller tarballs
>> with GHC (I tested with ghc-8.8.2-x86_64-deb9-linux.tar) and
>> decompression takes about the same amount of time.
>> 
> Indeed I recall seeing the "Why xz is not suitable for archival
> purposes" blog post quite a while ago and considered moving away from xz
> at the time but wasn't entirely convinced that the benefits would
> justify the churn, especially since xz tends to be pretty ubiquitous at
> this point while lzip is a fair bit less so.
> 
> I'd be happy to hear further reasons why we should switch but I'll admit
> that I still don't quite see what switching would buy us; we do have
> a few backups spread across the planet so the probability of us having
> to rely on the compressor for error recovery pretty small.
> 
> Cheers,
> 
> - Ben

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Using lzip instead of xz for distributed tarballs

[Vanessa McHale]

Hello all,


GHC is distributed as .tar.xz tarballs; I assume this is because it
produces small tarballs. However, xz is ill-suited for archiving due to
its lack of error recovery. Moreover, lzip produces smaller tarballs
with GHC (I tested with ghc-8.8.2-x86_64-deb9-linux.tar) and
decompression takes about the same amount of time.

There's more information on the project page:
https://www.nongnu.org/lzip/lzip.html.

Cheers,
Vanessa McHale



signature.asc
Description: OpenPGP digital signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cabal woes

[Vanessa McHale]

If you want to install it globally for use by GHC, I think you want
v1-install.

On 4/15/19 5:00 PM, Simon Peyton Jones via ghc-devs wrote:
>
> Thanks.  But alas I have no clue about whether I want a v1-install or
> a v2-install, nor how to achieve them if I knew what they were.  I
> just want to install ‘hspec’ so that I can use it when compiling a
> program.  How would I do that?
>
>  
>
> The instructions here https://wiki.haskell.org/Cabal-Install
> <https://wiki.haskell.org/Cabal-Install> just say “cabal install
> hspec” which is what I tried.  Those instructions are pointed to from
> here https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package,
> which in turn are pointed to from the main Cabal home page
> https://www.haskell.org/cabal/.
>
>  
>
> I must be missing something.
>
>  
>
> Simon
>
>  
>
> *From:*Brandon Allbery 
> *Sent:* 15 April 2019 22:54
> *To:* Simon Peyton Jones 
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Cabal woes
>
>  
>
> I think you wanted v1-install to install a library into the user
> package database, since your cabal is 3.x and the v2-* commands are
> now the default (that is, you did what used to be cabal new-install or
> cabal v2-install). 
>
>  
>
> On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs
> mailto:ghc-devs@haskell.org>> wrote:
>
> I’m trying to install ‘hspec’ on my WSL (Windows subsystem for
> Linux) system.
>
> But I fail; see below.
>
> For some reason cabal complains about installing a library.  (That
> seems peculiar – isn’t that what cabal is for?)  But it helpfully
> suggests adding –lib. 
>
> Alas, cabal then crashes outright, which should never happen.
>
> So I’m stuck.  What should I do?
>
> Thanks
>
> Simon
>
>  
>
> simonpj@MSRC-9870733:~$ cabal --version
>
> cabal-install version 3.0.0.0
>
> compiled using version 3.0.0.0 of the Cabal library
>
> simonpj@MSRC-9870733:~$ cabal install hspec
>
> Resolving dependencies...
>
> Up to date
>
> Warning: You asked to install executables, but there are no
> executables in
>
> target: hspec. Perhaps you want to use --lib to install libraries
> instead.
>
> simonpj@MSRC-9870733:~$ cabal install --lib hspec
>
> Resolving dependencies...
>
> Up to date
>
> Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed
> for pattern Just ghcPkgProg
>
>  
>
> simonpj@MSRC-9870733:~$ which ghc
>
> /opt/ghc/bin/ghc
>
> simonpj@MSRC-9870733:~$ which ghc-pkg
>
> /opt/ghc/bin/ghc-pkg
>
> simonpj@MSRC-9870733:~$
>
>  
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs=02%7C01%7Csimonpj%40microsoft.com%7C49de1a60a36e4a04bbe208d6c1ecdac9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909620364700618=dMUKGqIICFPisw%2Feskzb98WxcG9kfNFMOkZfd9fB7YU%3D=0>
>
>
>  
>
> -- 
>
> brandon s allbery kf8nh
>
> allber...@gmail.com <mailto:allber...@gmail.com>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- 



*Vanessa McHale*
Functional Compiler Engineer | Chicago, IL

Website: www.iohk.io <http://iohk.io>
Twitter: @vamchale
PGP Key ID: 4209B7B5

Input Output <http://iohk.io>

Twitter <https://twitter.com/InputOutputHK> Github
<https://github.com/input-output-hk> LinkedIn
<https://www.linkedin.com/company/input-output-global>


This e-mail and any file transmitted with it are confidential and
intended solely for the use of the recipient(s) to whom it is addressed.
Dissemination, distribution, and/or copying of the transmission by
anyone other than the intended recipient(s) is prohibited. If you have
received this transmission in error please notify IOHK immediately and
delete it from your system. E-mail transmissions cannot be guaranteed to
be secure or error free. We do not accept liability for any loss,
damage, or error arising from this transmission


signature.asc
Description: OpenPGP digital signature
___
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

[Vanessa McHale]

I use cabal new-repl.

I actually kind of like having GHC environment files (maybe not as a
default) but they remind me of "vim turds" in that they end up littering
your projects.

Cheers,
Vanessa McHale

On 3/28/19 1:09 PM, Iavor Diatchki wrote:
> I am quite confused as to how people are using `ghci` without loading
> the environment files, at least in the context of cabal v2 (aka "new
> cabal").   When you run `ghci` on its own, unless you load an
> environment file, you would only have access to globally installed
> packages, which is almost never what you want.   What is the workflow
> that this proposal optimizes?
>
> The default behavior should be what's commonly useful and, in my
> experience, when I run GHCi in the context of a project, I pretty much
> always want it to load the environment associated with the project. 
>  It is incredibly useful when you are working on a project where there
> are multiple broken modules (e.g., during refactoring), and you want
> to fix them one at a time, in the order that makes sense to you.
>
> -Iavor
>
>
> On Thu, Mar 28, 2019 at 10:02 AM Bardur Arantsson
> mailto:s...@scientician.net>> wrote:
>
> On 28/03/2019 14.58, Oleg Grenrus wrote:
> > There is. Add
> >
> >     write-ghc-environment-files: never
> >
> > to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0
> or later.
> >
>
> That doesn't really work if you actually want to be able to use both
> ways of working, does it? That same thing applies to
>
>   export GHC_ENVIRONMENT=-
>
> which someone else posted, but at least that can be done by tooling
> before invoking ghc. It's odd to have to change a global setting to
> avoid this. (However, thanks for the hints -- I'll be setting that
> GHC_ENVIRONMENT from now on.)
>
> +1 for changing the default.
>
> It seems really weird to force other tooling to opt out when this
> could
> easily be solved by just having
>
>    cabal ghci
>    cabal ghc
>
> commands which set up the environment properly and tell users to use
> that if they want to use cabal's environment files. FWIW, I also see
> e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas
> e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not
> something users should really be running unless they know what they're
> doing *and* it should be as tooling-friendly as possible.
>
> Regards,
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


signature.asc
Description: OpenPGP digital signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Parser.y rewrite with parser combinators

[Vanessa McHale]

I actually have some experience in this department, having authored both
madlang  and language-ats
. Parsers using
combinators alone are more brittle than parsers using Happy, at least
for human-facing languages.

I'm also not sure what exactly parser combinators provide over Happy. It
has macros that can emulate e.g. between, many. Drawing up a minimal
example might be a good idea.


On 10/08/2018 05:24 PM, Vladislav Zavialov wrote:
>> complex parsers written using parsing combinators is that they tend to be 
>> quite difficult to modify and have any kind of assurance that now you 
>> haven't broken something else
> That's true regardless of implementation technique, parsers are rather
> delicate. A LALR-based parser generator does provide more information
> when it detects shift/reduce and reduce/reduce conflicts, but I never
> found this information useful. It was always quite the opposite of
> being helpful - an indication that a LALR parser could not handle my
> change and I had to look for workarounds.
>
>> With a combinator based parser, you basically have to do program 
>> verification, or more pragmatically, have a large test suite and hope that 
>> you tested everything.
> Even when doing modifications to Parser.y, I relied mainly on the test
> suite to determine whether my change was right (and the test suite
> always caught many issues). A large test suite is the best approach
> both for 'happy'-based parsers and for combinator-based parsers.
>
>> and then have a separate pass that validates and fixes up the results
> That's where my concern lies. This separate pass is confusing (at
> least for me - it's not the most straightforward thing to parse
> something incorrectly and then restructure it), it is hard to modify,
> it does not handle corner cases (e.g. #1087).
>
> Since we have all this Haskell code that does a significant portion of
> processing, why even bother with having a LALR pass before it?
>
>> namely we can report better parse errors
> I don't think that's true, we can achieve better error messages with
> recursive descent.
>
>> Also, with the new rewrite of HsSyn, we should be able to mark such 
>> constructors as only usable in the parsing pass, so later passes wouldn't 
>> need to worry about them.
> Not completely true, GhcPs-parametrized structures are the final
> output of parsing, so at least the renamer will face these
> constructors.
>
> On Tue, Oct 9, 2018 at 1:00 AM Iavor Diatchki  
> wrote:
>> Hello,
>>
>> my experience with complex parsers written using parsing combinators is that 
>> they tend to be quite difficult to modify and have any kind of assurance 
>> that now you haven't broken something else.   While reduce-reduce errors are 
>> indeed annoying, you at least know that there is some sort of issue you need 
>> to address.   With a combinator based parser, you basically have to do 
>> program verification, or more pragmatically, have a large test suite and 
>> hope that you tested everything.
>>
>> I think the current approach is actually quite reasonable:  use the Happy 
>> grammar to parse out the basic structure of the program, without trying to 
>> be completely precise, and then have a separate pass that validates and 
>> fixes up the results.   While this has the draw-back of some constructors 
>> being in the "wrong place", there are also benefits---namely we can report 
>> better parse errors.  Also, with the new rewrite of HsSyn, we should be able 
>> to mark such constructors as only usable in the parsing pass, so later 
>> passes wouldn't need to worry about them.
>>
>> -Iavor
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Oct 8, 2018 at 2:26 PM Simon Peyton Jones via ghc-devs 
>>  wrote:
>>> I'm no parser expert, but a parser that was easier to understand and 
>>> modify, and was as fast as the current one, sounds good to me.
>>>
>>> It's a tricky area though; e.g. the layout rule.
>>>
>>> Worth talking to Simon Marlow.
>>>
>>> Simon
>>>
>>>
>>>
>>> | -Original Message-
>>> | From: ghc-devs  On Behalf Of Vladislav
>>> | Zavialov
>>> | Sent: 08 October 2018 21:44
>>> | To: ghc-devs 
>>> | Subject: Parser.y rewrite with parser combinators
>>> |
>>> | Hello devs,
>>> |
>>> | Recently I've been working on a couple of parsing-related issues in
>>> | GHC. I implemented support for the -XStarIsType extension, fixed
>>> | parsing of the (!) type operator (Trac #15457), allowed using type
>>> | operators in existential contexts (Trac #15675).
>>> |
>>> | Doing these tasks required way more engineering effort than I expected
>>> | from my prior experience working with parsers due to complexities of
>>> | GHC's grammar.
>>> |
>>> | In the last couple of days, I've been working on Trac #1087 - a
>>> | 12-year old parsing bug. After trying out a couple of approaches, to
>>> | my dismay I realised that fixing it properly (including support for
>>> | bang patterns 

Re: Running GHC 7.10.2 on Ubuntu 18.04 ?

[Vanessa McHale]

GHC 7.10.3 works fine for me when I use the hvr ppa
https://launchpad.net/~hvr/+archive/ubuntu/ghc


On 09/05/2018 09:23 AM, Ömer Sinan Ağacan wrote:
> Hi,
>
> I'm trying to use GHC 7.10.2 (the Debian 8 bindist from haskell.org) on Ubuntu
> 18.04. It's currently failing with linker errors when I compile `main = return
> ()`:
>
> /usr/bin/x86_64-linux-gnu-ld:
> /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Base__5.o):
> relocation R_X86_64_32S against `.text' can not be used when making a
> PIE object; recompile with -fPIC
> /usr/bin/x86_64-linux-gnu-ld:
> /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Base__125.o):
> relocation R_X86_64_32S against `.text' can not be used when making a
> PIE object; recompile with -fPIC
> /usr/bin/x86_64-linux-gnu-ld:
> /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Signal__13.o):
> relocation R_X86_64_32S against `.text' can not be used when making a
> PIE object; recompile with -fPIC
> /usr/bin/x86_64-linux-gnu-ld:
> /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Sync__199.o):
> relocation R_X86_64_32S against `.text' can not be used when making a
> PIE object; recompile with -fPIC
> /usr/bin/x86_64-linux-gnu-ld:
> /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Exception__170.o):
> relocation R_X86_64_32S against symbol `stg_bh_upd_frame_info' can not
> be used when making a PIE object; recompile with -fPIC
>
> I'm getting about 700 of these. Does anyone know a way to make GHC 7.10.2 work
> on Ubuntu 18.04? Not sure if related but the ld version is
>
> ~ $ /usr/bin/x86_64-linux-gnu-ld --version
> GNU ld (GNU Binutils for Ubuntu) 2.30
> Copyright (C) 2018 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a
> later version.
> This program has absolutely no warranty.
>
> Thanks,
>
> Ömer
> _______
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 



*Vanessa McHale*
Functional Compiler Engineer | Chicago, IL

Website: www.iohk.io <http://iohk.io>
Twitter: @vamchale
PGP Key ID: 4209B7B5

Input Output <http://iohk.io>

Twitter <https://twitter.com/InputOutputHK> Github
<https://github.com/input-output-hk> LinkedIn
<https://www.linkedin.com/company/input-output-global>


This e-mail and any file transmitted with it are confidential and
intended solely for the use of the recipient(s) to whom it is addressed.
Dissemination, distribution, and/or copying of the transmission by
anyone other than the intended recipient(s) is prohibited. If you have
received this transmission in error please notify IOHK immediately and
delete it from your system. E-mail transmissions cannot be guaranteed to
be secure or error free. We do not accept liability for any loss,
damage, or error arising from this transmission


signature.asc
Description: OpenPGP digital signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Haskell DLL (using FFI) causes memory leak.

[Vanessa McHale]

I don't know about C++, but I do know that when calling Haskell from C
code one must initialize the runtime and then exit it once finished. I
also know that one must only initialize the runtime once over the course
of the program's run. As far as I can tell, this does not occur in your
example.


On 08/27/2018 09:44 AM, Ольга Филиппская wrote:
> Hello.
>
> /Summary: /memory is consumed without releasing when a Haskell DLL
> (that uses FFI) is loaded and unloaded in an endless loop.
>
> /Details/: I'm working on a C++ project relying on a DLL that uses
> Haskell code. The DLL was built with GHC 8.0.1 x64, OS is Windows 7.
> (Newer versions of GHC - 8.2.1 and later - do not allow you to build
> such DLLs due to some bugs: ticket #1
> , ticker #2
> ). The C++ project
> was built with MSVC compiler 2015.
>
> We noticed that memory is not released when the library is unloaded.
> I've constructed a baseline example to reproduce the bug. It has three
> files: the first one is *HaskellSources.hs*(see attachments). It
> contains one foreign export function foo. This foreign export function
> is necessary to reproduce the bug. The second file is *CWrapper.cpp*.
> I intentionally didn't include any Haskell function export because
> they make no difference for this example. The last file is the code of
> the main program (see *main.cpp*) that loads the library and unloads
> it at once in an endless loop.
>
> There are two cases: whether HaskellExports.o is included into the
> library or not.
> 1. HaskellExports.o is not included into the library (see attached
> build script/ build_no_hs.sh/). Everything works just fine (i.e.
> amount of memory consumed by the app is the same before DLL loading
> and right after unloading.)
> 2. HaskellExports.o is included into the library
> (see /build_w_hs.sh/). Memory is not released after unloading the DLL,
> after repeated load/unload cycles memory consumption keeps growing
> until finally the application crashes.
>
> Is this a known problem? Is it tracked in your bugtracker? (Or maybe
> it is not a problem at all and I'm doing it wrong).
>
> Thank you for your time.
>
> -- 
> /
> Olga Philippskaya
> ./
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


signature.asc
Description: OpenPGP digital signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs