Issues with packaged native modules (On windows/osx, not linux)

A current package I'm working on requires the use of native packaging. One of the features of it is that it collects information about local disk usage (using diskusage) to inform the user as they download data. Two of the dependencies of the diskusage package (ref and ffi) are native modules and require compiling and by default don't work without using electron-rebuild.
If I perform an 'npm run' in my app directory, the application runs perfectly fine with no complaints on OSX/Windows/Linux. However, after running electron-packager, it only works on Linux. For Windows/OSX it breaks as soon as it attempts to access the ref package. It complains with a message of "expected module 50, got 49" but I'm not 100% on where it's getting those numbers.
Using node version 6.9.1
Console output when you run electron-packager with the environment variable DEBUG=electron-packager. Please include the stack trace if one exists.
Nothing other than 'Wrote new app to <directory>'

What command line arguments are you passing? Alternatively, if you are using the API, what
parameters are you passing to the packager() function?
node ./node_modules/electron-packager/cli.js ./ <appname> --platform=win32 --arch=all --out ../packageWin/ --version 1.4.3 --overwrite --icon ./icons/<appname>

Please provide either a failing minimal testcase (with a link to the code) or detailed steps to
reproduce your problem.
in the same folder where my 'app' directory is I have a 'postinstall.js' script with the content of
#!/usr/bin/env node
var exec = require('child_process').exec;

exec('./node_modules/.bin/electron-rebuild -w ffi',
    function(error,stdout,stderr){

    });

exec('./node_modules/.bin/electron-rebuild -w ref',
    function(error,stdout,stderr){

    });

With slight modification on Windows, so it uses electron-rebuild.cmd and strong paths instead. After running an npm install, the app installs fine with no errors and runs fine after 'npm run' no matter what (in terms of no packages crashing). Once I run the aforementioned packing command, I can launch and run the application and be fine on Linux, but on Win32/OSX I'm only fine until I open the page with the require('diskusage') command in it. As soon as it hits that line, bindings.js shows the 'expected 50, got 49' error.
As a side note, I'm building the Linux package on a Linux machine, Windows on Windows(7), and OSX on OSX.

CC: @MarshallOfSound since he has more experience with electron-rebuild.

@robogen I had to do some interesting things to get electron_rebuild working from within a JS script.  Basically two things come to mind when I think back to how I made it work.

Use spawn not exec
Ensure you set the cwd value correctly, it has to be the folder that contains your project (not a sub-folder but the top level)

For an example see --> https://github.com/MarshallOfSound/Google-Play-Music-Desktop-Player-UNOFFICIAL-/blob/master/vendor/rebuild.js#L24
In the latest electron-rebuild you can get extended output (and see what is actually happening) by using the --log argument

@MarshallOfSound Thank you for the help, the extra log output has helped a bit! Unfortunately, I'm still getting that 'Expected module version 50, got version 49' error when the 'diskusage' package gets called. (apologies on not posting this stack earlier!)
Error: Module version mismatch. Expected 50, got 49.
    at Error (native)
    at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:168:20)
    at Object.Module._extensions..node (module.js:583:18)
    at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:168:20)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)
    at Function.Module._load (module.js:424:3)
    at Module.require (module.js:483:17)
    at require (internal/module.js:20:19)
    at bindings (C:\Users\<user>\Documents\GitHub\<app>\packageWin\<app>-win32-x64\resources\app\node_modules\bindings\bindings.js:76:44) <div ng-view="" class="ng-scope">

This is my new postinstall.js
#!/usr/bin/env node
const spawn = require('child_process').spawn;
const ref = spawn(__dirname + '\\node_modules\\.bin\\electron-rebuild.cmd',
                  ['-w', 'ffi', '--log'],
                  { cwd: __dirname,
                    env: process.env});
const ffi = spawn(__dirname + '\\node_modules\\.bin\\electron-rebuild.cmd',
                  ['-w', 'ref', '--log'],
                  { cwd: __dirname,
                    env: process.env});

ref.stdout.on('data', (data) => {
    console.log(`refout: ${data}`);
});

ref.stderr.on('data', (data) => {
    console.log(`referr: ${data}`);
});

ref.on('close', (code) => {
    if (code !== 0) {
        console.log(`ref rebuild exited with code ${code}`);
    }
});

ffi.stdout.on('data', (data) => {
    console.log(`ffiout: ${data}`);
});

ffi.stderr.on('data', (data) => {
    console.log(`ffierr: ${data}`);
});

ffi.on('close', (code) => {
    if (code !== 0) {
        console.log(`ffi rebuild exited with code ${code}`);
    }
});

@robogen Can you see the modules actually rebuild in the logs.  If not something is wrong with your rebuild command.  I'd suggest removing the -w are and values.

@MarshallOfSound Yes, the output seems to indicate they're properly rebuilding. With the -w flag this is the output (produced on Windows)
ffiout:
><EMAIL_ADDRESS>install C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref
> node-gyp rebuild

refout:
><EMAIL_ADDRESS>install C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi
> node-gyp rebuild

refout:
C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi>if
refout: not defined npm_config_node_gyp (node "C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "" rebuild )

ffiout:

ffiout: C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref>if not defined npm_config_node_gyp (node "C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "" rebuild )

refout: Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.

ffiout: Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.

refout:   Building assembly file ..\..\..\deps\libffi\src\x86\win64.asm

ffiout:   binding.cc

ffiout:   win_delay_load_hook.cc

refout:    Assembling: ..\..\..\deps\libffi\src\x86\win64.asm

refout:   prep_cif.c

refout:   types.c

refout:   raw_api.c

refout:   java_raw_api.c

refout:   closures.c

refout:   ffi.c

refout:   win_delay_load_hook.cc

refout:   ffi.vcxproj -> C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\Release\\libffi.lib

refout:   ffi.cc

refout:   callback_info.cc
  threaded_callback_invokation.cc

refout:   win32-dlfcn.cc

refout:   win_delay_load_hook.cc

ffiout: ..\src\binding.cc(643): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref\build\binding.vcxproj]

ffiout:   C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

ffiout: ..\src\binding.cc(644): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref\build\binding.vcxproj]

ffiout:   C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

ffiout:      Creating library C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref\build\Release\binding.lib and object C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref\build\Release\binding.exp

ffiout:   Generating code

refout: ..\src\ffi.cc(111): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\ffi_bindings.vcxproj]

refout:   C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'
..\src\ffi.cc(114): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\ffi_bindings.vcxproj]

refout:   C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

refout: ..\src\ffi.cc(123): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\ffi_bindings.vcxproj]

refout:   C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

refout: ..\src\ffi.cc(124): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\ffi_bindings.vcxproj]

refout:   C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

refout: ..\src\ffi.cc(125): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\ffi_bindings.vcxproj]

refout:   C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

refout: ..\src\ffi.cc(126): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\ffi_bindings.vcxproj]

refout:   C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

refout: ..\src\ffi.cc(132): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\ffi_bindings.vcxproj]

refout:   C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

ffiout:   Finished generating code

ffiout:   binding.vcxproj -> C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref\build\Release\\binding.node

ffiout:   binding.vcxproj -> C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref\build\Release\binding.pdb (Full PDB)

ffiout<EMAIL_ADDRESS>C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref

refout:      Creating library C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\Release\ffi_bindings.lib and object C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\Release\ffi_bindings.exp

refout:   Generating code

refout:   Finished generating code

refout:   ffi_bindings.vcxproj -> C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\Release\\ffi_bindings.node

refout:   ffi_bindings.vcxproj -> C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\Release\ffi_bindings.pdb (Full PDB)

refout<EMAIL_ADDRESS>C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi

I'll try removing the -w and seeing if that makes the difference.

That seems to have made the difference, though I have some new errors to deal with
ffierr: npm
ffierr:  ERR! Windows_NT 6.1.7601
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\<user>\\Documents\\GitHub\\<app>\\<app>\\node_modules\\npm\\bin\\npm-cli.js" "rebuild" "--runtime=electron" "--target=1.3.8" "--arch=x64" "--update-binary"
npm ERR! node v6.9.1
npm ERR! npm  v3.10.9
npm ERR! path C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\.bin\uuid
npm ERR! code ENOENT
npm ERR! errno -4058
npm ERR! syscall chmod

npm ERR! enoent ENOENT: no such file or directory, chmod 'C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\.bin\uuid'
npm ERR! enoent ENOENT: no such file or directory, chmod 'C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\.bin\uuid'
npm ERR! enoent This is most likely not a problem with npm itself
npm ERR! enoent and is related to npm not being able to find a file.
npm ERR! enoent

ffierr:

ffierr: npm ERR! Please include the following file with any support request:
npm ERR!     C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\npm-debug.log

ffierr: Process exited with code:<PHONE_NUMBER>

ffierr: Error: Process exited with code:<PHONE_NUMBER>
    at ChildProcess.<anonymous> (C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\spawn.js:55:26)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at maybeClose (internal/child_process.js:877:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)

ffi rebuild exited with code<PHONE_NUMBER>
refout:
><EMAIL_ADDRESS>install C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi
> node-gyp rebuild

refout:
C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi>if
refout: not defined npm_config_node_gyp (node "C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "" rebuild )

refout: Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.

refout:   Building assembly file ..\..\..\deps\libffi\src\x86\win64.asm

refout:    Assembling: ..\..\..\deps\libffi\src\x86\win64.asm

refout:   prep_cif.c

refout:   types.c

refout:   raw_api.c

refout:   java_raw_api.c

refout:   closures.c

refout:   ffi.c

refout:   win_delay_load_hook.cc

refout:   ffi.vcxproj -> C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\Release\\libffi.lib

refout:   ffi.cc

refout:   callback_info.cc

refout:   threaded_callback_invokation.cc

refout:   win32-dlfcn.cc

refout:   win_delay_load_hook.cc

refout: ..\src\ffi.cc(111): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\ffi_bindings.vcxproj]
  C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

refout: ..\src\ffi.cc(114): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\ffi_bindings.vcxproj]
  C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

refout: ..\src\ffi.cc(123): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\ffi_bindings.vcxproj]

refout:   C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

refout: ..\src\ffi.cc(124): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\ffi_bindings.vcxproj]
  C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

refout: ..\src\ffi.cc(125): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\ffi_bindings.vcxproj]

refout:   C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

refout: ..\src\ffi.cc(126): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\ffi_bindings.vcxproj]

refout:   C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

