profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/gbaz/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

awakesecurity/proto3-suite 66

Haskell Protobuf Implementation

gbaz/mess 19

Martin-Löf Extensible Specification and Simulator

cohomolo-gy/differentiable-manifolds-UofUtah 1

Repo for MA6510 w/ Bromberg

gbaz/aeson 0

A fast Haskell JSON library

gbaz/cabal 0

Official upstream development repository for Cabal and cabal-install

push eventgbaz/cabal-doctest-demo

gbaz

commit sha 1e06fd42e68f736d75859be5b2ff32b4fbc678e9

Create README.md

view details

push time in 18 hours

issue commenthaskell/cabal

Make cabal new-doctest

PR for this approach here: https://github.com/haskell/cabal/pull/7688

phadej

comment created time in 18 hours

PR opened haskell/cabal

code-generators field in test stanza. Cabal: cmd/test

This PR extends the test stanza of a cabal file with a code-generators: field containing executables. These executables can be generated as dependencies via the build-tools-depends: field. They are run during the build step after all other preprocessors, and before the main build step, and can be used to autogenerate modules for test suites, e.g. for doctests, or other "discover" style test running.

These executables are expected to follow a very simple api. They are invoked as exe-name TARGETDIR [SOURCEDIRS] -- [GHCOPTIONS] -- where targetdir is a temp directory in the dist-newstyle hierarchy where they are directed to place their generated code. This is followed by a list of source directories containing the source files of all the local lib components which the test stanza depends on. Finally, following a double-dash, are all the options that cabal would pass to ghc for a build.

The expected output of these executables is a newline-separated list of names of all the generated modules. This PR also prevents checking for the existence of the main-is module in the preprocessor step, because that main module itself may be generated by the code generator.

A proof-of-concept of how this works is at https://github.com/gbaz/cabal-doctest-demo -- this repo gives a package that has two different doctest runners built on top of this functionality. One wraps up the doctest program with a wrapper generated from the ghc options (and so which does not rely on a ghc environment file to bring deps into scope, but rather extracts them directly form the build-depends). The other uses the lexer from https://github.com/phadej/cabal-extras/tree/master/cabal-docspec and generates a fully static tasty testsuite from the doctest comments in the source lib.

I think this code is basically correct and clean. If people like it, to finish off this PR it needs a changelog, doc updates, and some proper extension of the cabal test suite.

+101 -43

0 comment

5 changed files

pr created time in 18 hours

push eventhaskell/cabal

Gershom Bazerman

commit sha bc89056be9aea69c7d1a665d9f0d5bb89ddb1472

fixups

view details

push time in 18 hours

create barnchgbaz/cabal-doctest-demo

branch : main

created branch time in 18 hours

created repositorygbaz/cabal-doctest-demo

created time in 18 hours

pull request commenthaskell-infra/www.haskell.org

Adding a getting started tutorial describing the core GHC tools

@Kleidukos I mean, this PR was just closed in this repo because the submitter gave up on getting it merged here. So I would hope the work can be adopted elsewhere if its not going here.

soupi

comment created time in 21 hours

issue commenthaskell/cabal

Cabal takes 3 minutes to resolve dependencies

Well in that case they can always configure with --enable-tests and never switch -- there's no downside to it! It doesn't run the tests, it just creates a buildplan that enables them. In fact, in general, most people may as well configure with --enable-tests most of the time, so the constant need to switch buildplans here is a bit odd to me as a use case at all.

dfithian

comment created time in 21 hours

issue commenthaskell/cabal

Cabal takes 3 minutes to resolve dependencies

I'll leave this issue be after this, but again, there's no reason to do any of that complicated hash-sharing stuff when we could just have one cache per flag set for some common flags. Its a much simpler architectural approach, and gets the same benefit, if not more. Under this proposed more complicated solution, one would need to run the solver once in each configuration anyway.

dfithian

comment created time in 21 hours

issue commenthaskell/cabal

Cabal takes 3 minutes to resolve dependencies

How do I put this politely? That's completely not feasible given my understanding of how the solver and buildplans work. Further, even if it could work, it would still be less nice in all axes than simply caching a plan with and without the flag.

