text:
Projektübersicht / Filter

Liste der verfügbaren Filter etwas kondensieren, eher so wie 'ne Wolke anstatt einer Liste.
Speichern der zuletzt benutzten Filter (Projektgebunden).
Spalten dynamisch in der Übersicht auswählen können, Name, Description sind eigentlich erstmal uninteressant.
Allgemein weniger Spacing in den Listen.

Liste der Filter wurde verkleinert.

Die Filter klappen nichtmehr aus wenn ich welche hinzugefügt habe, kann also die Werte der Filter nichtmehr wählen.

Auf der aktuellen Version läuft es bei mir. Update nochmal und führ vorher "npm install" aus. Da ich neue packages hinzugefügt habe, kann es zu Problemen kommen, wenn die nicht aktuell sind.

Ah okay, ich hab das Problem jetzt auch. Tritt nur beim Navigieren zu der Seite auf. Beim neu laden läuft es. Arbeite am fix.

Habs gefixt. Eigenartiger Bug.

Top, nu hab ich gleich noch was gefunden, da müssen wir uns aber vllt. mal unterhalten was mehr Sinn macht, da die Flags einfach Integer sind, wirs natürlich hässlich, wenn man bei max_epochs z.B. 5 angibt, da will man natürlich nicht dass die "Flag" übersetzt wird weil es ja an dieser Stelle keine Flag sondern halt die Zahl 5 ist. Eine Möglichkeit wäre, dass man quasi für jeden Parameter 'nen Typ (Flag, Int) angeben kann und dementsprechend übersetzt wird oder nicht, oder die Flags werden alle in Hexadezimal umgestellt. Kein Plan was schlauer ist. Jedenfalls wäre es nice, wenn man auf Filter klickt, dass die Felder farblich getoggelt werden können, dann sieht man sofort welche man schon angeklickt hat und kann diese auch noch rausnehmen wenn man sich verklickt hat ;). Wann sollen wir uns mal wieder treffen?

Alle Punkte soweit umgesetzt.

Hm, ich kann die Filter jetzt toggeln, aber sie erscheinen nicht links in der Liste :o

jo. das war mein Versuch die Filter zu sortieren. Hat nicht geklappt. Sie wurden angezeigt wenn man zu einer anderen Seite navigiert und dann wieder zurück. Habe ich jetzt erstmal raus genommen. Muss ich mir was anderes überlegen.

authors: goforthanddie lgueldenhaupt

repo: lgueldenhaupt/BA


text:
OS_FrontendMaster-dl

tool cannot download workshops on front end Masters

This issue is not helpful unless you provide more details what problem are you currently facing. Please reopen the issue later when you can add a more detailed description to the issue.

source: gharchive/issue

authors: li-xinyang ssanusi

license: mit

license_type: permissive

license_source: bigquery


text:
Why don't bodies sometimes collide?

How can this be configured?
Video:
https://github.com/liabru/matter-js/assets/25684443/bd0a8523-d791-48f8-bcb6-d15992e43774

When I encounter this situation, the console will report an error

authors: MLH-AIDS MaxMinimus

repo: liabru/matter-js


text:
MouseConstraint preventing clicks on buttons on mobile.

<html>
  <body>
    <div id="mouse">
      <button id="button">Test</button>
    </div>
  </body>
</html>

<script>
  import Matter from "matter-js";

  document.querySelector("#button")!.addEventListener("click", console.log);

  const engine = Matter.Engine.create();
  Matter.Composite.add(
    engine.world,
    Matter.MouseConstraint.create(engine, {
      mouse: Matter.Mouse.create(document.querySelector("#mouse")!),
    }),
  );
</script>

I cant seem to click on the button on mobile when there is a MouseConstraint. Shouldn't at least nothing happen when there is no body at the location you touch, especially in this example when there is no bodies at all?

I don’t see how/where the matterJS is being placed with this dummy code. So I can’t verify if the problem is associated with an overlaying canvas element.
Nor do I understand why there is an explanation mark at the end of mouse: Matter.Mouse.create(

@JeffreyArts Presumably, the !s are TypeScript, but you're right it's unclear because TS doesn't work in <script> tags. A complete, runnable example is missing here.

authors: JeffreyArts MichaelPriebe ggorlen


text:
layout_behavior属性缺失

Error:(25) No resource identifier found for attribute 'layout_behavior' in package 'com.liaoinstan.demospring'

(⊙_⊙;) ...什么

authors: fishsoft liaoinstan

repo: liaoinstan/SpringView

license_source: github-api


text:
FileHandleResolver for model asset loaders

The G3dModelLoaders use JsonReader/UBJsonReader. I wrote my own FileHandleResolver and now the Modelloaders search in the wrong place. I guess the json readers need the resolvers as well? At least they get files passed to in the loader and look at the wrong place.

No, the json readers don't need to resolve any files. Please include enough information to reproduce the issue you're reporting. https://github.com/libgdx/libgdx/wiki/Getting-Help

Closing this. If you still think that this is an issue then please provide the requested information and we'll reopen.

will do. for now I've found another solution. :)

repo: libgdx/libgdx


text:
com.badlogic.gdx.backends.lwjgl.LwjglGL20.toIntBuffer problem

	private IntBuffer toIntBuffer (int v[], int offset, int count) {
		ensureBufferCapacity(count << 2);
		floatBuffer.clear(); // !!!! we use intBuffer, but clear floatBuffer
		com.badlogic.gdx.utils.BufferUtils.copy(v, count, offset, intBuffer);
		return intBuffer;
	}

https://github.com/libgdx/libgdx/wiki/Issue-Tracker

authors: fogone xoppa


text:
[Bug] one validator and one fullnode nodes rebooted on testnet

🐛 Bug
Unexpected node reboots were observed on testnet:

one validator node (val-5) rebooted at 2020-07-02T16:01:30 PST
one fullnode node (fn-0) rebooted at 2020-07-02T03:02:30 PST

To reproduce
There is no known reliable repro step at the moment.
This is the first recorded incident of validator reboot, and second for fullnode.  Fullnode was first seen rebooting on its own in a8cd371, deployed during the week of 5/20.
Expected Behavior
These two nodes are expected to remain up and in operation until next scheduled update.
System information
Please complete the following information:

Libra Version 21768f2
Rust Version 1.44.0

Additional context

All validators were connected to their network peers
All fullnodes were connected
val-5 's disk filled up before it rebooted
No log was found in the ECS instances to drill down further
ECS console recorded the event but no further info was available

can we ensure we retain the logs of crashed container in the future?

can we ensure we retain the logs of crashed container in the future?

We already did. There is log rotate. It was just unfortunately in this case the logs weren't there as they should have been.

cc @bmwill - flagging this issue to see if something the observability design can help with.

repo: libra/libra


text:
[cluster-test] [ci] Decouple --run-ci-suite and --changelog

This allow to combine --changelog and --run-ci-suite flags.
This is needed because when cluster test runs from CI, it can't reliably get from-to commits for changelog
For CI run we will need to specify them manually:
ct --run-ci-suite --changelog commit_from commit_to

@bors-libra delegate+

:v: @andll can now approve this pull request

@bors-libra r=sausagee

:pushpin: Commit 201a690 has been approved by sausagee

:hourglass: Testing commit 201a6907289409732d79416a0372ac9720de73fc with merge 45c946130e2fe7502f22fc73f5ffdd82744edc77...

@bors-libra r=sausagee

:pushpin: Commit 840675f has been approved by sausagee

:hourglass: Testing commit 840675fc0db6efbb3973b46cad247b2d91a49ea3 with merge 15a41a809e010b875c3156c66e8b1ba229bc99d6...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: sausagee
Pushing 15a41a809e010b875c3156c66e8b1ba229bc99d6 to master...

source: gharchive/pull-request

authors: andll bors-libra sausagee


text:
Consistent naming of 0x0

Why is one 0x00 and the other 0x0? Looks weird.

Thanks for the contribution! This looks like a good change, and we can definitely merge it.
However, due to some CI changes put in place this past week, to get CI to run the best thing for you to do is to close this PR and make a new one. Going forward this won't be an issue, but unfortunately, we do not have a way to force CI to run for older PRs.

authors: revmischa tnowacki


text:
Cherry-pick PR #6506 into release-0.23: [writeset-generator] Implement a primitive tooling for generating genesis writeset

This cherry-pick was triggerd by a request on #6506
Please review the diff to ensure there are not any unexpected changes.

Motivation
This implements an offchain binary tool that would be used by node operators to generate genesis writeset in case of some catestropic scenarios. In case of a majority of validator lossed, this tools, together with the db bootstrapper will be used to remove bad validators to kick validators out from the network.
The flow should be following: when we lost 1/3 of the node in the network, each node operator would:

Pause their own network
Sync their node to the latest committed state.
Use this tool to generate waypoint transaction. e.g:
run cargo run --bin libra-writeset-generator -- --output <path-to-genesis-transaction> remove-validators <addresses to be removed>
Spawn up the db bootstrapper with the genesis transaction generated in step 4 provided.

Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Added e2e test for the generated transaction.

cc @sherry-x

/land

@sherry-x :exclamation: This PR is still missing approvals, unable to queue for landing

/land

authors: bors-libra sherry-x


text:
glorious model O showing wrong dpi list again?

Information
ratbagd version (ratbagd --version): 0.17
Distribution: Arch
Kernel version (ex. uname -srmo): Linux 6.5.5-273-tkg-pds x86_64 GNU/Linux

just like in issue #1476
dpi shows from 0 to 2000, while it should show from 0 to 12000 for the model O, not sure how long this has again been broken for

Hi! It's probably not like that issue again, it is the same issue. We haven't had a new release yet, I've only recently pushed through the last blocker, so I hope release soon.
Since you are on Arch, you can use {libratbag,piper}-git from AUR for now, it's what I do myself. :smile:
By the way, if you by any chance have an account on AUR, could you ask piper-git maintainer to drop the libibus dependency? Piper never actually depended on it.

oh my bad, thought there was maybe a minor version release since april
also doesn't explain how it fixed itself after a ratbag update a few days after u responded to me in that issue
anyways, cheers and sorry for my dumass

repo: libratbag/libratbag

license: MIT


text:
cmake: Debug builds have a 'd' appended to the library name

Similar to https://github.com/libsdl-org/SDL/issues/6703

I suppose the following needs to be updated as well:

create libSDL3_image.so.0 instead of libSDL3_image-3.0.so.0
copy so/dylib versioning behavior of SDL3 to SDL3_image
install sdl3-image.pc instead of SDL3_image.pc

Thanks, can you make similar changes for SDL_ttf and then SDL_mixer?

authors: madebr slouken

license: Zlib


text:
aix: don't EISDIR on read from directory fd

Remove the artificial EISDIR that was generated when trying to
uv_fs_read() from a file descriptor that refers to a directory.
We don't do that on the BSDs either (where reading from a directory
is allowed) and it introduces an extra stat() call for every read.
Refs: https://github.com/libuv/libuv/pull/2023#issuecomment-427759265