refout: ..\src\ffi.cc(132): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\ffi_bindings.vcxproj]

refout:   C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

refout:      Creating library C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\Release\ffi_bindings.lib and object C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\Release\ffi_bindings.exp

refout:   Generating code

refout:   Finished generating code

refout:   ffi_bindings.vcxproj -> C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\Release\\ffi_bindings.node

refout:   ffi_bindings.vcxproj -> C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ffi\build\Release\ffi_bindings.pdb (Full PDB)

refout:
><EMAIL_ADDRESS>install C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref
> node-gyp rebuild

refout:
C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref>
refout: if not defined npm_config_node_gyp (node "C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "" rebuild )

refout: Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.

refout:   binding.cc

refout:   win_delay_load_hook.cc

refout: ..\src\binding.cc(643): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref\build\binding.vcxproj]

refout:   C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

refout: ..\src\binding.cc(644): warning C4996: 'v8::Object::ForceSet': was declared deprecated [C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref\build\binding.vcxproj]
  C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\headers\.node-gyp\iojs-1.3.8\deps\v8\include\v8.h(2687): note: see declaration of 'v8::Object::ForceSet'

refout:      Creating library C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref\build\Release\binding.lib and object C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref\build\Release\binding.exp

refout:   Generating code

refout:   Finished generating code

refout:   binding.vcxproj -> C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref\build\Release\\binding.node

refout:   binding.vcxproj -> C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\ref\build\Release\binding.pdb (Full PDB)

referr: npm
referr:  WARN prefer global<EMAIL_ADDRESS>should be installed with -g

refout:
><EMAIL_ADDRESS>postinstall C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-prebuilt
> node install.js

refout:
><EMAIL_ADDRESS>install C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\nslog
> node-gyp rebuild

refout:
C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\nslog>
refout: if not defined npm_config_node_gyp (node "C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "" rebuild )

referr: gyp
referr:  ERR! clean error

referr: gyp ERR! stack Error: EPERM: operation not permitted, unlink 'C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\nslog\build\Release\nslog.node'
gyp ERR! stack     at Error (native)
gyp ERR! System Windows_NT 6.1.7601
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\<user>\\Documents\\GitHub\\<app>\\<app>\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\nslog
gyp ERR! node -v v6.9.1
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok

referr:

referr: npm ERR! Windows_NT 6.1.7601
npm ERR!
referr:  argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\<user>\\Documents\\GitHub\\<app>\\<app>\\node_modules\\npm\\bin\\npm-cli.js" "rebuild" "--runtime=electron" "--target=1.3.8" "--arch=x64" "--update-binary"
npm ERR! node v6.9.1
npm ERR! npm  v3.10.9
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-gyp rebuild'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the nslog package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs nslog
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls nslog
npm ERR! There is likely additional logging output above.

referr:
npm ERR! Please include the following file with any support request:
npm ERR!     C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\npm-debug.log

referr: Process exited with code: 1

referr: Error: Process exited with code: 1
    at ChildProcess.<anonymous> (C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\electron-rebuild\lib\spawn.js:55:26)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at maybeClose (internal/child_process.js:877:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)

@MarshallOfSound After grabbing the packages 'uuid' and 'asar' it's now failing on
for ffi
Error: `C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe` failed with exit code: 1

for ref
referr: ERR! clean error
gyp ERR! stack Error: EPERM: operation not permitted, unlink 'C:\Users\<user>\Documents\GitHub\<app>\<app>\node_modules\nslog\build\Release\nslog.node'

Why does it give these error messages now though, without the -w? How does electron-rebuild handle them differently, or does it suppress warnings the first method? And why did it work before while it wasn't packaged but broke once it was?

And why did it work before while it wasn't packaged but broke once it was?

You'll be packaging for a different arch than your node install

gyp ERR! stack Error: EPERM: operation not permitted, unlink 'C:\Users<user>\Documents\GitHub<app><app>\node_modules\nslog\build\Release\nslog.node'

Yeah, nslog is a nightmare.  On windows I have rmdir /Q /S nslog\build 2>nul before I run the rebuild.

@MarshallOfSound I don't think I can say thank you enough, it's finally working now! Here's the new postinstall.js
#!/usr/bin/env node
const spawn = require('child_process').spawnSync;
const fs = require('fs');
var rebuilder = "";
const target = "1.4.3";

if (process.platform == 'win32') {
    rebuilder = "electron-rebuild.cmd";
} else {
    rebuilder = "electron-rebuild";
}

// nslog fixer
fs.unlinkSync(__dirname + '\\node_modules\\nslog\\build\\Release\\nslog.node');

const ref = spawn(__dirname + '\\node_modules\\.bin\\' + rebuilder,
                  ['--version='+target,'--log'],
		  { cwd: __dirname + '\\node_modules\\ref',
		    env: process.env,
			shell: true });
console.log('ref output: ' + ref.output);
console.log('ref error: ' + ref.error);

const ffi = spawn(__dirname + '\\node_modules\\.bin\\' + rebuilder,
                  ['--version='+target,'--log'],
		  { cwd: __dirname + '\\node_modules\\ffi',
		    env: process.env,
			shell: true });
console.log('ffi output: ' + ffi.output);
console.log('ffi error: ' + ffi.error);

I had trouble with exec not working with your rmdir command, but I substituted it for the fs.unlinkSync command and it's working great now. A hurdle that was giving me trouble was the spawn command, I didn't realize fully at first that it was an asynchronous command. With both the ref and the ffi spawned commands running, they were both attempting to access the same files in nslog at the same time, switching them to be synchronous fixed that however. With this new script it works perfect!
Once again, thank you for the assistance!


Remove the lazy_static dependency

I noticed there's a few things I missed in my previous PR.

lazy_static is not necessary anymore. We can just use the new const constructor functions instead.
The README still mentions lazy_static.

bors r+

bors retry


Feature/cab 2622

Handle date fields on edit page.

Coverage decreased (-0.04%) to 82.088% when pulling c77cc4dee2381119ad973604c970af8ac2a40c29 on feature/CAB-2622 into<PHONE_NUMBER>473958e61fc1089f414cc03ddde0f8 on develop.


Fix typo in BIO_push.pod

CLA: trivial
Checklist

[x] documentation is added or updated

This pull request is ready to merge


Download of 10k genes failing on production

metabolic genes in homo sapiens
http://amigo.geneontology.org/amigo/search/bioentity?q=*:*&fq=regulates_closure:"GO:0008152"&fq=taxon_subset_closure_label:"Homo sapiens"&sfq=document_category:"bioentity"
only 10k. Custom DL, default 2 fields times out. Runs in milliseconds on tomodachi
reboot required?
cc @kltm

@stuartmiyasato before rebooting (if that is indeed that correct course of action here), would it be possible to know what the usage on the machine is? I'm wondering if this is a bot or a killer query.
As @cmungall said, these queries go quite fast on our local machines, so I'm a little worried.
It's a bit strange that the Solr index seems to be otherwise responsive.

It seems like this is connected to a GO Helpdesk query: http://jira.geneontology.org/browse/GO-1355
'm using the search function to download the names of approximately 60K Homo
sapiens genes related to the search term "metabolic". The interface says that
downloads are possible for lists under 100k, but I'm getting a "504 Gateway
Time-out" error. Is there any way around this?

The 100k should be fine for us in most cases from the benchmarking we did.

Yes, this is the response I started writing:
Hi,

First I would caution you against using string based searches like "metabolic". One of the points of the gene ontology is that it can return all genes associated with a concept regardless of whether a the string is in the name of the annotation.

For example, in AmiGO you can search for 'metabolic process' http://amigo.geneontology.org/amigo/term/GO:0008152

Click ' Link to all genes and gene products annotated to metabolic process. '

Then select 'Homo sapiens'

You can then download the 10k genes annotated to 'metabolic process'

UH OH

The issue appears to have been an nginx (non-)configuration.  I increased the proxy timeout configuration and it seems to have fixed the problem.  @cmungall can you check to make sure it works properly for you?
For the record, I added the following configuration directives in our nginx.conf file:

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

@stuartmiyasato It certainly seems to be working better now, with results returning almost immediately.
Unfortunately, this was not the behavior yesterday, where it would spin until timing out--it seemed like something on the server was struggling.
Oh well, it looks to be cleared now :)

@stuartmiyasato The uptimerobot really only does pingable, not system stress, etc.
IIRC, you have nagios on the solr servers? Besides up/down, do you keep time series for CPU/RAM?

@kltm We do keep those stats, but it's not completely representative because the GOlr services are bundled on the same VM as AmiGO so it's not easy to separate which service is using what resources  at any given moment.  It will be easier to do so once the services are decoupled, probably once they are deployed into AWS.  Having multiple servers behind a load balancer doesn't make it any easier to monitor either...
That said, with reference to http://jira.geneontology.org/browse/GO-1364, I would be surprised if it's a resource limitation.  Without having looked at the problem at all, my gut feeling is that there's a bad service configuration in there somewhere -- probably the nginx config for GOlr.  Will have to investigate further.

@stuartmiyasato Thank you for looking into this more.
I that, pretty much besides the visualize stuff, which is pretty out of the way, most things in AmiGO are passed through to the Solr backend. I'd wager that unless the visualize is more used than I think, load should pretty much be on the Solr server.
I was guessing at resource limitation given that there seems to have been a "spike" (well, two) in people having issues with the disk-centric download operations.
Given our testing for seeing what would happen at 100k, I'd think that even a large volume of small requests would not sweat the system.
Ah well, if anything comes up, let me know. Hopefully, if it comes up again, we can catch it in the act.

This seems to be coming up again with http://jira.geneontology.org/browse/GO-1369 .

No current complaint, I believe. Will close for now.


Ansible Operator stuck in infinite reconciliation loop on K8S >= 18.x

Bug Report

What did you do?
simple operator  which is deploys two manifests: static pod and crd
What did you expect to see?
Operator successfully finish reconciliation loop
What did you see instead? Under which circumstances?
Operator stuck in infinite reconciliation loop
Environment
K8S v1.19.3
OperatorSDK 1.2.0

/language ansible
Kubernetes cluster type:
vanilla
$ operator-sdk version
operator-sdk version: "v1.2.0", commit: "215fc50b2d4acc7d92b36828f42d7d1ae212015c", kubernetes version: "v1.18.8", go version: "go1.15.3", GOOS: "darwin", GOARCH: "amd64"
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-16T00:04:31Z", GoVersion:"go1.14.4", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"clean", BuildDate:"2020-10-16T20:43:08Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}
Possible Solution

