for the clarification!
Hécate
Le 11/07/2024 à 10:41, Matthew Pickering a écrit :
The `haddock` executable must be dynamically linked as it must compile
source files. It is much more robust to use dynamic linking when
loading dependencies for TH evaluation than static linking. HLS is
dynamically linked
discussions about the mental model of
dependencies, cabal and GHC, I was wondering if anything was keeping us
expose these packages the user does not explicitly download.
I will take some time to see how to switch to (haskell-)static linking
for distribution releases.
Have a nice day,
Hécate
Le
it's not really that we don't care about size, just that these
tools
seemed not reliable enough for the benefits they offer in the past.
Am 10/07/2024 um 11:01 schrieb Hécate via ghc-devs:
> Hi devs,
>
> I had a chat earlier today with someone and found myself
de-all-packages` etc to clear all the
implicit stuff GHC may do.
- Oleg
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://g
haddock, hpc, etc can't be
(haskell-)statically linked when distributed?
Surely the size of binaries can't be the only concern, otherwise we'd
use upx¹ on them when distributing them.
Cheers,
Hécate
1: https://upx.github.io
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
e got the flu atm so the
above might be too rambly :)
Bye,
Gergo
On Wed, 3 Jul 2024, Hécate via ghc-devs wrote:
Hi GHC devs,
I was wondering recently, considering that type family evaluation is
notoriously slow, how one would implement type-level list
concatenation directly within GHC i
.
Thinking about it, I'm actually unsure where the tyfam evaluation is
happening.
Any advice would be appreciated.
Cheers,
Hécate
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
___
ghc-devs mailing list
ghc-devs
Hi Simon,
To modify nofib, simply submit a merge request to
https://gitlab.haskell.org/ghc/nofib with the appropriate change.
Once it's integrated, run `git submodule update --remote` in the GHC
repo to update the submodule and push the update as part of your work.
Cheers,
Hécate
Le 10/11
We should all certainly learn something from reading this post on
telemetry and user trust. I know I did:
https://estebank.github.io/rustc-metrics.html
Cheers,
Hécate
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
/ghc/-/wikis/commentary/GHCi/Tags
Thanks to everyone who was involved in this, especially Emily Martins.
Cheers,
Hécate
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
___
ghc-devs mailing list
ghc-devs@haskell.org
http
it takes
to do certain things. :)
Please do feel free to create your own for projects that are not fit for
a single milestone (or are not related to release milestones at all).
Cheers,
Hécate
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
__
unlocks on our side.
The epic is at https://gitlab.haskell.org/groups/ghc/-/epics/3
Please feel free to link future tickets that are related to this newer,
better way of doing space profiling.
My thanks to Matthew Pickering, David Eichmann, and Ben Gamari.
Cheers,
Hécate (with a project
of that? Something based upon eBPF would certainly
incur less modifications to the RTS?
Le 27/12/2022 à 21:12, Viktor Dukhovni a écrit :
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
re can be no half-measures that they usually tend to
make us slide back into the status quo.
So, what do you think?
¹
https://gitlab.haskell.org/ghc/ghc/-/issues/?label_name%5B%5D=Safe%20Haskell
² https://gitlab.haskell.org/ghc/ghc/-/issues/19605
³ https://github.com/haskell/directory/is
fast per
se, it's about in line with what I would expect.
Are either of you seeing significantly longer load times?
Cheers,
- Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Hécate
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail
Hi everyone,
As discussed earlier this year¹, the deprecation process for GHC.Pack
starts with the 9.6.1 milestone².
¹ https://gitlab.haskell.org/ghc/ghc/-/issues/21461
² https://gitlab.haskell.org/ghc/ghc/-/issues/21541
Cheers,
Hécate
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
___
ghc-devs mailing list
ghc
of ghcid, hls, ...
would it be nice
if ghc development would be that nice as well? I'd assume so, I've
just never
even tried.
Cheers,
Moritz
On Tue, 19 Jul 2022 at 18:21, Hécate wrote:
Hello ghc-devs,
I hadn't made significant contributions to the GHC code base in a
while
helpful to have more
information. There may be things we can't reasonably address (e.g.
make a small, light, non-optimising compiler instead, throwing away
most of the code base) but I bet that sheer size isn't the only factor.
Thanks!
Simon
On Tue, 19 Jul 2022 at 17:21, Hécate wrote:
sonably address (e.g.
make a small, light, non-optimising compiler instead, throwing away
most of the code base) but I bet that sheer size isn't the only factor.
Thanks!
Simon
On Tue, 19 Jul 2022 at 17:21, Hécate wrote:
Hello ghc-devs,
I hadn't made significant contributions
n the scale of hours , as
this is a hobby project.
Hope this will open some eyes.
Cheers,
Hécate
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/
mailing-list, as GHC is our main (if not only) consumer, and GHC
developers have already made contributions to Haddock.
Cheers,
Hécate
Le 26/05/2022 à 17:12, Mikolaj Konarski a écrit :
Talking as a Haskell user, but also a cabal maintainer:
the Haddock work Hécate describes is crucial for the health
company can spare some engineering hours for you
to give a hand, you're most welcome to do so.
Just so we are clear, I am immensely grateful to the people who have
submitted fixes and patches these past months, but this situation is
untenable.
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https
.
Best Wishes,
Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
askell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW:https://glitchbra.in
RUN: BSD
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
/listinfo/ghc-devs
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
to replace the tags feature.
This is being documented in the "Tags" wiki page³.
You are invited to help with broadcasting this announcement to your
fellow Haskell users.
I will post on Reddit and the Haskell Discourse but increasing the
coverage of this will be important.
Cheers,
Hécate
/-/issues/21540>)
3. By error (GHC 9.10) (#21536
<https://gitlab.haskell.org/ghc/ghc/-/issues/21536>)
You can read more about the whole thing here:
https://gitlab.haskell.org/ghc/ghc/-/issues/21461
Cheers, have a nice week!
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW:https://gli
___
ghc-devs mailing list
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
--
Hécate ✨
: @TechnoE
Of course it wouldn't be funny if I didn't forget to add a link to the
page that lists everything, so here it is:
https://gitlab.haskell.org/ghc/ghc/-/wikis/status/ghc-9.6
Le 03/05/2022 à 16:56, Hécate a écrit :
Hi everyone,
With 9.4 just around the corner, I am gathering broad ambitions
in
the future of GHC!
Cheers,
Hécate.
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
d koz ross.
Cheers
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
that Haddock transitions to GHC 9.6. Please advise.
Norman
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
Hi Ben, this is really helpful for me and other commercial users.
Thank you very much for clarifying this. :)
Cheers,
Hécate.
Le 24/02/2022 à 17:44, Ben Gamari a écrit :
Hécate writes:
Following a private discussion where many historical things and
processes have been described to me, I'd
t; LTS release will be
addressed to those in charge of this kind of decision.
Again Matt, I'm very happy that you're taking the helm for the WT team,
your work has been nothing else than important and excellent for the
future of Haskell.
Cheers,
Hécate
Le 23/02/2022 à 19:31, Hécate a écrit :
Hi Matthew!
in on this, but it's an
unfortunate and essential part of the job that I'd like to clear out,
for everyone's sake. :)
Please do not take this as an attack against you and your team, and I'm
truly sorry if my phrasing have led to think so.
Cheers,
Hécate
Le 23/02/2022 à 16:55, Matthew Pickering a éc
e official
position of your team on the matter?
Again, I'd like to echo Richard's words in the other thread, thank you
and your team for all this work, this is immensely appreciated.
Cheers,
Hécate
Le 22/02/2022 à 18:14, Matthew Pickering a écrit :
Hi all,
Firstly we are anticipating bran
/haddock.
I will try and warn folks who currently have PRs opened on GitHub
targeting ghc-head, but please know that they'll be closed in the next
few days.
Have a great end of the week,
Hécate, for the Haddock Team.
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
l.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
in the ticket so that this discussion may be
better archived.
Cheers!
--
Hécate ✨
: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
of appearing with its title or inserting a link with the
section name it is currently decoupled from.
Am Di., 14. Sept. 2021 um 16:25 Uhr schrieb Hécate :
Hi,
The named chunks can be positioned through the use of the export
list syntax:
module Foo
( main
n
Am Di., 14. Sept. 2021 um 14:32 Uhr schrieb Hécate :
> today’s Haddock doesn’t understand Notes. But we could fix that
if we were minded to.
I may have missed an episode or two here but what prevents us from
writing Notes as Named Chunks¹, write them where Haddock expects
y
bdb857c77298d6fdec12626b65e014aaeee33=04%7C01%7Csimonpj%40microsoft.com%7Cdb46814133bc4404b6d308d9685a487e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63769255360954%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=4616hEpSSUcOZ5zQYZMmEbF6mTJcIVKx2nlgA8ENsHM%3D=0>.
___
) such a standalone kind signature in our style guide. The cases where at
least one parameter of a datatype does not have kind Type are the places we
need the extra information.
This is indeed quite reasonable. I will follow you on that point.
--
Hécate ✨
: @TechnoEmpress
IRC: Uniaika
WWW: https
After reading this proposal, I agree that StandaloneKindSignatures ought
to be encouraged in the codebases, and I vote that we mention them in
the coding style¹.
Cheers,
Hécate
———
¹ https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/coding-style
Cheers,
Hécate.
Le 18/05/2021 à 19:58
implemented in HLint, you can use this (sad) workaround:
```
TERM=dumb hadrian/build -j lint:compiler
```
which remove all the colours from the output.
Hope this helps, sorry for the confusion.
Cheers,
Hécate
Le 30/04/2021 à 22:12, Richard Eisenberg a écrit :
Hi devs,
I see in CI that we'
lived with
it in my code bases, and I'd like to know if there are deeper issues
pertaining to their exclusion from the `stock` deriving strategy.
Here is the link to the discussion ticket:
https://gitlab.haskell.org/ghc/ghc/-/issues/19707
Cheers, and have a nice week!
--
Hécate
c-proposals/pull/417
Have a nice week-end!
--
Hécate ✨
: @TechnoEmpress
IRC: Uniaika
WWW: https://glitchbra.in
RUN: BSD
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
, this should be taken care of for you.
Hope it clarified things!
Cheers,
Hécate
Le 25 mars 2021 21:39:15 Richard Eisenberg a écrit :
Thanks for this update! Glad to know this effort is going well.
One quick question: suppose I am editing something in `base`. My
understanding is that my edit
.
Have a very nice day,
Hécate
---
[0]: https://github.com/ndmitchell/hlint
[1]: https://gitlab.haskell.org/ghc/ghc/-/issues/18424
[2]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4147
--
Hécate ✨
: @TechnoEmpress
IRC: Uniaika
WWW: https://glitchbra.in
RUN: BSD
_
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Hécate ✨
: @TechnoEmpress
IRC: Uniaika
WWW: https://glitchbra.in
RUN: BSD
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-b
that the PRs receive
all the love they deserve!
Cheers!
Hécate
Le 03/07/2020 à 12:20, Alexander Kjeldaas a écrit :
Hi devs!
I created a small documentation PR for the GHC FFI on github and
noticed that there's another one-liner PR from May 2019 that was not
merged.
https://github.com/ghc
g is among the major motivations behind it.
--
Best, Artem
On Mon, Jun 15, 2020, 5:07 PM Hécate <mailto:hec...@glitchbra.in>> wrote:
On 15/06/2020 19:50, Ben Gamari wrote:
> Frankly, this makes me wonder whether we should change the output
> produced for loops. The current er
On 15/06/2020 19:50, Ben Gamari wrote:
Frankly, this makes me wonder whether we should change the output
produced for loops. The current error is essentially un-Googleable, as
we see here. I know I have personally struggled with this same issue in
the past.
I wholeheartedly agree with this
My bad, it seems like this is another issue.
I found this StackOverflow page quite helpful in explaining the hows and
whys:
https://stackoverflow.com/questions/4873980/git-diff-says-subproject-is-dirty
Cheers,
Hécate
Le 15/05/2020 à 16:30, Hécate a écrit :
Hi Simon,
I usually manage
Hi Simon,
I usually manage to get it to disappear by using `git submodule update
--recursive`.
Is it a flag you've used in your previous attempts?
Cheers,
Hécate.
Le 15/05/2020 à 16:24, Simon Peyton Jones via ghc-devs a écrit :
No amount of git submodule update makes it go away. Any
>Hopefully that wouldn't become the only way to download GHC.
That wasn't my intention to suggest it to be the One True Way to
download it.
>Sounds great, but is it reasonable? GNU/Linux package managers AFAIK
don't install Haskell libraries either
Some do! On Fedora, the Haskell libraries
user base, this would would be wonderful.
Thank you for reading until the end.
Cheers,
Hécate.
PS: I am in no way trying to berate anyone for their implied
incompetence, or imply that Windows users are stupid and/or
technologically impaired.
This would be misinterpreting my words and lead
Hello ghc-devs
For everyone who doesn't know me (yet), I am Hécate, and I coordinate
the the Haskell Docs initiative.
You may have seen me on various community channels and on social media
to recruit
lost souls^W^Wmotivated volunteers to help improve the documentation of
the `base` library
60 matches
Mail list logo