profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/Ericson2314/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.
John Ericson Ericson2314 @ObsidianSystems New York *x* should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.

alpmestan/ghc.nix 98

Nix (shell) expression for working on GHC

ekmett/bytes 20

Serialization primitives that work with both cereal and binary.

Ericson2314/clash-prelude-quickcheck 6

QuickCheck instances for various types in the CλaSH Prelude

Ericson2314/disass 2

A conservative, sound disassembler designed to facilitate easy reassembly

Ericson2314/enet 2

ENet reliable UDP networking library

Ericson2314/APB-signiture-stats 1

for Command & Conquer: Red Alert: A Path Beyond. Design by APB_ICE

Ericson2314/agda-scratchpad 0

Messing with Agda

Ericson2314/alloc-wg 0

Attempt of collection several proposals of the allocators-wg

push eventNixOS/nixpkgs

Ben Siraphob

commit sha 0f1204bd2be0ca1ea60b70d6d1eb7a11077f6986

Initial implementation of s390 cross-compile

view details

John Ericson

commit sha 07223557671fabad8808dd8e5f5147512ba7e51d

Merge pull request #131317 from siraben/s390-cross Initial implementation of s390 cross-compile

view details

push time in an hour

PR merged NixOS/nixpkgs

Reviewers
Initial implementation of s390 cross-compile 10.rebuild-darwin: 0 10.rebuild-linux: 0

<!-- To help with the large amounts of pull requests, we would appreciate your reviews of other pull requests, especially simple package updates. Just leave a comment describing what you have tested in the relevant package/service. Reviewing helps to reduce the average time-to-merge for everyone. Thanks a lot if you do! List of open PRs: https://github.com/NixOS/nixpkgs/pulls Reviewing guidelines: https://nixos.org/manual/nixpkgs/unstable/#chap-reviewing-contributions -->

Motivation for this change

Try it out!

$ nix build .#pkgsCross.s390.hello
Things done