I couldn't find tests that check for the presence/absence of EISDIR. If the CI run turns up green, I'll see about adding some.

I tried to implement a test for the same in https://github.com/libuv/libuv/pull/2023. Perhaps we could use that?

Landed in https://github.com/libuv/libuv/commit/25a3894c8d59fada12253d3cb1befd14e18ecd75. Thanks Ben!

Thanks!

authors: bnoordhuis cjihrig thefourtheye vtjnash

repo: libuv/libuv


text:
questions about batch size in GHMC_loss

Hi,  thanks for your nice work. In your paper, you mentioned the best bin size is 30, which is a balanced value, what is the batch size in your experiments when you using bin size 30?

@longchuan1985 We use the batch size of 16 (8 GPUs with two images per GPU), which can be seen in the example script. And I want to clarify that the relationship between the bin size and batch size is not so strong because the effect of bin size mainly depends on the distribution of the gradient norm of examples (but I admit larger batch size will make the distribution more steady).


text:
addalpha() support

The VIPS docs mention an addalpha() function, but attempting to call image:addalpha() results in a VipsOperation: class "addalpha" not found error. I'm not sure why exactly this is. It's mentioned here that addalpha is just a convenience function for bandjoin_const, but I don't see what makes it different from any other operation that the binding supports.
I'd open a PR, but thing is, I'm not sure how to implement it. Typically, I'd just make a call to vips_lib.vips_addalpha(), but pyvips defines the function manually, so there might be something I'm missing.

Hi @RiskoZoSlovenska,
Most libvips operations are defined as subclasses of VipsOperation, and they all just appear in lua-vips automatically. A few very simple things (eg. addalpha, which is just two lines of code) are tiny convenience functions and are implemented in the bindings themselves.
I'd implement addalpha in lua in Image_methods.lua, which I guess is what you've done in your PR. I'll have a look.

authors: RiskoZoSlovenska jcupitt

repo: libvips/lua-vips


text:
parserInternal.h not found?

When forcing npm to rebuild from source the compilation fails since its unable to find parserInternal.h:
allon@computer:~/src/git/samplenode$ npm install --build-from-source libxmljs

> libxmljs@1.0.1 install /home/allon/src/git/samplenode/node_modules/libxmljs
> node-pre-gyp install --fallback-to-build --loglevel http

make: Entering directory '/home/allon/src/git/samplenode/node_modules/libxmljs/build'
  CXX(target) Release/obj.target/xmljs/src/xml_sax_parser.o
../src/xml_sax_parser.cc:6:10: fatal error: parserInternals.h: No such file or directory
 #include "parserInternals.h"
          ^~~~~~~~~~~~~~~~~~~
compilation terminated.
xmljs.target.mk:176: recipe for target 'Release/obj.target/xmljs/src/xml_sax_parser.o' failed
make: *** [Release/obj.target/xmljs/src/xml_sax_parser.o] Error 1
make: Leaving directory '/home/allon/src/git/samplenode/node_modules/libxmljs/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/home/allon/.nvm/versions/node/v14.16.0/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23)
gyp ERR! stack     at ChildProcess.emit (events.js:315:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:277:12)
gyp ERR! System Linux 4.15.0-202-generic
gyp ERR! command "/home/allon/.nvm/versions/node/v14.16.0/bin/node" "/home/allon/.nvm/versions/node/v14.16.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "build" "--fallback-to-build" "--loglevel=http" "--module=/home/allon/src/git/samplenode/node_modules/libxmljs/build/Release/xmljs.node" "--module_name=xmljs" "--module_path=/home/allon/src/git/samplenode/node_modules/libxmljs/build/Release" "--napi_version=7" "--node_abi_napi=napi" "--napi_build_version=0" "--node_napi_label=node-v83"
gyp ERR! cwd /home/allon/src/git/samplenode/node_modules/libxmljs
gyp ERR! node -v v14.16.0
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok
node-pre-gyp ERR! build error
node-pre-gyp ERR! stack Error: Failed to execute '/home/allon/.nvm/versions/node/v14.16.0/bin/node /home/allon/.nvm/versions/node/v14.16.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js build --fallback-to-build --loglevel=http --module=/home/allon/src/git/samplenode/node_modules/libxmljs/build/Release/xmljs.node --module_name=xmljs --module_path=/home/allon/src/git/samplenode/node_modules/libxmljs/build/Release --napi_version=7 --node_abi_napi=napi --napi_build_version=0 --node_napi_label=node-v83' (1)
node-pre-gyp ERR! stack     at ChildProcess.<anonymous> (/home/allon/src/git/samplenode/node_modules/@mapbox/node-pre-gyp/lib/util/compile.js:89:23)
node-pre-gyp ERR! stack     at ChildProcess.emit (events.js:315:20)
node-pre-gyp ERR! stack     at maybeClose (internal/child_process.js:1048:16)
node-pre-gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:288:5)
node-pre-gyp ERR! System Linux 4.15.0-202-generic
node-pre-gyp ERR! command "/home/allon/.nvm/versions/node/v14.16.0/bin/node" "/home/allon/src/git/samplenode/node_modules/.bin/node-pre-gyp" "install" "--fallback-to-build" "--loglevel" "http"
node-pre-gyp ERR! cwd /home/allon/src/git/samplenode/node_modules/libxmljs
node-pre-gyp ERR! node -v v14.16.0
node-pre-gyp ERR! node-pre-gyp -v v1.0.10
node-pre-gyp ERR! not ok
Failed to execute '/home/allon/.nvm/versions/node/v14.16.0/bin/node /home/allon/.nvm/versions/node/v14.16.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js build --fallback-to-build --loglevel=http --module=/home/allon/src/git/samplenode/node_modules/libxmljs/build/Release/xmljs.node --module_name=xmljs --module_path=/home/allon/src/git/samplenode/node_modules/libxmljs/build/Release --napi_version=7 --node_abi_napi=napi --napi_build_version=0 --node_napi_label=node-v83' (1)
npm WARN node-fetch@2.6.9 requires a peer of encoding@^0.1.0 but none is installed. You must install peer dependencies yourself.
npm WARN samplenode@1.0.0 No description
npm WARN samplenode@1.0.0 No repository field.

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! libxmljs@1.0.1 install: `node-pre-gyp install --fallback-to-build --loglevel http`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the libxmljs@1.0.1 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/allon/.npm/_logs/2023-03-30T18_20_14_564Z-debug.log

(Reproduced on several different Node.js versions and several different platforms, pasting here one example)

Looks like we need to find a way to init submodules before building from source after installing
Try after npm run init-submodules or git submodule update --init --recursive

Maybe I'm being daft, but there's no init-submodules script there - I'm not cloning it and trying to build, I'm trying to install it as a module in another project, but compile the C part locally instead of depending on a prebuilt binary

@rchipka no improvement, unfortunately. In fact, I think we're worse off:
With --build-from-source I still get an error about parserInternal.h, and another new error about failing to git run init-submodules (presumably because init-submodules assumes it would be run on libxmljs' root folder, but in fact its being executed on the root of the project that is trying to install it, which in this case isn't even a git project
allon@allon-z440:~/src/untracked/samplenode$ npm install --build-from-source libxmljs

> libxmljs@1.0.2 install /home/allon/src/untracked/samplenode/node_modules/libxmljs
> node-pre-gyp install --loglevel http || (npm run init && npm run build)

make: Entering directory '/home/allon/src/untracked/samplenode/node_modules/libxmljs/build'
  CXX(target) Release/obj.target/xmljs/src/xml_sax_parser.o
../src/xml_sax_parser.cc:6:10: fatal error: parserInternals.h: No such file or directory
 #include "parserInternals.h"
          ^~~~~~~~~~~~~~~~~~~
compilation terminated.
xmljs.target.mk:166: recipe for target 'Release/obj.target/xmljs/src/xml_sax_parser.o' failed
make: *** [Release/obj.target/xmljs/src/xml_sax_parser.o] Error 1
make: Leaving directory '/home/allon/src/untracked/samplenode/node_modules/libxmljs/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/home/allon/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (events.js:182:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:240:12)
gyp ERR! System Linux 4.15.0-202-generic
gyp ERR! command "/home/allon/.nvm/versions/node/v10.13.0/bin/node" "/home/allon/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "build" "--loglevel=http" "--module=/home/allon/src/untracked/samplenode/node_modules/libxmljs/build/Release/xmljs.node" "--module_name=xmljs" "--module_path=/home/allon/src/untracked/samplenode/node_modules/libxmljs/build/Release" "--napi_version=3" "--node_abi_napi=napi" "--napi_build_version=0" "--node_napi_label=node-v64"
gyp ERR! cwd /home/allon/src/untracked/samplenode/node_modules/libxmljs
gyp ERR! node -v v10.13.0
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
node-pre-gyp ERR! build error
node-pre-gyp ERR! stack Error: Failed to execute '/home/allon/.nvm/versions/node/v10.13.0/bin/node /home/allon/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js build --loglevel=http --module=/home/allon/src/untracked/samplenode/node_modules/libxmljs/build/Release/xmljs.node --module_name=xmljs --module_path=/home/allon/src/untracked/samplenode/node_modules/libxmljs/build/Release --napi_version=3 --node_abi_napi=napi --napi_build_version=0 --node_napi_label=node-v64' (1)
node-pre-gyp ERR! stack     at ChildProcess.cmd.on (/home/allon/src/untracked/samplenode/node_modules/@mapbox/node-pre-gyp/lib/util/compile.js:89:23)
node-pre-gyp ERR! stack     at ChildProcess.emit (events.js:182:13)
node-pre-gyp ERR! stack     at maybeClose (internal/child_process.js:962:16)
node-pre-gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:251:5)
node-pre-gyp ERR! System Linux 4.15.0-202-generic
node-pre-gyp ERR! command "/home/allon/.nvm/versions/node/v10.13.0/bin/node" "/home/allon/src/untracked/samplenode/node_modules/.bin/node-pre-gyp" "install" "--loglevel" "http"
node-pre-gyp ERR! cwd /home/allon/src/untracked/samplenode/node_modules/libxmljs
node-pre-gyp ERR! node -v v10.13.0
node-pre-gyp ERR! node-pre-gyp -v v1.0.10
node-pre-gyp ERR! not ok
Failed to execute '/home/allon/.nvm/versions/node/v10.13.0/bin/node /home/allon/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js build --loglevel=http --module=/home/allon/src/untracked/samplenode/node_modules/libxmljs/build/Release/xmljs.node --module_name=xmljs --module_path=/home/allon/src/untracked/samplenode/node_modules/libxmljs/build/Release --napi_version=3 --node_abi_napi=napi --napi_build_version=0 --node_napi_label=node-v64' (1)

