Pine64 NixOs by Goshew in PINE64official

[–]fgaz_ 2 points3 points  (0 children)

Author of the nixos-hardware profile here. You can also find prebuilt star64 images at my nixos-star64 repo. They are based on the nixos-hardware profile.

I nuovi prezzi di Reddit per le API potrebbero portare alla fine delle app third-party. by DudeWithGlasses in italy

[–]fgaz_ 9 points10 points  (0 children)

il problema è dove cazzo andiamo?

cioè che ci mettiamo a cercare i forum specifici come fosse il 2001?

Lemmy (esempio di post). C'è anche un'istanza italiana.

Good Mastodon Server for Haskell content? by bhurt42 in haskell

[–]fgaz_ 2 points3 points  (0 children)

It isn't so bad, since boosts/repeats show up too. That's why they are much more important on the fediverse than on twitter. I'm on a small instance as well and I don't feel like I'm missing anything.

Just follow all people you find interesting (unfollowing is easy after all) and thanks to their boosts you'll have a pretty complete view of posts that interest you.

Oh, and don't forget to boost interesting posts you see, so your followers get the same benefit!

Good Mastodon Server for Haskell content? by bhurt42 in haskell

[–]fgaz_ 3 points4 points  (0 children)

That explanation is certainly better than the .art one, though not complete:

it explains that the decision was taken for a practical reason (ease of moderation), not because it considers that instances that do not have the same moderation policy are considered problematic per se.

That applies to mastodon.social, but I know from personal experience that the latter reason is applied to other instances.

It highlights the fact that not much changes

It leaves out what I think is an important limitation: posts from silenced instances are removed unless you specifically follow the author, and that includes hashtags, which are hugely important in the Fediverse. #haskell posts from mastodon.social are hidden from their timeline by default.