<!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->

  • [ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • [ ] NixOS
    • [ ] macOS
    • [x] other Linux distributions
  • [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • [ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • [ ] Tested execution of all binary files (usually in ./result/bin/)
  • 21.11 Release Notes (or backporting 21.05 Relase notes)
    • [ ] (Package updates) Added a release notes entry if the change is major or breaking
    • [ ] (Module updates) Added a release notes entry if the change is significant
    • [ ] (Module addition) Added a release notes entry if adding a new NixOS module
  • [ ] Fits CONTRIBUTING.md.
+12 -3

2 comments

6 changed files

siraben

pr closed time in an hour

PullRequestReviewEvent

push eventNixOS/nixpkgs

Ben Siraphob

commit sha 407953e9df712b6d89295f1c402e8778a249a748

Initial implementation of m68k cross-compile

view details

John Ericson

commit sha c5a8d45d410a2e57ec6682cc358f7e30d218ea7b

Merge pull request #131310 from siraben/m86k-cross Initial implementation of m68k cross-compile

view details

push time in 14 hours

PR merged NixOS/nixpkgs

Reviewers
Initial implementation of m68k cross-compile 10.rebuild-darwin: 0 10.rebuild-linux: 0 11.by: package-maintainer 8.has: package (new)

<!-- To help with the large amounts of pull requests, we would appreciate your reviews of other pull requests, especially simple package updates. Just leave a comment describing what you have tested in the relevant package/service. Reviewing helps to reduce the average time-to-merge for everyone. Thanks a lot if you do! List of open PRs: https://github.com/NixOS/nixpkgs/pulls Reviewing guidelines: https://nixos.org/manual/nixpkgs/unstable/#chap-reviewing-contributions -->

Motivation for this change

Try it out!

$ nix build .#pkgsCross.m68k.hello
Things done

<!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->

  • [ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • [ ] NixOS
    • [ ] macOS
    • [x] other Linux distributions
  • [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • [ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • [ ] Tested execution of all binary files (usually in ./result/bin/)
  • 21.11 Release Notes (or backporting 21.05 Relase notes)
    • [ ] (Package updates) Added a release notes entry if the change is major or breaking
    • [ ] (Module updates) Added a release notes entry if the change is significant
    • [ ] (Module addition) Added a release notes entry if adding a new NixOS module
  • [x] Fits CONTRIBUTING.md.
+12 -2

0 comment

6 changed files

siraben

pr closed time in 14 hours

pull request commentNixOS/nixpkgs

[WIP] pulseaudio: build with meson

Do they have plans to drop autoconf eventually?

worldofpeace

comment created time in 14 hours

pull request commentsimonmar/happy

Modularize happy

OK it seems all the backends really do use the original Grammar meaningfully.

If that is something that is reasonable to fix (by instead passing in the residual information that is not duplicate with that in tables) I would have happy-grammar and happy-tabular together with happy-cli replace happy-core.

The final breakdown would be:

Tables -> happy-tabular GenUtils -> happy-grammar, but should be liquidated Grammar -> happy-grammar NameSet -> inline to happy-middleend, redefine in happy-rad OptionParsing -> happy-cli

Backends would depend on happy-grammar and happy-tabular until that situation is rectified.

If, on the other hand, it is not reasonable to keep Grammar away from the backends, then I would further combine happy-middleend into happy-tabular. (The backends would morally depend on how the tables were projected, but the fronted wouldn't depend on the tables.)

knothed

comment created time in 21 hours

pull request commentsimonmar/happy

Modularize happy

We're on same page for the CLI stuff now.

For the Grammar, I thought one could convert a Grammar to the tables and then dispense with the grammar, but the imports seem to indicate otherwise. That pulls the foundation out from underneath that the middle stuff is a pipeline stage at all.

(To recap, the structure I generally like would be ASTs/IRs 0..n+1, and transformations 0..n, depending online on the input and output ASTs/IRs.)

knothed

comment created time in a day

pull request commentsimonmar/happy

Modularize happy

Anyways, I like the happy-cli idea, it doesn't resolve the tensions but it is an improvement.

I would like to keep middleend separate, however. It is a bad name, but I do think it is useful to separating a yet-to-be-named middle stage of compilation from the stuff everything needs.

Ultimately, I don't think happy is written with modularity in mind, so it's better to do some split, erring on the side of more granularity, and then refactor things to be sane after. (I do not want to do a release right after this PR is merged.)

knothed

comment created time in a day

pull request commentsimonmar/happy

Modularize happy

Oh, I see packages/*/src/Happy/*/CLI.hs doesn't actually use that stuff.

knothed

comment created time in a day

pull request commentsimonmar/happy

Modularize happy

it does seem awfully convenient for whipping up exes like @knothed's happy-rad

True, hence the suggestion to put CLI utilities into their own package happy-cli

So it's OK if happy-frontend and happy-backend depend on those?

knothed

comment created time in a day

pull request commentsimonmar/happy

Modularize happy

@int-index I do not like the principle of putting CLI stuff everywhere either, but it does seem awfully convenient for whipping up exes like @knothed's happy-rad

knothed

comment created time in a day

pull request commentNixOS/nixpkgs

[WIP]: initrd: Use systemd

I also wonder if this rust script could be reused for a souped-up buildFHSEnv. That could be neat, and share the "burden" of this more wildly (though I am not concerned, bash is bad.)

ElvishJerricco

comment created time in a day

pull request commentghc-proposals/ghc-proposals

NoFallibleDo proposal

No breaking change is without pain, but I strongly believe it is worth it. Maybe and list are better served by MonadPlus anyways.

I also forgot I started #327 as an alternative to allow per-bind opt-ins for even fine-grained control, and structured error messages rather than strings. I would be to experiment with all manner of opt-ins and see what people like the best, but the foundation for that has to be a way to make the base-line the strictest.

cgibbard

comment created time in a day

push eventobsidiansystems/ledger-app-avalanche

John Ericson

commit sha 9cfc9ba929b7b208b52a9aac2e053c1c6e889bc5

Try disabling hardening flags

view details

push time in a day

push eventobsidiansystems/ledger-app-avalanche

Jonathan D.K. Gibbons

commit sha f0ad9d811d4d42bd64aaeae8f1051c199a115b41

WIP: try to use nix-built compilers from ledger-platform nano x requires clang/lld to link, nanos uses gcc/gnu ld, so we just make clang always use lld for consistency.

view details

John Ericson

commit sha fe97a56a071b43e15de19e9902a652b5a44028f5

WIP tests don't work

view details

push time in a day

push eventobsidiansystems/ledger-app-avalanche

John Ericson

commit sha 6d958fe90fcc42cc11ad9248106c200a11cabb87

Enable parallel building

view details

Jonathan D.K. Gibbons

commit sha 2b580c01835ba128d3fcf726918aae622e8ec01c

WIP: try to use nix-built compilers from ledger-platform

view details

John Ericson

commit sha 199249050df3e12cb3877edbc900a976dc5032dc

Fix nanox build with new compilers nano x reqired lld to link.

view details

John Ericson

commit sha 45b82f194fff81adac6b32a3a0f8d5bf81cc3a3c

Fix Clang analyzer job

view details

push time in a day

push eventobsidiansystems/ledger-app-nervos

John Ericson

commit sha 57b2d08e15d5977c87438587a096724925650567

Bump l-p

view details

John Ericson

commit sha bb470fdd442da4c0843313c6de93adb31815f54a

Enable parallel building

view details

John Ericson

commit sha e19f1c98340072ead1fd11cce7363030f2a80dc6

Bump l-p

view details

push time in a day

push eventobsidiansystems/ledger-app-avalanche

John Ericson

commit sha 6d958fe90fcc42cc11ad9248106c200a11cabb87

Enable parallel building

view details

push time in a day

Pull request review commentsimonmar/happy

Modularize happy

-error001.y: Multiple rules for 'foo'

Oh sorry, I forgot to ask: shouldn't this go somewhere?

knothed

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentsimonmar/happy

Modularize happy

 env: before_install:  - sudo add-apt-repository -y ppa:hvr/ghc  - sudo apt-get update- - sudo apt-get install alex-3.1.7 cabal-install-3.4 ghc-$GHCVER- - export PATH=/opt/cabal/3.4/bin:/opt/ghc/$GHCVER/bin:/opt/alex/3.1.7/bin:$PATH+ - sudo apt-get install cabal-install-3.4 ghc-$GHCVER+ - export PATH=/opt/cabal/3.4/bin:/opt/ghc/$GHCVER/bin:$PATH  install:  - cabal update  script:- - make sdist- - make sdist-test-only+ - | +   if [[ $(ghc --numeric-version) == "8.10.1" ]] # only perform make sdist-test once+   then+     make sdist-test+   else+     cabal test -f -bootstrap+   fi

OK, I should make separate jobs for with and without bootstrap to do in parallel after.

knothed

comment created time in a day

PullRequestReviewEvent

Pull request review commentsimonmar/happy

Modularize happy

+module Happy.Backend.GLR.CLI(Flag(..), options, characteristicOption, hasCharacteristicFlag, parseFlags) where++import Prelude hiding (filter)+import Happy.Backend.GLR+import System.Console.GetOpt++-------- CLI flags and options --------++data Flag =+    OptGLR |

@knothed actually I think this should be a top level flag. The top level decides what backend to to use. Once we are in this module we've already made that this, and this package doesn't use this flag at all.

knothed

comment created time in a day

PullRequestReviewEvent

delete branch obsidiansystems/nanox-secure-sdk

delete branch : sdk-1.3.0

delete time in a day

delete branch obsidiansystems/nanox-secure-sdk

delete branch : fix-clang-10

delete time in a day

pull request commentghc-proposals/ghc-proposals

NoFallibleDo proposal

To make the above more concrete, every infallible do is also a valid fallible do, so the only people that will use this will be advanced users writing polymorphic code or using GADTs or pattern synonyms. No one else will bother because the type checker won't remind them.

But I also want beginners, who have learned "do notation is for Monad" and might not even have heard of any of this fail stuff, to benefit from more diagnostics from -Wpartial, and not be surprised with with new unexpected failure mode.

Opt-in also allows these other benefits:

  • We can have separate opt-ins for MonadFail and MonadPlus.

  • For the opt-in fallibility(s), we can skip this silly rename-time heuristic, and just unconditionally add the fails/mzeros like we use to, and thus unconditionally incur the associated constraint. This is much simpler and more predictable, and shouldn't cause issues because, after all, the user opted in.

cgibbard

comment created time in a day