Unable to Install NPM - GYP Error

Node Version: 7.17.0
Platform: 5.8.0-53-generic #60~20.04.1-Ubuntu SMP Thu May 6 09:52:46 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Compiler:Using built-in specs. COLLECT_GCC=cc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.3.0-17ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-HskZEa/gcc-9-9.3.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
Module: npm

Verbose output (from npm or node-gyp):
kitty4962@kitty4962-870-115se:~/JMIR/cdp$ npm install npm WARN EBADENGINE Unsupported engine { package<EMAIL_ADDRESS>npm WARN EBADENGINE   required: { node: '>= v10.23.3' }, npm WARN EBADENGINE   current: { node: 'v10.19.0', npm: '7.17.0' } } npm WARN deprecated<EMAIL_ADDRESS>This module has moved and is now available at @hapi/topo. Please update your dependencies as this version is no longer maintained an may contain bugs and security issues. npm WARN deprecated<EMAIL_ADDRESS>request-promise-native has been deprecated because it extends the now deprecated request package, see https://github.com/request/request/issues/3142 npm WARN deprecated<EMAIL_ADDRESS>Please see https://github.com/lydell/urix#deprecated npm WARN deprecated<EMAIL_ADDRESS>this library is no longer supported npm WARN deprecated<EMAIL_ADDRESS>This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial). npm WARN deprecated<EMAIL_ADDRESS>This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial). npm WARN deprecated<EMAIL_ADDRESS>https://github.com/lydell/resolve-url#deprecated npm WARN deprecated<EMAIL_ADDRESS>This module has moved and is now available at @hapi/hoek. Please update your dependencies as this version is no longer maintained an may contain bugs and security issues. npm WARN deprecated<EMAIL_ADDRESS>No longer maintained. npm WARN deprecated<EMAIL_ADDRESS>No longer maintained. npm WARN deprecated<EMAIL_ADDRESS>No longer maintained. npm WARN deprecated<EMAIL_ADDRESS>Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies. npm WARN deprecated<EMAIL_ADDRESS>This loader has been deprecated. Please use eslint-webpack-plugin npm WARN deprecated<EMAIL_ADDRESS>Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details. npm WARN deprecated<EMAIL_ADDRESS>babel-eslint is now @babel/eslint-parser. This package will no longer receive updates. npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142 npm WARN deprecated<EMAIL_ADDRESS>This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial). npm WARN deprecated<EMAIL_ADDRESS>You can find the new Popper v2 at @popperjs/core, this package is dedicated to the legacy v1 npm WARN deprecated<EMAIL_ADDRESS><EMAIL_ADDRESS>is no longer maintained and not recommended for usage due to the number of issues. Because of the V8 engine whims, feature detection in old core-js versions could cause a slowdown up to 100x even if nothing is polyfilled. Please, upgrade your dependencies to the actual version of core-js. npm ERR! code 1 npm ERR! path /home/kitty4962/JMIR/cdp/node_modules/node-expat npm ERR! command failed npm ERR! command sh -c node-gyp rebuild npm ERR! gyp info it worked if it ends with ok npm ERR! gyp info using<EMAIL_ADDRESS>npm ERR! gyp info using<EMAIL_ADDRESS>| linux | x64 npm ERR! gyp ERR! configure error  npm ERR! gyp ERR! stack Error: Command failed: /usr/bin/python -c import sys; print "%s.%s.%s" % sys.version_info[:3]; npm ERR! gyp ERR! stack   File "<string>", line 1 npm ERR! gyp ERR! stack     import sys; print "%s.%s.%s" % sys.version_info[:3]; npm ERR! gyp ERR! stack                                ^ npm ERR! gyp ERR! stack SyntaxError: invalid syntax npm ERR! gyp ERR! stack  npm ERR! gyp ERR! stack     at ChildProcess.exithandler (child_process.js:294:12) npm ERR! gyp ERR! stack     at ChildProcess.emit (events.js:198:13) npm ERR! gyp ERR! stack     at maybeClose (internal/child_process.js:982:16) npm ERR! gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5) npm ERR! gyp ERR! System Linux 5.8.0-53-generic npm ERR! gyp ERR! command "/usr/bin/node" "/home/kitty4962/JMIR/cdp/node_modules/.bin/node-gyp" "rebuild" npm ERR! gyp ERR! cwd /home/kitty4962/JMIR/cdp/node_modules/node-expat npm ERR! gyp ERR! node -v v10.19.0 npm ERR! gyp ERR! node-gyp -v v3.8.0 npm ERR! gyp ERR! not ok
Paste your log here, between the backticks. It can be:

npm --verbose output,
or contents of npm-debug.log,
or output of node-gyp rebuild --verbose.
Include the command you were trying to run.

This should look like this:

The current release of node-gyp is v8.1.0 but the log above says:

gyp ERR! node-gyp -v v3.8.0

Please use https://github.com/nodejs/node-gyp/wiki/Updating-npm's-bundled-node-gyp to upgrade to the current node-gyp.

I ran the command as specified in the "Updating npm's bundle document" and then ran "npm install" I got this error.
npm ERR! code 1
npm ERR! path /home/kitty4962/JMIR/cdp/node_modules/node-expat
npm ERR! command failed
npm ERR! command sh -c node-gyp rebuild
npm ERR! gyp info it worked if it ends with ok
npm ERR! gyp info using<EMAIL_ADDRESS>npm ERR! gyp info using<EMAIL_ADDRESS>| linux | x64
npm ERR! gyp ERR! configure error
npm ERR! gyp ERR! stack Error: Command failed: /usr/bin/python -c import sys; print "%s.%s.%s" % sys.version_info[:3];
npm ERR! gyp ERR! stack   File "", line 1
npm ERR! gyp ERR! stack     import sys; print "%s.%s.%s" % sys.version_info[:3];
npm ERR! gyp ERR! stack                                ^
npm ERR! gyp ERR! stack SyntaxError: invalid syntax
npm ERR! gyp ERR! stack
npm ERR! gyp ERR! stack     at ChildProcess.exithandler (child_process.js:294:12)
npm ERR! gyp ERR! stack     at ChildProcess.emit (events.js:198:13)
npm ERR! gyp ERR! stack     at maybeClose (internal/child_process.js:982:16)
npm ERR! gyp ERR! stack     at Socket.stream.socket.on (internal/child_process.js:389:11)
npm ERR! gyp ERR! stack     at Socket.emit (events.js:198:13)
npm ERR! gyp ERR! stack     at Pipe._handle.close (net.js:607:12)
npm ERR! gyp ERR! System Linux 5.8.0-53-generic
npm ERR! gyp ERR! command "/usr/bin/node" "/home/kitty4962/JMIR/cdp/node_modules/.bin/node-gyp" "rebuild"
npm ERR! gyp ERR! cwd /home/kitty4962/JMIR/cdp/node_modules/node-expat
npm ERR! gyp ERR! node -v v10.19.0
npm ERR! gyp ERR! node-gyp -v v3.8.0
npm ERR! gyp ERR! not ok

the log output above still says:

gyp ERR! node-gyp -v v3.8.0

I have the same issue and after executing the commands here the node-gyp version didn't change.
npm ERR! gyp ERR!  System Windows_NT 10.0.19042
npm ERR! gyp ERR! command "C:\Program Files\nodejs\node.exe" "D:\Telechargements\xtermelectron\node_modules\node-gyp\bin\node-gyp.js" "rebuild"
npm ERR! gyp ERR! cwd D:\Telechargements\xtermelectron\node_modules\node-pty
npm ERR! gyp ERR! node -v v16.3.0
npm ERR! gyp ERR! node-gyp -v v6.1.0
npm ERR! gyp ERR! This is a bug in node-gyp.
npm ERR! gyp ERR! Try to update node-gyp and file an Issue if it does not help:
npm ERR! gyp ERR!     https://github.com/nodejs/node-gyp/issues

@DeeDeeG Do you have any hints on why the node-gyp upgrades are not working?

Hmm.
I think in both cases the node-gyp is a project-local copy, not the copy bundled with npm. I say this based on the paths.

/home/. . ./cdp/node_modules/.bin/node-gyp/.bin/node-gyp
D:\Telechargements\xtermelectron\node_modules\node-gyp\bin\node-gyp.js

Folks can use a similar technique as described in the wiki...

The first user @ElizabethD3 should be able to cd into their cdp project directory, and then do npm install node-gyp@latest.
The second user @03h7 should be able to cd into the Telechargements\xtermelectron directory and then npm install node-gyp@latest.

(I am really not sure why there are such old copies of node-gyp installed locally to these projects. If that's even what's happening here...)

@DeeDeeG  I tried your steps repeating to npm, then in npm-life-cycle foders with
sudo npm install node-gyp@latest
Now it is @latest , but still its incompatible?!
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /geojson.io/node_modules/contextify
gyp ERR! node -v v14.16.1
gyp ERR! node-gyp -v v8.1.0
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>install: node-gyp rebuild

Why https://www.npmjs.com/package/contextify v0.1.15 instead of v1.0.0?

Not sure, its  a dependency of another and so on . Tried @latest - still doesn't install , throwing same error.
gyp ERR! node -v v14.16.1
gyp ERR! node-gyp -v v8.1.0
gyp ERR! not ok

Please provide the entire error log.

geojson.io % npm i
npm WARN deprecated<EMAIL_ADDRESS>Use topojson-client, topojson-server or topojson-simplify directly.
npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated<EMAIL_ADDRESS>this library is no longer supported
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.

<EMAIL_ADDRESS>install /Users/geojson.io/node_modules/contextify
node-gyp rebuild