It's appears that on K8S version < 1.18, the same code works as expected.
The problem happens (in my case) only when I deploying either static pod with  toleration or when I deploy CRD (by operator) with status
I've created sample operator which can easily reproduce that issue.

# deploy operator
kubectl create -f https://raw.githubusercontent.com/Dimss/infinite-loop-operator/main/bundle.yaml

# deploy bad CR and watch operator logs, the operator will stack in infinite reconciliation loop
kubectl create -f https://raw.githubusercontent.com/Dimss/infinite-loop-operator/main/config/samples/bad.yaml

# remove bad CR
kubectl delete  -f https://raw.githubusercontent.com/Dimss/infinite-loop-operator/main/config/samples/bad.yaml

# manually remove test CRD
kubectl delete crd testcrds.mlops.cnvrg.io

# deploy good CR
kubectl create -f https://raw.githubusercontent.com/Dimss/infinite-loop-operator/main/config/samples/good.yaml

Additional context
The exact same flow will works without any issue on K8S v1.17.13

operator-sdk Helm operator has the same problem with infinite reconciliation loop on kubernetes 1.18 - might share the same root issue?

operator-sdk Helm operator has the same problem with infinite reconciliation loop on kubernetes 1.18 - might share the same root issue?

I was able to recreate this thanks for the excellent project example. One thing I've noticed between the good and the bad logs is as follows.
good
The good has 2 playbook_on_stats which prints out the following. Notice the changed value. The first run changed 1.
--------------------------- Ansible Task Status Event StdOut  -----------------

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

On the second reconcile it changed 0:
--------------------------- Ansible Task Status Event StdOut  -----------------

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

bad
Contrast that to the bad. On its first run it changed 2. Nothing to worry about there. It is the first reconcile.
--------------------------- Ansible Task Status Event StdOut  -----------------

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Let's check out the second reconcile. Hrm looks like it too changed 2.
--------------------------- Ansible Task Status Event StdOut  -----------------

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Now it seems we have a huge problem :) On the SEVENTH reconcile it still changed 2.
--------------------------- Ansible Task Status Event StdOut  -----------------

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

I'm still debugging the issue but wanted to add an update to what I've found so far.

So far I haven't found a bug in the ansible-operator itself, it is responding to events that are causing the reconcile to continue. There might be a problem with how the k8s modules are handling changes.

I bumped this to v1.5.0.


fix: tiny memory leak

Actually - ignore this. The tracking allocator was telling me that was a memory leak, but if I delete(str) then my whole program starts behaving unexpectedly, probably because something about the IDs becomes f*ed up, and I don't understand enough to be able to fix it :D !

Hey, yeah you can't delete that there because it is returned to the user. You have to determine for your own usecase when you want to do the deletion (when you are done with it).


Details Marketplace request has no userAgent

Microsoft.VisualStudio.Services.Content.Details

@joaomoreno I don't see any setting of the user agent in the code change? Is verification needed, should this be labelled debt instead?


Update mesa

There's a couple of blockers before we can actually update mesa

There's a bug in spirv-to-dxil.c right now where SPIR-V capabilities aren't properly set so OpCapability Shader gets rejected. This is bad and should be fixed

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30731

Updates to mesa_mako script: https://github.com/SnowflakePowered/spirv-to-dxil-rs/pull/8/commits/7268e7623c3e680d0d694844814ccee3c6353742#diff-afdb8f6229c797f896f21c0b0c7b56ca81cdc78acb736ce9c831253f2ac6c57f
u_format_gen.h is annoying and needs to be under util/format
blake3 utilities should be reimplemented in Rust

https://github.com/SnowflakePowered/spirv-to-dxil-rs/blob/7268e7623c3e680d0d694844814ccee3c6353742/spirv-to-dxil-sys/src/native.rs
We don't want to build a C copy of blake3 in tree, that would be bad.

investigate https://github.com/RustPython/RustPython/ to pull mesa locally

I don't mind basing off dxbc-rebase, but that branch needs cleaning up. Will wait until !30731 gets merged and rebase on top of that.


Is it Possible to get Tweets for all hours of the day?

Hello,
Is it possible to get tweets for all hours of the day? If i use query_tweets it always start to scrape from 23.59 from each day. I already tried to set the limit high and go day by day to get enough tweets until it reaches 0.00, but he still dont get enough tweets most of the time to get to the start of the day.
Also the API stops kinda random at high limits (sometimes just scrapes 1k sometimes 16k etc..)
It would be great if anyone got a solution for this problem.

Have you found a solution? I am also experiencing it. It only picks tweets in 23 hrs

not really,
i programmed a loop which scraped every 30 min with limit 56000 1 day of tweets. Its pretty random if its able to get the whole day or not.

I'm not sure what you think you're missing.  If you set your before and end date to scrape a single day, It scrapes from the beginning of the first day (00:00:00) to one second before midnight that same day (23:59:59).   Perhaps I've misunderstood - what are you missing?

@jomorrcode, it doesn't spool for the whole 24hrs.

I just tried it with Adele and it returned 3000+ rows from 4th of April to 6th

not really,
i programmed a loop which scraped every 30 min with limit 56000 1 day of tweets. Its pretty random if its able to get the whole day or not.

Can you share your code?

It must be intermittent or something.  I scraped #nfl with a begin date of March 03 and and end date of March 04 and the earliest tweet was March 03 00:00:00 and the last was March 04 23:59:48.

If you scrape a single day for Adele, what are the earliest and latest datestamps in the returned data?

If you scrape a single day for Adele, what are the earliest and latest datestamps in the returned data?

23:15:49 and 15:46:57 which returned 1670 rows. With the buzz around 'Adele' I expected more

Just querying for "adele" for April 5th, I got 4749 tweets.  The earliest is 2020-04-05 00:00:19 and the last one is 2020-04-05 23:59:55.    I have no idea how you verify  if any are missing.
from twitterscraper import query_tweets

begindate = dt.date(2020,4,5)
enddate = dt.date(2020,4,6)
query='adele'

tweets = query_tweets(query, begindate=begindate, enddate=enddate)

I do agree I've been seeing some oddly inconsistent behaviour.

Investigating here https://github.com/taspinar/twitterscraper/issues/311


[SPARK-11744][Launcher] Fix print version throw exception when using pyspark shell

Exception details can be seen here (https://issues.apache.org/jira/browse/SPARK-11744).

Test build #45950 has started for PR 9721 at commit 7f90c60.

Test build #45950 has finished for PR 9721 at commit 7f90c60.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/45950/
Test PASSed.

LGTM (although you could probably have a single flag for both).

OK, will update the code.

Test build #46059 has started for PR 9721 at commit 0534833.

Test build #46059 has finished for PR 9721 at commit 0534833.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/46059/
Test PASSed.

Merging to master/1.6.

Thanks @jerryshao and @vanzin for resolving this.


Fraud and theft

Yesterday digital currency x was withdrawn from my account
He stole 55,151. He was supposed to pay in dog currency.   To whom should I tell this pain? Please take care

@qartal2019 Thanks for posting the issue.
Your query would be best dealt with by the support team.
For the fastest resolution please see the link below to our dedicated support line:
Support : Help Center
Note: Click on the live chat icon at the bottom corner of the page to start a conversation

The address of the thief's wallet
UQClVtNNnmcqdgyWk_Qbv1-OWD_X5crFIaD1p-rw1W0HZ1_z

Write to the support team about your issues for further assistance.

Hello again
On Mon, Nov 11, 2024, 11:44 Tony-ptech @.***> wrote:

Write to the support team about your issues for further assistance.
—
Reply to this email directly, view it on GitHub
https://github.com/ton-blockchain/wallet-contract-v5/issues/123#issuecomment-2467495025,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALSIZY5SBAVJRFK6KOK5EAD2ABROFAVCNFSM6AAAAABRRH57ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRXGQ4TKMBSGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hello have you able to resolved your issues yet?

Not sure yet. The hacker stole the currencies of the wallet. He was supposed to send 30,000 Dogz digital currency in exchange.      My wallet address is UQDLlV3Hqnn508PMDALJksxExJNJrAT8xpyPCqP02J9asDOc

Not sure yet. The hacker stole the currencies of the wallet. He was
supposed to send 30,000 Dogz digital currency in exchange.      My
wallet address is UQDLlV3Hqnn508PMDALJksxExJNJrAT8xpyPCqP02J9asDOc
On Thu, Nov 14, 2024, 00:19 Tony-ptech @.***> wrote:

Hello have you able to resolved your issues yet?
—
Reply to this email directly, view it on GitHub
https://github.com/ton-blockchain/wallet-contract-v5/issues/123#issuecomment-2474754746,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALSIZY73XUK5UFY4RY2P2SL2AO3NHAVCNFSM6AAAAABRRH57ECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZUG42TINZUGY
.
You are receiving this because you were mentioned.Message ID:
@.***>

So sorry to hear that please kindly create chat with the support team so they can assist you with your issues.


De-duplicate GPU parameters.

Only define gpu_id and n_gpus in Learner TrainParam
Disable all GPU usage when GPU related parameters are not specified.

@RAMitchell It turns out there are some numeric difference between CPU and CUDA transform weren't caught by the tests before.  After disabling GPU this test won't pass:
https://github.com/dmlc/xgboost/blob/be0f346ec907b9b8c76597c2ee308fcd53ba311a/tests/python-gpu/test_gpu_prediction.py#L13
I tried to diff the outputs from two different settings.  The difference mostly come from GetGradient, starts at 1e-6 and accumulates up.  To pass the test rtol needs to be changed to 1e-3 from 1e-5.  Here is the mismatch rate with 5000x10 data set:
E               AssertionError:
E               Not equal to tolerance rtol=0.0001, atol=0
E
E               Mismatch: 0.04%
E                x: array([-0.108287,  0.163954,  0.096447, ..., -0.173721, -0.115342,
E                      -0.577273], dtype=float32)
E                y: array([-0.108287,  0.163954,  0.096447, ..., -0.173721, -0.115342,
E                      -0.577273], dtype=float32)

Another issue is, I'm currently hacking the configuration in Learner TrainParam, honestly I don't fully understand what's happening in there.

One last todo is either delay the configuration of Objective to after data is known, or resize the label checking result vector every time GetGradient is called.

it would be good to make sure the behaviour is expected upon serialisation/deserialisation of the model.

Good point, will try to make a test later.

One feature that would be nice to have is to log information

Will add a LOG(INFO) in GPUSet::Init.

@RAMitchell Actually I don't want to merge this PR.  I remember there were users who train different models on different GPUs.  Making a global variable will break it.  I need to think of something that doesn't break the functionality but also keep our implementation clean.

Suggestions are welcomed.

@hcho3 @RAMitchell I have a local branch that passes a pointer to const LearnerTrainParam to Predictor, Metric, TreeUpdater, GBM and LinearUpdater via Create method in respective class.  The change is quite massive and I would like to here about your opinions before proceeding.
The benefit of passing LearnerTrainParam is we can eliminate the duplication of gpu_id, n_gpus without creating a global variable.  As another benefit, nthread is also passed around,  creating an opportunity of eliminating global OpenMP variable.
The downside is the restructuring is massive, and all Create methods need to accept an addition parameter.

Also, this is a blocker for JSon.

Current structure of parameter handling causes duplication, as learning parameters are duplicated into objectives, metrics, and updaters. So your proposal has merits. Let me think over this and get back to you.

@hcho3 It also fixes the bug that XGBoost choosing GPU aggressively due to lack of global configuration.  Currently if the user didn't supply ngpu=0 parameter XGBoost will run metrics and objectives on GPU by default.

@hcho3 Could you help taking a look in Jenkins' cache?  It seems clang-tidy is running on an old copy of this PR: https://xgboost-ci.net/blue/organizations/jenkins/xgboost/detail/PR-4454/10/pipeline
In latest commit gpu_predictor.cu:376:3 is not a constructor.

@RAMitchell @canonizer Could you please explain why shared pointer is better?
From my point of view,  objects like Predictor do not own LearnerTrainParam, so its "borrowing" a pointer from Learner.  That's like when you what to access the internal data of std::vector by calling data(), or std::string by calling c_str(), you get a raw (const) pointer.  With the returned raw pointer you are only borrowing its content, but should not manage the content of the pointer (deallocate) because the ownership is still in std::string/std::vector.
Passing shared_ptr means the ownership is shared.  It's a semantic issue.  See
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-smart
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-ptr
and related topics.
I'm open the suggestions, but I need more context to understand why a shared pointer is a better choice.

@hcho3

Could you please help taking a look in Jenkins' cache?

Never mind, it works. Thanks.

Obviously let's not merge this until after 0.9

ping @hcho3

close #4494
close #4361

@trivialfis Thanks for fixing the pickling issue

@hcho3 Yes, this works great.  Please merge! :)