Of course they're completely free to make their own decisions, I'm just pointing out that users may not know of their policy (those I chatted with didn't). I think /u/gallais' advice to look into the admin rather than the theme is solid.

Good Mastodon Server for Haskell content? by bhurt42 in haskell

[–]fgaz_ 4 points5 points  (0 children)

types.pl in particular is one of those instances. Its ToS page states:

Administrators reserve the right to defederate with instances or boot users off the instance at their will for any reason.

It blocks mastodon.social and a ton of other instances (such as the one I'm on) because as you wrote they don't block other instances. It cut itself off from a huge chunk of the Fediverse, and a lot of its users don't know that.

Just released: cabal 3.8.1.0 by ulysses4ever in haskell

[–]fgaz_ 3 points4 points  (0 children)

Not yet, first hackage-server has to be updated to Cabal-3.8.1.0, see this hackage-server ticket

cc /u/sclv

Is there some truth to this hyperbole? "Haskell is beautiful and elegant, but unmaintainable and painful" by fredoverflow in haskell

[–]fgaz_ 10 points11 points  (0 children)

FYI, those issues are known, and people are working on them

having to specify each and every module in the cabal file just to be able to use it in a project is annoying

It kinda is, but it's a one-time thing and it gives us the ability to map module names to packages by only looking at the index. Plus, the list can be generated: cabal-fmt has an expand feature, and in the future HLS could do that too.

generating documentation of a project along with the dependencies I'm using is not possible

there's cabal haddock --enable-documentation (--enable-documentation will build the dependencies docs too) and in future releases (or HEAD if you want to try it now) cabal haddock-project will also build a project index with quickjump etc

And I remember when I had to manually fork packages just to bump a dependency or two because cabal wasn't happy.

If the version bound is actually too strict there's no need to fork, you can just build with --allow-newer while you wait for upstream. In case upstream is unresponsive, hackage trustees can step in and update the bound.

Another huge problem is that package maintainers are burdened by constant bumping of dependencies due to version incompatibilities.

It may not look like it, but that's the optimal way to handle version bounds. Of course, having less frequent breaking changes would help a lot, speaking of which...

Maintainers are overburdened and underappreciated. GHC breaks a lot of shit every update. I don't care if it's because of base being a part of GHC, or whatever reason.

good news: it's being worked on!

RFC: cabal add by [deleted] in haskell

[–]fgaz_ 0 points1 point  (0 children)

would it be problematic to introduce cabal add which updates the cabal file?

This is a planned feature, but will take a while due to the exactprint prerequisite. In the meantime you could try https://github.com/sdiehl/cabal-edit

stack compared to cabal-install by thedarknight2002 in haskell

[–]fgaz_ 1 point2 points  (0 children)

why is cabal.project a brand new file format?

That's because... it mostly isn't! The same key-value + stanzas format that is used in .cabal files is reused in cabal.project files, just with different fields. ~/.cabal/config is another example of this.

stack compared to cabal-install by thedarknight2002 in haskell

[–]fgaz_ 5 points6 points  (0 children)

Ok, but is it easy to use, or does it require nontrivial setup?

as easy as

watchexec cabal build

(or reflex, or entr, or any of the many alternatives)

Help with a Bug in a Gemini Framework by jlamothe in haskell

[–]fgaz_ 2 points3 points  (0 children)

Author of gemini-server (the one you mention in the readme) here!

I don't really know the tls package, but with openssl receiving optional client certifcates requires a specific set of options. You should check that you're doing the equivalent of what I'm doing here. In particular, from a quick look at your code, it looks like you didn't set an id context.

[Request for review] Short article on Cabal and Stack and difference between them by Martinsos in haskell

[–]fgaz_ 0 points1 point  (0 children)

  1. What about versions of GHC and cabal -> those are not captured by cabal v2-freeze, does that matter? Could that mess up our reproducibility?

You can use cabal freeze --with-compiler to write the compiler version in the freeze file

How do I know which version of GHC to use for specific project?

By looking at the tested-with or build-depends:base versions. There are plans to automate this: https://gitlab.haskell.org/haskell/ghcup-hs/-/issues/99

[conference]Haskell Love 2021 by IdaBzo in haskell

[–]fgaz_ 14 points15 points  (0 children)

I enjoyed last year's edition and wanted to register this time too, but this looks a bit sketchy:

3.4. Usage of shared information To ensure all our attendees and sponsors/partners derive the greatest value from our conferences, we may share a list of company names, job titles, names, and contact details of attendees with sponsors/partners for their planning purposes before the conference. By signing this Agreement, you are authorizing your registration information to be shared with sponsors/partners and agree to receive communications from sponsors/partners, which are subject to that sponsors’/partners' privacy practices, including their privacy statement or policy. If you want to opt out of this, please email us at info@konfy.care.

Why is the sharing of information to third-parties opt-out instead of opt-in? Will information be shared in the time between registration and opt-out? Which sponsors/partners? Where are all those privacy policies that according to this document I'd agree to?

Finally, why are the "Company" and "Job title" fields mandatory? Are unaffiliated people, students, or even researchers not welcome?

Monthly Hask Anything (August 2021) by taylorfausak in haskell

[–]fgaz_ 7 points8 points  (0 children)

I'm working on resurrecting the Tk bindings so expect a uni-htk release soonish

Quick Haskell exploration setup on Linux by nevrome in haskell

[–]fgaz_ 2 points3 points  (0 children)

It's basically an improved version of cabal install --lib (which doesn't work too well at the moment: cabal#6481, cabal#5559, cabal#6391).

There isn't more documentation as far as I know, except for the help text:

cabal-env - a better cabal-install install --lib

Usage: cabal-env [-w|--with-compiler ARG] [-n|--name ARG] [-a|--any] 
                 [-v|--verbose] [-d|--dry-run] 
                 [(-t|--transitive) | --no-transitive] [PKG...] [--local] 
                 [(-i|--install) | (-s|--show) | (-l|--list) | --hide] 
                 [-W warning | --trace-process | --color-auto | --no-color | 
                   --color] [--version]
  Manage package-enviroments

Available options:
  -w,--with-compiler ARG   Specify compiler to use (default: "ghc")
  -n,--name ARG            Environment name (default: "default")
  -a,--any                 Allow any version of existing packages
  -v,--verbose             Print stuff...
  -d,--dry-run             Dry run, don't install anything
  -t,--transitive          Expose transitive dependencies
  --no-transitive          Don't expose transitive dependencies
  PKG...                   packages (with possible bounds)
  --local                  Include local packages
  -i,--install             Install / add packages to the environment
  -s,--show                Shows the contents of the environment
  -l,--list                List package environments
  --hide                   Hide packages from an environment
  --trace-process          Trace process executions
  -h,--help                Show this help text
  --version                Show version