> libxmljs@1.0.2 init /home/allon/src/untracked/samplenode/node_modules/libxmljs
> node scripts/init.js

Initializing submodules

> libxmljs@1.0.2 init-submodules /home/allon/src/untracked/samplenode/node_modules/libxmljs
> git submodule update --init --recursive

fatal: not a git repository (or any of the parent directories): .git
npm ERR! code ELIFECYCLE
npm ERR! errno 128
npm ERR! libxmljs@1.0.2 init-submodules: `git submodule update --init --recursive`
npm ERR! Exit status 128
npm ERR!
npm ERR! Failed at the libxmljs@1.0.2 init-submodules script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm WARN Local package.json exists, but node_modules missing, did you mean to install?

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/allon/.npm/_logs/2023-03-31T13_45_18_262Z-debug.log
child_process.js:651
    throw err;
    ^

Error: Command failed: npm run init-submodules
    at checkExecSyncError (child_process.js:611:11)
    at execSync (child_process.js:648:13)
    at Object.<anonymous> (/home/allon/src/untracked/samplenode/node_modules/libxmljs/scripts/init.js:9:5)
    at Module._compile (internal/modules/cjs/loader.js:688:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:699:10)
    at Module.load (internal/modules/cjs/loader.js:598:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:537:12)
    at Function.Module._load (internal/modules/cjs/loader.js:529:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:741:12)
    at startup (internal/bootstrap/node.js:285:19)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! libxmljs@1.0.2 init: `node scripts/init.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the libxmljs@1.0.2 init script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm WARN Local package.json exists, but node_modules missing, did you mean to install?

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/allon/.npm/_logs/2023-03-31T13_45_18_282Z-debug.log
npm WARN node-fetch@2.6.9 requires a peer of encoding@^0.1.0 but none is installed. You must install peer dependencies yourself.
npm WARN samplenode@1.0.0 No description
npm WARN samplenode@1.0.0 No repository field.

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! libxmljs@1.0.2 install: `node-pre-gyp install --loglevel http || (npm run init && npm run build)`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the libxmljs@1.0.2 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/allon/.npm/_logs/2023-03-31T13_45_18_382Z-debug.log

I'd like to avoid bundling the entire libxml2 source code with the library if we don't have to.
The node_modules directory already has a significant bloat problem and if one less library contributes to this, then I'd consider that a win.
If this was a thing then we'd have an easy way to accomplish this. I've tried the solution they mentioned (gyp actions), but that doesn't work for windows builds.

What we need is a way to hook into (or otherwise preempt) node-pre-gyp/node-gyp so that we can do the proper initialization before build.
Having this infrastructure setup would be beneficial anyways since libxmljs now has a fairly complex build infrastructure if you truly want to start from scratch (submodules, cmake configure, SWIG, then build).

Actually, looking at the log, it's not a cwd issue.
We won't be able to init submodules from the npm packaged version unless we include the .git directory. Hmm.

Alright, for simplicity's sake I'm thinking we're just gonna have to go back to packaging submodules.
I think I've got an answer that at least keeps git-sourced installations (eg. CI builds) simple by automating submodule init in those instances.

@mureinik hoping we're good now

@rchipka unfortunately still not :-(
Definitely making progress, but now it's failing because it can't require nan:
allon@allon-z440:~/src/untracked/samplenode$ npm install --build-from-source libxmljs

> libxmljs@1.0.3 preinstall /home/allon/src/untracked/samplenode/node_modules/libxmljs
> node scripts/preinstall.js

Initializing git repo
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint:   git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint:   git branch -m <name>
Initialized empty Git repository in /home/allon/src/untracked/samplenode/node_modules/libxmljs/.git/

> libxmljs@1.0.3 install /home/allon/src/untracked/samplenode/node_modules/libxmljs
> node-pre-gyp install --fallback-to-build --loglevel http

internal/modules/cjs/loader.js:582
    throw err;
    ^

Error: Cannot find module 'nan'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:580:15)
    at Function.Module._load (internal/modules/cjs/loader.js:506:25)
    at Module.require (internal/modules/cjs/loader.js:636:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at [eval]:1:1
    at Script.runInThisContext (vm.js:96:20)
    at Object.runInThisContext (vm.js:303:38)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (internal/modules/cjs/loader.js:688:30)
    at evalScript (internal/bootstrap/node.js:582:27)
gyp: Call to 'node -e "require('nan')"' returned exit status 1 while in binding.gyp. while trying to load binding.gyp
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/home/allon/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:345:16)
gyp ERR! stack     at ChildProcess.emit (events.js:182:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:240:12)
gyp ERR! System Linux 4.15.0-202-generic
gyp ERR! command "/home/allon/.nvm/versions/node/v10.13.0/bin/node" "/home/allon/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "configure" "--fallback-to-build" "--loglevel=http" "--module=/home/allon/src/untracked/samplenode/node_modules/libxmljs/build/Release/xmljs.node" "--module_name=xmljs" "--module_path=/home/allon/src/untracked/samplenode/node_modules/libxmljs/build/Release" "--napi_version=3" "--node_abi_napi=napi" "--napi_build_version=0" "--node_napi_label=node-v64"
gyp ERR! cwd /home/allon/src/untracked/samplenode/node_modules/libxmljs
gyp ERR! node -v v10.13.0
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
node-pre-gyp ERR! build error
node-pre-gyp ERR! stack Error: Failed to execute '/home/allon/.nvm/versions/node/v10.13.0/bin/node /home/allon/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js configure --fallback-to-build --loglevel=http --module=/home/allon/src/untracked/samplenode/node_modules/libxmljs/build/Release/xmljs.node --module_name=xmljs --module_path=/home/allon/src/untracked/samplenode/node_modules/libxmljs/build/Release --napi_version=3 --node_abi_napi=napi --napi_build_version=0 --node_napi_label=node-v64' (1)
node-pre-gyp ERR! stack     at ChildProcess.cmd.on (/home/allon/src/untracked/samplenode/node_modules/@mapbox/node-pre-gyp/lib/util/compile.js:89:23)
node-pre-gyp ERR! stack     at ChildProcess.emit (events.js:182:13)
node-pre-gyp ERR! stack     at maybeClose (internal/child_process.js:962:16)
node-pre-gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:251:5)
node-pre-gyp ERR! System Linux 4.15.0-202-generic
node-pre-gyp ERR! command "/home/allon/.nvm/versions/node/v10.13.0/bin/node" "/home/allon/src/untracked/samplenode/node_modules/.bin/node-pre-gyp" "install" "--fallback-to-build" "--loglevel" "http"
node-pre-gyp ERR! cwd /home/allon/src/untracked/samplenode/node_modules/libxmljs
node-pre-gyp ERR! node -v v10.13.0
node-pre-gyp ERR! node-pre-gyp -v v1.0.10
node-pre-gyp ERR! not ok
Failed to execute '/home/allon/.nvm/versions/node/v10.13.0/bin/node /home/allon/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js configure --fallback-to-build --loglevel=http --module=/home/allon/src/untracked/samplenode/node_modules/libxmljs/build/Release/xmljs.node --module_name=xmljs --module_path=/home/allon/src/untracked/samplenode/node_modules/libxmljs/build/Release --napi_version=3 --node_abi_napi=napi --napi_build_version=0 --node_napi_label=node-v64' (1)
npm WARN node-fetch@2.6.9 requires a peer of encoding@^0.1.0 but none is installed. You must install peer dependencies yourself.
npm WARN samplenode@1.0.0 No description
npm WARN samplenode@1.0.0 No repository field.

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! libxmljs@1.0.3 install: `node-pre-gyp install --fallback-to-build --loglevel http`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the libxmljs@1.0.3 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/allon/.npm/_logs/2023-03-31T16_42_10_111Z-debug.log

With my local copy of libxmljs, moving nan from the devDependencies to dependencies solves the issue, but I'm not sure this is the right move.

Alternatively, if the consumer wants to use --build-from-source they can install nan directly.
I'm guessing that using --build-from-source isn't a common practice (e.g., in my usecase, I'm using it on a very old CentOS machine to force libxml to be compiled with an older glibc that the packaged binary). Perhaps instead of "dirtying" the dependencies, defining nan in the peerDependencies and documenting it in the README is a better move?

My bad, sorry for the whiplash here. I was fixing the duplicate NaN dependency and removed it from the wrong section.
I have no issues with keeping it in "dependencies" since that should contain everything necessary to build the C++ code imo.

My bad, sorry for the whiplash here. I was fixing the duplicate NaN dependency and removed it from the wrong section.
I have no issues with keeping it in "dependencies" since that should contain everything necessary to build the C++ code imo.

@rchipka Thanks!
I can confirm that with 1.0.6 it installs cleanly on both my Windows and Linux machines.
Closing this bug.

@mureinik Awesome, thanks for confirming and for the help on this one!

authors: mureinik rchipka riley-ciq

repo: libxmljs/libxmljs


text:
Add support to the REST API to search with FHIR search reference parameters

Greetings, Thanks for taking the time to consider this issue. Our team is ready and happy to tackle this issue asap. Recommendations and feedback welcome!
Problem
The Blaze REST API doesn't support searching with FHIR search reference parameters Which allows for Searching Resources by a field on that resource that is a reference type.
Currently, it only supports: _summary and identifier. Which are documented in the CapabilityStatment which is accessible at [base]/fhir/metadata (where base would be the host and port of your blaze server blaze:8080)
An example of a http request url query that currently isn't supported. This url also opens to a public fhir server so we can see the results:
http://hapi.fhir.org/baseR4/MedicationRequest?subject=1200
Here The MedicationRequest subject
is of Type Reference. This is important because it directly relates to the FHIR search reference parameters specification linked above.Meaning, the search params specification documents how to send a GET request to query that relationship.
Purposed Solution
Add a feature to allow Blaze to Generate REST api endpoints dynamically based off FHIR data.
Implementation details
This can be broken into essential two parts

get search parameters schema from.
extend blaze search to use search params

The FHIR schema containing the Reference paramaters specification is encoded in this fhir definitions download link downloads a set of files including search-paramaters.json.  This can be used to verify the reference parameters and build the lookup.
Context
Blaze version: 0.6.2
related issues
#33 : mentions enabling fhirs "_revinclude" functionality, which gets us the desired ability to query
resources by Patient, but i believe will return more data then we want because were loading data on demand.
e.g When the user loads the medications page, thats when we hope to request both the page and data for there medications. This
saves us having to load that data when they first visit the site and keeps response times down.

I've already read your proposal some days ago. Please give me more time to think about it in more detail.

The current approach does a scan of all resources of that type. In order to make use of indexes everything including those of type bytes would need to be defined in a way that their sort order is correct. We are implementing (locally in a temporary fork) something that extends the current approach for now, but I would like to see something more index based here. I would be happy to make other issues along those lines.
One more note a vase like approach is great to bring more observability to these generated endpoints. I am not saying use vase I am just saying the approach is nice.

The  answer to this question is at the end of #50 .

greetings again,
Here is how were currently solving the search problem on our fork of blaze.
This might give you some insight into how you want to handle it.
In blaze.edn we define a :blaze.interaction/search-type per resource
e.g  Here is how we handle Condition, we pass it a list of codes matched with their expressions
  [:blaze.interaction/search-type :blaze.interaction.search/Condition]
  {:database/conn                     #blaze/ref :blaze.datomic/conn
   :blaze.fhir.SearchParameter/config [{:blaze.fhir.SearchParameter/code       "patient"
                                        :blaze.fhir.SearchParameter/expression [:Condition/subject :Patient/id]}
                                       {:blaze.fhir.SearchParameter/code       "category"
                                        :blaze.fhir.SearchParameter/expression [:Condition/category :CodeableConcept/coding :Coding/code :code/code]}]}

This works with our modified version of the search_type namespace. Where we have changed
resource pred to take a config map that contains the code and expression from above.
These inform the search how to filter via the expression per code which mostly happens in the match? function.
(defn- match?
  [tree path search]
  (let [k       (first path)
        subtree (get tree k)]
    (cond
      (nil? k)       (= search tree)
      (nil? subtree) false
      (set? subtree) (some (fn [st] (match? st (rest path) search))
                           subtree)
      :else          (match? subtree (rest path) search))))

(defn- resource-pred [query-params config]
  (let [valid-query-params  (select-keys query-params (map :blaze.fhir.SearchParameter/code config))
        select-path-by-code (fn [config code]
                              (->> config
                                   (filter #(= (:blaze.fhir.SearchParameter/code %) code))
                                   first
                                   :blaze.fhir.SearchParameter/expression))]
    (when (seq valid-query-params)
      (fn [resource] (every? (fn [[path search]] (match? resource path search))
                            (mapv (fn [[k v]] [(select-path-by-code config k) v]) valid-query-params))))))

The rest of the search type handler is then opended up to pass these arguments. note this code is mostly the same, were must passing
the searchparam config along with the connection.
(defn- handler-intern [{:keys [database/conn blaze.fhir.SearchParameter/config]}]
  (fn [{{{:fhir.resource/keys [type]} :data} ::reitit/match
       :keys [params]
       ::reitit/keys [router]}]
    (-> (search router (d/db conn) type params config)
        (ring/response))))

(defn handler
  ""
  [config]
  (-> (handler-intern config)
      (wrap-params)
      (wrap-observe-request-duration "search-type")))

(defmethod ig/init-key :blaze.interaction/search-type
  [_ config]
  (log/info "Init FHIR search-type interaction handler")
  (handler config))

Hopefully this helps!

Ok that looks good. You then put the :blaze.interaction.search/Condition key in :blaze/rest-api under the Condition type - right? Integrant instantiates then a :blaze.interaction/search-type with the corresponding :blaze.fhir.SearchParameter/config.
How do you plan to handle the different types of search parameters like token, string or reference?
The search is still not indexed. Is that ok for you in a first iteration?

You then put the :blaze.interaction.search/Condition key in :blaze/rest-api under the Condition type - right?

correct. e.g
  [:blaze.interaction/search-type :blaze.interaction.search/Condition]
  {:database/conn                     #blaze/ref :blaze.datomic/conn
   :blaze.fhir.SearchParameter/config [{:blaze.fhir.SearchParameter/code       "patient"
                                        :blaze.fhir.SearchParameter/expression [:Condition/subject :Patient/id]}
                                       {:blaze.fhir.SearchParameter/code       "category"
                                        :blaze.fhir.SearchParameter/expression [:Condition/category :CodeableConcept/coding :Coding/code :code/code]}]}

How do you plan to handle the different types of search parameters like token, string or reference?
I don't have a strategy for the other types currently.

The search is still not indexed. Is that ok for you in a first iteration?

I'm not sure, will probably proceed assuming its ok and then benchmark if we notice things are too slow.

Would it be an idea to parse SeachParameter definitions directly instead of having to write them down by hand?

Yes It would. We plan on generating chunks of our blaze.edn from that data. but some of the expressions are non trivial to generate optimally. We would like to give ourselves hooks at least until we know we can read the SeachParameters we want.  Also this comes back to the possibility of different schema choices. If someone decided they wanted to use tuples to make a better index. We would like that flexibility somewhere.

authors: alexanderkiel drewverlee dspiteself

repo: life-research/blaze


text:
Update spray-json to 1.3.5

Updates io.spray:spray-json from 1.3.4 to 1.3.5.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention @scala-steward in the comments below.
Have a nice day!

Yes, that's expected, we didn't guarantee anything before and now it should be alphabetic. You can JsValue.sortedPrint which should have consistent ordering across releases.

@jrudolph I take it from https://github.com/spray/spray-json/issues/155 that there's no way to preserve insertion order? nbd I guess, though I'd prefer it, the ordering I had before was more human-readable

authors: SethTisue jrudolph scala-steward

repo: lightbend/scala-sculpt


text:
Add Required(Bool) to Textfield

Adding the required option for addTextField(). This will make the preferredAction action button disabled until there is text input.
Use case: You have an Alert+Textfield to name an object before saving, the name cannot be blank and you don't want to dismiss/reinit an alert to prompt the user for input again.
.addTextField(&nameField, required: true )

Note: only one required field is supported.
OP: Please check variable declarations, I'm new to iOS, feedback appreciated!

@eriksargent

repo: lightningkite/LKAlertController


text:
multi: remove existing meta field in asset TLV to replace w/ meta hash optionally revealed in genesis minting proof

Related to https://github.com/lightninglabs/taro/issues/62.
Problem Statement
In this PR, we fix an issue with the meta field as defined today:

The field in practice may be very large (hundreds of KBs), and is serialized along with each asset TLV in a proof chain.
This means that the proof size is a function of the size of the meta field itself, meaning more data to lug around for clients.

Solution
Meta -> Meta Hash in TLV
Instead, we make the meta field itself a hash commitment. Only the meta hash field exists in every asset TLV. This means the asset genesis (which rn is serialized along with addresses) nearly constant sized other than the tag (which we can also instead make into a commitment). The meta hash is then the hash of the TLV serialization of the meta reveal (see below).
To start, the meta has a single type: opaque blob. This type is itself a TLV, so we can add more types in the future, and also other types contingent on the type itself. Eg: we can add a JSON blob type, or a MIME type that then relies on the existence of some other string to fully bind the structure of the meta bytes.
MetaReveal in Proof File Blob
We then add a new optional field to the proof format that allows the minter (or anyone that knows of the pre-image) to reveal it within the first proof state transition. As this is only exist in the first state, which is to be bootstrapped by the users from a Base Universe, the proof sizes are no longer dependent on the asset meta itself (constant value at the start). We then add a rule that this can only exist for assets that have a genesis witness (minted assets).
New assets_meta table in the database
Along the way we modify the DB to add a new assets_meta table and reference that directly. This allows for larger meta blobs, as we no longer need to read the entire thing if we want to look at the genesis details for assets. Two query mechanisms based on the asset ID and the asset hash have also been added.
RPC + CLI Changes
On the RPC layer, we now expose the meta field to callers, and display the hash in most other locations. We also add an API that lets callers fetch the meta based on the hash or asset ID.
On the CLI, we propagate all the above updates, then also add a new option to read the meta from a file on disk, as it may be too large to pass as a command line string.
Follow up Work
Update the spec accordingly.

Spec PR here: https://github.com/Roasbeef/bips/pull/34

@jharveyb: review reminder
@roasbeef, remember to re-request review from reviewers when ready

@jharveyb: review reminder
@roasbeef, remember to re-request review from reviewers when ready

@jharveyb: review reminder
@roasbeef, remember to re-request review from reviewers when ready

@jharveyb: review reminder
@roasbeef, remember to re-request review from reviewers when ready

@jharveyb: review reminder
@roasbeef, remember to re-request review from reviewers when ready

@jharveyb: review reminder
@roasbeef, remember to re-request review from reviewers when ready

@jharveyb: review reminder
@roasbeef, remember to re-request review from reviewers when ready

@jharveyb: review reminder
@roasbeef, remember to re-request review from reviewers when ready

@jharveyb: review reminder
@roasbeef, remember to re-request review from reviewers when ready

@jharveyb: review reminder
@roasbeef, remember to re-request review from reviewers when ready

authors: Roasbeef lightninglabs-deploy

repo: lightninglabs/taro


text:
Whats the meaning of IncorrectOrUnknownPaymentDetails and how is it different from UnknownPaymentHash?

Get this error occasionally sending to route:
{ payment_error:
   'IncorrectOrUnknownPaymentDetails(amt=867594000 mSAT, height=629188)@1',
  payment_preimage: <Buffer >,
  payment_route: null,
  payment_hash:
   <Buffer 08 d9 5b 32 c1 ac 07 54 91 17 cb cb ba 6d 02 ad e0 28 3c 7c fa e1 98 6f a9 f5 5e a2 8a 24 0c c2> }

Feels like this is the same as UnknownPaymentHash but not quite sure

Failure due to incorrect details covers a few cases (from BOLT#4):

The node you are sending the payment to does not have an invoice with that hash
The amount being paid is wrong, or the htlc has the wrong expiry, or expires too soon so is rejected
Payment secret for MPP is wrong

These errors are all combined into a single error to prevent probing attacks.
What version of lnd are you running on?

0.10
Is it safe to assume that funds sent in this attempt are not spent?

Yes, it's a permanent failure so the payment status will say failed.

thanks!

authors: Overtorment carlaKC

repo: lightningnetwork/lnd


text:
Update README.md

What is changed, added or deleted? (Required)

What is the reference link(s)?

@BirdboyBolu Thanks for your contribution!


text:
Command: auto_complete

Reopening old Issue in relevant Repo
https://github.com/limetext/lime/issues/17

Ugh, old commit references limetext/lime/#62 not this one.

authors: haddel quarnster

repo: limetext/lime-backend


text:
Inject dask client into ensemble

Allows for a single dask client to be created for all unit tests. This speeds up execution and reduces warnings.
Locally, unit test execution goes from 35-45 seconds to 8-9 seconds
In github CI, execution goes from 67-77 seconds to 16-19 seconds
Addresses nearby black formatting and pylint warnings

Codecov Report

Merging #36 (9b1d62d) into main (f91b74b) will increase coverage by 0.54%.
The diff coverage is 97.22%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main      #36      +/-   ##
==========================================
+ Coverage   79.08%   79.63%   +0.54%
==========================================
  Files           6        6
  Lines         373      383      +10
==========================================
+ Hits          295      305      +10
  Misses         78       78

Impacted Files
Coverage Δ

src/lsstseries/analysis/__init__.py
100.00% <ø> (ø)

src/lsstseries/analysis/stetsonj.py
90.24% <ø> (ø)

src/lsstseries/timeseries.py
87.67% <ø> (ø)

src/lsstseries/ensemble.py
63.15% <97.05%> (ø)

src/lsstseries/__init__.py
100.00% <100.00%> (ø)

src/lsstseries/analysis/structurefunction2.py
97.84% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

authors: codecov-commenter delucchi-cmu

repo: lincc-frameworks/lsstseries


text:
Ask user for GitHub repo link

Currently, copier doesn't ask and doesn't know GitHub repo link. However it would be useful to have and use at least in two places:

[ ] asv.conf.json needs it
[ ] pyproject.toml should use it for project.urls to populate "Source Code" URL for PyPi

For pre-existing projects we can get it from git with something like git remote get-url origin and with a bit of parsing for ssh-based URLs.

We could also include some badges on the README if we have the github URL at the template hydration stage.

I'm thinking to instead just ask for the organization name, since that will help us to generate those badge URLs that aren't just appending to the base URL but perturb it in weird ways (that I'd prefer to have in the template than try to remember every time)
e.g.
https://github.com/{{project_organization}}/{{project_name}}
https://{{project_organization}}.github.io/{{project_name}}/
https://{{project_name}}.readthedocs.io/
https://codecov.io/gh/{{project_organization}}/{{project_name}}

authors: delucchi-cmu hombit


text:
[Feature request] Support thrift v0.14.0

Dear devs,
Are you planning to support thrift v0.14.0 ?
ref: https://github.com/apache/thrift/releases/tag/v0.14.0
ps: With thrift v0.13.0 there exists a CVE https://nvd.nist.gov/vuln/detail/CVE-2020-13949

Sure, why not! (Maybe) We will include supporting Thrift 0.14.0 in the next release(1.6.0).

authors: ikhoon selectAll

repo: line/armeria


text:
Add 'apiplural' directive for referring to a type in plural form

Motivation:
While documenting, it is often necessary to refer to a type in plural
form:
This class retrieves the list of :api:`Endpoint`\s from ZooKeeper.

Although \ does its job here, the rendered output isn't very pretty,
mainly because:

There's spacing between Endpoint and s. The spacing between them
should be moved after the plural suffix s.
There's gray background at Endpoint but not at s. Both Endpoint
and s should have the same background color.

Modifications:

Introduce a new directive apiplural which pluralizes a type
reference automatically

Result:

Aesthetics and convenience

Before:

After:

Thanks!


text:
Prohibit mirroring to internal repositories

Motivation:
We should prohibit mirroring to internal repositories which can cause a security incident.
Modification:

Raise an exception if the localRepo of mirroring setting is one of meta and dogma which are internal repositories.

Result:

You cannot set up mirroring to internal repositories anymore.

Thanks for reviewing. 😉

repo: line/centraldogma


text:
Support regex for deprecated apis

Describe the bug
Please add/fix support for regex in deprecated apis.
I attached the example when the first line of regex is working, but the second is not working.
To Reproduce
automations:
  {% for item in deprecated %}
  catch_deprecated_components_{{ loop.index }}:
    if:
      - {{ source.diff.files | matchDiffLines(regex=item.regex) | some }}
    run:
      - action: add-label@v1
        args:
          label: 'deprecated-component'
      - action: request-changes@v1
        args:
          comment: |
            `{{ item.regex }}` is deprecated, use `EventType` from `constants.py/constants.ts[js]`
  {% endfor %}

deprecated:
  - regex: r/^[+].*Types.EVENT_REQUESTED/
  - regex: r/^[+].*eventRequested\/v1/

Expected behavior
the current snippet should run as valid.
Screenshots

@MishaKav we can't seem to be able to repredocue this issue:

@MishaKav this was fixed, the issue was when using the string action in your rules, which triggered unjustified CM syntax check error,

authors: MishaKav vim-zz

repo: linear-b/gitstream


text:
Add wildcard/regex for ignore_repositories

Is your feature request related to a problem? Please describe.
I would like a feature that allows wildcard and/or regex values for the ignore_repositories option in config: so that we don't need to continually update rules when repos are created.
Describe the solution you'd like
When managing hundreds of repo's for an org, separating their name by a prefix/suffix for team/tool/department etc. makes organizing them easier. It would be great if we could dynamically assign rules based on a wildcard or regex syntax
i.e., Team1-Repo1 and Repo1-Team2 -- we want to build a rule that would only apply to everything under Team1- but not Team2.
It looks like wildcards are available for filenames, but not repositories: https://docs.gitstream.cm/cm-file/#configignore_repositories
Describe alternatives you've considered
Presently, it looks like our only option is to add each named repo as a per-line string in a rule's config:ignore_repositories sub-section. While precise, this isn't elegant and is a bit of a chore.
Thank you,

Thanks for the recommendation @PFarrell90, this is a great idea! We'll provide updates here on the status of this improvement.

Hi
We have recently added this capability to gitStream, documentation is available here
I am closing this issue; please re-open it in case you find it does not work as expected

authors: BenLloydPearson PFarrell90 PavelLinearB


text:
Share ClickCounter type between web & gtk

This is a pretty marginal win, but does remove some duplicate logic.

Oooh, had completely forgotten about that. This implementation doesn't fully follow the design detailed there, but it could definitely be the basis of a unified design at some point in the future.

repo: linebender/druid


text:
I encountered a problem in the second step

I use single-gpu to inference, but I made an error like this:
Traceback (most recent call last):
File "imaginaire/inference.py", line 95, in
main()
File "imaginaire/inference.py", line 86, in main
trainer.load_checkpoint(cfg, args.checkpoint)
File "/home/mio/work/project/Neural_Actor_Main_Code-master/imaginaire/imaginaire/trainers/base.py", line 259, in load_checkpoint
self.net_G.load_state_dict(checkpoint['net_G'])
File "/home/mio/anaconda3/envs/neuralactor/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1667, in load_state_dict
raise RuntimeError('Error(s) in loading state_dict for {}:\n\t{}'.format(
RuntimeError: Error(s) in loading state_dict for WrappedModel:
Missing key(s) in state_dict: "module.averaged_model.label_embedding.conv_first.layers.conv.weight_orig", "module.averaged_model.label_embedding.conv_first.layers.conv.weight_u", "module.averaged_model.label_embedding.down_0.layers.conv.weight_orig", "module.averaged_model.label_embedding.down_0.layers.conv.weight_u", "module.averaged_model.label_embedding.down_1.layers.conv.weight_orig", "module.averaged_model.label_embedding.down_1.layers.conv.weight_u", "module.averaged_model.label_embedding.down_2.layers.conv.weight_orig", "module.averaged_model.label_embedding.down_2.layers.conv.weight_u", "module.averaged_model.label_embedding.down_3.layers.conv.weight_orig", "module.averaged_model.label_embedding.down_3.layers.conv.weight_u", "module.averaged_model.label_embedding.down_4.layers.conv.weight_orig", "module.averaged_model.label_embedding.down_4.layers.conv.weight_u", "module.averaged_model.label_embedding.up_4.layers.conv.weight_orig", "module.averaged_model.label_embedding.up_4.layers.conv.weight_u", "module.averaged_model.label_embedding.up_3.layers.conv.weight_orig", "module.averaged_model.label_embedding.up_3.layers.conv.weight_u", "module.averaged_model.label_embedding.up_2.layers.conv.weight_orig", "module.averaged_model.label_embedding.up_2.layers.conv.weight_u", "module.averaged_model.label_embedding.up_1.layers.conv.weight_orig", "module.averaged_model.label_embedding.up_1.layers.conv.weight_u", "module.averaged_model.label_embedding.up_0.layers.conv.weight_orig", "module.averaged_model.label_embedding.up_0.layers.conv.weight_u", "module.averaged_model.up_7.conv_block_0.layers.conv.weight_orig", "module.averaged_model.up_7.conv_block_0.layers.conv.weight_u", "module.averaged_model.up_7.conv_block_1.layers.conv.weight_orig", "module.averaged_model.up_7.conv_block_1.layers.conv.weight_u", "module.averaged_model.up_6.conv_block_0.layers.conv.weight_orig", "module.averaged_model.up_6.conv_block_0.layers.conv.weight_u", "module.averaged_model.up_6.conv_block_1.layers.conv.weight_orig", "module.averaged_model.up_6.conv_block_1.layers.conv.weight_u", "module.averaged_model.up_5.conv_block_0.layers.conv.weight_orig", "module.averaged_model.up_5.conv_block_0.layers.conv.weight_u", "module.averaged_model.up_5.conv_block_1.layers.conv.weight_orig", "module.averaged_model.up_5.conv_block_1.layers.conv.weight_u", "module.averaged_model.up_4.conv_block_0.layers.conv.weight_orig", "module.averaged_model.up_4.conv_block_0.layers.conv.weight_u", "module.averaged_model.up_4.conv_block_1.layers.conv.weight_orig", "module.averaged_model.up_4.conv_block_1.layers.conv.weight_u", "module.averaged_model.up_4.conv_block_s.layers.conv.weight_orig", "module.averaged_model.up_4.conv_block_s.layers.conv.weight_u", "module.averaged_model.up_3.conv_block_0.layers.conv.weight_orig", "module.averaged_model.up_3.conv_block_0.layers.conv.weight_u", "module.averaged_model.up_3.conv_block_1.layers.conv.weight_orig", "module.averaged_model.up_3.conv_block_1.layers.conv.weight_u", "module.averaged_model.up_3.conv_block_s.layers.conv.weight_orig", "module.averaged_model.up_3.conv_block_s.layers.conv.weight_u", "module.averaged_model.up_2.conv_block_0.layers.conv.weight_orig", "module.averaged_model.up_2.conv_block_0.layers.conv.weight_u", "module.averaged_model.up_2.conv_block_1.layers.conv.weight_orig", "module.averaged_model.up_2.conv_block_1.layers.conv.weight_u", "module.averaged_model.up_2.conv_block_s.layers.conv.weight_orig", "module.averaged_model.up_2.conv_block_s.layers.conv.weight_u", "module.averaged_model.up_1.conv_block_0.layers.conv.weight_orig", "module.averaged_model.up_1.conv_block_0.layers.conv.weight_u", "module.averaged_model.up_1.conv_block_1.layers.conv.weight_orig", "module.averaged_model.up_1.conv_block_1.layers.conv.weight_u", "module.averaged_model.up_1.conv_block_s.layers.conv.weight_orig", "module.averaged_model.up_1.conv_block_s.layers.conv.weight_u", "module.averaged_model.up_0.conv_block_0.layers.conv.weight_orig", "module.averaged_model.up_0.conv_block_0.layers.conv.weight_u", "module.averaged_model.up_0.conv_block_1.layers.conv.weight_orig", "module.averaged_model.up_0.conv_block_1.layers.conv.weight_u", "module.averaged_model.up_0.conv_block_s.layers.conv.weight_orig", "module.averaged_model.up_0.conv_block_s.layers.conv.weight_u", "module.averaged_model.down_0.conv_block_0.layers.conv.weight_orig", "module.averaged_model.down_0.conv_block_0.layers.conv.weight_u", "module.averaged_model.down_0.conv_block_1.layers.conv.weight_orig", "module.averaged_model.down_0.conv_block_1.layers.conv.weight_u", "module.averaged_model.down_0.conv_block_s.layers.conv.weight_orig", "module.averaged_model.down_0.conv_block_s.layers.conv.weight_u", "module.averaged_model.down_1.conv_block_0.layers.conv.weight_orig", "module.averaged_model.down_1.conv_block_0.layers.conv.weight_u", "module.averaged_model.down_1.conv_block_1.layers.conv.weight_orig", "module.averaged_model.down_1.conv_block_1.layers.conv.weight_u", "module.averaged_model.down_1.conv_block_s.layers.conv.weight_orig", "module.averaged_model.down_1.conv_block_s.layers.conv.weight_u", "module.averaged_model.down_2.conv_block_0.layers.conv.weight_orig", "module.averaged_model.down_2.conv_block_0.layers.conv.weight_u", "module.averaged_model.down_2.conv_block_1.layers.conv.weight_orig", "module.averaged_model.down_2.conv_block_1.layers.conv.weight_u", "module.averaged_model.down_2.conv_block_s.layers.conv.weight_orig", "module.averaged_model.down_2.conv_block_s.layers.conv.weight_u", "module.averaged_model.down_3.conv_block_0.layers.conv.weight_orig", "module.averaged_model.down_3.conv_block_0.layers.conv.weight_u", "module.averaged_model.down_3.conv_block_1.layers.conv.weight_orig", "module.averaged_model.down_3.conv_block_1.layers.conv.weight_u", "module.averaged_model.down_3.conv_block_s.layers.conv.weight_orig", "module.averaged_model.down_3.conv_block_s.layers.conv.weight_u", "module.averaged_model.down_4.conv_block_0.layers.conv.weight_orig", "module.averaged_model.down_4.conv_block_0.layers.conv.weight_u", "module.averaged_model.down_4.conv_block_1.layers.conv.weight_orig", "module.averaged_model.down_4.conv_block_1.layers.conv.weight_u", "module.averaged_model.down_4.conv_block_s.layers.conv.weight_orig", "module.averaged_model.down_4.conv_block_s.layers.conv.weight_u", "module.averaged_model.res_0.conv_block_0.layers.conv.weight_orig", "module.averaged_model.res_0.conv_block_0.layers.conv.weight_u", "module.averaged_model.res_0.conv_block_1.layers.conv.weight_orig", "module.averaged_model.res_0.conv_block_1.layers.conv.weight_u", "module.averaged_model.res_1.conv_block_0.layers.conv.weight_orig", "module.averaged_model.res_1.conv_block_0.layers.conv.weight_u", "module.averaged_model.res_1.conv_block_1.layers.conv.weight_orig", "module.averaged_model.res_1.conv_block_1.layers.conv.weight_u", "module.averaged_model.res_2.conv_block_0.layers.conv.weight_orig", "module.averaged_model.res_2.conv_block_0.layers.conv.weight_u", "module.averaged_model.res_2.conv_block_1.layers.conv.weight_orig", "module.averaged_model.res_2.conv_block_1.layers.conv.weight_u", "module.averaged_model.res_3.conv_block_0.layers.conv.weight_orig", "module.averaged_model.res_3.conv_block_0.layers.conv.weight_u", "module.averaged_model.res_3.conv_block_1.layers.conv.weight_orig", "module.averaged_model.res_3.conv_block_1.layers.conv.weight_u", "module.averaged_model.flow_network_temp.down_lbl.0.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.down_lbl.0.layers.conv.weight_u", "module.averaged_model.flow_network_temp.down_lbl.1.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.down_lbl.1.layers.conv.weight_u", "module.averaged_model.flow_network_temp.down_lbl.2.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.down_lbl.2.layers.conv.weight_u", "module.averaged_model.flow_network_temp.down_lbl.3.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.down_lbl.3.layers.conv.weight_u", "module.averaged_model.flow_network_temp.down_img.0.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.down_img.0.layers.conv.weight_u", "module.averaged_model.flow_network_temp.down_img.1.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.down_img.1.layers.conv.weight_u", "module.averaged_model.flow_network_temp.down_img.2.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.down_img.2.layers.conv.weight_u", "module.averaged_model.flow_network_temp.down_img.3.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.down_img.3.layers.conv.weight_u", "module.averaged_model.flow_network_temp.res_flow.0.conv_block_0.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.res_flow.0.conv_block_0.layers.conv.weight_u", "module.averaged_model.flow_network_temp.res_flow.0.conv_block_1.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.res_flow.0.conv_block_1.layers.conv.weight_u", "module.averaged_model.flow_network_temp.res_flow.1.conv_block_0.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.res_flow.1.conv_block_0.layers.conv.weight_u", "module.averaged_model.flow_network_temp.res_flow.1.conv_block_1.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.res_flow.1.conv_block_1.layers.conv.weight_u", "module.averaged_model.flow_network_temp.res_flow.2.conv_block_0.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.res_flow.2.conv_block_0.layers.conv.weight_u", "module.averaged_model.flow_network_temp.res_flow.2.conv_block_1.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.res_flow.2.conv_block_1.layers.conv.weight_u", "module.averaged_model.flow_network_temp.res_flow.3.conv_block_0.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.res_flow.3.conv_block_0.layers.conv.weight_u", "module.averaged_model.flow_network_temp.res_flow.3.conv_block_1.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.res_flow.3.conv_block_1.layers.conv.weight_u", "module.averaged_model.flow_network_temp.res_flow.4.conv_block_0.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.res_flow.4.conv_block_0.layers.conv.weight_u", "module.averaged_model.flow_network_temp.res_flow.4.conv_block_1.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.res_flow.4.conv_block_1.layers.conv.weight_u", "module.averaged_model.flow_network_temp.res_flow.5.conv_block_0.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.res_flow.5.conv_block_0.layers.conv.weight_u", "module.averaged_model.flow_network_temp.res_flow.5.conv_block_1.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.res_flow.5.conv_block_1.layers.conv.weight_u", "module.averaged_model.flow_network_temp.up_flow.1.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.up_flow.1.layers.conv.weight_u", "module.averaged_model.flow_network_temp.up_flow.3.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.up_flow.3.layers.conv.weight_u", "module.averaged_model.flow_network_temp.up_flow.5.layers.conv.weight_orig", "module.averaged_model.flow_network_temp.up_flow.5.layers.conv.weight_u", "module.averaged_model.img_prev_embedding.conv_first.layers.conv.weight_orig", "module.averaged_model.img_prev_embedding.conv_first.layers.conv.weight_u", "module.averaged_model.img_prev_embedding.down_0.layers.conv.weight_orig", "module.averaged_model.img_prev_embedding.down_0.layers.conv.weight_u", "module.averaged_model.img_prev_embedding.down_1.layers.conv.weight_orig", "module.averaged_model.img_prev_embedding.down_1.layers.conv.weight_u", "module.averaged_model.img_prev_embedding.down_2.layers.conv.weight_orig", "module.averaged_model.img_prev_embedding.down_2.layers.conv.weight_u", "module.averaged_model.img_prev_embedding.down_3.layers.conv.weight_orig", "module.averaged_model.img_prev_embedding.down_3.layers.conv.weight_u", "module.averaged_model.img_prev_embedding.down_4.layers.conv.weight_orig", "module.averaged_model.img_prev_embedding.down_4.layers.conv.weight_u", "module.averaged_model.img_prev_embedding.up_4.layers.conv.weight_orig", "module.averaged_model.img_prev_embedding.up_4.layers.conv.weight_u", "module.averaged_model.img_prev_embedding.up_3.layers.conv.weight_orig", "module.averaged_model.img_prev_embedding.up_3.layers.conv.weight_u", "module.averaged_model.img_prev_embedding.up_2.layers.conv.weight_orig", "module.averaged_model.img_prev_embedding.up_2.layers.conv.weight_u", "module.averaged_model.img_prev_embedding.up_1.layers.conv.weight_orig", "module.averaged_model.img_prev_embedding.up_1.layers.conv.weight_u", "module.averaged_model.img_prev_embedding.up_0.layers.conv.weight_orig", "module.averaged_model.img_prev_embedding.up_0.layers.conv.weight_u".
Is there a problem with the model? How can I solve it?

I have the same problem, how to solve it?


text:
4G网络下无法下载并且要一分钟左右才会回调onError，WIFI下可以下载

4G网络下无法下载并且要一分钟左右才会回调onError，WIFI下可以下载

  FileDownloader.setupOnApplicationOnCreate(context)

            .connectionCreator(new FileDownloadUrlConnection
                    .Creator(new FileDownloadUrlConnection.Configuration()
                    .connectTimeout(5_000) // set connection timeout.
                    .readTimeout(8_000) // set read timeout.
                    .proxy(Proxy.NO_PROXY) // set proxy
            ))
            .commit();

看上去像是单纯的网络问题，发生的错误是 SocketTimeoutException 。日志看上去也没有什么不正常的地方。有确保当时的 4G 网络确实是 ok 的吗？

方便的话可以提供下你的下载地址，我这边尝试复现一下问题，我的邮箱：vesperdone@gmail.com

authors: rantianhua striveenFei

repo: lingochamp/FileDownloader


text:
javax.net.ssl.SSLException: Read error: ssl=0x743c10e800: I/O error during system call, Connection reset by peer

你好，在使用三星手机下载单个视频文件时，连接某个wifi网络下载每次都是失败，回调error：notify error -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 javax.net.ssl.SSLException: Read error: ssl=0x743c10e800: I/O error during system call, Connection reset by peer
25 17:15:12.101 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify pending -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93
09-25 17:15:12.103 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[1] new[6] 1
09-25 17:15:12.103 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify started -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93
09-25 17:15:12.103 4620-11895/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.ConnectTask: -2108620344 request header {Range=[bytes=0-]}
09-25 17:15:13.632 4620-11895/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FileDownloadUtils: etag find "69e304385b148360137e9c2e286aa027-2" for task(-2108620344)
09-25 17:15:13.644 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[6] new[2] 1
09-25 17:15:13.645 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify connected -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93
09-25 17:15:13.676 4620-11895/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.DownloadLaunchRunnable: fetch data with multiple connection(count: [3]) for task[-2108620344] totalLength[7391596]
09-25 17:15:13.677 4620-11895/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.DownloadLaunchRunnable: enable multiple connection: id[-2108620344] index[0] range[0, 2463864) current offset(0)
09-25 17:15:13.678 4620-11895/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.DownloadLaunchRunnable: enable multiple connection: id[-2108620344] index[1] range[2463865, 4927729) current offset(2463865)
09-25 17:15:13.679 4620-11895/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.DownloadLaunchRunnable: enable multiple connection: id[-2108620344] index[2] range[4927730, 0) current offset(4927730)
09-25 17:15:13.685 4620-11923/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.ConnectTask: -2108620344 request header {Range=[bytes=0-2463864]}
09-25 17:15:13.686 4620-11924/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.ConnectTask: -2108620344 request header {Range=[bytes=2463865-4927729]}
09-25 17:15:13.694 4620-11925/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.ConnectTask: -2108620344 request header {Range=[bytes=4927730-]}
09-25 17:15:14.960 4620-11924/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.DownloadRunnable: the connection[1] for -2108620344, is connected range[2463865, 4927729) current offset[2463865] with code[206]
09-25 17:15:14.962 4620-11924/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: start fetch(1): range [2463865, 4927729), seek to[2463865]
09-25 17:15:14.963 4620-11925/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.DownloadRunnable: the connection[2] for -2108620344, is connected range[4927730, 0) current offset[4927730] with code[206]
09-25 17:15:14.966 4620-11923/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.DownloadRunnable: the connection[0] for -2108620344, is connected range[0, 2463864) current offset[0] with code[206]
09-25 17:15:14.967 4620-11925/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: start fetch(2): range [4927730, 0), seek to[4927730]
09-25 17:15:14.969 4620-11923/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: start fetch(0): range [0, 2463864), seek to[0]
09-25 17:15:14.994 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[2] new[3] 1
09-25 17:15:14.995 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 4096 7391596
09-25 17:15:15.000 4620-11924/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[1] offset[2467961], consume[9]
09-25 17:15:15.036 4620-11925/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[2] offset[4931826], consume[17]
09-25 17:15:15.213 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:15.214 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 84735 7391596
09-25 17:15:15.218 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:15.221 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 85783 7391596
09-25 17:15:16.699 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:16.700 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 163607 7391596
09-25 17:15:16.701 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:16.703 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 171775 7391596
09-25 17:15:16.706 4620-11923/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[0] offset[68169], consume[9]
09-25 17:15:18.070 4620-11924/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[1] offset[2537172], consume[8]
09-25 17:15:18.100 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:18.100 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 245503 7391596
09-25 17:15:18.244 4620-11925/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[2] offset[5001037], consume[17]
09-25 17:15:18.469 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:18.472 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 333591 7391596
09-25 17:15:18.919 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:18.921 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 414439 7391596
09-25 17:15:18.924 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:18.926 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 414439 7391596
09-25 17:15:19.248 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:19.249 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 493311 7391596
09-25 17:15:19.251 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:19.252 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 501479 7391596
09-25 17:15:19.788 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:19.788 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 576255 7391596
09-25 17:15:20.018 4620-11923/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[0] offset[133729], consume[21]
09-25 17:15:20.096 4620-11924/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[1] offset[2724564], consume[20]
09-25 17:15:20.112 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:20.116 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 659199 7391596
09-25 17:15:20.120 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:20.124 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 660247 7391596
09-25 17:15:21.489 4620-11925/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[2] offset[5192525], consume[16]
09-25 17:15:21.520 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:21.521 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 737023 7391596
09-25 17:15:22.101 4620-11923/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[0] offset[203361], consume[8]
09-25 17:15:22.374 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:22.376 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 815871 7391596
09-25 17:15:23.165 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:23.168 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 894743 7391596
09-25 17:15:23.171 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:23.174 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 902911 7391596
09-25 17:15:23.290 4620-11924/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[1] offset[2793148], consume[11]
09-25 17:15:23.423 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:23.424 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 977687 7391596
09-25 17:15:23.642 4620-11925/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[2] offset[5296973], consume[18]
09-25 17:15:23.650 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:23.653 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 1058535 7391596
09-25 17:15:24.221 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:24.222 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 1138455 7391596
09-25 17:15:24.469 4620-11923/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[0] offset[334433], consume[7]
09-25 17:15:24.473 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:24.474 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 1216255 7391596
09-25 17:15:24.785 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:24.790 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 1291031 7391596
09-25 17:15:25.060 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:25.061 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 1372927 7391596
09-25 17:15:25.371 4620-11924/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[1] offset[2954964], consume[29]
09-25 17:15:25.424 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:25.427 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 1447703 7391596
09-25 17:15:25.684 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:25.685 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 1529599 7391596
09-25 17:15:25.686 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:25.687 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 1529599 7391596
09-25 17:15:25.840 4620-11925/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[2] offset[5471053], consume[17]
09-25 17:15:26.040 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:26.043 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 1604375 7391596
09-25 17:15:26.396 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:26.397 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 1678103 7391596
09-25 17:15:27.796 4620-11923/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[0] offset[525921], consume[20]
09-25 17:15:27.818 4620-11924/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[1] offset[3059412], consume[19]
09-25 17:15:27.834 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:27.837 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 1765143 7391596
09-25 17:15:27.840 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:27.843 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 1773311 7391596
09-25 17:15:27.893 4620-11925/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[2] offset[5540685], consume[21]
09-25 17:15:30.237 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:30.240 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 1848087 7391596
09-25 17:15:30.453 4620-11923/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[0] offset[595553], consume[26]
09-25 17:15:30.462 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:30.466 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 1925911 7391596
09-25 17:15:30.672 4620-11925/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[2] offset[5610317], consume[22]
09-25 17:15:30.827 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:30.829 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 2003711 7391596
09-25 17:15:30.835 4620-11924/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[1] offset[3129044], consume[23]
09-25 17:15:31.196 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:31.199 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 2081535 7391596
09-25 17:15:31.202 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:31.205 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 2085607 7391596
09-25 17:15:31.935 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:31.937 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 2164479 7391596
09-25 17:15:31.940 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:31.942 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 2168575 7391596
09-25 17:15:32.396 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:32.397 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 2252567 7391596
09-25 17:15:32.399 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:32.400 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 2260735 7391596
09-25 17:15:32.480 4620-11923/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[0] offset[748129], consume[19]
09-25 17:15:32.835 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[3] 1
09-25 17:15:32.838 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify progress -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 2335511 7391596
09-25 17:15:32.851 4620-11925/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[2] offset[5749581], consume[23]
09-25 17:15:32.940 4620-11923/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[0] offset[765537], consume[7]
09-25 17:15:32.961 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.MessageSnapshotGate: ~~~callback -2108620344 old[3] new[-1] 1
09-25 17:15:32.963 3088-11896/com.ubtechinc.alpha2_alexa V/FileDownloader.FileDownloadList: remove -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 left -1 0
09-25 17:15:32.964 3088-11896/com.ubtechinc.alpha2_alexa D/FileDownloader.FileDownloadMessenger: notify error -2108620344@com.liulishuo.filedownloader.DownloadTask@cc33e93 javax.net.ssl.SSLException: Read error: ssl=0x743c10e800: I/O error during system call, Connection reset by peer
09-25 17:15:32.965 3088-11896/com.ubtechinc.alpha2_alexa V/FileDownloader.DownloadTaskHunter: filedownloader:lifecycle:over com.liulishuo.filedownloader.DownloadTaskHunter@29b2ec9 by -1
09-25 17:15:32.970 4620-11924/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[1] offset[3216084], consume[9]
09-25 17:15:32.989 4620-11925/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[2] offset[5762893], consume[7]
09-25 17:15:32.990 4620-11925/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.DownloadStatusCallback: require callback -1 but the host thread of the flow has already dead, what is occurred because of there are several reason can final this flow on different thread.
09-25 17:15:33.018 4620-11924/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.FetchDataTask: require sync id[-2108620344] index[1] offset[3216084], consume[11]
09-25 17:15:33.020 4620-11895/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.DownloadLaunchRunnable: finish sub-task for [-2108620344] TRUE FALSE
09-25 17:15:33.021 4620-11895/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.DownloadLaunchRunnable: finish sub-task for [-2108620344] TRUE FALSE
09-25 17:15:33.022 4620-11895/com.ubtechinc.alpha2_alexa:filedownloader D/FileDownloader.DownloadLaunchRunnable: finish sub-task for [-2108620344] TRUE FALSE

我刚刚也遇到这个问题，我下载的视频地址为：
https://scontent-sin6-1.cdninstagram.com/t50.2886-16/20639948_1877553475898837_2968671662599307264_n.mp4

这个应该不是FileDownloader的问题，是网络连接的问题，参考这里: https://github.com/lingochamp/FileDownloader/issues/473#issuecomment-278847797

authors: Jacksgong didikeeLunaon leoncoding


text:
restructure composer requirements

Not all requirements are needed, only for testing.

Thanks! :+1:

authors: dennisdegreef jildertmiedema


text:
Não é possivel instalar

Pessoal, não consigo rodar o front. Alguém pode ajudar?

@jvoltz, poderia informar qual a versão do Node/Npm vc está utilizando?

Olá. Eu estava testando em um Ubuntu com a versão 10.15 do node.

@jvoltz, Poderia tentar rodar novamente utilizando a versão 6.11.5 do node?

Estou com um problema semelhante, instalei a versao 6.11.5 do node e deu tudo certo... O problema é que com a versão 6.11.5 o problema ocorre com o 'getokr-api' , não reconhece o token 'async function' (que pelo que vi só está disponível no node 7.6 pra cima.
Instalei o 7.6 e o problema volta a ocorrer no getokr-web

@mtkkk Obrigado por reportar o problema, subi uma alteração tanto na API quanto no WEB para corrigir o mesmo.
Após corrigir o problema, realizei os testes utilizando a versão 8.11.1 de Node e 3.10.10 do NPM.
Poderia tentar novamente? Aguardo o feedback

Problema resolvido! Obrigado pela atenção :)

authors: icarocleto jvoltz mtkkk

repo: linkapi/getokr-web


text:
C++ module example using VS 2022/CMake

Here is an example on how to provide a C++ module alongside the header file.
Only tested with Visual Studio 2020 alongside CMake. Currently don't have access to clang 17.
I also had to explicitly add the required standard library includes to the test files.

If nothing else, it is way to learn about how to do this, when modules are more mature.

I see.
I'd rather not have CMake though for this very little library. I'll lookup what the CMake directives are actually doing and check if I can do this with gcc/mingw64.

Thanks, I'll keep it open for reference, and probably add a milestone in the future. I consider closed PRs as either rejected (aka: wontfix) or merged 🙂

authors: linkdd pjmlp

repo: linkdd/logfmtxx


text:
Report ClientID for consumers

Store and report ClientID for consumers, this is useful in environments where IPs are not ideal for identifying consumers. The ClientID is an ideal choice as it's user controlled so can be configured to be whatever the user finds most useful for correlation purposes.

Coverage increased (+0.0004%) to 74.614% when pulling 5ae52aea7990ccbeb449cce09c6f8ca10b52b0b2 on postmates:jpg/report-client-id into 429c6e8d4f58cfd9b6b76da035d98f12d3cf0c41 on linkedin:master.

Thanks!

authors: bai coveralls josephglanville

repo: linkedin/Burrow


text:
Support nextMarker and nextContinuationToken

Support nextMarker for listObject and nextContinuationToken for listObjectV2

Codecov Report
Attention: Patch coverage is 48.64865% with 19 lines in your changes missing coverage. Please review.

Project coverage is 18.65%. Comparing base (52ba813) to head (fe3ca37).
Report is 33 commits behind head on master.

Files
Patch %
Lines

...com/github/ambry/frontend/s3/S3MessagePayload.java
52.38%
10 Missing :warning:

...va/com/github/ambry/frontend/s3/S3ListHandler.java
43.75%
7 Missing and 2 partials :warning:

:exclamation:  There is a different number of reports uploaded between BASE (52ba813) and HEAD (fe3ca37). Click for more details.
HEAD has 2 uploads less than BASE
| Flag | BASE (52ba813) | HEAD (fe3ca37) |
|------|------|------|
||3|1|

Additional details and impacted files
@@              Coverage Diff              @@
##             master    #2807       +/-   ##
=============================================
- Coverage     64.24%   18.65%   -45.60%
+ Complexity    10398     2919     -7479
=============================================
  Files           840      842        +2
  Lines         71755    72314      +559
  Branches       8611     8703       +92
=============================================
- Hits          46099    13489    -32610
- Misses        23004    57585    +34581
+ Partials       2652     1240     -1412

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

repo: linkedin/ambry


text:
Cleanup deprecated code from PinotLLCRealtimeSegmentManager and ValidationManager

As part of https://github.com/linkedin/pinot/pull/2721 we refactored the PinotLLCRealtimeSegmentManager to not depend on znode for stream partition assignment. A lot of methods were rewritten, and older ones deprecated. This PR attempts to clean up all the deprecated and unused methods

Codecov Report

Merging #2762 into master will increase coverage by 11.48%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #2762       +/-   ##
==========================================
+ Coverage   57.51%     69%   +11.48%
==========================================
  Files         876     876
  Lines       42319   41993      -326
  Branches     5754    5708       -46
==========================================
+ Hits        24339   28976     +4637
+ Misses      16288   11144     -5144
- Partials     1692    1873      +181

Impacted Files
Coverage Δ

.../core/realtime/PinotLLCRealtimeSegmentManager.java
55.6% <ø> (+49.79%)
:arrow_up:

...pinot/controller/validation/ValidationManager.java
84.39% <ø> (+48.32%)
:arrow_up:

...not/transport/scattergather/ScatterGatherImpl.java
55.69% <0%> (+0.63%)
:arrow_up:

...ore/realtime/impl/RealtimeSegmentStatsHistory.java
80.95% <0%> (+0.68%)
:arrow_up:

.../pinot/core/segment/index/SegmentMetadataImpl.java
81.56% <0%> (+0.7%)
:arrow_up:

...t/creator/impl/SegmentIndexCreationDriverImpl.java
88.43% <0%> (+0.74%)
:arrow_up:

...r/transform/function/ValueInTransformFunction.java
39.2% <0%> (+0.8%)
:arrow_up:

.../helix/core/realtime/SegmentCompletionManager.java
69.54% <0%> (+0.9%)
:arrow_up:

...din/pinot/core/realtime/stream/StreamMetadata.java
67.88% <0%> (+0.91%)
:arrow_up:

...e/io/writer/impl/MutableOffHeapByteArrayStore.java
86.59% <0%> (+1.03%)
:arrow_up:

... and 272 more

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 2d22966...84e50a3. Read the comment docs.

authors: codecov-io npawar

repo: linkedin/pinot