@pseudotensor Thanks for trying it out. I will review this PR and approve it today.

 ModuleNotFoundError: No module named 'xgboost.training'

@pseudotensor Can we have a repro script?

@trivialfis Currently, Python tests on Win64 are not idempotent, as they attempt to install and remove XGBoost package into the system Python environment. So running more than one jobs in the same machine will cause problems (one job installs XGBoost and another removes it). For now, I limited the number of jobs to 1 for Windows workers, but I'd like to make Win64 tests idempotent in a follow-up PR.

@pseudotensor Can we have a repro script?

That's just from the CI, seems fixed.

@pseudotensor sounds like the reason described by @hcho3 .

Thanks for clarification. I will follow up with a PR to stabilize Windows CI


printf from CVODES again

Summary:
CVODES uses printf() statements
Description:
This is a bad idea for Stan in general and causes problems on CRAN
Reproducible Steps:
goodrich@T540p:/opt/stan/lib/stan_math/lib/cvodes_2.9.0$ grep -R -F -n -w "printf" .

Current Output:
./src/nvec_ser/nvector_serial.c:280:    printf("%35.32Lg\n", xd[i]);
./src/nvec_ser/nvector_serial.c:282:    printf("%19.16g\n", xd[i]);
./src/nvec_ser/nvector_serial.c:284:    printf("%11.8g\n", xd[i]);
./src/nvec_ser/nvector_serial.c:287:  printf("\n");
Binary file ./src/nvec_ser/nvector_serial.o matches
Binary file ./src/sundials/sundials_direct.o matches
./src/sundials/sundials_direct.c:316:    printf("\n");
./src/sundials/sundials_direct.c:320:        printf("%12Lg  ", DENSE_ELEM(A,i,j));
./src/sundials/sundials_direct.c:322:        printf("%12g  ", DENSE_ELEM(A,i,j));
./src/sundials/sundials_direct.c:324:        printf("%12g  ", DENSE_ELEM(A,i,j));
./src/sundials/sundials_direct.c:327:      printf("\n");
./src/sundials/sundials_direct.c:329:    printf("\n");
./src/sundials/sundials_direct.c:336:    printf("\n");
./src/sundials/sundials_direct.c:340:      for (j=0; j < start; j++) printf("%12s  ","");
./src/sundials/sundials_direct.c:343:        printf("%12Lg  ", a[j][i-j+A->s_mu]);
./src/sundials/sundials_direct.c:345:        printf("%12g  ", a[j][i-j+A->s_mu]);
./src/sundials/sundials_direct.c:347:        printf("%12g  ", a[j][i-j+A->s_mu]);
./src/sundials/sundials_direct.c:350:      printf("\n");
./src/sundials/sundials_direct.c:352:    printf("\n");
Binary file ./lib/libsundials_nvecserial.a matches
Binary file ./lib/libsundials_cvodes.a matches

Expected Output:
None
Additional Information:
Provide any additional information here.
Current Version:
v2.15.0

Should we fork and just get rid of the printf statements?
Or can we somehow avoid compiling the files they're in?  Looks like "direct" might be some kind of command-line thing and presumably the serial one is for serializing vectors (which we also won't need).

I think direct refers to direct solvers and serial is for non-parallel execution. We need both.

Then the only solution I see is to fork CVODES and remove the printf statements in our versions.

Yep. This is what we have done in the past. I have possibly forgotten those patches when doing the 2.9.0 upgrade. I can take a look at this.

So I checked things and we have patched CVODES ourselves and these patches were originally applied to CVODES 2.8 and these were correctly propagated to the current 2.9.0. Essentially we have defined a
NO_FPRINTF_OUTPUT
macro which guards all calls to fprintf which directly print to stderr in the CVODES code. The quoted calls to printf are OK from my perspective as these are never called from us:

./src/nvec_ser/nvector_serial.c: This is in the N_VPrint_Serial function which we never call
./src/sundials/sundials_direct.c: These printf statements are in the PrintMat function which we also never call

@bgoodri : do you think thats safe to proceed as is or should we expand or add another NO_XPRINTF_OUTPUT?
From what I can tell is that all direct fprintf calls are taken out with the macro.

Yes, the NO_FPRINTF_OUTPUT worked previously I believed, which is why I was
surprised to see the problem come back. But it does not matter if we never
call the printf() functions; as long as the functions are in the shared
object CRAN complains. So, they need to get optimized away by the compiler
or we have to modify CVODES in the Stan repo.
On Tue, Apr 18, 2017 at 2:49 PM, wds15<EMAIL_ADDRESS>wrote:

So I checked things and we have patched CVODES ourselves and these patches
were originally applied to CVODES 2.8 and these were correctly propagated
to the current 2.9.0. Essentially we have defined a
NO_FPRINTF_OUTPUT
macro which guards all calls to fprintf which directly print to stderr in
the CVODES code. The quoted calls to printf are OK from my perspective as
these are never called from us:

./src/nvec_ser/nvector_serial.c: This is in the N_VPrint_Serial
function which we never call
./src/sundials/sundials_direct.c: These printf statements are in the
PrintMat function which we also never call

@bgoodri https://github.com/bgoodri : do you think thats safe to
proceed as is or should we expand or add another NO_XPRINTF_OUTPUT?
From what I can tell is that all direct fprintf calls are taken out with
the macro.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/issues/524#issuecomment-294944038, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADOrqsfzwUfFOPsCVXTLKyWBIvBtkhA4ks5rxQXTgaJpZM4NAbcq
.

could you take a look at the respective branch?
I have used the same macro name NO_FPRINTF_OUTPUT to if-def out those extra instances (which sometimes call printf instead of fprintf as the macro name may suggest). Adapting the macro name cause a number of required upstream changes as well so I left it as is.


⚠ Bofrost.fr has degraded performance

In a06dd56, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1843 ms

Resolved: Bofrost.fr performance has improved in 958e26a after 6 minutes.


Implement lynx browser for Issue #1

Let me know your thoughts on this, I'm open to other implementations.
There appears to be a conflict(s) that require resolution before merging.

Conflicts resolved.

@gsornsen I decided to discard your PR in favour of a more simple configuration and removing another "if".
Do you mind to submit another PR with your version of the README, so that you remain in the history?

@gsornsen I decided to discard your PR in favour of a more simple configuration and removing another "if".
Do you mind to submit another PR with your version of the README, so that you remain in the history?

Sure thing and No problem


requirements-dev.txt: Remove requirements copied from setup.py

Most of these were already pulled in via -r requirements.txt → -e .[all]; add the remainder with -e [all,server].

Codecov Report

Merging #3619 (e1396fe) into master (6519988) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3619      +/-   ##
==========================================
- Coverage   94.37%   94.35%   -0.02%
==========================================
  Files         420      420
  Lines       45888    45888
==========================================
- Hits        43307    43298       -9
- Misses       2581     2590       +9

Impacted Files
Coverage Δ