CXX(target) Release/obj.target/contextify/src/contextify.o
../src/contextify.cc:52:53: error: too few arguments to function call, single argument 'context' was not specified
target->Set(className, ljsTmpl->GetFunction());
~~~~~~~~~~~~~~~~~~~~ ^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:6482:46: note: 'GetFunction' declared here
V8_WARN_UNUSED_RESULT MaybeLocal GetFunction(
^
../src/contextify.cc:62:74: error: too few arguments to function call, single argument 'context' was not specified
ContextifyContext* ctx = new ContextifyContext(info[0]->ToObject());
~~~~~~~~~~~~~~~~~ ^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2822:44: note: 'ToObject' declared here
V8_WARN_UNUSED_RESULT MaybeLocal ToObject(
^
../src/contextify.cc:77:48: error: too few arguments to function call, single argument 'context' was not specified
Local code = info[0]->ToString();
~~~~~~~~~~~~~~~~~ ^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2810:44: note: 'ToString' declared here
V8_WARN_UNUSED_RESULT MaybeLocal ToString(
^
../src/contextify.cc:83:51: error: too few arguments to function call, single argument 'context' was not specified
ScriptOrigin origin(info[1]->ToString());
~~~~~~~~~~~~~~~~~ ^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2810:44: note: 'ToString' declared here
V8_WARN_UNUSED_RESULT MaybeLocal ToString(
^
../src/contextify.cc:126:45: error: too few arguments to function call, single argument 'context' was not specified
constructor.Reset(tmpl->GetFunction());
~~~~~~~~~~~~~~~~~ ^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:6482:46: note: 'GetFunction' declared here
V8_WARN_UNUSED_RESULT MaybeLocal GetFunction(
^
../src/contextify.cc:131:56: error: no matching member function for call to 'NewInstance'
Local wrapper = Nan::New(constructor)->NewInstance();
~~~~~~~~~~~~~^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:4454:44: note: candidate function not viable: requires single argument 'context', but no arguments were provided
V8_WARN_UNUSED_RESULT MaybeLocal NewInstance(
^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:4451:44: note: candidate function not viable: requires 3 arguments, but 0 were provided
V8_WARN_UNUSED_RESULT MaybeLocal NewInstance(
^
../src/contextify.cc:140:16: error: no member named 'SetHiddenPrototype' in 'v8::FunctionTemplate'
ftmpl->SetHiddenPrototype(true);
~~~~~~~^
../src/contextify.cc:150:16: error: no member named 'SetAccessCheckCallbacks' in 'v8::ObjectTemplate'
otmpl->SetAccessCheckCallbacks(GlobalPropertyNamedAccessCheck,
~~~~~~~^
../src/contextify.cc:176:52: error: too few arguments to function call, single argument 'context' was not specified
Local data = info.Data()->ToObject();
~~~~~~~~~~~~~~~~~~~~~ ^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2822:44: note: 'ToObject' declared here
V8_WARN_UNUSED_RESULT MaybeLocal ToObject(
^
../src/contextify.cc:182:80: error: too few arguments to function call, expected 2, have 1
Local rv = Nan::New(ctx->sandbox)->GetRealNamedProperty(property);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~         ^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3988:43: note: 'GetRealNamedProperty' declared here
V8_WARN_UNUSED_RESULT MaybeLocal GetRealNamedProperty(
^
../src/contextify.cc:192:52: error: too few arguments to function call, single argument 'context' was not specified
Local data = info.Data()->ToObject();
~~~~~~~~~~~~~~~~~~~~~ ^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2822:44: note: 'ToObject' declared here
V8_WARN_UNUSED_RESULT MaybeLocal ToObject(
^
../src/contextify.cc:198:33: error: no matching member function for call to 'Set'
Nan::New(ctx->sandbox)->Set(property, value);
~~~~~~~~~~~~~~~~~~~~~~^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3670:37: note: candidate function not viable: requires 3 arguments, but 2 were provided
V8_WARN_UNUSED_RESULT Maybe Set(Local context,
^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3673:37: note: candidate function not viable: requires 3 arguments, but 2 were provided
V8_WARN_UNUSED_RESULT Maybe Set(Local context, uint32_t index,
^
../src/contextify.cc:203:52: error: too few arguments to function call, single argument 'context' was not specified
Local data = info.Data()->ToObject();
~~~~~~~~~~~~~~~~~~~~~ ^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2822:44: note: 'ToObject' declared here
V8_WARN_UNUSED_RESULT MaybeLocal ToObject(
^
../src/contextify.cc:209:67: error: too few arguments to function call, expected 2, have 1
if (!Nan::New(ctx->sandbox)->GetRealNamedProperty(property).IsEmpty() ||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~         ^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3988:43: note: 'GetRealNamedProperty' declared here
V8_WARN_UNUSED_RESULT MaybeLocal GetRealNamedProperty(
^
../src/contextify.cc:210:71: error: too few arguments to function call, expected 2, have 1
!Nan::New(ctx->proxyGlobal)->GetRealNamedProperty(property).IsEmpty()) {
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~         ^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3988:43: note: 'GetRealNamedProperty' declared here
V8_WARN_UNUSED_RESULT MaybeLocal GetRealNamedProperty(
^
../src/contextify.cc:218:52: error: too few arguments to function call, single argument 'context' was not specified
Local data = info.Data()->ToObject();
~~~~~~~~~~~~~~~~~~~~~ ^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2822:44: note: 'ToObject' declared here
V8_WARN_UNUSED_RESULT MaybeLocal ToObject(
^
../src/contextify.cc:224:48: error: no matching member function for call to 'Delete'
bool success = Nan::New(ctx->sandbox)->Delete(property);
~~~~~~~~~~~~~~~~~~~~^~
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3755:37: note: candidate function not viable: requires 2 arguments, but 1 was provided
V8_WARN_UNUSED_RESULT Maybe Delete(Local context,
^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3760:37: note: candidate function not viable: requires 2 arguments, but 1 was provided
V8_WARN_UNUSED_RESULT Maybe Delete(Local context,
^
../src/contextify.cc:229:52: error: too few arguments to function call, single argument 'context' was not specified
Local data = info.Data()->ToObject();
~~~~~~~~~~~~~~~~~~~~~ ^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2822:44: note: 'ToObject' declared here
V8_WARN_UNUSED_RESULT MaybeLocal ToObject(
^
../src/contextify.cc:237:59: error: no matching member function for call to 'GetPropertyNames'
info.GetReturnValue().Set(Nan::New(ctx->sandbox)->GetPropertyNames());
~~~~~~~~~~^~
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3825:43: note: candidate function not viable: requires single argument 'context', but no arguments were provided
V8_WARN_UNUSED_RESULT MaybeLocal GetPropertyNames(
^
/Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3827:43: note: candidate function not viable: requires at least 4 arguments, but 0 were provided
V8_WARN_UNUSED_RESULT MaybeLocal GetPropertyNames(
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make: *** [Release/obj.target/contextify/src/contextify.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/node_modules/node-gyp/lib/build.js:194:23)
gyp ERR! stack     at ChildProcess.emit (events.js:315:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:277:12)
gyp ERR! System Darwin 20.4.0
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/geojson.io/node_modules/contextify
gyp ERR! node -v v14.16.1
gyp ERR! node-gyp -v v8.1.0
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>install: node-gyp rebuild
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR!      /Users/.npm/_logs/2021-06-21T18_35_28_864Z-debug.log

contextify is umaintained and last released three years ago: https://www.npmjs.com/package/contextify
That predates Node.js 14 -- the module has not been updated to work on newer versions of Node.js.
Note that contextify's README states that it's no longer required since Node.js 0.12 (that's 0.12 and not 12.x) so whatever it is you're trying to install would need to be updated, or you're stuck on older unsupported versions of Node.js.

@ElizabethD3 Can this issue be closed?

geojson.io % npm i npm WARN deprecated<EMAIL_ADDRESS>Use topojson-client, topojson-server or topojson-simplify directly. npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see request/request#3142 npm WARN deprecated<EMAIL_ADDRESS>this library is no longer supported npm WARN deprecated<EMAIL_ADDRESS>Please upgrade to version 7 or higher. Older versions may use Math.random() in certain circumstances, which is known to be problematic. See https://v8.dev/blog/math-random for details.

<EMAIL_ADDRESS>install /Users/geojson.io/node_modules/contextify
node-gyp rebuild

CXX(target) Release/obj.target/contextify/src/contextify.o ../src/contextify.cc:52:53: error: too few arguments to function call, single argument 'context' was not specified target->Set(className, ljsTmpl->GetFunction()); ~~~~~~~~~~~~~~~~~~~~ ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:6482:46: note: 'GetFunction' declared here V8_WARN_UNUSED_RESULT MaybeLocal GetFunction( ^ ../src/contextify.cc:62:74: error: too few arguments to function call, single argument 'context' was not specified ContextifyContext* ctx = new ContextifyContext(info[0]->ToObject()); ~~~~~~~~~~~~~~~~~ ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2822:44: note: 'ToObject' declared here V8_WARN_UNUSED_RESULT MaybeLocal ToObject( ^ ../src/contextify.cc:77:48: error: too few arguments to function call, single argument 'context' was not specified Local code = info[0]->ToString(); ~~~~~~~~~~~~~~~~~ ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2810:44: note: 'ToString' declared here V8_WARN_UNUSED_RESULT MaybeLocal ToString( ^ ../src/contextify.cc:83:51: error: too few arguments to function call, single argument 'context' was not specified ScriptOrigin origin(info[1]->ToString()); ~~~~~~~~~~~~~~~~~ ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2810:44: note: 'ToString' declared here V8_WARN_UNUSED_RESULT MaybeLocal ToString( ^ ../src/contextify.cc:126:45: error: too few arguments to function call, single argument 'context' was not specified constructor.Reset(tmpl->GetFunction()); ~~~~~~~~~~~~~~~~~ ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:6482:46: note: 'GetFunction' declared here V8_WARN_UNUSED_RESULT MaybeLocal GetFunction( ^ ../src/contextify.cc:131:56: error: no matching member function for call to 'NewInstance' Local wrapper = Nan::New(constructor)->NewInstance(); ~~~~~~~~~~~~~^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:4454:44: note: candidate function not viable: requires single argument 'context', but no arguments were provided V8_WARN_UNUSED_RESULT MaybeLocal NewInstance( ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:4451:44: note: candidate function not viable: requires 3 arguments, but 0 were provided V8_WARN_UNUSED_RESULT MaybeLocal NewInstance( ^ ../src/contextify.cc:140:16: error: no member named 'SetHiddenPrototype' in 'v8::FunctionTemplate' ftmpl->SetHiddenPrototype(true); ~~~~~~~^ ../src/contextify.cc:150:16: error: no member named 'SetAccessCheckCallbacks' in 'v8::ObjectTemplate' otmpl->SetAccessCheckCallbacks(GlobalPropertyNamedAccessCheck, ~~~~~~~^ ../src/contextify.cc:176:52: error: too few arguments to function call, single argument 'context' was not specified Local data = info.Data()->ToObject(); ~~~~~~~~~~~~~~~~~~~~~ ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2822:44: note: 'ToObject' declared here V8_WARN_UNUSED_RESULT MaybeLocal ToObject( ^ ../src/contextify.cc:182:80: error: too few arguments to function call, expected 2, have 1 Local rv = Nan::New(ctx->sandbox)->GetRealNamedProperty(property); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3988:43: note: 'GetRealNamedProperty' declared here V8_WARN_UNUSED_RESULT MaybeLocal GetRealNamedProperty( ^ ../src/contextify.cc:192:52: error: too few arguments to function call, single argument 'context' was not specified Local data = info.Data()->ToObject(); ~~~~~~~~~~~~~~~~~~~~~ ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2822:44: note: 'ToObject' declared here V8_WARN_UNUSED_RESULT MaybeLocal ToObject( ^ ../src/contextify.cc:198:33: error: no matching member function for call to 'Set' Nan::New(ctx->sandbox)->Set(property, value); ~~~~~~~~~~~~~~~~~~~~~~^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3670:37: note: candidate function not viable: requires 3 arguments, but 2 were provided V8_WARN_UNUSED_RESULT Maybe Set(Local context, ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3673:37: note: candidate function not viable: requires 3 arguments, but 2 were provided V8_WARN_UNUSED_RESULT Maybe Set(Local context, uint32_t index, ^ ../src/contextify.cc:203:52: error: too few arguments to function call, single argument 'context' was not specified Local data = info.Data()->ToObject(); ~~~~~~~~~~~~~~~~~~~~~ ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2822:44: note: 'ToObject' declared here V8_WARN_UNUSED_RESULT MaybeLocal ToObject( ^ ../src/contextify.cc:209:67: error: too few arguments to function call, expected 2, have 1 if (!Nan::New(ctx->sandbox)->GetRealNamedProperty(property).IsEmpty() || ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3988:43: note: 'GetRealNamedProperty' declared here V8_WARN_UNUSED_RESULT MaybeLocal GetRealNamedProperty( ^ ../src/contextify.cc:210:71: error: too few arguments to function call, expected 2, have 1 !Nan::New(ctx->proxyGlobal)->GetRealNamedProperty(property).IsEmpty()) { ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3988:43: note: 'GetRealNamedProperty' declared here V8_WARN_UNUSED_RESULT MaybeLocal GetRealNamedProperty( ^ ../src/contextify.cc:218:52: error: too few arguments to function call, single argument 'context' was not specified Local data = info.Data()->ToObject(); ~~~~~~~~~~~~~~~~~~~~~ ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2822:44: note: 'ToObject' declared here V8_WARN_UNUSED_RESULT MaybeLocal ToObject( ^ ../src/contextify.cc:224:48: error: no matching member function for call to 'Delete' bool success = Nan::New(ctx->sandbox)->Delete(property); ~~~~~~~~~~~~~~~~~~~~^~ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3755:37: note: candidate function not viable: requires 2 arguments, but 1 was provided V8_WARN_UNUSED_RESULT Maybe Delete(Local context, ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3760:37: note: candidate function not viable: requires 2 arguments, but 1 was provided V8_WARN_UNUSED_RESULT Maybe Delete(Local context, ^ ../src/contextify.cc:229:52: error: too few arguments to function call, single argument 'context' was not specified Local data = info.Data()->ToObject(); ~~~~~~~~~~~~~~~~~~~~~ ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:2822:44: note: 'ToObject' declared here V8_WARN_UNUSED_RESULT MaybeLocal ToObject( ^ ../src/contextify.cc:237:59: error: no matching member function for call to 'GetPropertyNames' info.GetReturnValue().Set(Nan::New(ctx->sandbox)->GetPropertyNames()); ~~~~~~~~~~^~ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3825:43: note: candidate function not viable: requires single argument 'context', but no arguments were provided V8_WARN_UNUSED_RESULT MaybeLocal GetPropertyNames( ^ /Users/Library/Caches/node-gyp/14.16.1/include/node/v8.h:3827:43: note: candidate function not viable: requires at least 4 arguments, but 0 were provided V8_WARN_UNUSED_RESULT MaybeLocal GetPropertyNames( ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. make: *** [Release/obj.target/contextify/src/contextify.o] Error 1 gyp ERR! build error gyp ERR! stack Error: make failed with exit code: 2 gyp ERR! stack at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/node_modules/node-gyp/lib/build.js:194:23) gyp ERR! stack at ChildProcess.emit (events.js:315:20) gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:277:12) gyp ERR! System Darwin 20.4.0 gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/node_modules/node-gyp/bin/node-gyp.js" "rebuild" gyp ERR! cwd /Users/geojson.io/node_modules/contextify gyp ERR! node -v v14.16.1 gyp ERR! node-gyp -v v8.1.0 gyp ERR! not ok npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR<EMAIL_ADDRESS>install: node-gyp rebuild npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the<EMAIL_ADDRESS>install script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR!  /Users/.npm/_logs/2021-06-21T18_35_28_864Z-debug.log

Did you fix this issue?


[draft] Let user specify a fixed size or aspect ratio for rectangles/ellipses

Closes #26

@manthey this isn't functional yet, but is this UI in line with what you were thinking?

When the user selects rectangle or ellipse, an additional dropdown will appear under the existing style group dropdown, which allows them to choose between unconstrained, fixed aspect ratio, and fixed size. If they select unconstrained, nothing happens. If they select one of the other options, a popup dialog appears so they can specify a height and width.

I was imagining a very compact control like:

Where clicking the arrow would drop down out a small set on controls with the options (rather than open a dialog).  My thought was that by having it more compact, it would feel quicker to change.

Closing in favor of #197


Add logarithmic progress bar growth rate

There should be an option to make the progress bar grow logarithmic, as in it will never reach 100% but keeps on growing.
i.e. The progress bar grows toward 70% but slows down, making it never reach 100%.

Logarithmic will reach 100%, it has no upper bound. What you want is something like x/(x+1), that just approaches 100%, never hitting it.


Add support for alternative C libraries

 Issue by brson
Friday Jun 21, 2013 at 21:14 GMT
For earlier discussion, see https://github.com/rust-lang/rust/issues/7283
This issue was labelled with: A-an-interesting-project, A-runtime, I-wishlist in the Rust repository

Makes snapshots more compatible. Required for microcontroller Rust. musl is the favorite.

Experimental musl support added in rust-lang/rust#24777

It was indeed! We can continue to add support for other C libraries, but we will likely not actively pursue many beyond just one, so I'm going to close this.

Please support Newlib ;_;


Debian drbd-driver-loader support

This adds images for bullseye and buster. I haven't tested this on buster, but I had tested the bullseye image yesterday and it worked fine.

Commit sha: b08c5e7, Author: Michael H, Committer: Michael H; Expected "Michael H<EMAIL_ADDRESS>but got "Michael H<EMAIL_ADDRESS>
Note the extra . in H..


Remove definitions of external files

What this PR does / why we need it:
This PR reverts changes to the frontmatter of certain md files where the titles were wrongly capitalized. All changes to the frontmatter will now be done in the respective repositories of the md files.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

NONE

/review @JordanJordanov @dimitar-kostadinov


Unify namespaces in Kentico.Kontent.Delivery.Abstractions

Motivation
Unify all namespaces in Kentico.Kontent.Delivery.Abstractions assembly to the same namespace.
Based on https://github.com/Kentico/kontent-delivery-sdk-net/pull/300#issuecomment-974854350
Related to #287
Checklist

[ ] Code follows coding conventions held in this repo
[ ] Automated tests have been added
[ ] Tests are passing
[ ] Docs have been updated (if applicable)
[ ] Temporary settings (e.g. variables used during development and testing) have been reverted to defaults

How to test
If manual testing is required, what are the steps?

@petrsvihlik - I have bad news - I have found one class -  DeliveryOptionsExtensions - that used sub-namespace Kentico.Kontent.Delivery.Abstractions.Extensions.
I wanted to fix single namespace requirement and cover this rule in tests.
For now, I have fixed this, but I would like to hear your opinion on this first.

Yeah, it makes sense to unify this one and have it covered by a unit test - a good idea btw.
Regarding the prevention of problems caused by referencing multiple versions of the same package (e.g. through nested dependencies). The only good solution is to be 100% backwards compatible with older versions of the same package. This requires extreme diligence when designing the APIs and ideally a very thorough review process.
Just for the sake of completeness - there is another way to prevent assembly conflicts and that's called strong-naming. I even wrote an article on that a couple of years ago. Even MSFT says that "Strong-names are leftover from previous eras of .NET" and acknowledges that "the majority of third-party assemblies do not need strong names". Even though, MSFT says that publicly published .NET libraries should be strong-named as not strong-naming a .NET library excludes anyone who does need to strong-name their application or library from using it.  You can't force them to reference strong-named assembly.
In other words, it might be a good idea to start signing the assemblies in case someone wants to use them in an application they have 100% control of. But it's not a solution to this problem in general.


Portus missing some repositories when syncing

Description
I am deploying Portus in Kubernetes with a preexisting Docker registry . Portus is apparently able to sync with the registry but the web interface only shows some of the repositories.
Steps to reproduce

Create Docker registry, have a catalog similar to this:

$ curl http://registry.example.com:5000/v2/_catalog
{"repositories":["busybox/busybox","clair","httpd","myapp/myapp","vulnerables/cve-2016-10033"]}

Deploy Portus, point it to the private Docker registry
In the Docker registry namespace, only these repositories are shown:

Expected behavior: The web interface shows all repositories
Actual behavior: The web interface does not show repos returned as <library>/<repository>

Deployment information
Deployment method: I am testing Portus in Kubernetes with a configuration, based on https://github.com/mssola/Portus/tree/c0bdfa54687e0ad7117a65cb244cdf9cf186d4aa/examples/kubernetes
Configuration:
apiVersion: v1
kind: Secret
metadata:
  name: mariadb-secrets
  namespace: portus-ns
type: Opaque
data:
  root: <pass>
  password: <pass>
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mariadb-storage
  namespace: portus-ns
  labels:
    app: mariadb
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: v1
kind: Service
metadata:
  name: mariadb
  namespace: portus-ns
  labels:
    app: mariadb
    tier: backend
spec:
  ports:
  - port: 3306
    targetPort: 3306
  selector:
    app: mariadb
    tier: backend
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: mariadb
  namespace: portus-ns
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: mariadb
        tier: backend
    spec:
      containers:
      - name: master
        image: library/mariadb
        env:
        - name: MYSQL_USER
          value: portus
        - name: MYSQL_DATABASE
          value: portus_production
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mariadb-secrets
              key: root
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mariadb-secrets
              key: password
        args:
          - "--character-set-server=utf8"
          - "--collation-server=utf8_unicode_ci"
          - "--init-connect='SET NAMES UTF8;'"
          - "--innodb-flush-log-at-trx-commit=0"
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: mariadb-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mariadb-storage
        persistentVolumeClaim:
          claimName: mariadb-storage
---
# NOTE: this file should be hidden somehow, or recreated only from the CLI. This
# has been done this way to illustrate better the example.

apiVersion: v1
kind: Secret
metadata:
  name: portus-secrets
  namespace: portus-ns
type: Opaque
data:
  # openssl rand -hex 64 | base64 -w 0
  keybase: <keybase>
  # openssl rand -hex 64 | base64 -w 0
  password: <pwd>
---
apiVersion: v1
kind: Service
metadata:
  name: portus
  namespace: portus-ns
  labels:
    app: portus
spec:
  type: NodePort
  ports:
  - port: 3000
    targetPort: 3000
    nodePort: 32119
  selector:
    app: portus
    tier: registry
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: portus
  namespace: portus-ns
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: portus
        tier: registry
    spec:
      containers:
      - name: portus
        image: opensuse/portus:latest
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: 100m
            memory: 1Gi
        ports:
        - containerPort: 443
        volumeMounts:
        - name: certificates
          mountPath: /certificates
          readOnly: true
        env:
        - name: REGISTRY_TIMEOUT
          value: "2"
        - name: REGISTRY_READ_TIMEOUT
          value: "120"
        - name: REGISTRY_CATALOG_PAGE
          value: "100"
        - name:  PORTUS_MACHINE_FQDN_VALUE
          value: "portus.kubernetes.cluster"
        # DB
        - name:  PORTUS_DB_HOST
          value: "mariadb.portus-ns.svc.cluster.local"
        - name:  PORTUS_DB_DATABASE
          value: "portus_production"
        - name: PORTUS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mariadb-secrets
              key: password
        # Secrets
        - name: PORTUS_SECRET_KEY_BASE
          valueFrom:
            secretKeyRef:
              name: portus-secrets
              key: keybase
        - name: PORTUS_KEY_PATH
          value: "/certificates/portus.key"
        - name: PORTUS_PASSWORD
          valueFrom:
            secretKeyRef:
              name: portus-secrets
              key: password
        # For simplicity we serve assets through Rails.
        - name: RAILS_SERVE_STATIC_FILES
          value: "true"
        - name: PORTUS_PUMA_TLS_KEY
          value: "/certificates/portus.key"
        - name: PORTUS_PUMA_TLS_CERT
          value: "/certificates/portus.crt"
      - name: background
        image: opensuse/portus:latest
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: certificates
          mountPath: /certificates
          readOnly: true
        env:
        - name: REGISTRY_TIMEOUT
          value: "2"
        - name: REGISTRY_READ_TIMEOUT
          value: "120"
        - name: REGISTRY_CATALOG_PAGE
          value: "100"
        - name:  PORTUS_MACHINE_FQDN_VALUE
          value: "portus.kubernetes.cluster"
        # DB
        - name:  PORTUS_DB_HOST
          value: "mariadb.portus-ns.svc.cluster.local"
        - name:  PORTUS_DB_DATABASE
          value: "portus_production"
        - name: CCONFIG_PREFIX
          value: "PORTUS"
        - name: PORTUS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mariadb-secrets
              key: password
       # Secrets
        - name: PORTUS_SECRET_KEY_BASE
          valueFrom:
            secretKeyRef:
              name: portus-secrets
              key: keybase
        - name: PORTUS_KEY_PATH
          value: "/certificates/portus.key"
        - name: PORTUS_PASSWORD
          valueFrom:
            secretKeyRef:
              name: portus-secrets
              key: password
        - name: PORTUS_BACKGROUND
          value: "true"
      volumes:
      - name: secrets
        secret:
          secretName: certificates
      - name: certificates
        secret:
          secretName: certificates

Portus version: I'm using the official portus:latest image.

I think it is happen, because the namespaces 'busybox', 'myapp' and 'vulnerables' are not created (manually) in Portus. In my understand this must be done before. It sounds like it is related to the feature request #752 .

That seems to be it, I have no probles otherwise. Thanks for the answer, I'm closing this issue :)


lib/systems/inspect.nix: replace isPowerPC with isPower32BigEndian

Description of changes
Very confusingly, the isPowerPC predicate in lib/systems/inspect.nix does not match powerpc64le!
This is because isPowerPC is defined as
  isPowerPC      = { cpu = cpuTypes.powerpc; };

Where cpuTypes.powerpc is:
  { bits = 32; significantByte = bigEndian; family = "power"; };

This means that the isPowerPC predicate actually only matches the subset of machines marketed under this name which happen to be 32-bit and running in big-endian mode.
This seems like a sharp edge that people could easily cut themselves on.  In fact, that has already happened: in linux/kernel/common-config.nix there is a test which will always
fail:
   (stdenv.hostPlatform.isPowerPC && stdenv.hostPlatform.is64bit) ||

Let's rename the predicate to isPower32BigEndian since that's what it really checks.  This predicate is used in only three places: ghc, linux/kernel, and nixos's iso-image.nix.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin
[X] powerpc64le-linux

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release 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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

This seems like a sharp edge that people could easily cut themselves on. In fact, that has already happened: in linux/kernel/common-config.nix there is a test which will always fail:
  (stdenv.hostPlatform.isPower && stdenv.hostPlatform.is64bit)

Let's rename the predicate to isPower32BigEndian since that's what it really checks. This predicate is used in only three places: ghc, linux/kernel, and nixos's iso-image.nix.

isPower != isPowerPC, though, so this would succeed for powerpc64 and powerpc64le, as isPower checks the CPU family?!

GHC supports PowerPC in general (see this wiki page)

That's actually what I'm working on next...

the predicate should be changed to isPower everywhere GHC-related, I believe.

Sorry, I don't quite understand?  This PR changes the predicate from isPower to isPower32BigEndian.  What are you suggesting be changed to isPower?

isPower != isPowerPC, though, so this would succeed for powerpc64 and powerpc64le, as isPower checks the CPU family?!

Sorry, I cut-and-pasted that line from an unsubmitted earlier version of this PR by mistake.  I have corrected my comment at the top of the thread.  That line currently reads

(stdenv.hostPlatform.isPowerPC && stdenv.hostPlatform.is64bit) ||

Squashed @sternenseemann's changes into a single commit and fixed the typo in the commit message.  No other changes.

GHC supports PowerPC in general (see this wiki page)

That's actually what I'm working on next...

By the way @sternenseemann, I'm using the Gentoo bootstrapping binaries for ghc-8.6.5 on powerpc64le.  If you know of a better source (Hydra-generated?) please let me know.  It looks like nixpkgs can't cross-compile GHC, otherwise I'd submit a PR to build it in cross-trunk and use that.

By the way @sternenseemann, I'm using the Gentoo bootstrapping binaries for ghc-8.6.5 on powerpc64le. If you know of a better source (Hydra-generated?) please let me know.

There is an official bindist for GHC 8.6.5 for powerpc64le which I'd encourage you to use: https://downloads.haskell.org/~ghc/8.6.5/ghc-8.6.5-powerpc64le-fedora29-linux.tar.xz
I don't think nixpkgs can cross compile GHC at the moment (it can build a GHC cross compiler), GHC's cross build system is probably going to give you a lot of trouble in that case.

There is an official bindist for GHC 8.6.5 for powerpc64le which I'd encourage you to use: https://downloads.haskell.org/~ghc/8.6.5/ghc-8.6.5-powerpc64le-fedora29-linux.tar.xz

Wow, thanks!  I looked all over the place on haskell.org but could not find that.  I will use that.

@ofborg eval
(ofborg seems to have become stuck)

Sorry, I don't quite understand? This PR changes the predicate from isPower to isPower32BigEndian. (maybe this was a result of the confusion I caused with my error above).

isPower, not isPowerPC. On master it's isPowerPC atm (aka isPower32BigEndian), but it really should be isPower since GHC has NCG support for all (?) power pc platforms.

@sternenseemann sorry, I still do not understand what you are asking for.    After this commit, there are no occurrences of the string isPowerPC anywhere in nixpkgs:
nix@moore:/nix/git/nixpkgs$ git rev-parse HEAD
bc623b3ab7d2f37b177d3eab72f2a6d8109ac61f
nix@moore:/nix/git/nixpkgs$ rg isPowerPC
nix@moore:/nix/git/nixpkgs$

If this has not resolved your request, could you please make a self-contained statement of what you are asking me to do?

@sternenseemann in this comment, were you suggesting that the following substitutions be made (on top of this PR)?
s_isPower64_isPowerPc64_
s_isPower32_isPowerPc32_
s_isPower32BigEndian_isPowerPc32BigEndian_

I am fine with that.  I originally picked isPower because the architecture is called "POWER".  "Power PC" was a marketing name used for a subset of IBM/Motorola's POWER-architecture processors.  Every "Power PC" branded CPU is a POWER architecture CPU but not vice versa.
On the other hand, the autoconf/gcc multiarch tuple for this architecture is powerpc[64][le], and I'm generally in favor of using the autoconf/gcc multiarch taxonomy wherever possible.
So really it doesn't matter to me.  If you were asking for the substitutions above just say so and I will implement them (and also update #168111 which I pushed for a merge of because I needed to use that predicate in other PRs).  At this point it's still very easy to make changes like this, and I don't have a strong preference one way or the other.

Latest push applies all of @sternenseemann's suggestions and squashes to a single commit.
Thank you so much for the clarification!  Makes perfect sense now.

I think this deserves a brief changelog entry (under “Backwards incompatible changes”) and then we should be good to go!

I think this deserves a brief changelog entry (under “Backwards incompatible changes”)

Done.
I noticed that after your changes, there were only three uses of this predicate remaining.  How about we just inline its definition and remove the predicate entirely?  Since both renaming it and deleting it are both backwards-incompatible changes, I further suggest doing both at the same time so we only have one such change rather than two.
I've pushed an extra commit onto this PR which does what is described in the previous paragraph.  If that's not okay, you can merge all-but-the-last commit in this series.
Let me know if I should squash all or some of the commits.

Hrm, github accepted my push to this branch, but the web UI isn't showing the extra commits.  That's weird.
You can see them if you view the branch through my personal repo rather than through the PR: https://github.com/a-m-joseph/nixpkgs/commits/ispowerpc-becomes-ispower32

Yep, still waiting for pandoc to build...

Finally finished.  It tried to remove the language="" attributes from all the <programlisting> tags, which I assume is not something I ought to commit?  So I committed only the lines added.  I guess we'll see if CI is okay with that.

Is it important to you that this makes 22.05? We can still backport this to the release branch until the actual release is cut.
I'm not sure, I guess it depends on whether you plan on backporting other fixes for powerpc64le-linux later as well.

Is it important to you that this makes 22.05?

No, it is not -- but thanks for asking.
If the nixpkgs-genie gave me one wish, it would be #168413 so we can finally commit a bootstrap-files hash for mips64el, which has been blocking pretty much all progress on that platform for a few months now.

I've squashed the branch and moved the Changelog entry to the 21.11 release notes. Let me know if you're happy with the commit message and I'll merge.

I've squashed the branch and moved the Changelog entry to the 21.11 release notes. Let me know if you're happy with the commit message and I'll merge.

Thank you!  Looks good to me.


chore(repo): Extend linting

Description
Our current ESLint configuration was global which left a lot to be desired as each of our packages have unique requirements.
This PR extends leans on a generic set of ESLint configurations while also allowing for a lot of customizability at both the ESLint "feature"-level as well as the package-level.
Please focus on this commit as these are the changes: https://github.com/clerkinc/javascript/pull/1906/commits/f2c3b647559d8ec165c78470505a2067b340177d
The other changes are to appease Prettier.
Please Note:
In an effort to keep this PR as minimal as possible, I've disabled a number of rules. The plan is to re-enable them via follow-on PRs.)
Other Notes:

The /integration directory has been factored into NPM workspaces and, ultimately, Turborepo. This doesn't have any tangible change other than running linting along with the packages.
ESLint (when utilizing Typescript) will target tsconfig.lint.json. If that does not exists, it moves on to tsconfig.json. The lint TSConfig was required in a few cases as the default one wasn't permissive enough with it's includes/excludes.
I had to skip the Husky tasks so that it didn't attempt to update and commit all of the "fixable" issues.

Checklist

[x] npm test runs as expected.
[x] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[ ] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[x] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

Packages affected

[ ] @clerk/clerk-js
[ ] @clerk/clerk-react
[ ] @clerk/nextjs
[ ] @clerk/remix
[ ] @clerk/types
[ ] @clerk/themes
[ ] @clerk/localizations
[ ] @clerk/clerk-expo
[ ] @clerk/backend
[ ] @clerk/clerk-sdk-node
[ ] @clerk/shared
[ ] @clerk/fastify
[ ] @clerk/chrome-extension
[ ] gatsby-plugin-clerk
[x] build/tooling/chore

How much of an effort would it be to to not use tsconfig.lint.json across the board? Just as an estimated guess

How much of an effort would it be to to not use tsconfig.lint.json across the board and instead rely on tsconfig.json (and fixing those)? Just as an estimated guess

@LekoArts Not much of an effort, but it would make the tsconfig.json quite all-encompassing. I just didn't want to cause any unnecessary side-effects.

Is the addition of integration into the workspaces necessary? It'll mean that you have to install more dependencies for the monorepo even though you might not be interested in running the tests + you could more easily run into problems of "multiple different versions of packages".
In CI you could still cache the node_modules on an individual level for each test suite.

Is the addition of integration into the workspaces necessary? It'll mean that you have to install more dependencies for the monorepo even though you might not be interested in running the tests + you could more easily run into problems of "multiple different versions of packages".
In CI you could still cache the node_modules on an individual level for each test suite.

There's actually no noticeable difference. I should note that integrations is included, not integations/* so it's not attempting to install each integration test's deps.

The integration folder doesn't have a package.json file (I see it in another commit but not in the total view of this PR). What you're saying makes sense then, but isn't that package.json then missing?

The integration folder doesn't have a package.json file (I see it in another commit but not in the total view of this PR). What you're saying makes sense then, but isn't that package.json then missing?

Ah, you are correct, it's a remnant of a past commit. Updated, thanks!


use release 2.3 to run e2e

use registration-operator release-2.3 to run mco e2e.
Signed-off-by: Song Song Li<EMAIL_ADDRESS>

/test test-e2e

/lgtm


add playlist random start time

add a random start time to the songs in playlists just like the stand alone videos.

done using same method as solo videos but added a embedded timer within the palylsit shuffle logic. also added a mute until  the video random start loads to prevent random noises


console-base-rc-messenger-resource-group

给 console-base-rc-messenger-resource-group 添加 payload 字段，并且修复 依赖包循环使用、依赖未引入的问题

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.李勇 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Issue with SPI mode for mikroe-4237 board ( ICM42688-p )

If you get an error in the simple SPI example on the very first read, change the SPI mode to mode3 in the source code.

It seems like the SPI mode should be set as SPI_MODE3 for all masters/boards. Looking at Section 9.6 of the datasheet, data is latched on the rising edge of SCLK, which is either MODE0 or MODE3. Looking at Section 3.5 of the datasheet shows that an inactive clock should be pulled high, which is either MODE2 or MODE3. Therefore, SPI_MODE3 is the appropriate choice.

See the following for more info on SPI modes: https://www.corelis.com/education/tutorials/spi-tutorial/

tested on esp32

Thank you for the issues and the reply.
I tested the repo with teensy 4.0. So, It would be a little different at other boards.


Feature make virtctl a kubectl plugin

What this PR does / why we need it:
This PR adds the install command into our virtctl cli.
The command creates the plugin yaml and copy the virctl binary to the kubectl plugin folder.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #912
Special notes for your reviewer:
This PR is in wip. I will add unit tests and functional tests.
Release note:

make virtctl a kubectl plugin

This change is

@rmohr Can you take a look if the split between the install file inside the virtctl folder and the kubecli folder is good or I just need to put all the functions inside the virtctl folder.

I just a little bit skeptic that we need virtctl to install virtual as the plugin.
We need to decide what the preferred path to get virtctl, to download it as binary from GitHub not to complex, but it also not user-friendly.
I can see some possibilities to deliver it to the user:

use Linux packaging(rpm, deb) that will also deploy it as a plugin to k8s
deliver it in a container

@cynepco3hahue I think it's just like istio and other projects that have a cli program for them.
This can be part of the release in the kubevirt repo, just like you download the yaml to install kubevirt you will download the cli and you can choose if you want to install it as a plugin or just use it.

retest this please

@petrkotas can you make another review please :)

ci test please

/cc @stu-gott
Can you take a look on this PR?

@rmohr Can you please make a review on this PR?

@rmohr Can you please make another review ?

ping.
Let's do a quick effort to get this done.

@karmab something you or somebody close to you can help with to test or whatever is needed?

This looked so close. What is missing?

@SchSeba ?

@fabiand The last comment from rmohr is missing.
I will try to finish this as soon as possible.

@rmohr Make the request change.
The only thing is I wasn't have to configured the namespace as a flag because it doesn't get recognize as a flag on the plugin (kubectl gets it)

ci test please

I try to add a new flag call namespace for every command like this
cmd.Flags().StringVarP(&namespace,"namespace","n","","")

But I get and error when I try to run the command that this flags is recognize. in the plugin and it also breaks the regular virtctl -n . this is why I leave the namespace as before

get it from the kubeconfig file
if exist get it from the environment variable call KUBECTL_PLUGINS_CURRENT_NAMESPACE

rebase and run make to fix travis problem

/close

We should rethink how to integrate our plugin.

Yep. Good that there is now a simpler mechanism. I feel sorry for the good work from @SchSeba.


Is there support for github enterprise

Is your feature request related to a problem? Please describe.
I'd like to have github enterprise support so I can use this dashboard for my work repos
Describe the solution you'd like
I'd like to have an option in config.yml to specify which github server to use (regular one or github enterprise)
Describe alternatives you've considered
I've tried just map my work repos to my work org, but obviously that didn't work since gh-dash doesn't know address of our github enterprise server and have no personal access token to read data
Additional context

I'll be happy to get contributions for this.
I dont have a github enterprise account so I have no idea how is it different from a regular one. Also, I wouldnt be able to test this.

I've realized that it will work if I'll pass the GH_HOST and GH_ENTERPRISE_TOKEN env vars before running gh-dash (because go-gh package is used under the hood which is recognizing those env vars).
And it works actually 🎉
Not sure though how to make it to use those host and token permanently, currently I need to set up them each time I've started shell.
Also, facing issues with some missing icons (not sure if that's related to the fact that I'm using Nerd Fonts)

I don't think this requires support at the extension level. With the gh auth login command you can already log into a GHE account and securely store the credentials, so that all later gh commands will refer to that GHE account, including gh dash.

I use a alias and a env variable:
My .zshrc:
#GitHub
alias ghe='GH_HOST=ourgithub.enterprise.com gh'
export GH_ENTERPRISE_TOKEN="$(cat $HOME/.git_token_enterprise)"

so by calling gh i refer to github.com and with ghe to the internal one.


[UOW] Only get change set from documentChangeSets if it exists.

This prevents notices of Undefined index:<PHONE_NUMBER>aacd13000000000d79d12e in documents that use CHANGETRACKING_NOTIFY and for some reason do not have an entry in UnitOfWork::documentChangeSets.

@rjelierse I know some time has passed but any news on test suite? :)

Closing the issue for now, if anyone would have more information on it please reopen

I also ran into this problem and it happens when you flush a single (managed) document for the second time without property changes since the first flush and the document uses the NOTIFY change tracking policy. After the first flush the UnitOfWork::$documentChangeSets is cleared (at the end of the UnitOfWork::commit() method) and when you try to flush for the second time (without changing any properties on the document) than this notice gets thrown. If you use a different change tracking policy everything works fine in this scenario, so this should too.
@jwage The required index (the oid of the document) on the UnitOfWork::$documentChangeSets property doesn't get set because no one calls the UnitOfWork::propertyChanged() method on the flushed document beforehand. That's what creates the index and I think it is perfectly acceptable, if you don't call this method between two flushes and you should only get an empty change set during the second flush doing so. So I think this is the proper fix for this problem.
What should be done to reopen and accept this pull request?

@banrobert it seems like you've nailed the problem, best thing to do is create PR with test case (and this fix included if it indeed solves the problem) :)

OK, I'll create a new PR next week with a test case.
I also found an other problem with the UnitOfWork::commit() method when using the NOTIFY change tracking policy (it clears the whole UnitOfWork::$documentChangeSets when flushing only one document and by this all the subsequent flushes become useless). I'll also include the fix for that in the PR as these two problems seem to be connected to each other. I'll write a test case for this too.


"ext install " fails with EACCES error using corporate proxy

I originally reported this on StackOverflow but it was suggested by Benjamin Pasero that I log this as an issue.
I am working behind a corporate firewall which has outgoing authentication by Active Directory username. When I try the "ext install " command, after a some time I get the message "Error connect EACCES <IP_ADDRESS>:443".
I've tried setting the "http.proxy" value to all variations of FQDN and IP address,both with and without the "http://" prefix and also tried setting "http.proxyStrictSSL" both true and false, always with the same result.
There do not seem to be any settings to specify username and password or any other options for outgoing authentication.

VSCode
Version 1.0.0
Commit fa6d0f03813dfb9df4589c30121e9fcffa8a8ec8
Date 2016-04-13T14:08:36.599Z
Shell 0.35.6
Renderer 45.0.2454.85
Node 4.1.1
OS Version:
Window 10.0.10856

Steps to Reproduce:
Type
{ctrl-P}ext{space}install{space}

What's your proxy address?

OK. I tried all the tests again, restarting Code between each one.

"http.proxy": "http://<IP_ADDRESS>:8080/",
"http.proxyStrictSSL": true

Does nothing. Command line closes after a minute or so. No error.

"http.proxy": "http://proxy2.emr.com:8080/",
"http.proxyStrictSSL": true

Does nothing. Command line closes after a minute or so. No error.

"http.proxy": "http://proxy2.emr.com:8080/",
"http.proxyStrictSSL": false

Does nothing. Command line closes after a few seconds. No error.

"http.proxy": "http://<IP_ADDRESS>:8080/",
"http.proxyStrictSSL": false

Does nothing. Command line closes after a minute or so. No error.

"http.proxy": "<IP_ADDRESS>:8080",
"http.proxyStrictSSL": false

There's a blue line repeatedly sliding across under the command line. Then get "Error connect EACCES <IP_ADDRESS>:443"

"http.proxy": "<IP_ADDRESS>:8080",
"http.proxyStrictSSL": true

There's a blue line repeatedly sliding across under the command line. Then get "Error connect EACCES <IP_ADDRESS>:443"

"http.proxy": "proxy2.emr.com:8080",
"http.proxyStrictSSL": true

There's a blue line repeatedly sliding across under the command line. Then get "Error connect EACCES <IP_ADDRESS>:443"

"http.proxy": "proxy2.emr.com:8080",
"http.proxyStrictSSL": false

There's a blue line repeatedly sliding across under the command line. Then get "Error connect EACCES <IP_ADDRESS>:443"
Our automatic proxy detection (WPAD) returns either proxy-man.emr.com or proxy-war.emr.com, but currently both are aliases for proxy2.emr.com, hence have address <IP_ADDRESS>
Pinging proxy2.emr.com [<IP_ADDRESS>] with 32 bytes of data:
Reply from <IP_ADDRESS>: bytes=32 time=1ms TTL=61
Pinging proxy-war.emr.com [<IP_ADDRESS>] with 32 bytes of data:
Reply from <IP_ADDRESS>: bytes=32 time<1ms TTL=61
Pinging proxy-man.emr.com [<IP_ADDRESS>] with 32 bytes of data:
Reply from <IP_ADDRESS>: bytes=32 time=1ms TTL=61
Obviously, normal browsing is working fine.

Thanks for the many details, let's catch this sucker!
1-4 are the correct syntax: protocol://host:port. I have pushed 79b25eaac88479ff0d374d0dba0317f3ba5228f1 which adds a regular expression validator, so you'd get a warning next time you try to configure it like 5-8. 👍
No error tells me the request is working but the proxy is somehow returning an empty response or similar...
Let's try something else... what happens if you use "https://<IP_ADDRESS>:8080" and true?

Apologies for the delay. Using https: as a prefix (and both true and false) and the command appears to do nothing. No blue bar, no error message. The command window just closes after a time.

I just tried version 1.2 with the settings as in 1. above. Still does nothing. Should the newer version have fixed anything?

No, the only change we pushed was about warning if the syntax of http.proxy was invalid. Unfortunately we still don't have a fix for your issue.

Hi,
just tried with latest version 1.10.2 under RHEL7 with everything set: http_proxy/https_proxy as environment variable and in settings.json.
Extentions seem to still ignore these settings. Funny that "check for updates" is using the proxy settings.
Is there still no fix or workaround for this?
thx,
Johannes

Closing as a dupe of #22214


suggestion: consider improving the type signature for Observable.catch

RxJS version: 5.2.0
Code to reproduce:
case 1: Observable<number> decays to Observable<any>
import {Observable} from 'rxjs/Rx';

const o = Observable.of(1)
  .catch((err, caught) => Observable.throw(err))

case 2: Observable<number> decays to Observable<{}>
import {Observable} from 'rxjs/Rx';

const o = Observable.of(1)
  .catch((err, caught) => {
    throw Error(err);
  });

Expected behavior:
For o to have the type Observable<number> in both cases.
Actual behavior:
o has type Observable<any> in case 1.
o has type Observable<{}> in case 2.
This can mask serious bugs such as
function f() {
  const o = Observable.of(1)
    .map(() => {
      console.log(1);
    }) // programmer likely meant to return something
    .catch((err, caught) => Observable.throw(err));
  return o;
}

Where f should have type Observable<void>, likely due to programmer error, but any absorbs even void.
Additional information:
For better or worse, the catch and rethrow idiom seems to have overtaken RxJS, sometimes even when they only rethrow (not even logging the error) developers insist on explicitly catching and rethrowing all exceptions. I suspect the Angular docs are the primary reason for this, but that is beside the point except to remark that clearer usage guidelines for these operators would be helpful. Catching and only rethrowing doesn't make much sense to me but I am very new to RxJS.
For reference here is what the idiom I see daily (at work and on Stack Overflow) looks like
import { Observable } from 'rxjs/Observable';
import 'rxjs/add/operator/map';
import 'rxjs/add/operator/catch';

export interface Something {
  name: string;
}

export class SomeService {
  getItems() {
    return this.http('api/something')
      .map(x => (x.json() as Something).name) // Observable<string>
      .catch((err, caught) => Observable.throw(err.json())); // Observable<any>
  }
}

The problem with this pattern, and the pattern really is pervasive in the Angular at least, is that chaining catch removes all type information unless the user actually uses catch to recover by supplying a new Observable. If they return the result of an Observable.throw call all further operations receive Observable<any>.
To fix the type issue, I suggest that the signatures of catch and _catch be changed from
export declare function _catch<T, R>(
    selector: (err: any, caught: Observable<T>) => ObservableInput<R>
): Observable<R>;

export interface CatchSignature<T> {
    <R>(selector: (err: any, caught: Observable<T>) => ObservableInput<R>): Observable<R>;
}

to
export declare function _catch<T>(
    this: Observable<T>, selector: (err: any, caught: Observable<T>) => ErrorObservable
): Observable<T>;

export declare function _catch<T, R>(
    this: Observable<T>, selector: (err: any, caught: Observable<T>) => ObservableInput<R>
): Observable<R>;

export interface CatchSignature<T> {
    (selector: (err: any, caught: Observable<T>) => ErrorObservable): Observable<T>;
    <R>(selector: (err: any, caught: Observable<T>) => ObservableInput<R>): Observable<R>;
}

This worked well when I tested it. I suppose the question is whether the idiom of catching and rethrowing is meant to be common for observables.
I would be happy to submit a PR for this if you are interested.
One final note, these could still arguably be more precise as the resulting stream from a catch returning a well-typed observable, e.g. Observable<string> when recovering from an error raised by an Observable<number> is arguably Observable<number | string> but that is perhaps out of scope.
Thank you.

I'd be curious of usecase for 2 that instead of returning ErrorObservable throw directly, but otherwise this looks valid approach we'd like to improve. If you have PR, it'd be appreciate.

Observable when recovering from an error raised by an Observable is arguably Observable<number | string> but that is perhaps out of scope.

refer https://github.com/ReactiveX/rxjs/pull/2478 for this, afaik it's dealing this one.

@kwonoj great to hear. Thanks for linking #2478.
With respect to usecase 2, I've never actually seen it that way until I read the code example in the JSDoc comment for the catch operator.
I was actually wondering what the preferred style is. I take it that it is returning ErrorObservable.

Also note that
.catch(err => Observable.throw(err))

is 100% equivalent to
.catch(err => {
  throw err;
})

So the overloaded signature should not only return Observable<T> in the case of return type ErrorObservable, but also in the case of return type never.
I met this a lot because I found a chain of
.catch(err => {
  span.setTag('error', true);
  span.log({ 'event': 'error', 'error.object': err, 'message': err.message, 'stack': err.stack });
  throw err;
})
.finally(() => {
  span.finish();
});

easier to read (because they are closer to their synchronous counterparts and because of #2534) than
.do(() => undefined, err => {
  span.setTag('error', true);
  span.log({ 'event': 'error', 'error.object': err, 'message': err.message, 'stack': err.stack });
})
.finally(() => {
  span.finish();
});

Unfortunately, the former cripples the return type.

@felixfbecker that's a great point. I also find that to be much more readable and it is mentioned in the JSDoc comment for the catch operator.
Using never is a great idea. If no one has any objections, I will update the PR to cover the use case where throw is used directly by creating such an overload.

I think this has been addressed in #3395 #3421


HIVE-2400: credential_process run right hiveutil

Keeping how we copy, let's just do a symlink so that it finds the right executable

Duplicates #2322
/close


Sort comma separated list without parenthesis

This could be done

via selection
from the cursor up to specific char.

For instance I would like to sort people in markdown table:
|...| ...| Simone, Dean, Jane, Ana | ... |

In this case I could select entire cell and gs, or not select anything but gs,|. The end char cold even be specified in some array, i.e. let stopchars = '()|[]{}-' in which case above example becomes only gs,. Even , can be dynamic for instance gs- to sort Simone - Dean - Jane - Ana

Hey @majkinetor, this is an interesting idea. Thanks for sharing! From an implementation standpoint I think we'd need to limit to commas (although we could have alt mappings for other delimiters), but gst] for sorting until ] makes sense to me.
I don't have a ton of need for this, but feel free to take a stab at implementing if you're interesting and I'll be happy to review.

Normal Vim philosophy is to use the f and t movements. In you case place the cursor at the first item and then gst| should just work. This is how all other vim motion commands work when dealing with non brackets/quotes.


[BUG] BOM / Build validation needs improvements

Currently, "simple" BOMs work well, but BOM validation (and build order allocation) can fail when using:

Inherited BOM items
BOM items which allow use of variant stock
BOM items which allow substitutes

Need to improve the validation code, and add unit testing for all of the above cases.

This is very outdated now, and can be closed due to subsequent work.


Bug beds / respawn in the space.

The bug only happens when you go to sleep at night.

fixed bug by picking the first available bed spawn when the bed is destroyed.


Hibernate Decorators

FEATURE REQUEST
Hibernate decorators

OneToOne
OneToMany
ManyToOne
ManyToMany

still used heavily in the field today
make collecting entities a breeze
relationships
would a real treasure to the field
If decorators such as these could articulate proper ID modeling across entities
win win for back end and frontend

An additional feature to consider in this domain would be graph decorators

dots and lines
or
nodes and vertices
or
nouns and relationships

an implied graph database would grow from these decorator constructs
Dots and lines By Richard J Trudeau
this was my freshman discrete mathematics course
and this science is just making it to the field with graph databases
but we can implement this right on the mongodb middle tier

@Ben305 this can be closed


add: geoffreykithuku

Description

Related Issues

Changes Proposed

Checklist

[x] I have read and followed the Contribution Guidelines.
[x] All new and existing tests passed.
[x] I have updated the documentation to reflect the changes I've made.
[x] My code follows the code style of this project.
[x] The title of my pull request is a short description of the requested changes.

Screenshots
Note to reviewers

I have fixed the url.

@geoffreykithuku Thank you so much for your contribution! Your efforts are greatly appreciated and will go a long way in improving our project. Please feel free to share it with others and help us grow even further!


feat: update react media

Updates react-media to 1.10.0
Why
The previous version uses componentWillMount, which was fixed in 1.10.0 according to this comment https://github.com/ReactTraining/react-media/issues/134#issuecomment-520776934

Published on 4.21.31


Moved context to array of objects

Summary
Because of two different types of context data objects being used, it was causing an issue for the payment_requests ticket. These changes aim to fix it
How to run the code

Go to officelocal:3000/
Login as a user
Choose a move with service items to approve
Approve them
Make sure the details match the image below

Warnings

:warning:
Please add the JIRA issue key to the PR title (e.g. MB-123)

  Generated by :no_entry_sign: dangerJS against f3c404e4e20769d6bdaa4cc1666e4f8fbbaa4742


Implement PageTree overhaul

This PR fixes numerous issues with the pagetree and slight adaptions. There have been separate pull requests for all code additions already.

looking forward for this :3

@FinalAngel @vxsx is this for 3.2?

@yakky for 3.2.2

I'm not 100% that such a huge refactoring should go in a patch release @divio/django-cms-core
How about calling next release as 3.3 (released off 3.2.x branch, Imeang)?

I'm not 100% that such a huge refactoring should go in a patch release @divio/django-cms-core
How about calling next release as 3.3 (released off 3.2.x branch, Imeang)?

Just looking at the numbers, 250+ commits, 100 changed files, ~8kloc changes I'd say this deserves a version bump, so 3.3 sounds reasonable to me.

@ojii it's actually small if you know whats going on. We also had several PR's that lead to this. We actually wanted to merge it to 3.2.0 originally. 3.3.0 will introduce a complete new pagetree design (this only updates jstree to the latest 3.2.1 from originally 0.9 :D

Coverage decreased (-0.6%) to 88.902% when pulling 1b6206c40ff28f072f637639bd48053435e67d93 on FinalAngel:release/3.2.x into 94faefcdb62eaefc32bd6857ce3eff89cb87e0b0 on divio:release/3.2.x.


Upgrade to .Net Standard 2.0

Useful library, kindly migrate to Net Standard 2.0 to reduce the dependencies with the library

The support for .NET Standard 2.0 should be transparent, that is, since it supports netstandard 1.6, it automatically supports netstandard 2.0. The additional dependencies you're seeing only apply when targeting netstandard 1.6, if your project is netstandard 2.0, no additional dependencies should be pulled in.
If more dependencies are being pulled in, can you show where that's happening?


Add On the fly snippets

An idea borrowed from https://github.com/abo-abo/auto-yasnippet

Oho, that's pretty neat👌👌
How exactly does the new syntax work?
$word = module.$word?

Yes

What about giving a more explicit name to the file &  the function? Like on_the_fly

What about giving a more explicit name to the file & the function? Like on_the_fly

I just wanted to make it short, the longer version is fine to me, I can change it if @L3MON4D3 agree.

Sounds good to me👍👍

Another, more general thought: Opening a popup-window, into which the otf (or other, eg. lsp/lua) snippets can be written seems (to me at least) a bit more comfortable (and flexible) than writing it into the buffer and then selecting that exactly (or the whole line, but then we'll have to deal with trimming spaces correctly)

I prefer not to use popups, so users can enjoy syntax highlighting, linters, completion...

Okay, I might look into that another time :+1:

I'd like to be able to trigger the otf-snippets directly from INSERT, because NORMAL restricts valid cursor-positions (at least with virtualedit~=all) eg. it's not possible to position the cursor (and with that, expand a snippet) behind the last character of a line. Is there a way to set v:register from INSERT without leaving INSERT (and with that, repositioning the cursor)?

It is posible, you can use  in the mapping to call the function as if it where in normal mode.

Do you mean like inoremap <C-a> lua require("luasnip.extras.otf").on_the_fly()? If so, I'd still need to set the last-used register before the call and I'm a bit unsure on how to do that

What do you think about the spaces? The most comfortable way of using otf-snippets would (I guess) be writing it and then deleting the whole thing with dd, potentially ndd.
But with that the snippet would include the entire line before the snippet (and would get indented even deeper on expansion I believe), so common indent should probably be removed (reuse code from SELECT_DEDENT?)
(the second problem, eg. indent on multiline snippets would need to be handled even if the user perfectly selects their snippet)

:inoremap <c-a>  <C-O>"p:lua require('luasnip.extras.otf').on_the_fly()<cr>
this works in insert mode.
Regarding the indent. I really won't like to delete them, as like you said, I prefer to use the full like for this kind of snippets.

That doesn't work :/
https://user-images.githubusercontent.com/41961280/152859045-ca48684b-122f-4544-bcdf-f94b6e94c746.mp4
I'm using lsp_expand, but both use snip_expand() so this will also occur with otf: the last b is pushed behind the snippet with <C-O> (because, at expansion, the), with <cmd> it works correctly, but we cannot easily set v:register
We could solve it by passing the register to get the text from to otf() :P

That can be avoided by using <c-\><c-o> instead of <c-o> so the cursor does not move, I just tested it. I could for sure change the args to the function, at this point I'm just avoiding having to rewrite the doc :smile:
Let me change it so everybody is happy.

That can be avoided by using <c-\><c-o> instead of <c-o> so the cursor does not move, I just tested it. I could for sure change the args to the function, at this point I'm just avoiding having to rewrite the doc smile Let me change it so everybody is happy.

Thank you :smile:
(didn't know about <c-\><c-o>, that's useful :+1:)

Regarding the indent. I really won't like to delete them, as like you said, I prefer to use the full like for this kind of snippets.

I'm not sure what you mean, but when it comes to multiline-snippets the indent on lines following the first will have to be removed :/ (luasnip assumes that the snippet is not indented at all and insert the indent at which the snippet was expanded behind all linebreaks)

Could you rebase? I reenabled stylua for PRs, no idea if it will be applied after merging :sweat_smile:

Weird, not quite sure why committing the docs works fine, while stylua fails... I'll look into it tomorrow

One more thing for this PR: tests :D
Could you add some? I'd be fine with some integration-tests, if you feel like it unit-tests for dedent and the parser.

@L3MON4D3   Do I need to add integration tests? I mean, as the expansion of snippets is already tested elsewhere and  I added tests for the parsing and snippet generation already.

Oh true, yeah this is probably enough :+1:

I'm just trying them out, looks like one newline is appended; is that intentional?
https://user-images.githubusercontent.com/41961280/153748448-091780be-2757-4e2f-abe9-dcc9a4ec8a7b.mp4

Oh nvm, that's because of linewise selection... that's unfortunate. Should we ignore a trailing newline?

That would be nice :+1:

Wait, c will enter in insert mode so I will have to rework the whole mapping :smile:

Yeah, a bit :D
In the video I used vnoremap <c-f> "ec<C-\><C-O>:lua require('luasnip.extras.otf').on_the_fly()<Cr>


Remove _insight debug flag base.jl

There is a default keyword parameter in all objective function call. I suspect this causes a significant overhead.
We should remove it and benchmark the code performance.
A global const debug flag might be used if we really need one there.

I found it very useful on numerous occasions, especially when fits are not going well I found it it to be invaluable. I think Ale @ab2425  did too from memory, but we would have to check with her.
If on benchmarking a const global is similar performance then that has some benefits in that it makes the code cleaner and could easily be used in other functions as well. However, a major drawback of being a const global is that it is const, and thus can't be changed by the user. So it becomes enforced as a feature only usable by those comfortable enough with Julia to investigate RHEOS internals and would force recompilation of the module each time it was changed. Both implications are undesirable.
Would be curious to know what overhead it adds. My bet would be that its presence as a parameter is negligible. The branch in the function body may add a little more overhead but this would still be required if we used a const global. Also, I would expect the branch to be negligible compared to mittleff, convolution and any other operation we perform over large arrays. Branches like that can often occur in one CPU instruction Vs many for array operations.

I agree that when a complex function is called, this is probably insignificant. Maybe we should think more broadly about how to assist the user tracking how the optimisation evolves. It is indeed useful. Maybe we could make it feature!

Thinking about this again recently:

Maybe we could make it feature
It's a feature already; it's not extensively documented but it is in the API section, which is enough I think. Maybe we could add it to an example.

Maybe we should think more broadly about how to assist the user tracking how the optimisation evolves
I was reading about this the other day -
https://docs.julialang.org/en/v1/stdlib/Logging/
the @info macro could be one way to extend logging as a more general feature. From a 2 minute exploration, I don't like how much extra noise comes with it (2 lines for each invocation of the macro) because it means more mess when printing out lots parameter iterations. But something to explore further, I'm sure there's room for customization. We should also benchmark.


Incomplete code without instructions

Thanks for providing a useful medical nas benchmark and repository. I noticed that the code for reproducing the benchmark and accessing the benchmark is missing. Could you please provide the code.

The code will be updated as soon as publication and complementary analysis on the benchmark are completed.
Thanks for the interest.


inItialising object  EpsonDiscovery()

const epsonDiscover = new EpsonDiscover(); => having this line will always crash the app and results this error message:
TypeError: undefined is not a constructor (evaluating 'new _reactNativeEpsonEposPrinter.EpsonDiscover()')
Any ideas how to fix / why does this happen?
Many thanks

Can anyone please help

The name of the constructor is PrinterDiscover.
import { PrinterDiscover } from 'react-native-epson-epos-printer';
const discover = new PrinterDiscover();

The same error I'm getting even with PrinterDiscover

The same error I'm getting even with PrinterDiscover

The package is not updated on npmjs, you need to install it from Github if you want to use PrinterDiscover.


I wonder if the method setAnimationColors(ArrayList colors) is useful.

AppIntro Version:
AppIntro Version：4.2.3
Device/Android Version:
null
Issue details / Repro steps / Use case background:
I looked at the source code，ArrayList set through "setAnimationColors(ArrayList colors)" are not used by any objects.I wonder if the method setAnimationColors(ArrayList colors) is useful.
Your Code:
null
Stack trace / LogCat:
null

Yeah you're right. That method can be removed.
Here the PR @paolorotolo #582

#582 is merged now.
Thanks for the contribution.


Using a negative value for dropdownPosition results in a huge blank space at the top of the dropdown on iOS

As the title states, using a negative value for dropdownPosition results in a blank space at the top of the dropdown until you have interacted with it, at which point the blank space disappears. The actual position of the dropdown is perfect, however the blank space is an issue. :(
Issue seems to only happen on iOS as everything looks perfect on Android.

react-native v0.52.2
react-native-material-dropdown v0.7.2
Here's the code I'm using:
<Dropdown
  label=''
  labelHeight={ 0 }
  baseColor='#fff'
  textColor='#fff'
  itemColor='#fff'
  selectedItemColor='#fff'
  containerStyle={{ backgroundColor: '#932f61', borderColor: '#9d3470', borderWidth: 1, marginVertical: 20, padding: 10 }}
  pickerStyle={{ backgroundColor: '#932f61', borderColor: '#9d3470', borderWidth: 1 }}
  inputContainerStyle={{ borderBottomWidth: 0, marginBottom: -10 }}
  rippleInsets={{ bottom: -10, top: -10, left: 0, right: 0 }}
  dropdownPosition={ -1 }
  data={ this.props.data }
  value={ this.props.value }
  onChangeText={ this.props.onChange }
/>

Just updated react-native-material-dropdown to v0.9.0 and the issue is still there.

Oddly enough, setting dropdownPosition to { this.props.data.length - 1 } results in the same display issue.

It seems that this only happens if value is null. Was able to fix it by setting value to a blank string. :)

This is probably related to #69

Thanks for issue! Released fix in 0.10.0. Overscroll is now disabled for positive and negative dropdownPosition.


DF Scene Enhancement: Conflict with Monk's Active Tile Triggers

Conflicting Module(s)

Monk's Active Tile Triggers

Describe the conflict
I receive constant warnings from libWrapper about "potential conflict" haven't seen any bug so far, I just like to warning you about that, perhaps it helps this amazing module!
Expected behavior
Like I say above, just the libWrapper warnings
Screenshots (Optional)
I have lost the Screenshot of the game screen but sending you the console.

I get similar conflict warnings about these two modules...mine looks as follows.

There's not really a way around this issue. I have a MIXED wrapper for this function. If I were to call the original function then it would display the SceneConfig, so instead I override when you click a scene to prevent this behaviour. It looks like MATT also has a MIXED wrapper.

I appreciate the effort and the time!


sortBySelector CSS classes not applying to select element

When I add cssClasses to the sortBySelector widget, the classes on the select element don't apply. If I add classes to the root element, they apply to both the root and the select.
cssClasses: {
    root: 'white ttu tracked f6 fw5 bg-colour-button pa2 pv105 br1',
    item: 'white'
},

Hi there, thanks for opening this issue :)
Which version of InstantSearch.js are you using?

Hey, I'm using 2.1.4 from the cloudflare cdnjs
https://cdnjs.cloudflare.com/ajax/libs/instantsearch.js/2.1.4/instantsearch.min.js

Hi @lukepearce can you try with 2.2.*?

That's got it working 👍


Add unit tests

This adds a lot of unit tests for the template functionality. Since #9 has not yet been merged some of the tests are currently failing (with regards to editing a template). Some tests are failing due to bugs found, which I opened new issues for (see #10, #11, #12).

Fixed #6


chore(storage): remove t prefix in fullkey

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
The t prefix in a full key is used to identify whether it contains a table ID. However, only unit tests will have full keys that do not start with a table ID. Therefore, we can make all tests use prefixed keys and then remove the t prefix.
Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Documentation
If your pull request contains user-facing changes, please specify the types of the changes, and create a release note. Otherwise, please feel free to remove this section.
Types of user-facing changes
Please keep the types that apply to your changes, and remove those that do not apply.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note
Please create a release note for your changes. In the release note, focus on the impact on users, and mention the environment or conditions where the impact may occur.
Refer to a related PR or issue link (optional)

... just search for magic number 5 and see if there're more places to fix

Can we try the following steps to ensure that all unit tests have been explicitly added a table id prefix?

add a t prefix in prefixed_key.
check the t prefix in get_table_id

I added the t in a previous commit, then removed it after all tests have passed.