profile
viewpoint
Rod Vagg rvagg require.io NSW, Australia http://r.va.gg Awk Ninja; Yak Shaving Rock Star

microsoft/ChakraCore 8202

ChakraCore is the core part of the Chakra JavaScript engine that powers Microsoft Edge

ded/reqwest 2860

browser asynchronous http requests

nodejs/nan 2763

Native Abstractions for Node.js

fat/bean 1383

an events api for javascript

ded/bonzo 1302

library agnostic, extensible DOM utility

ded/qwery 1101

a query selector engine

microsoft/node-v0.12 799

Enable Node.js to use Chakra as its JavaScript engine.

ded/morpheus 501

A Brilliant Animator

justmoon/node-bignum 408

Big integers for Node.js using OpenSSL

isaacs/st 371

A node module for serving static files. Does etags, caching, etc.

push eventrvagg/js-bitcoin

Rod Vagg

commit sha 138bae8d176e4c8af961b602160bd02f6cc30416

fix jsdoc param names

view details

push time in 6 hours

pull request commentipld/js-ipld-bitcoin

WIP big redo with bitcoin-block and full tx, segwit and merkle handling

I've pushed this as master to https://github.com/rvagg/js-bitcoin. Docs are done and it should be ready to roll. I propose we move that repo into the ipld org and publish as @ipld/bitcoin.

rvagg

comment created time in 6 hours

push eventrvagg/js-bitcoin

Rod Vagg

commit sha 28e05bbf7e6b9deb592faaaf9aea0837dd550927

update subtitle

view details

push time in 6 hours

push eventrvagg/js-bitcoin

Rod Vagg

commit sha 9aed2df48c9a8465df7a43d736c7921ea66550db

clarify non-multiformats API additions

view details

push time in 6 hours

push eventrvagg/js-bitcoin

Rod Vagg

commit sha 385d41a739879ee79e2109301322d006c1512374

add badge

view details

push time in 6 hours

create barnchrvagg/js-bitcoin

branch : master

created branch time in 6 hours

created repositoryrvagg/js-bitcoin

JavaScript Bitcoin data multiformats codecs and utilities for IPLD

created time in 6 hours

push eventipld/js-ipld-bitcoin

Rod Vagg

commit sha 6149fe92cfb82dff5c4037193726d462da3c5553

docs and prepare for publish

view details

push time in 6 hours

pull request commentbitcoin/bitcoin

Expose txinwitness for coinbase in JSON form from RPC

Wondering what the process is for getting things merged in this project? This is not super urgent but it'd be nice to know if it's in a process and not going to get lost.

rvagg

comment created time in 7 hours

push eventnodejs/node-gyp

Rod Vagg

commit sha 575360b0068bb34db8b48c27d9070288bac6b7ed

test: add tap-parallel-not-ok

view details

Rod Vagg

commit sha ff2256cfd64fe5a9c7b6960e99c4480bece44e96

deps: update deps, match to npm@7 PR-URL: https://github.com/nodejs/node-gyp/pull/2126 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Christian Clauss <cclauss@me.com>

view details

Rod Vagg

commit sha dedebce466f7328b2ebae8df21fcb93992f63811

test: upgrade tap

view details

push time in 8 hours

issue commentmultiformats/multicodec

Make CID versions multicodecs

I think the next step to move this forward is to open a PR against table.csv to add something like cid, ipld, 0x1, CIDv1, you're welcome to do that @hobofan and maybe we can move forward. The step after this might be to implement the spec change detailed @ https://github.com/multiformats/cid/issues/25 to cement it.

0x1 isn't in here anymore, I believe it was extracted when multibase was split out and along the way somewhere base1 / unary was dropped entirely, so it's up for grabs here without needing to do conflict resolution.

I'm still not clear on why #94 is necessarily a different thing though tbh. It seems to be part of the same bundle of concerns and just a matter of definitions.

Stebalien

comment created time in 8 hours

issue commentworkshopper/goingnative

Publish v2.0.8

@calvinmetcalf not for stream-adventure, I don't have owner access there so you'll need to do that

ccarruitero

comment created time in 8 hours

push eventipld/specs

Rod Vagg

commit sha 8018d14d515c54d7d0add2d3c81d582330dfe456

dag-pb: express as IPLD Schema Fixes: #245

view details

Eric Myhre

commit sha 81dcd4caaa472fdf378791ffdee8065ed309fb8d

dag-pb: restructure to logical and serial format and properly describe pathing Add section headers for serial and logical format separately. Retitled pathing section to clarify that it's one of several mechanisms, and nonstandard compared to other parts of IPLD.

view details

push time in 8 hours

delete branch ipld/specs

delete branch : rvagg/dag-pb-schema

delete time in 8 hours

PR merged ipld/specs

dag-pb: express as IPLD Schema

Fixes: #245

While I have it open, may as well push something for this. Feel free to edit directly if you have opinions.

+35 -4

4 comments

1 changed file

rvagg

pr closed time in 8 hours

issue closedipld/specs

Describe DagPB also as IPLD Schema

DagPB doesn't support the full IPLD Data Model, nonetheless it can be serialized into the IPLD Data Model. Hence it would be great to have an IPLD Schema for it. Such a Schema already exists in code at https://github.com/ipld/go-ipld-prime-proto/blob/e32bd156a1e52653dbdb8b1696d74205a20f220c/gen/main.go and could be translated into the schema syntax.

closed time in 8 hours

vmx

push eventipld/specs

Eric Myhre

commit sha 4eb7b233f38864262c24cc91203098f483f21432

Merge pull request #242 from ipld/type-theory-concepts-glossary Introduce a type theory glossary.

view details

Volker Mische

commit sha f0473482e7bb3f3128ff1a29a48f85b2357a82f4