dfithian

comment created time in a day

issue commenthaskell/hackage-server

Create permanent urls to latest hackage package documentation

Hackage server doesn't have a notion of special urls for special package docs -- anything we do should be able to be uniform for all docs. I don't think its particularly great to have canonical docs be version independent, as modules can disappear between releases, and this would cause links that used to work to stop working. The search engine results problem is very real, and I'm not sure of the right way to approach it -- there are some tickets littered about on this question.

cf https://github.com/haskell/hackage-server/issues/504 and https://github.com/haskell/hackage-server/issues/198

malteneuss

comment created time in a day

issue commenthaskell/cabal

Cabal takes 3 minutes to resolve dependencies

I will note there's one future idea that could improve things still further, which is to have not just a single cache file, but for some subset of flags, a cache file per flag set. That way we would still need to solve at least once in each case, but toggling the flag back and forth further could make use of the correct cached plans. This would need some careful architecture/thinking as currently cache files don't have a way to be "per-X" for various input parameters. This work could be tackled in conjunction with https://github.com/haskell/cabal/issues/7502

dfithian

comment created time in a day

issue commenthaskell/cabal

Cabal takes 3 minutes to resolve dependencies

The fix in https://github.com/haskell/cabal/pull/7516 as well as others are about as much performance as I think can reasonably be gained.

I think what you're proposing here is wrong -- it simply does not regenerate the build plan when the tests enabled flag is changed. But the desired behavior is that enabling or disabling tests should regenerate the plan, because the dependencies chosen are different if test stanzas are taken into account or not.

dfithian

comment created time in a day

PullRequestReviewEvent

pull request commenthaskell-infra/www.haskell.org

Adding a getting started tutorial describing the core GHC tools

Well hopefully @Kleidukos can get this merged into the school of haskell work?

soupi

comment created time in a day

issue commenthaskell/cabal

ar issue on OmniOS

I'd encourage you to inspect the equivalent of your ~/.ghcup/ghc/9.0.1/lib/ghc-9.0.1/settings file (depending on where your ghc install dir is) and see if it contains a line like ("ar supports at file", "YES"), and if so change that to NO.

yobson

comment created time in a day

push eventhaskell/hackage-server

Jack Kelly

commit sha 352680782e13c59e8a87cd22e9d407c491ef199e

Ask new uploaders to name the package they want to upload (And to only include packages they believe will be useful and intend to maintain.)

view details

gbaz

commit sha a1cab6b2b2dd0692b1e9f19cd0872d21a118b3c1

Update SignupConfirmation.email.st

view details

gbaz

commit sha ccdf599431bf9353cfeea2a93b5d71bc168ce41f

Merge pull request #978 from endgame/what-package-are-you-uploading Ask new uploaders to name the package they want to upload

view details

push time in a day

PR merged haskell/hackage-server

Ask new uploaders to name the package they want to upload

(And to only upload packages they believe will be useful and intend to maintain.)

Hopefully this will remove one email round-trip from most Hackage uploader requests, and discourage submission of toy packages.

I will email this PR to the Trustees list, so they get a chance to weigh in before merge.

+8 -5

2 comments

1 changed file

endgame

pr closed time in a day

pull request commenthaskell/hackage-server

Ask new uploaders to name the package they want to upload

I'll merge this as is, and we can always update later. A pre-release checklist could go either on the haskell wiki, or the trustees wiki, or just in a .md document in the trustees repo?

endgame

comment created time in a day

push eventendgame/hackage-server

gbaz

commit sha a1cab6b2b2dd0692b1e9f19cd0872d21a118b3c1

Update SignupConfirmation.email.st

view details

push time in a day

issue commenthaskell/cabal

ar issue on OmniOS

The @ syntax indicates a response file. Such a file is not taken as an argument to the program itself, but rather is supposed to contain a further set of command line arguments. This is used to work around limitations on long cmd-line lengths which some OSes or programs explicitly disallow. What it looks like is happening here is the OSes in question do not have an ar executable that understands response file syntax, and so are treating the @ argument as a regular argument, and not finding a file with the @ appended.

