On Sat, Nov 25, 2023 at 05:23:33PM -0500, Viktor Dukhovni wrote:
> > Which GHC version are you attempting to build with? My guess is that
> > `cabal-install-3.4` excludes your GHC's `base` via its version
> > constraints.
>
> No, I'm specifically using GHC 8.
On Sat, Nov 25, 2023 at 05:09:59PM -0500, Ben Gamari wrote:
> Viktor Dukhovni writes:
>
> > Just, for example:
> >
> > $ cabal install --constraint "cabal-install ^>= 3.4" cabal-install
> >
> > This fails due to a conflict between Cabal-3.4 a
On Sat, Nov 25, 2023 at 04:52:04PM -0500, Ben Gamari wrote:
> > The latter shows up as a dependency of "Cabal" on hackage, but not
> > in the upstream Git repo. Is there is there some sort of problem
> > with the hackage metadata for Cabal 3.0, 3.2, 3.4, ...
> >
> > It is odd for these to have
On Sat, Nov 25, 2023 at 01:07:37AM -0500, Viktor Dukhovni wrote:
> I am having a rather unexpected difficulty building older versions of
> cabal-install. The invariably run into conflicts between "Cabal" and
> "Cabal-syntax".
>
> The latter shows up as
I am having a rather unexpected difficulty building older versions of
cabal-install. The invariably run into conflicts between "Cabal" and
"Cabal-syntax".
The latter shows up as a dependency of "Cabal" on hackage, but not
in the upstream Git repo. Is there is there some sort of problem
with the
On Mon, Nov 13, 2023 at 09:35:06PM -0500, Matthew Craven wrote:
> Your proposed `arrayToByteArray` seems plausible.
Thanks, that could be handy, but see below.
> Your proposed `byteArrayToShort` is just the newtype-constructor
> `ShortByteString` which is exposed from Data.ByteString.Short
The 'ShortByteString' type in the "bytestring" package has seen some
singnificant improvement recently, and yet its API is still noticeably
limited in comparison to its pinned, I/O friendly 'ByteString' elder
sibling.
One of the limitations is that that there are fewer ways to construct a
On Fri, Nov 10, 2023 at 04:22:54PM -0500, Viktor Dukhovni wrote:
> On Fri, Nov 10, 2023 at 09:23:11PM +0530, Zubin Duggal wrote:
>
> > The GHC developers are happy to announce the availability of GHC 9.4.8.
> > Binary
> > distributions, source distributions, and doc
On Fri, Nov 10, 2023 at 09:23:11PM +0530, Zubin Duggal wrote:
> The GHC developers are happy to announce the availability of GHC 9.4.8. Binary
> distributions, source distributions, and documentation are available on the
> [release page](/download_ghc_9_4_8.html).
>
Many thanks. I am, however,
On Mon, Oct 30, 2023 at 09:20:16AM +0100, Vladislav Zavialov via ghc-devs wrote:
> Can you tell more about the code you're writing? Would it be possible
> to use it as the basis for the "Motivation" section of a GHC proposal?
>
Working with DNS resource records (A, NS, CNAME, SOA, MX, SRV,
...)
I am working on some code where it is useful to have types indexed by a
16-bit unsigned value.
Presently, I am using type-level naturals and having to now and then
provide witnesses that a 'Nat' value I am working with is at most 65535.
Also, perhaps there's some inefficiency here, as Naturals
On Tue, Oct 17, 2023 at 04:54:41PM +0100, Adam Gundry wrote:
> Thanks for starting this discussion, it would be good to see progress in
> this direction. As it happens I was discussing this question with Ben and
> Matt over dinner last night, and unfortunately they explained to me that it
> is
On Tue, Aug 08, 2023 at 11:33:52AM -0400, Viktor Dukhovni wrote:
> The build was failing, because rts/OSThreads.h via Rts.h from
> libraries/bytestring/cbits/is-valid-utf8.c had no definition of
> `clockid_t`. This type is not exposed when _POSIX_C_SOURCE is
> not defined to a suffi
The build was failing, because rts/OSThreads.h via Rts.h from
libraries/bytestring/cbits/is-valid-utf8.c had no definition of
`clockid_t`. This type is not exposed with _POSIX_C_SOURCE is
not defined to a sufficiently high value:
SYNOPSIS
#include
int
Spam detection software, running on the system "mail.haskell.org", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
@@CONTACT_ADDRESS@@ for
On Sun, Apr 30, 2023 at 11:18:07AM +0200, Torsten Schmits via ghc-devs wrote:
> I created an issue for this:
> https://gitlab.haskell.org/ghc/ghc/-/issues/22741
>
> You can share your insights there!
Done. It does look like we encountered the same underlying issue..
--
Viktor.
For some time now I'd been unable to build GHC 9.6 from source. The
reason turned out to be that my hadrian command-line selected an
explicit build directory that was not an immediate child of the source
directory (default it seems is "_build").
With the source tree under "$HOME/dev/ghc/", the
On Sat, Mar 11, 2023 at 09:14:12PM -0500, Ben Gamari wrote:
> The GHC team is very pleased to announce the availability of GHC 9.6.1.
> As usual, binaries and source distributions are available at
> downloads.haskell.org:
>
> https://downloads.haskell.org/ghc/9.6.1/
Is anyone else having
On Mon, Jan 23, 2023 at 03:41:21PM +0100, Joachim Breitner wrote:
> Hi Ben,
>
> gentle reminder about this issue? I’m worried I (and maybe others) are
> going to miss gitlab notifications.
A recent gitlab notice has:
Received: by gitlab.haskell.org (Postfix, from userid 165)
id
On Tue, Dec 27, 2022 at 09:39:22PM +0100, Hécate wrote:
> I came across the nsjail system from Google a little while after posting
> this thread: https://github.com/google/nsjail/#overview
Yes, this is the sort of thing that one can begin to trust, provided
that the exposed capabalities are
On Tue, Dec 27, 2022 at 10:31:07PM +0100, Jaro Reinders wrote:
> The bytestring package does have run time bounds checks. So maybe Safe
> Haskell is safer than you think?
No. The safety depends on careful Safe/Unsafe marking of an
unmanageable and growing set of modules. How does GHC know
that
On Tue, Dec 27, 2022 at 06:09:59PM +0100, Hécate wrote:
> Now, there are two options (convenient!) that are left to us:
>
> 1. Deprecate Safe Haskell: We remove the Safe mechanism as it exists
> today, and keep the IO restriction under another name. This will
> certainly cause much joy amongst
On Wed, Nov 30, 2022 at 05:33:44PM +0100, Joachim Breitner wrote:
> I noticed that a small number of Gitlab notification emails end up in
> my spamfilter. While there is not much you can do about triggering some
> bayesian style spam filter at my email provider (mailbox.org), I did
> notice this
On Wed, Nov 23, 2022 at 12:28:46PM +1100, Clinton Mead wrote:
> I have a class with a "method" which has a default definition, and that
> default definition has no arguments on the LHS, will a separate "instance"
> of that default definition be created for each instance of that class that
>
On Wed, Aug 10, 2022 at 10:06:43PM -0400, Viktor Dukhovni wrote:
> I just built a GHC 9.4 bindist on FreeBSD 12, and found that the bindist
> Makefile installed unusable wrappers when the source was a symlink. It
> seems plausible that the issue may not be FreeBSD-specific, but that's
&
I just built a GHC 9.4 bindist on FreeBSD 12, and found that the bindist
Makefile installed unusable wrappers when the source was a symlink. It
seems plausible that the issue may not be FreeBSD-specific, but that's
all I've tried so far.
The problem wrappers do not have execute permissions, and
On Mon, Aug 08, 2022 at 09:59:48AM -0400, Viktor Dukhovni wrote:
> On my MacOS laptop I get:
>
> $ /usr/local/bin/pkg-config --libs libffi
> -lffi
>
> which does not use the "brew"-installed libffi. Not surprising, since
> /usr/local/lib/pkgconfig/ h
On Mon, Aug 08, 2022 at 07:29:38AM -0400, Ryan Scott wrote:
> An exception to this rule is macOS, however. On macOS, building libffi
> always appears to default to linking against the static version of libffi,
> even when a dynamic version is also available. To reproduce this
> phenomenon, check
On Wed, Aug 03, 2022 at 10:35:43PM +0200, J. Reinders wrote:
> I found the mistake:
>
>compactAdd c k
>p <- anyToPtr k
>
> Should be:
>
>p <- anyToPtr . getCompact =<< compactAdd c k
>
> Otherwise I guess I’m not using the pointer that’s on the compact region.
Correct, I started
On Wed, Aug 03, 2022 at 10:16:50PM +0200, J. Reinders wrote:
> I have an implementation that mostly works here:
> https://github.com/noughtmare/clutter
> in the src/Counter.hs file.
>
> The only problem is that I get segfaults or internal GHC errors if I
> run it on large files. I’ve adding some
On Tue, Aug 02, 2022 at 05:32:58PM +0200, J. Reinders wrote:
> > Could you use `StablePtr` for the keys?
>
> That might be an option, but I have no idea how performant stable
> pointers are and manual management is obviously not ideal.
If your hash table keys qualify for being stored in a
On Tue, Aug 02, 2022 at 03:31:57PM +0200, J. Reinders wrote:
> I’ve been investigating fast hash table implementations. In particular
> hash tables used for counting unique items. For this use case, I
> believe the most performant hash tables are, in C terms, arrays of
> structures with a (boxed)
On Wed, Apr 06, 2022 at 10:55:09PM +0100, Simon Peyton Jones wrote:
> I see this
> bash$ git status
> On branch wip/romes/ttg-splices-improvements
> Your branch is up to date with 'origin/wip/romes/ttg-splices-improvements'.
>
> modified libraries/Cabal
> +Subproject commit
On Thu, Dec 30, 2021 at 04:46:29PM +, Richard Eisenberg wrote:
> I agree that this kind of backward-compatibility pattern synonym is
> good and shouldn't be prefixed with PS_.
>
> But do you have a concrete example of this leakage of an internal GHC
> type via TH? While I can imagine this
Some "GHC-internal" types leak to users via TH, and their constructors
occasionally pick up new fields, causing breakage downstream. The extra
field often has a sensible default (Nothing, [], ...) and it should be
best practice to rename the constructor when adding the new field, while
replacing
On Wed, Nov 24, 2021 at 06:32:04PM -0500, Viktor Dukhovni wrote:
> > Yes exactly. And it would not be hard to adapt the existing CSE pass
> > to support this. Just needs doing.
> >
> > A ticket and a repo case would be really helpful.
>
> I'll do my best to con
On Wed, Nov 24, 2021 at 11:14:00PM +, Simon Peyton Jones via ghc-devs wrote:
> | For two join points to be duplicates they need to not only be alpha
> | equivalent but to also have the same continuation.
>
> Yes exactly. And it would not be hard to adapt the existing CSE pass
> to support
On Sun, Nov 21, 2021 at 06:53:53AM -0500, Carter Schonwald wrote:
> On Sat, Nov 20, 2021 at 4:17 PM Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
> > There is absolutely no reason not to common-up those to join points. But
> > we can't common up some join points when we
On Sat, Nov 20, 2021 at 09:15:15PM +, Simon Peyton Jones via ghc-devs wrote:
> GHC.Core.Opt.CSE is conservative at the moment, and never CSE's *any*
> join point. It would not be hard to make it clever enough to CSE join
> points, but no one has yet done it.
>
> Do open a ticket!
Thanks, I
On Sat, Nov 20, 2021 at 01:54:36PM -0500, Viktor Dukhovni wrote:
> Is there some way for GHC to figure out to not float out such cheap
> computations? The 'Result' constructor is strict, so there's no cost to
> evaluating `used > 0`, and cloning the entire computation is I thin
On Sat, Nov 20, 2021 at 12:49:08PM +0100, Andreas Klebinger wrote:
> For the assembly I opened a ticket:
> https://gitlab.haskell.org/ghc/ghc/-/issues/20714
Thanks, much appreciated. Understood re redundant join points, though
in the non-toy context the redundnat point code is noticeably
[ Sorry wrong version of attachment in previous message. ]
The below "Core" output from "ghc -O2" (9.2/8.10) for the attached
program shows seemingly rendundant join points:
join {
exit :: State# RealWorld -> (# State# RealWorld, () #)
exit (ipv :: State# RealWorld) = jump
The below "Core" output from "ghc -O2" (9.2/8.10) for the attached
program shows seemingly rendundant join points:
join {
exit :: State# RealWorld -> (# State# RealWorld, () #)
exit (ipv :: State# RealWorld) = jump $s$j ipv } in
join {
exit1 :: State#
> On 14 Sep 2021, at 8:29 am, Hécate wrote:
>
> I may have missed an episode or two here but what prevents us from writing
> Notes as Named Chunks¹, write them where Haddock expects you to put
> documentation, and refer to them from the relevant spot in the code?
> Viktor (in CC) has done a
On Fri, Aug 27, 2021 at 07:15:26PM +0200, Alexis Praga wrote:
> As a complete beginner in regards to GHC, I tried to build GHC 9.2 as it
> looked like the latest stable from git.I failed to build 9.0.1 before that.
>
> After checking out the ghc-9.2 branch, I ran (following the wiki):
>
> >
On Wed, Aug 25, 2021 at 07:05:58PM +0300, Oleg Grenrus wrote:
> The newew proposal [1] is tagged as "needs revision". It doesn't
> include(# Int#, Addr# #), but those are easy to get from ByteArray#
> which has negligible overhead.
> [...]
> [1]
On Tue, Aug 24, 2021 at 09:03:30AM -0400, Viktor Dukhovni wrote:
I originally wrote:
> > >Is there any GHC syntax for constructing a primitive string literal
> > >with a known (not hand coded) byte count?
> > >With `"some bytes"#` I get just
On Tue, Aug 24, 2021 at 08:48:53AM +0200, Sylvain Henry wrote:
> Le 24 août 2021 à 06:34, à 06:34, Viktor Dukhovni a
> écrit:
> >
> >Is there any GHC syntax for constructing a primitive string literal
> >with a known (not hand coded) byte count?
> >With `"
Is there any GHC syntax for constructing a primitive string literal with a
known (not hand coded) byte count?
With `"some bytes"#` I get just the `Addr#` pointer, but not the size.
If there's nothing available, would it be reasonable to introduce a new syntax?
Perhaps:
"some bytes"##
On Fri, Jul 02, 2021 at 08:08:39AM +, Simon Peyton Jones via ghc-devs wrote:
> I strongly urge you to keep a constantly-update status wiki page,
> which lists the ideas you are working on, and points to relevant
> resources and tickets. An email thread like this is a good way to
> gather
On 19 May 2021, at 11:48 am, Carter Schonwald
wrote:
> I personally vote for irc. Perhaps via Libera.
Perhaps I'm too much of an IRC noob, but I still found it it rather
surprising to be banned from libera.chat (my IP is blacklisted) for
pasting a 25-line build script for building GHC via
On Wed, Jun 02, 2021 at 07:06:59PM +, Simon Peyton Jones via ghc-devs wrote:
> "/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/bin/ghc-pkg" --force
> --global-package-db
> "/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d" update
> rts/dist/package.conf.install
>
> ghc-pkg:
On Wed, Apr 14, 2021 at 06:26:38PM +, Richard Eisenberg wrote:
> In the work on simplifying the error-message infrastructure (heavy
> lifting by Alfredo, in cc), I've been tempted (twice!) to add
>
> > instance Semigroup (Bag a) where
> > (<>) = unionBags
> >
> > instance Monoid (Bag a)
On Tue, Apr 06, 2021 at 11:10:51AM -0400, Viktor Dukhovni wrote:
> > λ> let v = VS.fromList [3,2,5] in isSameVector (SomeVector v) (SomeVector v)
>
> One thing I'm not sure about, that perhaps someone else can shed light
> on, is whether with optimisation one might expect the
On Tue, Apr 06, 2021 at 10:58:20PM +0800, YueCompl via ghc-devs wrote:
> On a second thought, maybe GHCi's silence is a bad thing here? Maybe
> it should complain loudly as GHC does?
No, GHCi is doing the expected thing. Because GHCi's REPL sees one line
at a time, it is not generally possible
On Tue, Apr 06, 2021 at 07:12:51PM +0800, YueCompl via ghc-devs wrote:
> λ> import Control.Monad.ST
> λ> import qualified Data.Vector.Storable as VS
> λ>
> λ> :{
> λ|
> λ| newtype SomeVector = SomeVector (VS.Vector Int)
> λ|
> λ| isSameVector :: SomeVector -> SomeVector -> Bool
> λ|
On Sun, Mar 28, 2021 at 11:00:56PM -0400, Carter Schonwald wrote:
> On Sun, Mar 28, 2021 at 10:19 PM Richard Eisenberg wrote:
>
> > I think this is the key part of Alexis's plea: that the type checker take
> > into account exhaustivity in choosing how to proceed.
> >
> > Another way to think
On Fri, Mar 26, 2021 at 07:41:09PM -0500, Alexis King wrote:
> type applications in patterns are still not enough to satisfy me. I
> provided the empty argument list example because it was simple, but I’d
> also like this to typecheck:
>
> baz :: Int -> String -> Widget
> baz =
>
On Mon, Mar 22, 2021 at 12:39:28PM +0800, Gergő Érdi wrote:
> I'd love to have this in a GHC 8.10 release:
> https://mail.haskell.org/pipermail/ghc-devs/2021-March/019629.html
This is already in 9.0, 9.2 and master, but it is a rather non-trivial
change, given all the new work that went into the
On Sat, Mar 20, 2021 at 08:13:18AM -0400, Viktor Dukhovni wrote:
> As soon as I try add more complex contraints, I appear to need an
> explicit type signature for HNil, and then the code again compiles:
But aliasing the promoted constructors via pattern synonyms, and using
those instead, a
On Sat, Mar 20, 2021 at 04:40:59AM -0500, Alexis King wrote:
> Today I was writing some code that uses a GADT to represent
> heterogeneous lists:
>
> data HList as where
> HNil :: HList '[]
> HCons :: a -> HList as -> HList (a ': as)
>
> This type is used to provide a
> On Mar 17, 2021, at 2:35 PM, Richard Eisenberg wrote:
>
> My vote is that the manual should be self-standing. References to proposals
> are good, but as supplementary/background reading only. My gold standard
> always is: if we lost all the source code to GHC and all its compiled
>
On Mon, Mar 15, 2021 at 06:44:20AM -0400, Viktor Dukhovni wrote:
> ..., the FreeBSD "validate --legacy"
> successfully builds GHC. [ The tests seem to all be failing, perhaps
> the test driver scripts are not portable to FreeBSD, but previously
> the compiler was not buildi
On Mon, Mar 15, 2021 at 09:46:35AM +0100, Sylvain Henry wrote:
> >
> > Thank you! Don’t forget to comment it – especially because it is fake.
>
> Done in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5265
Speaking of build failures with the legacy make system, I see a build
failure on
> On Mar 14, 2021, at 6:53 PM, Simon Peyton Jones via ghc-devs
> wrote:
>
> I’m getting this (with ‘sh validate –legacy’). Oddly
>
> • It does not happen on HEAD
> • It does happen on wip/T19495, a tiny patch with one innocuous change
> to GHC.Tc.Gen.HsType
> I can’t see how my
On Thu, Mar 11, 2021 at 07:53:20PM +, Simon Peyton Jones via ghc-devs wrote:
> Voila
Thanks!
> /etc/nsswitch.conf group entry
> group: files systemd
The main "suspicious" thing here (decoded traces below my signature) is
that the nsswitch.conf file is configured to try "systemd"
On Thu, Mar 11, 2021 at 12:21:15PM +, Simon Peyton Jones via ghc-devs wrote:
> Like Tom, I'm not following the details, but if you want me to run
> some commands and send you the output I can do that. Just send the
> script!
See attached. If any of the prerequisite shell utilities are not
> On Mar 11, 2021, at 9:41 AM, Tom Ellis
> wrote:
>
> I'm not really following the details, but is this useful to you?
>
> % cat g.c && cc g.c -o g && ./g
> #include
> #include
> #include
> #include
>
> int main(int argc, char **argv)
> {
>char buf[1024];
>struct group g, *p;
>
On Thu, Mar 11, 2021 at 06:05:04AM -0500, Viktor Dukhovni wrote:
> So the question is why the lookup is failing. To that end compiling a
> tracing with "strace" the below C program should tell the story:
>
> #include
> #include
> #include
>
On Thu, Mar 11, 2021 at 10:19:52AM +, Tom Ellis wrote:
> SPJ Wrote:
> > I've just installed WSL2 and built GHC. I get this (single)
> > validation failure in libraries/unix/tests/getGroupEntryForName. It
> > seems to be just an error message wibble, but I can't push a change
> > to master
70 matches
Mail list logo