DagJSON: Be more specific about Base encoding (#259) How CIDs are encoded was underspecified. The binary type is now also using multibase instead of plain Base64. Reasons for using Multibase instead of raw Base64: - It is clear which variant of Base64 is used - Having symmetry between different Base encded items makes it easier to remember and probably also the implementation easier to follow Reasons for using Base32 for CIDv1s: - DagJSON is mostly used for testing/debugging purpose. IPFS moved to Base32 encoded CIDs. Comparing CIDs for debugging purpose is easier if they are encoded with the same base

view details

Volker Mische

commit sha acf08c3c02f8eecd85f9077f8d403bdb941d5da7

DagJSON: lowercase spec filename and fix links Now files in that directory are named the same way.

view details

Eric Myhre

commit sha 68d360f9993aa4643f2f3408cbc6713cc2c9d6a1

Introduce "EDITING.md". Some content in here covers recommended places to contact the team and other community members; some is about checklists of concerns we use when considering changes; some of it is about sheer syntax. Bit of a grab bag. The part I'm most interested in getting up and out is the considerations checklist. This list gathers a bunch of items we already informally check through when considering new ideas... and it seems to be enough of this list is full of recurring (yet also *terribly* easy to forget on a bad day) concerns, so we might as well document it -- both for ourselves and for others.

view details

Volker Mische

commit sha 7ffdb0c98af6d0a0a3d3e334e6c9606abb4cf62e

fix: capitalize DAG correctly It's e.g. DAG-CBOR and not DagCBOR. I only updated the specs and not the exploration reports as I would just keep them as they are.

view details

Eric Myhre

commit sha d3ab77f491e6adf21771963d7866bca4e0fa6123

Use sentence case for section headings.

view details

Eric Myhre

commit sha ce218014ca4287131f78e2fa8846afef6479958c

fill in links

view details

Eric Myhre

commit sha 476e72c5b771d1c8d86365e0a5e19e1b75de4d86

Merge pull request #264 from ipld/editing-guidelines Introduce "EDITING.md".

view details

Rod Vagg

commit sha 4bb8bdae4b7792b36eff82d90a892900922d2687

dag-pb: express as IPLD Schema Fixes: #245

view details

Eric Myhre

commit sha d13bf7d5f2076689552d511facb147217fbbdfc5

dag-pb: restructure to logical and serial format and properly describe pathing Add section headers for serial and logical format separately. Retitled pathing section to clarify that it's one of several mechanisms, and nonstandard compared to other parts of IPLD.

view details

push time in 8 hours

push eventipld/specs

Volker Mische

commit sha abc088f30edb3f6436b99203b57c011d2ca59c32

DagJSON: Be more specific about Base encoding (#259) How CIDs are encoded was underspecified. The binary type is now also using multibase instead of plain Base64. Reasons for using Multibase instead of raw Base64: - It is clear which variant of Base64 is used - Having symmetry between different Base encded items makes it easier to remember and probably also the implementation easier to follow Reasons for using Base32 for CIDv1s: - DagJSON is mostly used for testing/debugging purpose. IPFS moved to Base32 encoded CIDs. Comparing CIDs for debugging purpose is easier if they are encoded with the same base

view details

Volker Mische

commit sha 2737a214e01004f5d31dad02ab36490a3402e1a0

DagJSON: lowercase spec filename and fix links Now files in that directory are named the same way.

view details

Volker Mische

commit sha 19678b35e28257c30aeec54a2fbc909809a2bef6

fix: capitalize DAG correctly It's e.g. DAG-CBOR and not DagCBOR. I only updated the specs and not the exploration reports as I would just keep them as they are.

view details

Eric Myhre

commit sha eb032747483ec22f88dda768fcc1dbceae916b70

Introduce "EDITING.md". Some content in here covers recommended places to contact the team and other community members; some is about checklists of concerns we use when considering changes; some of it is about sheer syntax. Bit of a grab bag. The part I'm most interested in getting up and out is the considerations checklist. This list gathers a bunch of items we already informally check through when considering new ideas... and it seems to be enough of this list is full of recurring (yet also *terribly* easy to forget on a bad day) concerns, so we might as well document it -- both for ourselves and for others.

view details

Eric Myhre

commit sha 131bd7de4b4385e3d4f50469e806b53b1c8348c2

Use sentence case for section headings.

view details

Eric Myhre

commit sha 803ee3e74196865c0e50ca7cc84aecd4b7be3173

fill in links

view details

Rod Vagg

commit sha cb230a7a4c69534ed52f559d60b3b7aecb6d3ed3

dag-pb: express as IPLD Schema Fixes: #245

view details

Eric Myhre

commit sha b94e308a7646e341b8c64dc97f94045a0574d43c

dag-pb: restructure to logical and serial format and properly describe pathing Add section headers for serial and logical format separately. Retitled pathing section to clarify that it's one of several mechanisms, and nonstandard compared to other parts of IPLD.

view details

push time in 8 hours

pull request commentipld/go-car

Handle reading null-padded files

merged commit 3b87370 into ipld:feat/filestore

OK, sorry, this wasn't into master, not a big deal then. But could we have a clearer rationale and discussion about the implications so we can move on with the other PR now that it's being further complicated? My guess is this is to support reading from Filecoin sectors where the CAR contents get zero padded at the end to get to the right size for storage, but doesn't Filecoin store length information about chunks that would allow it to avoid pushing this concern down into CAR decoding? It seems like something that belongs at a layer or two above here?

magik6k

comment created time in 9 hours

pull request commentipld/go-car

Handle reading null-padded files

Wait, what? Can you explain what this is doing and what it's here for? It looks like this is a spec adjustment. It might be good to hold on PRs like this for a decent amount of time for review since we now have a lot of moving pieces depending on CAR implementations being stable and this isn't the only CAR implementation in the wild and being used.

magik6k

comment created time in 11 hours

issue openednodejs/gyp-next

Flaky tests

We're getting this pretty regularly in node-gyp CI: https://travis-ci.com/github/nodejs/node-gyp/jobs/339883554

The command "npm test" exited with 0.
10714.02s$ GYP_MSVS_VERSION=2015 GYP_MSVS_OVERRIDE_PATH="C:\\Dummy" python -m pytest
1072============================= test session starts ==============================
1073platform linux -- Python 3.5.6, pytest-4.6.6, py-1.7.0, pluggy-0.13.1
1074rootdir: /home/travis/build/nodejs/node-gyp
1075collected 27 items                                                             
1076
1077gyp/pylib/gyp/MSVSSettings_test.py F.F.....                              [ 29%]
...

I don't really know how to interpret the log output that follows, but it's been consistent. I can restart it in Travis and it should pass again, this shows up in maybe 50% of Travis runs and it seems to be most common on Node.js 12 + Python 3.5, but I don't have numbers to back that up.

created time in a day

pull request commentnodejs/node-gyp

v7.0.0 Proposal

Oh, request still hasn't been dealt with. But I did ask Mikeal his advice on this recently because the proxy stuff is pretty critical for this project (a lot of corp folks will be depending on this working in a particular way) and a lot of the potential replacements don't do proxies completely, or at all. He suggested that we look at https://www.npmjs.com/package/tunnel-agent which was extracted from request to handle proxies and is currently used by a number of potential replacements, so we could possibly make a switch and still be using the same proxy code under the hood.

Not entirely sure this is critical to "fix" in this relead, it doesn't feel as critical as it once did, perhaps npm has changed their handling of depecated dependencies? When I install it here I only get this amongst the stream of installs (using loglevel http):

npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142

It doesn't come up at the end of the install nagging you about it, so it's not as spiky as a security vulnerability would be. Maybe we just proceed as is and deal with this soon after in a minor or patch update?

rvagg

comment created time in a day

PR opened nodejs/node-gyp

Modernise codebase (big WIP)

This is something I've been chipping away at. Only about half done at the moment but I thought I should push it in case I forget about it and someone else wants to pick it up and to collect intermediate feedback on my approach if anyone wants to weigh in.

The aim here is to embrace modern JS, >= Node 10 style. So primarily async / await and the various pieces of syntactic sugar that we haven't yet embraced here (template strings, arrow functions, no more var, etc.). Secondarily is to clean up the style a bit to make it more clear and get rid of the huge nesting that's been piling up since the original code and make it more maintainable in the process. In the process I'd like to expose more of the code for testing, so it'll probably meaning splitting out more files that are focused on just one thing that can be isolated and tested.

test/ should all be done I think, lib/ is where the bulk of the remaining work is.

There's a couple of places where new Promise() appears in this WIP code that will eventually be factored out, they're just used as bridging points between callback and async/await style so the tests still pass. In the end I think the only place explicit new Promise() will appear is around child_process work which is still hard to promisify nicely, but I think that should probably all be factored out into a single place to avoid the duplication.

+1435 -1679

0 comment

23 changed files

pr created time in a day

create barnchnodejs/node-gyp

branch : rvagg/modernise

created branch time in a day

pull request commentnodejs/node-gyp

v7.0.0 Proposal

I think this is as ready as it can be for now. Can I get a :thumbsup: or two? I'll push it out in the next couple of days unless there are any hold-ups.

  • [e18a61afc1] - build: shrink bloated addon binaries on windows (Shelley Vohr) #2060
  • [d45438a047] - (SEMVER-MAJOR) deps: update deps, match to npm@7 (Rod Vagg) #2126
  • [e529f3309d] - doc: update README to reflect upgrade to gyp-next (Ujjwal Sharma) #2092
  • [9aed6286a3] - doc: give more attention to Catalina issues doc (Matheus Marchini) #2134
  • [963f2a7b48] - doc: improve cataline discoverability for search engines (Matheus Marchini) #2135
  • [7b75af349b] - doc: add macOS Catalina software update info (Karl Horky) #2078
  • [4f23c7bee2] - doc: update link to the code of conduct (#2073) (Michaël Zasso) #2073
  • [473cfa283f] - doc: note in README that Python 3.8 is supported (#2072) (Michaël Zasso) #2072
  • [e7402b4a7c] - doc: update catalina xcode cli tools download link (#2044) (Dario Vladović) #2044
  • [35de45984f] - doc: update catalina xcode cli tools download link; formatting (Jonathan Hult) #2034
  • [48642191f5] - doc: add download link for Command Line Tools for Xcode (Przemysław Bitkowski) #2029
  • [ae5b150051] - doc: Catalina suggestion: remove /Library/Developer/CommandLineTools (Christian Clauss) #2022
  • [d1dea13fe4] - doc: fix changelog 6.1.0 release year to be 2020 (Quentin Vernot) #2021
  • [6356117b08] - doc, bin: stop suggesting opening node-gyp issues (Bartosz Sosnowski) #2096
  • [a6b76a8b48] - gyp: update gyp to 0.2.1 (Ujjwal Sharma) #2092
  • [ebc34ec823] - gyp: update gyp to 0.2.0 (Ujjwal Sharma) #2092
  • [972780bde7] - (SEMVER-MAJOR) gyp: sync code base with nodejs repo (#1975) (Michaë l Zasso) #1975
  • [c255ffbf6a] - lib: drop "-2" flag for "py.exe" launcher (DeeDeeG) #2131
  • [1f7e1e93b5] - lib: ignore VS instances that cause COMExceptions (Andrew Casey) #2018
  • [741ab096d5] - test: remove support for EOL versions of Node.js (Shelley Vohr)
  • [ca86ef2539] - test: bump actions/checkout from v1 to v2 (BSKY) #2063
rvagg

comment created time in a day

push eventnodejs/node-gyp

DeeDeeG

commit sha c255ffbf6adc6b60cb39fa1aa40bfc8eb45f80ac

lib: drop "-2" flag for "py.exe" launcher Now that node-gyp supports both Python 2 and Python 3, We don't need to explicitly try to find only Python 2. Fixes: https://github.com/nodejs/node-gyp/issues/2130 Refs: https://docs.python.org/3/using/windows.html#launcher PR-URL: https://github.com/nodejs/node-gyp/pull/2131 Reviewed-By: Christian Clauss <cclauss@me.com> Reviewed-By: Rod Vagg <rod@vagg.org>

view details

Rod Vagg

commit sha 5f47b7a18397dd8530176f380d4bc1c99e0839ac

v5.1.1: bump version and update changelog

view details

Rod Vagg

commit sha d45438a047a30b6c6993553459e4544e810bb3f5

deps: update deps, match to npm@7 PR-URL: https://github.com/nodejs/node-gyp/pull/2126 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Christian Clauss <cclauss@me.com>

view details

Matheus Marchini

commit sha 963f2a7b481ac4b8dee7f8c1c582f0d78e207f03

doc: improve cataline discoverability for search engines By showing the error in the guide, search engines should be able to find this document when users search for specific lines from the error. Co-authored-by: Christian Clauss <cclauss@me.com> PR-URL: https://github.com/nodejs/node-gyp/pull/2135 Reviewed-By: Rod Vagg <rod@vagg.org> Reviewed-By: Christian Clauss <cclauss@me.com>

view details

Matheus Marchini

commit sha 9aed6286a3d6debbcbb6306cf6ef317fc50f4375

doc: give more attention to Catalina issues doc It's easy to miss the Catalina issues doc when reading the readme. Since it can be a common issue among developers, it makes sense to give more attention to it in the readme. PR-URL: https://github.com/nodejs/node-gyp/pull/2134 Reviewed-By: Rod Vagg <rod@vagg.org> Reviewed-By: Christian Clauss <cclauss@me.com>

view details

Ujjwal Sharma

commit sha ebc34ec823d20b593ee9713bb0887daaa363cbe2

gyp: update gyp to 0.2.0 PR-URL: https://github.com/nodejs/node-gyp/pull/2092 Reviewed-By: Rod Vagg <rod@vagg.org>

view details

Ujjwal Sharma

commit sha e529f3309d41111d5d6d5d08b4fbde610cd0efff

doc: update README to reflect upgrade to gyp-next PR-URL: https://github.com/nodejs/node-gyp/pull/2092 Reviewed-By: Rod Vagg <rod@vagg.org>

view details

Ujjwal Sharma

commit sha a6b76a8b488c3ca3ee39f4138644593075c25306

gyp: update gyp to 0.2.1 PR-URL: https://github.com/nodejs/node-gyp/pull/2092 Reviewed-By: Rod Vagg <rod@vagg.org>

view details

Rod Vagg

commit sha ba0db798251bce98ba37ddda7f83c61b7d5da9a6

v7.0.0: bump version and update changelog

view details

push time in a day

PR closed nodejs/node-gyp

gyp: update gyp to 0.2.0

<!-- Thank you for your pull request. Please review the below requirements.

Contributor guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

  • [ ] npm install && npm test passes
  • [ ] tests are included <!-- Bug fixes and new features should include tests -->
  • [ ] documentation is changed or added
  • [ ] commit message follows commit guidelines
Description of change

<!-- Provide a description of the change -->

/cc @targos @cclauss @nodejs/gyp @nodejs/node-gyp

For some reason, I don't have write access to this repo? Is it not open to collaborators? :sweat_smile:

+27621 -24448

12 comments

64 changed files

ryzokuken

pr closed time in a day

pull request commentnodejs/node-gyp

gyp: update gyp to 0.2.0

  • a6b76a8 gyp: update gyp to 0.2.1
  • e529f33 doc: update README to reflect upgrade to gyp-next
  • ebc34ec gyp: update gyp to 0.2.0
ryzokuken

comment created time in a day

push eventnodejs/node-gyp

Ujjwal Sharma

commit sha ebc34ec823d20b593ee9713bb0887daaa363cbe2

gyp: update gyp to 0.2.0 PR-URL: https://github.com/nodejs/node-gyp/pull/2092 Reviewed-By: Rod Vagg <rod@vagg.org>

view details

Ujjwal Sharma

commit sha e529f3309d41111d5d6d5d08b4fbde610cd0efff

doc: update README to reflect upgrade to gyp-next PR-URL: https://github.com/nodejs/node-gyp/pull/2092 Reviewed-By: Rod Vagg <rod@vagg.org>

view details

Ujjwal Sharma

commit sha a6b76a8b488c3ca3ee39f4138644593075c25306

gyp: update gyp to 0.2.1 PR-URL: https://github.com/nodejs/node-gyp/pull/2092 Reviewed-By: Rod Vagg <rod@vagg.org>

view details

push time in a day

pull request commentnodejs/node-gyp

Update macOS Catalina XCode CLT download link

You were 2 days too early for 11.5! Would you mind updating to https://download.developer.apple.com/Developer_Tools/Command_Line_Tools_for_Xcode_11.5/Command_Line_Tools_for_Xcode_11.5.dmg please?

vladimyr

comment created time in a day

pull request commentnodejs/node-gyp

doc: give more attention to Catalina issues doc

9aed628

mmarchini

comment created time in a day

PR closed nodejs/node-gyp

doc: give more attention to Catalina issues doc

It's easy to miss the Catalina issues doc when reading the readme. Since it can be a common issue among developers, it makes sense to give more attention to it in the readme.

<!-- Thank you for your pull request. Please review the below requirements.

Contributor guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

+2 -1

2 comments

1 changed file

mmarchini

pr closed time in a day

push eventnodejs/node-gyp

Matheus Marchini

commit sha 9aed6286a3d6debbcbb6306cf6ef317fc50f4375

doc: give more attention to Catalina issues doc It's easy to miss the Catalina issues doc when reading the readme. Since it can be a common issue among developers, it makes sense to give more attention to it in the readme. PR-URL: https://github.com/nodejs/node-gyp/pull/2134 Reviewed-By: Rod Vagg <rod@vagg.org> Reviewed-By: Christian Clauss <cclauss@me.com>

view details

push time in a day

PR closed nodejs/node-gyp

gyp: quote a few paths potentially containing spaces in makefile gene…

This is a tentative fix for https://github.com/nodejs/node-gyp/issues/439 (at least when using the makefile generator). It protects a few paths that may contain spaces in the generator. There are probably more instances of this problem, in that generator and other generators.

Unfortunately I am unable to write tests for assessing the fix and make a proper PR. I was nevertheless able to compile better-sqlite3 from a directory containing spaces.

Checklist
  • [x] npm install && npm test passes
  • [ ] tests are included
  • [x] commit message follows commit guidelines
+6 -6

1 comment

1 changed file

benob

pr closed time in a day

pull request commentnodejs/node-gyp

gyp: quote a few paths potentially containing spaces in makefile gene…

Sorry that we probably haven't made it very clear but this code is now being primarily maintained @ https://github.com/nodejs/gyp-next so could you please open a PR there and discuss with the team maintaining it? Thanks.

benob

comment created time in a day

PR closed nodejs/node-gyp

doc: improve Catalina discoverability for search engines gyp: No Xcode or CLT version detected!

By showing the error in the guide, search engines should be able to find this document when users search for specific lines from the error.

<!-- Thank you for your pull request. Please review the below requirements.

Contributor guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

+5 -1

1 comment

1 changed file

mmarchini

pr closed time in a day

pull request commentnodejs/node-gyp

doc: improve Catalina discoverability for search engines

963f2a7

mmarchini

comment created time in a day

push eventnodejs/node-gyp

Matheus Marchini

commit sha 963f2a7b481ac4b8dee7f8c1c582f0d78e207f03

doc: improve cataline discoverability for search engines By showing the error in the guide, search engines should be able to find this document when users search for specific lines from the error. Co-authored-by: Christian Clauss <cclauss@me.com> PR-URL: https://github.com/nodejs/node-gyp/pull/2135 Reviewed-By: Rod Vagg <rod@vagg.org> Reviewed-By: Christian Clauss <cclauss@me.com>

view details

push time in a day

pull request commentnodejs/node-gyp

deps: update deps, match to npm@7, upgrade to tap 14

d45438a047a

rvagg

comment created time in a day

PR closed nodejs/node-gyp

deps: update deps, match to npm@7, upgrade to tap 14 semver-major

semver, tar and which were the major bumps in here, but none had breaking APIs that we touch, thankfully.

I've matched the ranges to npm@7's current ranges, as seen @ https://github.com/npm/cli/blob/release/v7.0.0-beta/package.json, so for some of them they're not the actual latest but they're only out by a patch release or two.

Updated tap to v14, which drops support for older versions of Node.js, but it runs nicer in parallel and gives automatic coverage reporting (which is dismal, but we knew that).

+9 -9

5 comments

1 changed file

rvagg

pr closed time in a day

delete branch nodejs/node-gyp

delete branch : rvagg/update-deps

delete time in a day

push eventnodejs/node-gyp

Rod Vagg

commit sha d45438a047a30b6c6993553459e4544e810bb3f5

deps: update deps, match to npm@7 PR-URL: https://github.com/nodejs/node-gyp/pull/2126 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Christian Clauss <cclauss@me.com>

view details

push time in a day

delete branch rvagg/browserify-sign

delete branch : rvagg/readable-stream

delete time in a day

issue commentnodejs/Release

Trim active releasers list

sadly this isn't done yet, I don't think we have an agreed upon solution and I still haven't trimmed the active releasers list, can someone please reopen this?

rvagg

comment created time in a day

delete branch multiformats/multicodec

delete branch : rvagg/bitcoin-witness-commitment

delete time in a day

push eventmultiformats/multicodec

Rod Vagg

commit sha 31aa3ed1989017dc98fb1c6b1948584bf127ba92

Add Bitcoin Witness Commitment (0xb2)

view details

push time in a day

PR merged multiformats/multicodec

Add Bitcoin Witness Commitment (0xb2)

This completes the set needed to interact with the full Bitcoin graph with IPLD. The Witness Commitment is the link to the second binary merkle that contains the transactions with full witness data, whereas the initial binary merkle pointed to from the block header (known as merkleroot) points to the transactions without witness data. Since SegWit, this second binary merkle tree gets linked to from the coinbase scriptPubKey property and the coinbase is excluded from the binary merkle (replaced with 0x000...000) as a result. The reason we need this new element is that the coinbase points to an intermediate structure which concatenates a nonce and the new merkleroot together and the nonce, in the standard representation, becomes the "witness" property of the coinbase itself. So to reconstruct the original full block graph structure you have to navigate to the transactions in the witness merkle and on the way pick up this nonce to re-attach it to the coinbase. This Witness Commitment is 64-bytes long and otherwise looks like a node in the normal binary merkle, but the leftmost side is the nonce (which happens to be 0x000...000 on most blocks because Bitcoin Core does that, but other miners are allowed to insert random strings here and there are so far ~4000 of these in the blockchain).

Decoding a bitcoin-witness-commitment yields a:

type WitnessCommitment struct {
  merkleRoot &MaybeTransaction
  nonce Bytes # 32-bytes long
}

Where a MaybeTransaction is a union that could be an actual transaction or a node in a binary merkle tree, which are also 64-bytes long but look like this:

type TransactionMerkleNode [&MaybeTransaction] # strictly 2 elements long

Another notable problem that makes a dedicated codec for this helpful is that there are pre-SegWit blocks with a coinbase scriptPubKey that look like they point to a witness commitment and there's no firm way to determine whether it is one or not unless you try to load it (from wherever these blocks are coming from). A failure to load an 0xb2 can be a signal that the presumed witness commitment is actually not a witness commitment. A failure to load anything else can be firmly interpreted as a failure to locate something that should exist.

This is implemented and in use in the code @ https://github.com/ipld/js-ipld-bitcoin/pull/63 (will likely be made into a separate repo for @ipld/bitcoin with the js-ipld-bitcoin repo being the k

+1 -0

0 comment

1 changed file

rvagg

pr closed time in a day

pull request commentnodejs/node

tools,doc: fix version picker in docs to show all available versions

Without having enough time or headspace to grok this entirely (so this might not be relevant, I'm skimming comments), any linking needs to account for doc locations including /api/x.html, https://nodejs.org/docs/vx.y.z/api/x.html, https://nodejs.org/download/release/vx.y.z/docs/api/x.html (and /dist/). So any solution involving relative paths become a bit tricky because you have 3 different depths and one of them doesn't have siblings.

Trott

comment created time in a day

pull request commentipfs/go-cid

feat: add Filecoin multicodecs

The short answer is "partly". But we also purposefully didn't tag them as "ipld", or "serialization" in the multicodec table because (a) it's not as clear that these can be a clean & bi-directional serialization format and (b) it's not even clear that you'd ever want to use them in this way. We also still haven't received a clear answer regarding why these things need to be CIDs but we're going forward in good faith that there is (and that grokking the full "why" of any of these things is probably beyond the scope of multicodecs in general if multicodecs are to continue to scale). A pointer to a content-addressed thing of a particular, discernible type whose address is composed in a particular way - is partly (but not wholly) how I think it's being conceptualised.

Deep context can be found in this thread if anyone's interested in diving head-first: https://github.com/multiformats/multicodec/pull/172

rvagg

comment created time in a day

delete branch rvagg/go-cid

delete branch : rvagg/filecoin-codecs

delete time in a day

pull request commentnodejs/node-gyp

deps: update deps, match to npm@7, upgrade to tap 14

I've backed out the tap@14 upgrade and tap@12 seems to have stabilised things. It's probably due to the parallel processing tap@14 tries to do. There seems to be a flaky Python test in there though, https://travis-ci.com/github/nodejs/node-gyp/jobs/339548918, aside from that I think this is good to go.

rvagg

comment created time in 2 days

push eventnodejs/node-gyp

DeeDeeG

commit sha c255ffbf6adc6b60cb39fa1aa40bfc8eb45f80ac

lib: drop "-2" flag for "py.exe" launcher Now that node-gyp supports both Python 2 and Python 3, We don't need to explicitly try to find only Python 2. Fixes: https://github.com/nodejs/node-gyp/issues/2130 Refs: https://docs.python.org/3/using/windows.html#launcher PR-URL: https://github.com/nodejs/node-gyp/pull/2131 Reviewed-By: Christian Clauss <cclauss@me.com> Reviewed-By: Rod Vagg <rod@vagg.org>

view details

Rod Vagg

commit sha 5f47b7a18397dd8530176f380d4bc1c99e0839ac

v5.1.1: bump version and update changelog

view details

Rod Vagg

commit sha ad2525ec3ff726f992adbe0d88d3bec1a95ed0c9

deps: update deps, match to npm@7, upgrade to tap 14

view details

Rod Vagg

commit sha 82d1acf0e8b463aa530974b62b1afc0a25645428

fixup! deps: update deps, match to npm@7, upgrade to tap 14

view details

push time in 2 days

push eventnodejs/node-gyp

Rod Vagg

commit sha 5f47b7a18397dd8530176f380d4bc1c99e0839ac

v5.1.1: bump version and update changelog

view details

push time in 2 days

delete branch nodejs/node-gyp

delete branch : rvagg/v5.1.1-proposal

delete time in 2 days

pull request commentnodejs/node-gyp

v5.1.1 Proposal

released and merged

rvagg

comment created time in 2 days

created tagnodejs/node-gyp

tagv5.1.1

Node.js native addon build tool

created time in 2 days

PR closed nodejs/node-gyp

v5.1.1 Proposal

The main change is @codebytere's Windows binary size fix, otherwise it's just test & doc.

+0 -0

0 comment

0 changed file

rvagg

pr closed time in 2 days

push eventnodejs/node-gyp

Rod Vagg

commit sha 748478eb195208b7e30f65c08b2e7d7d684253e0

v5.1.1: bump version and update changelog

view details

push time in 2 days

push eventnodejs/node-gyp

BSKY

commit sha a876ae58adfa22717aadee8670841e3cb578abe6

test: bump actions/checkout from v1 to v2 PR-URL: https://github.com/nodejs/node-gyp/pull/2063 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Christian Clauss <cclauss@me.com>

view details

Shelley Vohr

commit sha bdd3a79abeb75c14017f0679d96d4f91b3dcf555

build: shrink bloated addon binaries on windows PR-URL: https://github.com/nodejs/node-gyp/pull/2060 Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>

view details

Michaël Zasso

commit sha 251d9c885ca6d79b7c52787a8b6cf435e07d6e6a

doc: note in README that Python 3.8 is supported (#2072) PR-URL: https://github.com/nodejs/node-gyp/pull/2072 Refs: https://github.com/nodejs/node-gyp/issues/2071 Reviewed-By: Christian Clauss <cclauss@me.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com>

view details

Michaël Zasso

commit sha fb2e80d4e3025a97c186b12a85ba7966ccc822c9

doc: update link to the code of conduct (#2073) PR-URL: https://github.com/nodejs/node-gyp/pull/2073 Reviewed-By: Christian Clauss <cclauss@me.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com>

view details

Bartosz Sosnowski

commit sha 2b6fc3c8d6d5b534ff5715d6b5ea60f9b150a28d

doc, bin: stop suggesting opening node-gyp issues A lot of new issues in node-gyp are related to outdated node-gyp or broken modules. This removes the suggestion to open a new issue in the node-gyp, instead suggesting the user should open the issue in the module issue tracker. It also makes the issue template more explicit about providing the logs. PR-URL: https://github.com/nodejs/node-gyp/pull/2096 Reviewed-By: Christian Clauss <cclauss@me.com> Reviewed-By: Rod Vagg <rod@vagg.org>

view details

Christian Clauss

commit sha bb8d0e7b10a071cbd86532d6c261b3dc3bc90924

doc: Catalina suggestion: remove /Library/Developer/CommandLineTools PR-URL: https://github.com/nodejs/node-gyp/pull/2022 Reviewed-By: Rod Vagg <rod@vagg.org>

view details

Przemysław Bitkowski

commit sha 59b0b1add87c9653485d6e7cebdb696761e970f5

doc: add download link for Command Line Tools for Xcode PR-URL: https://github.com/nodejs/node-gyp/pull/2029 Reviewed-By: Rod Vagg <rod@vagg.org>

view details

Jonathan Hult

commit sha 9a6fea92e250980d5d3163104624004afcbbc88a

doc: update catalina xcode cli tools download link; formatting PR-URL: https://github.com/nodejs/node-gyp/pull/2034 Reviewed-By: Rod Vagg <rod@vagg.org> Reviewed-By: Christian Clauss <cclauss@me.com>

view details

Dario Vladović

commit sha c106d915f561993bfab19372372c5511167edfeb

doc: update catalina xcode cli tools download link (#2044) PR-URL: https://github.com/nodejs/node-gyp/pull/2044 Reviewed-By: Rod Vagg <rod@vagg.org> Reviewed-By: Jiawen Geng <technicalcute@gmail.com>

view details

Karl Horky

commit sha 1f2ba75bc0d02bab0fe45de11e937f4011f2d7b3

doc: add macOS Catalina software update info PR-URL: https://github.com/nodejs/node-gyp/pull/2078 Reviewed-By: Christian Clauss <cclauss@me.com> Reviewed-By: Rod Vagg <rod@vagg.org>

view details

Rod Vagg

commit sha 748478eb195208b7e30f65c08b2e7d7d684253e0

v5.1.1: bump version and update changelog

view details

push time in 2 days

issue openedipld/specs

ADLs as a core part of IPLD?

Continuing a discussion from elsewhere where we're trying to clarify this graphic:

IPLD Diagram

Without quoting semi-private discussion, there is disagreement about the place of ADLs here. @mikeal wants to remove them from a graphic that is trying to define "what is IPLD".

@warpfork has been suggesting that their existence is important for the proper design of extensible IPLD implementations and omitting them may lead to suboptimal implementations that have difficulty being extended to all that we're trying to build.

I'm very sympathetic to the latter view and see its importance in go-ipld-prime and would love to see the same design make its way through the new Rust implementation. But we really don't have anything that looks like a proper ADL yet and we keep on talking as if they are concrete thing, which they aren't, and maybe that's not been helpful to people who aren't clued in to the way we're all conceptualising it. Even putting it in this graphic suggests that we have something to show, but we just don't.

I'm fine either way wrt this graphic. If we leave it out then we could re-insert it later when we get closer to the ultimate dream. Mostly I just want to isolate this particular discussion here.

created time in 2 days

issue commentworkshopper/goingnative

Publish v2.0.8

@ccarruitero I'm assuming ccarruitero on npm is you. I've added you to goingnative, please take the responsibility seriously and make sure to do everything through this repo. Thanks for taking on this task!

ccarruitero

comment created time in 2 days

pull request commentipfs/go-cid

feat: add Filecoin multicodecs

@Stebalien I think this is good to land, could you merge it please?

rvagg

comment created time in 2 days

PR opened multiformats/multicodec

Add Bitcoin Witness Commitment (0xb2)

This completes the set needed to interact with the full Bitcoin graph with IPLD. The Witness Commitment is the link to the second binary merkle that contains the transactions with full witness data, whereas the initial binary merkle pointed to from the block header (known as merkleroot) points to the transactions without witness data. Since SegWit, this second binary merkle tree gets linked to from the coinbase scriptPubKey property and the coinbase is excluded from the binary merkle (replaced with 0x000...000) as a result. The reason we need this new element is that the coinbase points to an intermediate structure which concatenates a nonce and the new merkleroot together and the nonce, in the standard representation, becomes the "witness" property of the coinbase itself. So to reconstruct the original full block graph structure you have to navigate to the transactions in the witness merkle and on the way pick up this nonce to re-attach it to the coinbase. This Witness Commitment is 64-bytes long and otherwise looks like a node in the normal binary merkle, but the leftmost side is the nonce (which happens to be 0x000...000 on most blocks because Bitcoin Core does that, but other miners are allowed to insert random strings here and there are so far ~4000 of these in the blockchain).

Decoding a bitcoin-witness-commitment yields a:

type WitnessCommitment struct {
  merkleRoot &MaybeTransaction
  nonce Bytes # 32-bytes long
}

Where a MaybeTransaction is a union that could be an actual transaction or a node in a binary merkle tree, which are also 64-bytes long but look like this:

type TransactionMerkleNode [&MaybeTransaction] # strictly 2 elements long

Another notable problem that makes a dedicated codec for this helpful is that there are pre-SegWit blocks with a coinbase scriptPubKey that look like they point to a witness commitment and there's no firm way to determine whether it is one or not unless you try to load it (from wherever these blocks are coming from). A failure to load an 0xb2 can be a signal that the presumed witness commitment is actually not a witness commitment. A failure to load anything else can be firmly interpreted as a failure to locate something that should exist.

This is implemented and in use in the code @ https://github.com/ipld/js-ipld-bitcoin/pull/63 (will likely be made into a separate repo for @ipld/bitcoin with the js-ipld-bitcoin repo being the k

+1 -0

0 comment

1 changed file

pr created time in 2 days

create barnchmultiformats/multicodec

branch : rvagg/bitcoin-witness-commitment

created branch time in 2 days

pull request commentipld/js-ipld-bitcoin

WIP big redo with bitcoin-block and full tx, segwit and merkle handling

ok, so a new repo name, should it just be ipld/js-bitcoin? I think this matches the pattern @mikeal is establishing

rvagg

comment created time in 2 days

push eventipld/js-ipld-bitcoin

Rod Vagg

commit sha 1ac57ce7021c6490adb3f929a6e409f3eca2314b

add another unicorn block to fixtures

view details

Rod Vagg

commit sha 9fae89769744df1a4f1c4b07b207bd09b8dff44b

expose and test cidToHash()

view details

push time in 2 days

push eventrvagg/js-bitcoin-block

Rod Vagg

commit sha da3bb146900020da0d67d0dcb66770407e6b3ed7

introduce strict length consumption during decode

view details

Rod Vagg

commit sha 5d77ede0875583e4a038d869a513d4b82f67fab9

size strictness in decoding

view details

Rod Vagg

commit sha 9849abb52de5e3647f904ce8b530a2319451d0ef

1.4.0

view details

push time in 2 days

pull request commentipld/js-datastore-car

Switch to @ipld/multiformats

Latest commit adds a readFileIndexed() mode. You give it a path to a CAR file, it'll do a quick scan of it and keep an index of CID:location mapping in memory and then do random access reads for get() and query() operations (quick from-memory has() of course too). So it's not a memory hog like readFileComplete() for large files and not as fast as readFileStreaming() for sequential reads but supports random access reads.

Pretty neat for interacting with large files and wanting to do arbitrary get()s.

rvagg

comment created time in 5 days

push eventipld/js-datastore-car

Rod Vagg

commit sha 211a6737ff8dbd1d9fd1a0f0795c22d74cfc567f

feat: add readFileIndexed for large files, random access, pre-indexed

view details

push time in 5 days

pull request commentnodejs/build

ansible: metrics server (WIP) & removal of Cloudflare cache bypass

@jbergstroem are you able to help @AshCripps out with GCP functions? He's trying to engineer the thing you originally suggested - process logs as they come in from Cloudflare.

I think im going to have to call the google functions solutions quits for the moment as its just refusing to work, the code works locally and I can see its triggered but it just wont write to a new file - its give no errors or anything.

@AshCripps regarding space on that server -- it's all up for grabs, there's nothing on that server that's super critical and couldn't be deleted. Mostly it was just a WIP.

The thing that filled it up was /home/nodejs/logs/cloudflare/ which started off as a mirror of the cloudflare logs to start processing like you're talking about. I've deleted everything in there now so there's ~128G free. /home is a 500G disk, it's currently got mirrors of logs from nodejs.org and the backup server in /home/nodejs/logs - these could be deleted if need be. And also the processed metrics served at nodejs.org/metrics/ in /home/nodejs/metrics-out, although it might be nice to keep those and use that as the authoritative home of what we push onto nodejs.org to be served at /metrics. They're also useful for comparing against new files to make sure we're getting it right!

There's also the option of replacing /home with a larger disk. I just chose 500G as a fairly arbitrary number to start with but if it's helpful to have a larger cache space then we can do that easily enough. Let me know.

I've cleaned it up a little, rebooted and updated the OS so it should be good to go now. I'm pretty sure all the timers I had that did syncing are all disabled so it shouldn't fill up again without asking it to.

The (hopefully disabled) timer I used for syncing GCP are in /lib/systemd/system/sync-cloudflare-periodic.service and /lib/systemd/system/sync-cloudflare-periodic.timer if that's helpful.

rvagg

comment created time in 5 days

issue commentnodejs/build

root access to OSUOSL AIX machines for Michael Felt

+1 I'm generally fine with this as long as (1) we can establish a decent trust relationship with the individuals involved (they work for a donor, they work for a member company, etc.) and (2) it doesn't involve exposing the staging SSH key on release machines or present risk to the release build pipeline that may undermine confidence in its security. Since this is for test machines and is from a donor then :thumbsup:.

mhdawson

comment created time in 6 days

issue commentnodejs/node-gyp

Colud not find my_node_addon on Windows

this needs more context to be actionable @ali-chaudhry, why are you looking for "my_node_addon", as far as I know this is not part of the documentation for node-gyp.

ali-chaudhry

comment created time in 8 days

push eventipld/js-ipld-bitcoin

Rod Vagg

commit sha 8c1f25ecee0d8731b64f0e54fe78f9d6a0e0aa2b

handle non-null witness nonces

view details

push time in 8 days

pull request commentnodejs/node-gyp

deps: update deps, match to npm@7, upgrade to tap 14

Sigh, typical useless output on compiling the test addon.

gyp info spawn C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe
5221          
5222              gyp info spawn args [
5223          
5224              gyp info spawn args   'build/binding.sln',
5225          
5226              gyp info spawn args   '/nologo',
5227          
5228              gyp info spawn args   '/p:Configuration=Release;Platform=x64'
5229          
5230              gyp info spawn args ]
5231          
5232              gyp ERR! build error 
5233          
5234              gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe` failed with exit code: 1
5235          
5236              gyp ERR! stack     at ChildProcess.onExit (C:\Users\travis\build\nodejs\node-gyp\lib\build.js:21:656)
5237          
5238              gyp ERR! stack     at ChildProcess.emit (events.js:310:20)
5239          
5240              gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
5241          
5242              gyp ERR! System Windows_NT 10.0.17763
5243          
5244              gyp ERR! command "C:\\ProgramData\\nvs\\node\\12.16.3\\x64\\node.exe" "C:\\Users\\travis\\build\\nodejs\\node-gyp\\bin\\node-gyp.js" "rebuild" "-C" "C:\\Users\\travis\\build\\nodejs\\node-gyp\\test\\node_modules\\hello_world" "--loglevel=verbose"
5245          

I've rerun the tests twice now with different runners failing.

rvagg

comment created time in 8 days

push eventipld/js-ipld-bitcoin

Rod Vagg

commit sha f2f9b9895ffaeda4c7e3d50554af8778a42c96bd

more strictness about 64-byte transactions

view details

push time in 8 days

push eventipld/js-ipld-bitcoin

Rod Vagg

commit sha ea9d7fed04782011b4752ae2730c9688b6518958

additional strictness during decodes - consume all bytes, txs must have vin & vout

view details

push time in 8 days

issue commentworkshopper/goingnative

Publish v2.0.8

It looks like @julianduque or @calvinmetcalf might be the best chances to get a stream-adventure published. Either of you two active and interested in continuing to help maintain it and other workshoppers, or at least be available for publishing?

I'd like to give @ccarruitero publish access to goingnative, any @workshopper/deploy folks object please let me know here or in private email.

ccarruitero

comment created time in 9 days

push eventipld/js-ipld-bitcoin

Rod Vagg

commit sha b36f3af24c141214ee0f2de76dcf890fe33c41f9

handle faux-segwit and segwit with 1tx special cases

view details

Rod Vagg

commit sha b61cc924de2135228edfeda700fd862a4cccabdd

expose {block,tx}HashToCID utility functions

view details

Rod Vagg

commit sha 0b3ee9f7083c5b0b45b2d365366b812c4afb1383

handle transactions with byte length of 64

view details

push time in 9 days

Pull request review commentnodejs/node-gyp

gyp: update gyp to 0.2.0

-*.pyc

ditto, gyp-next, shouldn't impact us I think

ryzokuken

comment created time in 9 days

Pull request review commentnodejs/node-gyp

gyp: update gyp to 0.2.0

+# TODO: Enable os: windows-latest+# TODO: Enable python-version: 3.5+# TODO: Enable pytest --doctest-modules++name: Python_tests+on: [push, pull_request]+jobs:+  Python_tests:+    runs-on: ${{ matrix.os }}+    strategy:+      fail-fast: false+      max-parallel: 15+      matrix:+        os: [macos-latest, ubuntu-latest] # , windows-latest]+        python-version: [2.7, 3.6, 3.7, 3.8] # 3.5,+    steps:+      - uses: actions/checkout@v1

ditto, a critique for nodejs/gyp-next

ryzokuken

comment created time in 9 days

Pull request review commentnodejs/node-gyp

gyp: update gyp to 0.2.0

+[flake8]

@cclauss I think this critique should be taken over to gyp-next since we're just vendoring in that code, no?

ryzokuken

comment created time in 9 days

pull request commentnodejs/node-gyp

deps: update deps, match to npm@7, upgrade to tap 14

any reviews?

rvagg

comment created time in 9 days

PR closed nodejs/node-gyp

Don't use the "-2" flag with the py.exe launcher on Windows

<!-- Thank you for your pull request. Please review the below requirements.

Contributor guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

  • [x] npm install && npm test passes
  • [ ] tests are included <!-- Bug fixes and new features should include tests -->
  • [ ] documentation is changed or added
  • [x] commit message follows commit guidelines
Description of change

<!-- Provide a description of the change -->

Fixes #2130

The py.exe launcher for Windows helps to locate Python on the system.

The -2 or -3 flags can specify a major version to find. Now that node-gyp supports Python 3, it makes sense to not restrict the py.exe launcher to only finding Python 2. It would be advantageous to let it find Python 3 as well.

The py.exe launcher prefers newer (higher version number) Python when multiple versions are found. (i.e. it prefers Python 3 over Python 2 if both are available).

+4 -10

11 comments

2 changed files

DeeDeeG

pr closed time in 9 days

pull request commentnodejs/node-gyp

Don't use the "-2" flag with the py.exe launcher on Windows

excellent work, landed in c255ffb, will get it into v7.0.0 this week

DeeDeeG

comment created time in 9 days

push eventnodejs/node-gyp

DeeDeeG

commit sha c255ffbf6adc6b60cb39fa1aa40bfc8eb45f80ac

lib: drop "-2" flag for "py.exe" launcher Now that node-gyp supports both Python 2 and Python 3, We don't need to explicitly try to find only Python 2. Fixes: https://github.com/nodejs/node-gyp/issues/2130 Refs: https://docs.python.org/3/using/windows.html#launcher PR-URL: https://github.com/nodejs/node-gyp/pull/2131 Reviewed-By: Christian Clauss <cclauss@me.com> Reviewed-By: Rod Vagg <rod@vagg.org>

view details

push time in 9 days

issue closednodejs/node-gyp

Consider using the "py.exe" launcher to find Python 3 as well, not just for Python 2

<!-- Thank you for reporting an issue!

Remember, this issue tracker is for reporting issues ONLY with node-gyp.

If you have an issue installing a specific module, please file an issue on that module's issue tracker (npm issues modulename). Open issue here only if you are sure this is an issue with node-gyp, not with the module you are trying to build.

Fill out the form below. We probably won't investigate an issue that does not provide the basic information we require.

-->

  • Node Version: <!-- node -v and npm -v --> Applies to any versions of Node/NPM, but tested on Node 10.20.1 with npm 6.14.4
  • Platform: <!-- uname -a (UNIX), or systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"System Type" (Windows) --> This is about Windows, in general. Tested on Windows 10.
  • Compiler: <!-- cc -v (UNIX) or msbuild /version & cl (Windows) --> N/A; this is just about finding a Python binary. No compiler needed on the system to find a Python binary.
  • Module: <!-- what you tried to build/install --> Nothing, just did findPython = require(./lib/find-python) in a little standalone .js script to test Python detection.

<details><summary>My script ("fpy.js") (to be saved to/called from the node-gyp repo's main folder, like so: "node fpy.js".)</summary>

findPython = require('./lib/find-python')

findPython(null, function (err, found) {
  if (err) {
    console.error(err)
  } else {
    python = found
    console.log('python was found: ' + python)
  }
})

</details>

<details><summary>Verbose output (from npm or node-gyp):</summary>

node.exe ./fpy.js
ERR! find Python
ERR! find Python Python is not set from command line or npm configuration
ERR! find Python Python is not set from environment variable PYTHON
ERR! find Python checking if "python3" can be used
ERR! find Python - "python3" is not in PATH or produced an error
ERR! find Python checking if "python" can be used
ERR! find Python - "python" is not in PATH or produced an error
ERR! find Python checking if "python2" can be used
ERR! find Python - "python2" is not in PATH or produced an error
ERR! find Python checking if Python is C:\Python37\python.exe
ERR! find Python - "C:\Python37\python.exe" could not be run
ERR! find Python checking if Python is C:\Python27\python.exe
ERR! find Python - "C:\Python27\python.exe" could not be run
ERR! find Python checking if the py launcher can be used to find Python 2
ERR! find Python - "py.exe" is not in PATH or produced an error
ERR! find Python
ERR! find Python **********************************************************
ERR! find Python You need to install the latest version of Python.
ERR! find Python Node-gyp should be able to find and use Python. If not,
ERR! find Python you can try one of the following options:
ERR! find Python - Use the switch --python="C:\Path\To\python.exe"
ERR! find Python   (accepted by both node-gyp and npm)
ERR! find Python - Set the environment variable PYTHON
ERR! find Python - Set the npm configuration variable python:
ERR! find Python   npm config set python "C:\Path\To\python.exe"
ERR! find Python For more information consult the documentation at:
ERR! find Python https://github.com/nodejs/node-gyp#installation
ERR! find Python **********************************************************
ERR! find Python
Error: Could not find any Python installation to use
    at PythonFinder.fail (C:\Users\[User]\node-gyp\lib\find-python.js:307:47)
    at PythonFinder.runChecks (C:\Users\[User]\node-gyp\lib\find-python.js:136:21)
    at PythonFinder.<anonymous> (C:\Users\[User]\node-gyp\lib\find-python.js:205:18)
    at PythonFinder.execFileCallback (C:\Users\[User]\node-gyp\lib\find-python.js:271:16)
    at ChildProcess.exithandler (child_process.js:301:5)
    at ChildProcess.emit (events.js:198:13)
    at maybeClose (internal/child_process.js:982:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5)

</details>


<!-- Any further details -->

Intro, Background, and the Gist of it

Hi folks, I'm wondering if the node-gyp team would be interested in using the py.exe launcher to find not only/exclusively Python 2, like it does now, but potentially Python 3 as well.

(I just installed Python 3.8 from python.org, in the default install location, and node-gyp can't find it. py.exe can find it, though.)

Apparently, judging by the commit history, using the Python launcher strictly to find Python 2 dates back just over four years ago, to BEFORE node-gyp had any support for Python 3. From here: https://github.com/nodejs/node-gyp/pull/894 (The latest published version of node-gyp would have been v3.3.1 at the time, judging by the release history: https://github.com/nodejs/node-gyp/releases?after=v3.5.0)

Thus, I assume the justification for only finding Python 2 at that time would have been the following: "node-gyp can't work with Python 3, so finding Python 3 would be counter-productive! We must only find Python 2..." (That's no longer true, and I think it might be nice to find Python 3 with such a convenient helper/launcher like py.exe.)


About the py.exe Launcher, and the installation location of Python on Windows

The py.exe launcher is quite useful for finding Python. It claims to be able to find the version downloadable from python.org AND the Python downloadable from the Windows Store. Source: https://docs.python.org/3/using/windows.html#launcher) It comes with Python installers for Windows since Python 3.3.

The Python situation on Windows is a little odd now, because it seems it used to be saved under something like C:\Python[Maj[Min]\python.exe (for example: C:\Python37), but recent installers save to somewhere more like this: 'C:\Users\[User]\AppData\Local\Programs\Python\Python38-32' and in fact, the location can be customized during the install wizard. So it could end up anywhere, I guess.

I think the launcher might be the most reliable way to find Python on Windows these days. And in any case, it makes an excellent fallback. I only find that it is a shame that it isn't being used to find Python 3.

Indeed, going to Python.org, downloading Python 3.8.x and installing it will result in a Python installation that node-gyp can't find. I would like to approximate node-gyp's Python finding algorithm (or require its find-python.js file directly), but not being able to find the default install location from python.org seems somehow not right. I didn't want to re-implement what seems like a (small) oversight in the repo I'm working on.

I do think the Python from the Windows Store might end up on the path as python and/or python3, but I haven't tested or confirmed this.


Suggested Solution / Notes on an Implementation

Sorry I'm not very good with JS, or I'd whip up an implementation for a PR. But I think you could really just drop the -2 here, and update the comment above that, and that should do it.

(If that solution would be sufficient, or you'd like to see it run it through the CI tests and such, I would be GLAD to whip that up as a PR.)

From a quick read of the documentation page, the py.exe launcher seems to prefer Python 3 over Python 2, so just dropping the -2 flag might not be appropriate for for the node-gyp 5.x branch (which, from what I can see, generally prefers Python 2 over Python 3.)

closed time in 9 days

DeeDeeG

pull request commentnodejs/node-gyp

Don't use the "-2" flag with the py.exe launcher on Windows

all sounds good, and py.exe is an official Python thing too, correct? so we'd expect to see this installed by default on Windows systems with some version of Python installed? Has it been shipping for long enough to likely be everywhere that Python is on Windows?

DeeDeeG

comment created time in 10 days

issue commentnodejs/build

WG Membership - Larson Carter

A bunch of people in #node-build interact with it via Slack. I'm not sure what slack that is that has a bridge, I prefer just plain IRC for this, but that's an option too that others may be able to fill in.

larson-carter

comment created time in 10 days

push eventipld/js-ipld-bitcoin

Rod Vagg

commit sha df2563e3a16a8a170678b9e7abc67d29b866b3ee

add genesis block to fixtures and handle it properly

view details

push time in 11 days

push eventipld/js-ipld-bitcoin

Rod Vagg

commit sha 8ddbcaa97b14934f81571a8048584866f578a339

return rootCid from blockToCar

view details

push time in 11 days

pull request commentipld/js-dag-cbor

fix: make clean Uint8Array

Yeah, CI should be ignored for now, this is still using the .travis.yml from js-ipld-dag-cbor, I imagine Mikeal will pull in his standard Github Actions workflows which do test and publish. This PR is against his WIP branch which isn't quite ready for merging into master, although with this patch it's working for me in js-datastore-car.

rvagg

comment created time in 11 days

Pull request review commentipld/js-datastore-car

Switch to @ipld/multiformats

 async function readMultihash (reader) {   return multihash } -async function readCid (reader) {+async function readCid (multiformats, reader) {   const first = await reader.exactly(2)   if (first[0] === 0x12 && first[1] === 0x20) {     // cidv0 32-byte sha2-256     const bytes = await reader.exactly(34)     reader.seek(34)-    return new CID(bytes)+    return new multiformats.CID(0, 0x70, Uint8Array.from(bytes))

I made them all constants:

const CIDV0_BYTES = {
  SHA2_256: 0x12,
  LENGTH: 0x20,
  DAG_PB: 0x70
}
rvagg

comment created time in 11 days

push eventipld/js-datastore-car

Rod Vagg

commit sha f33413c41b6cc2b783a000316fb376b44ab2b963

turn cidv0 magic numbers into constants

view details

push time in 11 days

issue commentworkshopper/goingnative

Publish v2.0.8

Published.

Lots of good work in here @ccarruitero. Some notes as I was reviewing the diff since the last release (mine, January 2016!).

  • I assume standard --fix was used to help get the formatting wrangled. One problem that it doesn't handle well is converting single-line if, if/else, if/elseif/else's to braced versions. There's some funny looking very long lines, the best one is probably in exercises/mission_possible_part_three/exercise.js
  • You should add yourself to credits.txt
  • .jshintrc can go

Thanks for putting in the effort here so far, I'm sure it'll be appreciated.

ccarruitero

comment created time in 11 days

issue commentnodejs/admin

Transfer canterberry/nodejs-keys into nodejs/keys

What is this existing nodejs/keys repo? Can someone with org access please definitively confirm that such a thing exists and what it contains? I'm not aware of it ever existing and have only been without org admin access for a year or so now. The secrets repo is nodejs-private/secrets. I don't believe we're storing GPG private keys for anything anywhere, I know for sure we're not in secrets. Our policy to date has for people who access nodejs-private/secrets (and releasers who sign releases) to maintain their own GPG keys and we just use public keys for encrypting shared secrets so they can be accessed by certain individuals only (see https://github.com/ConradIrwin/dotgpg for our main tool).

canterberry

comment created time in 11 days

pull request commentipld/specs

Introduce "EDITING.md".

ok

I'm hesitant introducing a new top level document. It's also too long and will likely not be read by most people approaching this repo wanting to make changes. It either needs a TL;DR at the top, or be compacted a bit more. If this lands, maybe I'll have a go at squishing it down.

warpfork

comment created time in 11 days

Pull request review commentipld/specs

Introduce "EDITING.md".

+Editing+=======++Editing specifications is hard!  Here are some partial guidelines and rules-of-thumb.++- [Communicate!](#communicate)+- [Make sure your change fits](#make-sure-your-change-fits)+  - ... especially if it's a [semantic change](#semantic-changes)+- [Use Exploration Reports](#use-exploration-reports)+- Heed the [stylistic preferences](#stylistic-preferences)+++Communicate!+------------++There's lots of ways to communicate with the IPLD team and community.++- IRC/Matrix/Discord: FIXME LINK+- All our development is in the open on GitHub:+  - This repo is https://github.com/ipld/specs/ !+  - Other work exists in other repos the same org: https://github.com/ipld/+  - GitHub issues and Pull Requests work just fine.+- We have a (mostly) weekly meeting on Zoom: FIXME LINK++If you'd like to discuss something before proposing a change,+there's lots of venues that can host a conversation.++Escalating in levels of formality can be a good idea:+e.g., ask questions on IRC/Matrix/Discord or in an issue first;+then work on PRs later if an idea seems worth pursuing.+++Make sure your change fits+--------------------------++### textual changes++Small textual changes can be made by Pull Request easily.  Go for it!++(Since the amount of effort involved in creating and reviewing this kind of+change is minimal for both sides, it's easier to just send it than to ask permission.)++### semantic changes++_Editing specifications is **really** hard!_++We welcome everyone's effort in refining the specs to be the best they can be.+At the same time, be warned that it's a serious investment of energy!+As shepherds of what we hope is a stable process, we have to be careful and+deliberate when considering what changes to accept.++A lot of decisions in specifications involve looking out for long-range effects+and non-obvious implications.  We try to document these considerations,+but also in many documents try to strike a balance with brevity.+Hitting a perfect stride with this is arguably objectively not possible;+it's pretty much guaranteed that in your reading, you'll encounter a document+that doesn't sufficiently explain all the "why isn't this different" branches.++Specs deserve an extra long think before proposing changes.+[Chesterton's fence](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence)+applies in _spades_ to specifications.++Some common reasons things may be less tenable than they first appear:++- Does this feature interact with other features in complex ways?+- Does this presence of this feature with other features make the system overall+  more difficult to reason about?+- Does adding this feature create an undue burden to library implementers?+- Does this feature interact exceptionally poorly with any major programming languages?+- Does this feature interact exceptionally poorly with any common serialization formats?+  (Would it shift any common formats to be more 'incomplete', e.g. unable to+  fully represent data from the Data Model or from other formats?)+- Does this feature introduce potentially unbounded or difficult-to-estimate+  time or memory costs when implemented?+- Does this feature make canonicalization or hashing of data exceptionally+  more difficult, confusing, or error-prone?+- Does this change add too much verbosity to a detail that we don't want to emphasize?+- Does this change remove explicitness and reduce focus from something we _do want_ to draw attention to?++If you've considered all these things, and still think that you've got a good+change in mind, then thank you for the depth of your thoughts so far!+Go ahead and either create an issue on github, or hoist a PR, or move forward+by writing up an [exploration report](#use-exploration-reports) to help+hone further discussion, or, simply find us and start a conversation on+the `#ipld` channel on freenode IRC!+++Use Exploration Reports+-----------------------++One way to make progress in designing something or discussing a tricky issue+is to make an "exploration report".++The key point of an "exploration report" is to document some thinking+and collate notes about a complex topic, *without* jumping straight to a+proposed solution.  This is useful because we can readily preserve the notes,+even if the idea in question doesn't pan out or can't be completed in one joust.++We've got a bunch of these -- and more description of what that concept is --+in the [`./design/history/exploration-reports`](./design/history/exploration-reports)+directory.  You can also make exploration reports as gists, or other kinds of+documents, or even issues in github; whatever creates the least burden is best.++Exploration reports are almost guaranteed to be a good idea if proposing+any kind of [semantic change](#semantic-changes).+++Stylistic Preferences+---------------------++### headings++Be careful with headings -- they should look good as links.+Being able to link deeply into a spec document is every bit as important+as being able to read it from top to bottom.++Be very careful not to have headings that are repeated; this makes linking to that heading impossible.+(If you feel that repeated headings are still visually good formating,+consider if a `"**bold text**: subject details"` approach fits.+Because this doesn't try to produce links, it's not a problem to repeat the bold component.+But, by the other side of the same coin, _it can't be linked to_; be mindful of the concession.)++Don't put redundant information or parenthetical remarks in a heading;+it rarely comes out legible in the resulting links.+For example, "#block-layer" is preferable to "#block-layer-layer-0".+Clarifications and secondary terminology variations are better expressed in the body text+than jammed into the heading and adding tongue-twisters to links.++### linking++The preferred linking format depends on what you're linking to and how far away it is.+In general, the aim is to make editing easier in the long run.++- The preferred link syntax depends on how distant the target is.+  - Links within a document should use bare hashtags -- `[text](#heading)`.+  - Links to documents in the same folder should use relative paths -- `[text](./file.md#heading)`.+  - Links to documents elsewhere in the repo should use rooted paths -- `[text](/full/path.md#heading)`.+    (This makes repo-wide reorganizations and searching easier; a series of "../../.." can be inconvenient to work with, and are difficult to verify by eye.)+  - Links to content outside the repo should of course use the full URL.+- Links should include the file extension for '.md' files.+  (It will be stripped by our site publish tooling, but is necessary for links to work well within github's markdown processing.)+- When linking to source code: use the full commit hash!  (Github has a handy `'y'` shortcut for this; use it!)+  - If linking to specific line numbers, a full commit hash is an absolute requirement.  It is otherwise far too easy to have "working" but semantically invalid links.+  - If aiming to whole packages or high level documents in other repos, it _may_ be viable to link to the master branch.  But be judicious.++### todos++Some documents have "TODO"s within them.++This isn't necessarily something to emulate when submitting new changes.+Documentation that's done is much better than documentation that's to-do!++Whether or not a "TODO" is acceptable in a PR depends:++- How critical is it?+  - if it's a "TODO" in critical parts of system definition?  No.  (Consider re-writing what you're working on as an [exploration report](#use-exploration-reports) instead!)+  - If it's a "TODO" stating that better description is still wanted?  Maybe.  If it's useful in context to state that, and a legitimate open ask to the community at large when they read the document, we can consider merging it.+- How sure are we it can be addressed?+  - If it's coming from someone with known long-term investment in the project?  Maybe; we can have a reasonable expectation the same person will either come back to finish it, or at least has a good idea about whether or not it will be possible for other contributors to fill the missing piece.+  - If it's coming from someone making their first contributions?  Unfortunately, we have to set a higher bar here.  It's harder to know whether follow-up will come, and so its more risky to bet that it will.++None of these factors have a clear yes-or-no answer (nor are they intended to),+so, ultimately, expect this to be resolved by discussion during review.+By default?  Fewer "TODO"s are better: avoid introducing them if you can.++### line breaks++Linebreaks are non-semantic in markdown, so where to break lines is up to you.+We don't enforce any strict line-length limit.

for now ... I like the vicinity rule but I think this is an area we should work on because we have something approaching "line break by feel" in this repo.

warpfork

comment created time in 11 days

Pull request review commentipld/specs

Introduce "EDITING.md".

+Editing+=======++Editing specifications is hard!  Here are some partial guidelines and rules-of-thumb.++- [Communicate!](#communicate)+- [Make sure your change fits](#make-sure-your-change-fits)+  - ... especially if it's a [semantic change](#semantic-changes)+- [Use Exploration Reports](#use-exploration-reports)+- Heed the [stylistic preferences](#stylistic-preferences)+++Communicate!+------------++There's lots of ways to communicate with the IPLD team and community.++- IRC/Matrix/Discord: FIXME LINK+- All our development is in the open on GitHub:+  - This repo is https://github.com/ipld/specs/ !+  - Other work exists in other repos the same org: https://github.com/ipld/+  - GitHub issues and Pull Requests work just fine.+- We have a (mostly) weekly meeting on Zoom: FIXME LINK++If you'd like to discuss something before proposing a change,+there's lots of venues that can host a conversation.++Escalating in levels of formality can be a good idea:+e.g., ask questions on IRC/Matrix/Discord or in an issue first;+then work on PRs later if an idea seems worth pursuing.+++Make sure your change fits+--------------------------++### textual changes++Small textual changes can be made by Pull Request easily.  Go for it!++(Since the amount of effort involved in creating and reviewing this kind of+change is minimal for both sides, it's easier to just send it than to ask permission.)++### semantic changes++_Editing specifications is **really** hard!_++We welcome everyone's effort in refining the specs to be the best they can be.+At the same time, be warned that it's a serious investment of energy!+As shepherds of what we hope is a stable process, we have to be careful and+deliberate when considering what changes to accept.++A lot of decisions in specifications involve looking out for long-range effects+and non-obvious implications.  We try to document these considerations,+but also in many documents try to strike a balance with brevity.+Hitting a perfect stride with this is arguably objectively not possible;+it's pretty much guaranteed that in your reading, you'll encounter a document+that doesn't sufficiently explain all the "why isn't this different" branches.++Specs deserve an extra long think before proposing changes.+[Chesterton's fence](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence)

I love that you've inserted this reference. Sadly the implications are usually lost on most people who wade straight in on the deep end though.

warpfork

comment created time in 11 days

Pull request review commentipld/specs

Introduce "EDITING.md".

+Editing+=======++Editing specifications is hard!  Here are some partial guidelines and rules-of-thumb.++- [Communicate!](#communicate)+- [Make sure your change fits](#make-sure-your-change-fits)+  - ... especially if it's a [semantic change](#semantic-changes)+- [Use Exploration Reports](#use-exploration-reports)+- Heed the [stylistic preferences](#stylistic-preferences)+++Communicate!+------------++There's lots of ways to communicate with the IPLD team and community.++- IRC/Matrix/Discord: FIXME LINK+- All our development is in the open on GitHub:+  - This repo is https://github.com/ipld/specs/ !+  - Other work exists in other repos the same org: https://github.com/ipld/+  - GitHub issues and Pull Requests work just fine.+- We have a (mostly) weekly meeting on Zoom: FIXME LINK++If you'd like to discuss something before proposing a change,+there's lots of venues that can host a conversation.++Escalating in levels of formality can be a good idea:+e.g., ask questions on IRC/Matrix/Discord or in an issue first;+then work on PRs later if an idea seems worth pursuing.+++Make sure your change fits+--------------------------++### textual changes

s/# t/# T

can we have sentence case for titles at least?

warpfork

comment created time in 11 days

Pull request review commentipld/specs

Introduce "EDITING.md".

+Editing+=======++Editing specifications is hard!  Here are some partial guidelines and rules-of-thumb.++- [Communicate!](#communicate)+- [Make sure your change fits](#make-sure-your-change-fits)+  - ... especially if it's a [semantic change](#semantic-changes)+- [Use Exploration Reports](#use-exploration-reports)+- Heed the [stylistic preferences](#stylistic-preferences)+++Communicate!+------------++There's lots of ways to communicate with the IPLD team and community.++- IRC/Matrix/Discord: FIXME LINK+- All our development is in the open on GitHub:+  - This repo is https://github.com/ipld/specs/ !+  - Other work exists in other repos the same org: https://github.com/ipld/+  - GitHub issues and Pull Requests work just fine.+- We have a (mostly) weekly meeting on Zoom: FIXME LINK

https://github.com/ipld/team-mgmt#weekly-call

warpfork

comment created time in 11 days

more