(cf https://gcc.gnu.org/wiki/Response_Files)

Note that cabal itself only uses response files if the ghc info (based on the configure/install of ghc) says this is ok. (https://github.com/haskell/cabal/pull/4596). So perhaps the ghc --info on these systems is incorrect, which should be fixed in the ghc toolchain for them.

yobson

comment created time in 2 days

pull request commenthaskell/cabal

fix curl auth on upload

I can verify by the way that I successfully both ran cabal update (for get) and cabal upload (for putting a file) with this patch and they worked

gbaz

comment created time in 8 days

pull request commenthaskell/cabal

fix curl auth on upload

So again, I'd like some tests, but would appreciate help on that front. Also, before merge, a few of us should give it a workout and sanity check it by hand -- I think we really dropped the ball in reviewing this properly to begin with, sigh.

gbaz

comment created time in 8 days

PR opened haskell/cabal

fix curl auth on upload

Resolves https://github.com/haskell/cabal/issues/7666

This fixes up the logic from #7630 which in turn was an update of #6184

I think this is a collective failure that we didn't review that PR well -- the logic was pretty busted all around, and we wrongly thought that worst case it wouldn't cause regressions, just not handle new functionality well.

I tried to rework the logic so I'm pretty sure its sensible, and I will test this by hand a fair amount. We're sorely lacking in transport tests (not least because we have four transports, etc), so any help in adding a good regression/sanity check around this test would be very welcome. We should not actually have our upload tests hit the running hackage server (even with candidates), so to test the upload rather than fetch functionality properly we'd arguably need a curl mock? ugh.

To give the general context -- some users have repos that are pass-authenticated -- so they want urls like http://user@pass:repo.com -- and they need that authentication to occur even for download, not upload. This I guess always worked with the plain http transport, when we moved to other transports it was added to wget, but not curl. The patches merged tried to add it to curl. However, they overrode other auth info, even when no u/p pair was provided. This refactor tries to make the logical branches very explicit and clear, preserving standard behavior when there's no user info in the uri, or when a u/p pair are otherwise provided in any manner, and only falling back to the uri info when that's not around (such as in the case of a plain get request).

+15 -14

0 comment

1 changed file

pr created time in 8 days

create barnchhaskell/cabal

branch : gb/fix-curl-auth

created branch time in 8 days

issue commenthaskell/cabal

Regression: upload fails with "No authorization provided" (works with 3.4)

Thanks for the report, working on it now.

andreasabel

comment created time in 8 days

create barnchhaskell/cabal

branch : gb/test-code-generator

created branch time in 8 days

pull request commenthaskell/cabal

pipe auth into curl (v2)

Ok, I think I see what's wrong, and why its my fault for not reviewing this better, ugh. The issue is that the uriAuthority of a URI is a Just instead of a Nothing even when there's no user login info. So I had thought this patch was safe because it would only add new behavior on the user:password@server.com case (which had no handling before -- so this would be strictly better) -- but it turns out the case matches even without the u/p pair. Thanks for catching the problem -- I'll make a PR with appropriate changes. Not sure if we have any good curl tests or how to add them, sadly.

gbaz

comment created time in 8 days

issue commenthaskell/cabal

Ask about (or at least signpost!) init --interactive

ok, just checked master and indeed its changed on master. closing again :-)

tom-audm

comment created time in 10 days

issue closedhaskell/cabal

Ask about (or at least signpost!) init --interactive

I'm finding cabal init defaulting to non interactive insanely frustrating, particularly because there's no indication for users of how to get the interactive behavior. No note when the init happens, no documentation in cabal --help.

If you want to, say, init a library, and don't have all the required fields memorized, you probably want to use "--interactive". This is a basic need. Making basic tinkering with libraries more difficult just creates a subclass of users who are unable to contribute.

What I think is best

$ cabal init
Create automatically using sensible defaults? (y/n): y
Initializing using sensible defaults. You can make "cabal init" default to this by [...]
[...]

Bare minimum

$ cabal init
Defaulting to non-interactive init. To use interactive instead, use "cabal init --interactive". You can set the default in [...]

closed time in 10 days

tom-audm