moto/batch/models.py
82.44% <0.00%> (-1.51%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6519988...e1396fe. Read the comment docs.

Codecov Report

Merging #3619 (e1396fe) into master (6519988) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3619      +/-   ##
==========================================
- Coverage   94.37%   94.35%   -0.02%
==========================================
  Files         420      420
  Lines       45888    45888
==========================================
- Hits        43307    43298       -9
- Misses       2581     2590       +9

Impacted Files
Coverage Δ

moto/batch/models.py
82.44% <0.00%> (-1.51%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6519988...e1396fe. Read the comment docs.


feat(masthead): grouped search results

Related Ticket(s)
#4845
Description
Adds grouped results to masthead search.
https://user-images.githubusercontent.com/909118/107543122-e8cdcd00-6b96-11eb-9897-7560e9eaf5f9.mp4
Changelog
New

masthead search grouped results

Changed

SearchTypeahead API to support custom endpoint APIs

Based on Kenny's and Jenny's participation in the KC design and engineering meetings: The features needed are customized to the KC platform and are not something that we would ever add to the carbon for ibm.com code base.

LGTM so far, will we set the env vars for the deploy previews after we merge?

LGTM so far, will we set the env vars for the deploy previews after we merge?

@annawen1 At the moment this can't be tested in our Storybook environments since the only search returning multiple sections is KC's. I plan on a standalone example for that using a canary package.


fix add missing flush context for BetaRowsetWriter::_add_block()

Proposed changes
If segment_id is set in flush context, we expect the entire memtable being flushed into one segment.
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run buildall


Cast inferred label to data type of label column

Overview
Prevents errors around trying to set ints in incompatible columns.
Description of changes
Cast the int values to be the same value as the label column in infer_label.
Author Checklist

[x] Linting passes; run early with pre-commit hook.
[x] Tests added for new code and issue being fixed.
[ ] Added type annotations and full numpy-style docstrings for new methods.
[ ] Draft your news fragment in new changelog/ISSUE.TYPE.rst files; see changelog/README.md.

I think #92 + #100 obviates the need for this update.
Let me know if you think it is still necessary, otherwise we should close this


Change error message on unknown M Code from 'G Code' to 'M Code'

This clarifies the panic message when an M Code is not supported.
It changes the message from
G Code not yet supported:
to
M Code not yet supported:
when an unknown M Code is encountered.
This does not change the unsupported G Code message.

Looks like I blindly copied and pasted from convert_g. Thanks for picking up on this!


policy: decouple policy calculation from regeneration

Tasks:

[x] Decouple identity policy from endpointy policy (#7542)
[ ] Shift identity policy resolution from endpoint to earlier

[ ] Allow cache/lookup of identity policy from endpoints

Get data from v1.6 and see how the cost of different parts of regeneration work out in various scenarios (various policies, # of identities, etc.).


Feature request: add attribute openbsd

Trying to compile a recent version of optimism on OpenBSD/adJ 7.6beta1 I found that it uses just.
On OpenBSD/adJ 7.6beta1, it was straightforward to compile just and run its tests except for two tests that depend on attributes for the supported platforms (linux, windows, macos):
 % uname -a
OpenBSD selah.pasosdeJesus.org 7.6 APRENDIENDODEJESUS.MP#1 amd64
% rustc --version
rustc 1.81.0 (eeb90cda1 2024-09-04) (built from a source tarball)
% git clone git@github.com:casey/just.git/
...
% cargo build
...
% cargo install --path .
...
% RUST_BACKTRACE=1 LANG=POSIX cargo test
...

failures:

---- attributes::multiple_attributes_one_line stdout ----
Bad stderr: Diff < left / right > :
<error: Justfile contains no recipes.
>exit 1

thread 'attributes::multiple_attributes_one_line' panicked at tests/attributes.rs:59:6:
Output mismatch.
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: integration::test::Test::run
             at ./tests/test.rs:293:7
   3: integration::attributes::multiple_attributes_one_line
             at ./tests/attributes.rs:48:3
   4: integration::attributes::multiple_attributes_one_line::{{closure}}
             at ./tests/attributes.rs:47:34
   5: core::ops::function::FnOnce::call_once
             at /usr/obj/ports/rust-1.81.0/rustc-1.81.0-src/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

---- os_attributes::os stdout ----
thread 'os_attributes::os' panicked at tests/os_attributes.rs:59:7:
unexpected os family
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: integration::os_attributes::os
             at ./tests/os_attributes.rs:59:7
   3: integration::os_attributes::os::{{closure}}
             at ./tests/os_attributes.rs:35:8
   4: core::ops::function::FnOnce::call_once
             at /usr/obj/ports/rust-1.81.0/rustc-1.81.0-src/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

failures:
    attributes::multiple_attributes_one_line
    os_attributes::os

test result: FAILED. 850 passed; 2 failed; 7 ignored; 0 measured; 0 filtered out; finished in 20.05s

error: test failed, to rerun pass `--test integration`

Since Rust supports OpenBSD:  https://doc.rust-lang.org/rustc/platform-support/openbsd.html, IMHO it makes sense to add initial support for OpenBSD in just by adding an attribute openbsd to enable recipes on OpenBSD.

Fixed in #2497.


Add directory structure and API support

Add directory structure and API support

Uploads would get a new parameter: path: / would be default, if not specified, but subdirectories could be specified. The server would automatically generate a tree and send it through a route /getdirs

#13


link_to_next_page generating link without controller path

Hi! I have a partial with a paginated table, so my index calls
= render 'table_view', :products => @products

The link to next page is generating a url without the controller path
= link_to_next_page products, 'Next Page', :params => params, :remote => true

Link generated was:
Next page

Instead of
Next page

I think I've encountered this issue.  The problem is that you probably have a route defined like
root to: 'products#index'
I "fixed" the problem by rooting to a different url.

I think @elmo is right, and the issue lives in your app, not in kaminari. I'm closing this issue since this is more like a question about how to use kaminari, not a bug report.


Issues with ktrain.load_predictor: get_tokenizer maybe should be explicitly called?

Hey there,
I have been using ktrain as a library for a containerized application that does not have internet access, I realize it has some issue.
When I do:
predictor = ktrain.load_predictor("some_model_path/located_within_container")

predictor.predict(["just some sentence"])

Where "some_model_path/located_within_container" is a path towards a distilbert-base-uncased based Huggingface model that has been finetuned on another dataset, saved through save_predictor, I get an error:
....
2022-02-08T03:15:15.586967260Z   File "/usr/local/lib/python3.8/dist-packages/ktrain/text/preprocessor.py", line 1290, in preprocess_test
2022-02-08T03:15:15.586970440Z     return self.preprocess_train(texts, y=y, mode='test', verbose=verbose)
2022-02-08T03:15:15.586974250Z   File "/usr/local/lib/python3.8/dist-packages/ktrain/text/preprocessor.py", line 1258, in preprocess_train
2022-02-08T03:15:15.586977540Z     tseq = super().preprocess_train(texts, y=y, mode=mode, verbose=verbose)
2022-02-08T03:15:15.586980580Z   File "/usr/local/lib/python3.8/dist-packages/ktrain/text/preprocessor.py", line 1008, in preprocess_train
2022-02-08T03:15:15.586983690Z     tok, _ = self.get_preprocessor()
2022-02-08T03:15:15.586986600Z   File "/usr/local/lib/python3.8/dist-packages/ktrain/text/preprocessor.py", line 957, in get_preprocessor
2022-02-08T03:15:15.586989750Z     return (self.get_tokenizer(), self.tok_dct)
2022-02-08T03:15:15.586992640Z   File "/usr/local/lib/python3.8/dist-packages/ktrain/text/preprocessor.py", line 938, in get_tokenizer
2022-02-08T03:15:15.586995730Z     raise ValueError(error_msg)
2022-02-08T03:15:15.586998680Z ValueError: Could not load tokenizer from model_name: distilbert-base-uncased. If distilbert-base-uncased is a local path, please make sure it exists and contains tokenizer files from Hugging Face. You can also reset model_name with preproc.model_name = '/your/new/path'.

Apparently, Huggingface would like to re-download the base tokenizer, but inside my container I do not have internet access.
I get it working by attempting the following hack:
predictor = ktrain.load_predictor("some_model_path/located_within_container")

predictor.preproc.get_tokenizer("some_model_path/located_within_container")

predictor.predict(["just some sentence"])

But I wonder if get_tokenizer should be called as part of the load_predictor? Something inside load_predictor be:
if isinstance(preproc, TransformersPreprocessor):
    preproc.get_tokenizer(fpath)

at: https://github.com/amaiya/ktrain/blob/master/ktrain/core.py#L1553
Please let me know your thoughts on it

Hi @ReluXingZeng
Thanks for taking the time to let us know about this.  It doesn't seem like this should be happening in the latest version of ktrain. I just tested loading predictors with no internet access, and everything worked on my end. I ensured the cache was deleted, so that the only place the tokenizer could possibly be loaded was from fpath.
I do recall implementing changes to avoid this issue in the past.  In the latest version of ktrain, I believe get_tokenizer(fpath) is automatically/implicitly called, as the model_name for saved predictors is updated to the supplied fpath to address various issues with offline training and usage.   In other words, the tokenizer should always be loaded from the saved predictor folder (without you having to do it manually).
What version of ktrain are you using?
It is very easy to implement your suggestion if necessary, but I'd like to better understand why the existing solution is not working for you. Thanks.

ktrain v0.29.2 was just released and now includes an implicit call to get_tokenizer(fpath) to prevent this problem from arising when loading predictors in air-gapped environments (added to _load_pretrained).
Thanks again for opening this issue.


[Dialog] fullWidth is capped by default 'sm' theme

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

When calling Dialog component with fullWidth=true and no other props I would expect the Dialog to take up the full width of the screen
Current Behavior

What's happening is because the of the defaultProps value for maxWidth is 'sm' the true width ends up being capped at 600px like so:

I only noticed the issue when I accidentally put 'lg' a value which is not supported and noticed that it worked like I wanted it to
Steps to Reproduce (for bugs)

Open Dialog component with props fullScreen=true

Context

I would like to submit a PR if approved to check if there is fullScreen applied and no maxWidth prop provided to ignore the defaultProps of 'sm'
Your Environment

Tech
Version

Material-UI
1.0.0-beta.26

React
16

browser
Chrome 63

etc

Im getting an error if I put maxWidth as "lg", wich is working, but showing an error at the console

@FernandoGOT  lg isn't supported:
maxWidth: PropTypes.oneOf(['xs', 'sm', 'md', false]),

Is there a reason for excluding 'lg'? There's a pretty big jump between 'md' and just disabling maxWidth altogether.
I'm curious if it was a conscious design decision or it just wasn't needed at the time.

@MoonDawg92 No good reason. Do you want to add this support?

Sure, I'll give it a shot!

@oliviertassinari I see that the maxWidth settings are using the theme's breakpoints. Should I also add an support for xl while I'm at it, or is that probably overkill?

@MoonDawg92 Awesome!
1920px, I doubt there is a valid use case for that value 😬.

That's what I figured too, so I'll leave it out for now. 😄

@oliviertassinari
PR is up: https://github.com/mui-org/material-ui/pull/12626


Test that Claims Set submission using dummy set is working

This one is one @ParkourPunk needs to test.


Helium hit

unsubscribe
From: RON1179 @.>
Sent: Saturday, December 4, 2021 6:39 AM
To: helium/HIP @.>
Cc: Subscribed @.***>
Subject: Re: [helium/HIP] Helium hit (Issue #318)
Reopened #318 https://github.com/helium/HIP/issues/318 .
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/helium/HIP/issues/318#event-5715659045 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ARX7ONZSNO5K3PWZXHCR6TTUPIKYDANCNFSM5JLSUTPA .
Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675  or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .   https://github.com/notifications/beacon/ARX7ONYR5W6CUCHIPOF2RBDUPIKYDA5CNFSM5JLSUTPKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGPAAAAAAKUVYESK.gif


[BUG] two fsx instances with two lustre-integration modules fails

Describe the bug
create an eks cluster and two fsx volums.
Now use path: git::https://github.com/awslabs/idf-modules.git//modules/integration/fsx-lustre-on-eks?ref=release/1.11.0&depth=1
two times to connect the fsx voulums to the cluster. This fails, one time with the EksHandlerRoleArn (which is not documented but needed) already existing and the second time with the set_permissions_job already existingj
To Reproduce

create eks cluster
create fsx volume
create another fsx volume
make two fsx-lustre-on-eks modules to connect the fsx with eks

Expected behavior
ressources are created
Screenshots
addf-llpdrsw-integration-lustre-on-eks-1a | 10/13 | 2:06:49 PM | CREATE_FAILED        | Custom::AWSCDK-EKS-KubernetesResource | addf-llpdrsw-integration-lustr-eks-cluster/manifest-SetPermissionsJob/Resource/Default (addfllpdrswintegrationlustreksclustermanifestSetPermissionsJob14F57FB1) Received response status [FAILED] from custom resource. Message returned: Error: b'Error from server (AlreadyExists): error when creating "/tmp/manifest.yaml": jobs.batch "set-permissions-job" already exists\n'

Unfortunately no. While it says "SUCCEEDED" in the state, the pvc of the previous integration module was deleted. Also, when trying this out with a third fsx volume and integration module it failed again. All seems kind of random

I think for the bug with the set-permissions-job we need to give it a unique name here:
"metadata": {"name": "set-permissions-job", "namespace": eks_namespace},
the rest: dont know

I gave a unique name to the permission jobs and removed the pv and pvc from depending on the namespace. Now it works after the second make deploy. the first gives:
❌  addf-llpdrsw-integration-lustre-on-eks-1b failed: Error: The stack named addf-llpdrsw-integration-lustre-on-eks-1b failed creation, it may need to be manually deleted from the AWS console: ROLLBACK_COMPLETE: The policy HandlerRolePolicy39F50E2E already exists on the role addf-llpdrsw-core-eks-clusterKubectlHandlerRoleF633-QNfBIeFDXTsB.


the otel-go-instrumentation not works as expected in ubuntu 22.04

Describe the bug
the otel-go-instrumentation not works as expected in ubuntu 22.04 local virtual machine from vmware.
Environment

OS: linux
Go Version: [e.g. 1.20.4]
Ubuntu 22.04.1,Linux version 5.19.0-41-generic

To Reproduce
Steps to reproduce the behavior:
follow the docs (https://github.com/open-telemetry/opentelemetry-go-instrumentation/tree/main/docs/getting-started)
kubectl apply -f emojivoto-instrumented.yaml -n emojivoto

the otel-go-instrumentation not works as expected.
enter kind's docker and
crictl ps -a
CONTAINER           IMAGE               CREATED             STATE               NAME                               ATTEMPT             POD ID              POD
c6ad06edfb1fc       0fc3761f3f87d       3 minutes ago       Exited              emojivoto-emoji-instrumentation    25                  b41b8e14bc802       emoji-5c59d4f5f9-8g6nq
431bdddf06d93       0fc3761f3f87d       3 minutes ago       Exited              emojivoto-web-instrumentation      25                  2bbe9a5bffdbb       web-7d9f79f7d7-gwbtt
39b22e4c6f6cf       0fc3761f3f87d       3 minutes ago       Exited              emojivoto-voting-instrumentation   25                  603e0f2e4ac92       voting-574dff6f47-wkd5l

and search first instrumentation's log:
crictl logs c6ad06edfb1fc
{"level":"info","ts":1683201490.9597812,"caller":"cli/main.go:37","msg":"starting Go OpenTelemetry Agent ..."}
{"level":"info","ts":1683201490.959896,"caller":"opentelemetry/controller.go:119","msg":"Establishing connection to OTLP receiver ..."}
{"level":"info","ts":1683201492.962331,"caller":"process/discover.go:55","msg":"found process","pid":19}
{"level":"info","ts":1683201492.963499,"caller":"ptrace/ptrace_linux.go:121","msg":"attach successfully","tid":19}
{"level":"info","ts":1683201492.9638128,"caller":"ptrace/ptrace_linux.go:121","msg":"attach successfully","tid":20}
{"level":"info","ts":1683201492.964077,"caller":"ptrace/ptrace_linux.go:121","msg":"attach successfully","tid":21}
{"level":"info","ts":1683201492.9644198,"caller":"ptrace/ptrace_linux.go:121","msg":"attach successfully","tid":22}
{"level":"info","ts":1683201492.9648137,"caller":"ptrace/ptrace_linux.go:121","msg":"attach successfully","tid":23}
{"level":"info","ts":1683201492.9651833,"caller":"ptrace/ptrace_linux.go:121","msg":"attach successfully","tid":24}
{"level":"info","ts":1683201492.9655643,"caller":"ptrace/ptrace_linux.go:121","msg":"attach successfully","tid":25}
{"level":"info","ts":1683201492.9658918,"caller":"ptrace/ptrace_linux.go:121","msg":"attach successfully","tid":44}
{"level":"info","ts":1683201492.9662254,"caller":"ptrace/ptrace_linux.go:121","msg":"attach successfully","tid":448}
{"level":"info","ts":1683201492.982999,"caller":"process/analyze.go:94","msg":"Detaching from process","pid":19}
{"level":"info","ts":1683201492.9832432,"caller":"process/analyze.go:139","msg":"mmaped remote memory","start_addr":"7F7175000000","end_addr":"7F7176800000"}
{"level":"info","ts":1683201492.9944782,"caller":"process/analyze.go:168","msg":"found relevant function for instrumentation","function":"net/http.HandlerFunc.ServeHTTP","start":2870464,"returns":[2870541]}
{"level":"info","ts":1683201492.9962378,"caller":"process/analyze.go:168","msg":"found relevant function for instrumentation","function":"google.golang.org/grpc/internal/transport.(*http2Client).createHeaderFields","start":4254816,"returns":[4260087,4266761,4266816]}
{"level":"info","ts":1683201492.9970098,"caller":"process/analyze.go:168","msg":"found relevant function for instrumentation","function":"google.golang.org/grpc/internal/transport.(*http2Server).operateHeaders","start":4296672,"returns":[4297106,4298064,4298299,4298532,4299573,4301293]}
{"level":"info","ts":1683201492.9972656,"caller":"process/analyze.go:168","msg":"found relevant function for instrumentation","function":"google.golang.org/grpc.(*ClientConn).Invoke","start":4758080,"returns":[4758386,4758556]}
{"level":"info","ts":1683201492.9977455,"caller":"process/analyze.go:168","msg":"found relevant function for instrumentation","function":"google.golang.org/grpc.(*Server).handleStream","start":4857024,"returns":[4857689,4859097,4859906,4860203,4860308]}
{"level":"info","ts":1683201492.9978814,"caller":"cli/main.go:79","msg":"target process analysis completed","pid":19,"go_version":"1.15.0","dependencies":{"contrib.go.opencensus.io/exporter/ocagent":"v0.6.0","github.com/beorn7/perks":"v1.0.1","github.com/census-instrumentation/opencensus-proto":"v0.2.1","github.com/cespare/xxhash/v2":"v2.1.1","github.com/golang/groupcache":"v0.0.0-20200121045136-8c9f03a8e57e","github.com/golang/protobuf":"v1.4.0","github.com/grpc-ecosystem/go-grpc-prometheus":"v1.2.0","github.com/grpc-ecosystem/grpc-gateway":"v1.14.4","github.com/matttproud/golang_protobuf_extensions":"v1.0.1","github.com/prometheus/client_golang":"v1.6.0","github.com/prometheus/client_model":"v0.2.0","github.com/prometheus/common":"v0.9.1","github.com/prometheus/procfs":"v0.0.11","go.opencensus.io":"v0.22.3","golang.org/x/net":"v0.0.0-20200425230154-ff2c4b7c35a0","golang.org/x/sync":"v0.0.0-20200317015054-43a5402ce75a","golang.org/x/sys":"v0.0.0-20200430082407-1f5687305801","golang.org/x/text":"v0.3.2","google.golang.org/api":"v0.22.0","google.golang.org/genproto":"v0.0.0-20200430143042-b979b6f78d84","google.golang.org/grpc":"v1.29.1","google.golang.org/protobuf":"v1.21.0"},"total_functions_found":5}
{"level":"info","ts":1683201492.9980018,"caller":"cli/main.go:85","msg":"invoking instrumentors"}
{"level":"info","ts":1683201493.012342,"logger":"allocator","caller":"allocator/allocator_linux.go:43","msg":"Loading allocator","start_addr":140125270966272,"end_addr":140125296132096}
{"level":"info","ts":1683201493.0141346,"caller":"instrumentors/runner.go:85","msg":"loading instrumentor","name":"net/http"}
{"level":"info","ts":1683201493.0148523,"caller":"inject/injector.go:91","msg":"Injecting variables","vars":{"ctx_ptr_pos":232,"is_registers_abi":false,"method_ptr_pos":0,"path_ptr_pos":56,"url_ptr_pos":16}}
{"level":"info","ts":1683201493.037925,"caller":"instrumentors/runner.go:85","msg":"loading instrumentor","name":"google.golang.org/grpc"}
{"level":"info","ts":1683201493.0421581,"caller":"inject/injector.go:91","msg":"Injecting variables","vars":{"clientconn_target_ptr_pos":24,"end_addr":140125296132096,"is_registers_abi":false,"start_addr":140125270966272,"total_cpus":2}}
{"level":"error","ts":1683201493.0505607,"caller":"instrumentors/runner.go:88","msg":"error while loading instrumentors, cleaning up","name":"google.golang.org/grpc","error":"field UprobeHttp2ClientCreateHeaderFields: program uprobe_Http2Client_CreateHeaderFields: load program: permission denied: 983: (bf) r2 = r0                     ; R0=scalar(id=53) R2_w=scalar(id=53): 984: (67) r2 <<= 32                   ; R2_w=scalar(smax=9223372032559808512,umax=18446744069414584320,var_off=(0x0; 0xffffffff00000000),s32_min=0,s3 (truncated, 1045 line(s) omitted)","stacktrace":"go.opentelemetry.io/auto/pkg/instrumentors.(*Manager).load\n\t/app/pkg/instrumentors/runner.go:88\ngo.opentelemetry.io/auto/pkg/instrumentors.(*Manager).Run\n\t/app/pkg/instrumentors/runner.go:36\nmain.main\n\t/app/cli/main.go:86\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:250"}
{"level":"info","ts":1683201493.050718,"caller":"server/probe.go:242","msg":"closing gRPC server instrumentor"}
{"level":"info","ts":1683201493.0507877,"caller":"server/probe.go:217","msg":"closing net/http instrumentor"}
{"level":"info","ts":1683201493.0802684,"caller":"grpc/probe.go:241","msg":"closing gRPC instrumentor"}
{"level":"error","ts":1683201493.0803745,"caller":"cli/main.go:88","msg":"error while running instrumentors","error":"field UprobeHttp2ClientCreateHeaderFields: program uprobe_Http2Client_CreateHeaderFields: load program: permission denied: 983: (bf) r2 = r0                     ; R0=scalar(id=53) R2_w=scalar(id=53): 984: (67) r2 <<= 32                   ; R2_w=scalar(smax=9223372032559808512,umax=18446744069414584320,var_off=(0x0; 0xffffffff00000000),s32_min=0,s3 (truncated, 1045 line(s) omitted)","stacktrace":"main.main\n\t/app/cli/main.go:88\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:250"}

Expected behavior
everything works  as expected
Additional context
  emojivoto-emoji-instrumentation:
    Container ID:   containerd://d90fdecaaaf9d70b0dc8b5e798a2894325d99094394eea0766e82cb519de746d
    Image:          otel-go-instrumentation
    Image ID:       docker.io/library/import-2023-05-04@sha256:e1e0a2ede7b8d3edfc5eb3735ba942d48ad60a5366f484a9ef42b38ac3fb36da
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Thu, 04 May 2023 13:13:27 +0100
      Finished:     Thu, 04 May 2023 13:13:30 +0100
    Ready:          False
    Restart Count:  28
    Environment:
      OTEL_GO_AUTO_TARGET_EXE:      /usr/local/bin/emojivoto-emoji-svc
      OTEL_EXPORTER_OTLP_ENDPOINT:  http://jaeger:4317
      OTEL_SERVICE_NAME:            emojivoto-emoji
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-d4rfb (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  kube-api-access-d4rfb:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason   Age                  From     Message
  ----     ------   ----                 ----     -------
  Warning  BackOff  1s (x548 over 119m)  kubelet  Back-off restarting failed container

@JamieDanielson PTAL

Unfortunately this is a known issue with the gRPC instrumentation probe that we are working on. This is the issue reported in #78, and referenced in the emojivoto PR update #129. We're also working on e2e tests for gRPC instrumentation in #106 so once this is fixed we can monitor for regressions.


Runtime Configuration

is any plan to split the existing configuration into startup time configuration and runtime configuration allowing admins to modify certain configuration without the need to restart the server, such as loggers.

One can configure the logging levels through the admin task endpoint. Admittedly, not as powerful as having the entire configuration being modified at runtime (à la logback.xml)
There is not a plan to split into the configuration into two files.

How should to work in the end. Lets say you have your WatchService and it signals a changed config. Should DW now simply parse this file and override the fields of the existing config object? That would work without any kind of API changes, but is kind of risky. If the app changed any field in the config that is lost now. This could also create racing conditions.
On the other hand the WatchService could throw an event. Maybe the Configuration base class could contain an update method that is called with the changed Configuration and the user has to implement it himself?


Console warning: "Unbalanced calls to begin/end appearance transitions" on App start

When a passcode is set, and you start the app, the following warning appears in the console:
2015-09-03 08:31:41.141 PasscodeLockDemo[2751:663098] Unbalanced calls to begin/end appearance transitions for <UIViewController: 0x12f6517b0>.
After doing some research, this issue is caused from line 21 on the PasscodeLockPresenter.swift file.  When creating a UIViewController() w/o specifying the nib file to pass in to the initializer, it is causing an animation when it's added to the window, but there are other animations already currently taking place via the normal startup means on the mainWindow object (best I can tell.)

I guess I should've mentioned this, that the pull request that I created has a fix for this.

Thanks!

Actually the warning is caused by presenting the PasscodeLockViewController before the rootViewController of the passcode window has a chance to appear. Your pull request has some issues that I will fix in my next commit.
Thanks!


'module' object has no attribute 'Consul' when execute script as non-root user

Hi,
I have an issue on CentOS 7 with python-consul 0.6.1:
    try:
        c = consul.Consul(host=consul_host, port=consul_port)
    except Exception, e:
        sys.exit("Failure to connect. " + str(e))

When I execute this script (where consul_host = localhost and consul_port = 8500) as non-root user, I get the following message:
Failure to connect. 'module' object has no attribute 'Consul'

When I'm executing the script as root, everything is fine.
What am I doing wrong?

Hi there!
Is it possible to reply with the output of:
find $(python -c "import os, consul; print(os.path.dirname(consul.__file__))") -ls

Hi @cablehead
Can do, but it was related to the very tight rights on /usr/lib64/python2.7/site-packages. They were only accessible for user root and nothing else. A chmod 755 -R * did the trick.
So, will close the ticket.


Whitespace in contact form (message field)

When I open the theme, the message field in the contact form is already pre-filled with about a dozen spaces. This way, the cursor blinks halfway the message field and the field tip ("Message*") is hidden. I've only run the theme locally thus far.

Should be fixed by PR #61. @aosavi are you still experiencing this issue?

@aosavi You have to re-build/deploy your repo for the fix to appear. For this repo, the latest commit triggered a build and deploy to GitHub Pages, and once that was done the fix appeared.

@raviriley Thanks, that's good to know. I'm not sure how to do that though. Could you tell me, or is there documentation that I can use to find out? I've generated a website from your repo once and never rebuild it. Is that necessary for updates to be applied? Thanks!

@aosavi if you have your repo set up with GitHub Pages, simply push anything to the repo and it will re-deploy.

For example I added a space to the README to trigger a deployment for this repo: https://github.com/raviriley/agency-jekyll-theme-starter/commit/72f949fc00bc58f8e79dd771510bcd1278f72c2e

@aosavi great! Thanks for the kind words :)


[IOTDB-3880] Optimize asyncclientpool retry logic

Optimize asyncclientpool retry logic
move create handler to AsyncClientPool

 Will these methods produced npe?

fixed~This part has been modified


Add TypeScript declaration file

Hi everyone!
Thanks for this great plugin ☺
I added a type declaration file and tried to stick to the same style as used in @fastify/static. For the linting to work I also adapted the ESLint configuration (uses the same as fastify-static).

Thank you so much — this is definitely going into the next release.


Implement dynamic query caching

Fixes  #2040
Solution
Introduce normalization cache to reduce dynamic query overhead
Notes
@deusaquilus Suggest introduce some new AST as lifting placeholder. But that will break the normalization test case.
So this pr just replace the lifting value with LiftToken .
Also LiftToken is an internal data structure used inside  normalization cache, it seems reasonable not being a part of AST
Checklist

[x] Unit test all changes
[x] Update README.md if applicable
[x] Add [WIP] to the pull request title if it's work in progress
[x] Squash commits that aren't meaningful changes
[x] Run sbt scalariformFormat test:scalariformFormat to make sure that the source files are formatted

@getquill/maintainers

This looks really great!
Please add a couple more manual tests building up some AST trees (similar to what QuotationSpec does) and then using StablizeLifts.stablize to check the right changes have happened, then using StablizeLifts.revert to see that we changed back to the original thing. Something like this:
"can stablize and revert to get previous result" in {
  val treeWithScalarLift = quote { query[Person].filter(p => p.name == lift(name)) }
  val (stablizedAst, state) = StablizeLifts.stablize(treeWithScalarLift.ast)
  val PQ = quatOf[Person]
  stablizedAst must matchPattern { // I think I got this right but not 100% sure
    case
      Filter(
        EntityQuery("Person", List())(PQ),
        Ident("p")(PQ)
        BinaryOperation(Property(Ident("p"), "name"), BinaryOperator.`==`, ScalarLift("p", Token(0), _)
      ) =>
  }
  val originalAst = stablizedAst.revert(stablizedAst, state)
  originalAst mustEqual treeWithScalarLift.ast
}

Could you please try to do the same kind of test with ScalarQueryLift and the others?

Looks great! Thanks!

@jilen Thank you so much for adding the tests and this great functionality!
Any chance you'd be willing to do this in ProtoQuill too sometime :sweat_smile: ?
ProtoQuill has no lifts in the AST itself so it's probably a bit easier...

@deusaquilus  I'll try to do it in few days.

Thank you!!!!


Fix issues with patch

The composer-install target was failing to apply the patch because "composer install" was run under Docker, so the files were owned by root when running patch as a regular user. (There was also a typo in the directory name.)
Circle now gets as far as running phan, which has some regressions that need to be fixed again.

Was already fixed latest commit..


Object Side Bar Report - objects not loaded

In current version 5.3.2:
In Report view no objects are loaded (Loading ...  is displayed)
Export of report contains objects as expected.
@Y4nnikH have you got time to check this?

closing again - not reproducible on a fresh install


Can't get a tape.gradient when tf.signal.frame is used.

Tensorflow 2.0.
I believe this is related to the tf.gather problems that have been noted already.
    inputs = tf.keras.Input(shape=data_loader_train[0][0][0].shape, name='img') ## (108, 192, 3)
    x = layers.Conv2D(32, 3, activation='relu')(inputs)
    x = layers.Conv2D(16, 3, activation='relu')(x)
    block_1_output = layers.MaxPooling2D(2)(x)

    x = layers.Conv2D(16, 3, activation='relu', padding='same')(block_1_output)
    # x = layers.Conv2D(32, 3, activation='relu', padding='same')(x)
    block_2_output = layers.add([x, block_1_output])
    block_2_output = layers.MaxPooling2D(2)(block_2_output)

    x = layers.Conv2D(16, 3, activation='relu', padding='same')(block_2_output)
    # x = layers.Conv2D(32, 3, activation='relu', padding='same')(x)
    block_3_output = layers.add([x, block_2_output])
    block_3_output = layers.MaxPooling2D(2)(block_3_output)

    x = layers.Conv2D(32, 3, activation='relu')(block_3_output)
    x = layers.GlobalAveragePooling2D()(x)

### if this part is included we get an error ##########
    # x = layers.Flatten()(x)
    x = tf.signal.frame(x,args.num_frames,1, axis=0)
    x = layers.Flatten()(x)
##############################
    x = layers.Dense(16, activation='relu')(x)
    x = layers.Dense(1)(x)
    counts = tf.keras.activations.softplus(x)
    # x = layers.Dropout(0.5)(x)
    # outputs = layers.Dense(10, activation='softmax')(x)

    model = tf.keras.Model(inputs, counts, name='toy_resnet')

Now if we do this....
            with tf.GradientTape() as tape:
                loss = tf.math.squared_difference(tf.reduce_sum(model(x_mb)), y_mb)

            grads = tape.gradient(loss, model.trainable_variables)

we get the following error at "grads = ..."
Error = AssertionError: Expected all args to be Tensors or Variables; but got CompositeTensor: [<tensorflow.python.framework.indexed_slices.IndexedSlices object

@johnpjust
Looks like code is incomplete. Request you to provide complete code snippet or colab link to reproduce the issue in our environment. It helps us in localizing the issue faster. Thanks!

@ravikyram  Thanks -- after more examination I found it's not an interaction with the tape.gradient, but isolated to VRAM (GPU) memory leaks in two separate functions in TF (timedistributedlayer & tf.signal.frame).  I'm closing this and focusing on a separate thread.  Thanks.


Docker: Add support for remote DOCKER_HOST

Description
Docker information should not only be shown when the user is in a directory with a local Dockerfile, but also if they are connected to remote Docker daemons. This can either be via docker-machine or by setting the environment variable DOCKER_HOST to a remote Docker daemon exposed over TCP (usually port 2375).
Screenshot

Hi @denysdovhan, is there anything missing to get this merged?
Maybe @Runrioter or @jgsqware can review this change?

Hmm, sadly nobody seems to review this change, and I've already a follow up-PR to this one in mind. Starting Docker 19.x, they introduced a third way to connect to remote machines "Docker contexts", which I'd love to add as well.
This would make the Docker plugin complete.

Pinging previous contributors to docker section.
// @RolfKoenders @jgsqware @bleys @aj-may @codepunkt @sarkkisjuha @charlesvdv @aheaume

That's an awesome idea, i'd love to have this. Thanks @fhemberger! ❤

Thank you @fhemberger


[Question/Bug?] Exiting with a key/mouse press

Environment:

OS: MacOS Sequoia 15.0 (24A335)
zsh: zsh 5.9 (arm64-apple-darwin24.0)

Currently, pressing any key will just kill the shell that's running the screensaver. This is probably not the intended behavior, correct? It'd be nice for any key (or mouse) press to bring one back to the original shell, unaffected by the screensaver daemon.

this same is happening with me i use zsh and tmux and pressing any key closes the windows or shell or tmux I am not sure which it is closing. here is a recording
Screencast From 2024-10-05 00-16-40.webm

Oh, odd. I'm developing on Sequoia/Zsh so I'm unsure why the behavior would be different. I'll dig into this and see if I can fix it with the existing command, but if not it should be easy for me to add an option that just creates an inner shell first.

Can I ask which terminal emulator you use?

Mine's iTerm2 v. 3.5.5.

@cxreiff Hii,
For me it's
Kitty, zsh(with zinit) and tmux

Hello @cxreiff, any updates ?

So its difficult for me to know for sure as I've been unable to recreate this myself, but I asked around and I do have some things you could try for us to identify the cause.

Do either of you use zsh extensions/plugins? I talked to one person who had zsh extensions set up (fast-syntax-highlighting or zsh-autosuggestions) and those interfered with this TMOUT technique.

It could be that on my end, either the screensaver command or the "zle reset-prompt" are resetting the timeout timer, but for you they aren't. If you run TMOUT=5; trap "ttysvr; TMOUT=0; TMOUT=5; zle reset-prompt" ALRM does it work? Or TMOUT=5; trap "echo test; ttysvr; echo test; zle reset-prompt" ALRM?

The only code in this repo that has anything to do with this is the TMOUT=5; trap "ttysvr; zle reset-prompt" ALRM shell command that the --init option generates, so it almost definitely is to do with something in your .zshrc.

Hi @cxreiff,
Thank you for your suggestions and insights. I followed the first point you mentioned, and as you suspected, the issue was related to my shell customizations. Starting the zsh shell with the --no-rcs option resolved the problem—when I press any keystroke, the shell session persists and does not exits.
In my configuration, I had the plugins fast-syntax-highlighting, zsh-autosuggestions, zsh-completion, and zsh-history-substring-search. This confirms that the first two plugins are the primary cause of this unusual behavior. However, I am unsure if the latter two also contribute to the issue. For reference, I’ve linked my .zshrc file here.


[Event Change Request] codeunit 30189 "Shpfy Variant API" OnBeforeSendAddShopifyProductVariant

Describe the request
I would like to submit a request regarding our integration between Business Central and Shopify. We need to add additional information to the product synchronization, such as InventoryItem.CountryCodeOfOrigin and InventoryItem.HarmonizedSystemCode. To achieve this, we need to be able to add additional fields (removing the internal tag) on the InventoryItem table and to customize the request adding product variants (adding "isHandled")
internal procedure AddProductVariant(var ShopifyVariant: Record "Shpfy Variant"): Boolean
var
        ShopLocation: Record "Shpfy Shop Location";
        NewShopifyVariant: Record "Shpfy Variant";
        JResponse: JsonToken;
        GraphQuery: TextBuilder;
        IsHandled: Boolean;
begin
        ProductEvents.OnBeforeSendAddShopifyProductVariant(Shop, ShopifyVariant, IsHandled);
        if IsHandled then
        exit;
...

[IntegrationEvent(false, false)]
internal procedure OnBeforeSendAddShopifyProductVariant(ShopifyShop: Record "Shpfy Shop"; var ShopifyVariant: Record "Shpfy Variant"; IsHandled: Boolean)
begin
end;

table 30126 "Shpfy Inventory Item"
{
    Caption = 'Shopify Inventory Item';
    DataClassification = CustomerContent;
...
}

Additional context
The Shopify connector doesn't fully respond to our customer need.
Internal work item: AB#556907

We cannot add this event. IsHandled events are anti pattern, in this case it gives ability to completely bypass Microsoft code that creates and sends the request to create a variant in Shopify.
I also do not fully understand your scenario. "Shpfy Inventory Item" table is only used for importing, not exporting. But the event you are interested in is used when exporting.
We have taken a different approach with Shopify Connector extensibility, so let's try that:
"As you know the Shopify Connector is made non-extensible. We plan to change it in the future, and we want to try a different model.
Motivation: we want to avoid misuse of extensibility to address bugs, minor improvements, or gaps – all of that end-user expects to be part of product. Millions of events spread across the code reduce readability and scalability, increase maintenance and upgrade costs for all parties.
As source code of Shopify Connector is on GitHub we would like to reuse pattern we have for System App:
Prioritize submitting improvement over extensibility. For example, if your customer needs to export multiple translations of a product to Shopify, instead of asking for making some objects extensible – submit PR that implements this feature.
If extensibility is really necessary – for example to orchestrate multiple extensions dealing with various sales channels – please create PR directly. Remember to write the proper justification of scenario.
We will not process extensibility requests for connector registered as Issues on GitHub."


.gitleaksignore bug

Hi,
As I tested .gitleaksignore file does not ignore anything without the proper fingerpring, is it possible a "whitecard" solution in this case?
For example, I used this sample:
acce01f2338434a78f6a4a06a097b0fd23280484:README.md:aws-access-token:218
README.md:aws-access-token:204
README.md:aws-access-token:205
README.md:aws-access-token:244
In this case gitleaks, does not ignore the README.md without the hash, so  just the first line works.
Any advise?
Thanks

This could either be a bug or documentation, depending on your perspective. As a user, I would expect the following example to ignore all aws-access-token findings from README.md lines 204, 205, and 244.
https://github.com/gitleaks/gitleaks/blob/839f114f2b2ca9429300e545aa5c93a2caf2e3d8/.gitleaksignore#L658-L660
However, the code seems to only check for exact matches, meaning those will only apply if you perform a scan with the --no-git option.
https://github.com/rgmz/gitleaks/blob/839f114f2b2ca9429300e545aa5c93a2caf2e3d8/detect/detect.go#L596-L606
Ideally, it should be possible to exempt a fingerprint across ALL commits.

Hi,
Any updates on this one?
We are facing the same issue and would love to be able to ignore some false positives with just specifying the file and the line. Because currently we need to create a number of PRs when we merge a branch to master that contains a gitleaks ignore and then when we merge the master branch into other branches, because the merge commits contain this change and gitleaks believes that it is a newly defined secret, so we end up with something like this:
xxxxx.README.md:204
yyyyy.README.md:204
zzzzz.README.md:204
bbbbb.README.md:204
cccccc.README.md:204
Thanks in advance!


CHEBI:26167

This is not searchable just by CHEBI ID
www.ebi.ac.uk/chebi/searchId.do?chebiId=CHEBI%3A26167
Can this be fixed as I wat to xref it for a polar amino acid transporter complex

The entry was not searchable since it was a 1-star entry. I have now annotated this entry and marked it up to 3-stars. It should be searchable by tomorrow.


没必要每个文件里都写完整版的LICENSE

Weex 项目的源码文件每个都写了几百行的LICENSE，开源项目除了顶层的LICENSE文件，其他只需要十几行写简略版的就够了。
见：

而Weex的：

好建议， @sospartan 我们要不要简化一下？

@Jinjiang 可以的 这是android编译的时候 插件自动实现的

This PR/issue doesn't receive response since Weex migrated to Apache two years ago and this repository is no longer active yet.
Feel free to ask question in new repository and thanks for your contribution.

This issue is outdated for a long time and will be closed now. You can create a new one if you still have questions.

This issue is outdated for a long time and will be closed now. You can create a new one if you still have questions.