Expo - Duplicate module name: react-native

Paths<EMAIL_ADDRESS>collides with /Users/user/myapp/app/node_modules/react-native/package.json
$ expo diagnostics

  Expo CLI 2.21.2 environment info:
    System:
      OS: macOS 10.14.5
      Shell: 5.3 - /bin/zsh
    Binaries:
      Node: 10.16.0 - ~/.nvm/versions/node/v10.16.0/bin/node
      Yarn: 1.16.0 - ~/.yarn/bin/yarn
      npm: 6.9.0 - ~/.nvm/versions/node/v10.16.0/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    IDEs:
      Android Studio: 3.4 AI-183.6<IP_ADDRESS>22156
      Xcode: 10.2.1/10E1001 - /usr/bin/xcodebuild
    npmPackages:
      expo: ^33.0.0 => 33.0.7
      react: 16.8.3 => 16.8.3
      react-native: https://github.com/expo/react-native/archive/sdk-33.0.0.tar.gz => 0.59.8
      react-navigation: ^3.3.0 => 3.11.0
    npmGlobalPackages:
      expo-cli: 2.21.2

"dependencies": {
    "@expo/vector-icons": "^9.0.0",
    "@rimiti/react-native-toastify": "^1.2.0",
    "axios": "^0.18.0",
    "expo": "^33.0.0",
    "expo-linear-gradient": "~5.0.1",
    "formik": "^1.5.1",
    "lodash": "^4.17.11",
    "metro-react-native-babel-preset": "^0.52.0",
    "moment": "^2.24.0",
    "react": "16.8.3",
    "react-native": "https://github.com/expo/react-native/archive/sdk-33.0.0.tar.gz",
    "react-native-datepicker": "^1.7.2",
    "react-native-dotenv": "^0.2.0",
    "react-native-elements": "^1.1.0",
    "react-native-modal-selector": "^1.0.3",
    "react-navigation": "^3.3.0",
    "styled-components": "^4.1.3",
    "yup": "^0.26.10"
  },

$ expo publish
Unable to find an existing Expo CLI instance for this directory, starting a new one...
Starting Metro Bundler on port 19001.
Tunnel ready.
Publishing to channel 'default'...
(node:4924) UnhandledPromiseRejectionWarning: Error: jest-haste-map: Haste module naming collision:
  Duplicate module name: react-native
  Paths<EMAIL_ADDRESS>collides with /Users/user/myapp/app/node_modules/react-native/package.json

This error is caused by `hasteImpl` returning the same name for different files.
    at setModule (/Users/user/myapp/app/node_modules/jest-haste-map/build/index.js:569:17)
    at workerReply (/Users/user/myapp/app/node_modules/jest-haste-map/build/index.js:641:9)
    at process._tickCallback (internal/process/next_tick.js:68:7)
(node:4924) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:4924) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
(node:4924) UnhandledPromiseRejectionWarning: Error: jest-haste-map: Haste module naming collision:
  Duplicate module name: react-native
  **Paths<EMAIL_ADDRESS>collides with /Users/user/myapp/app/node_modules/react-native/package.json**

This error is caused by `hasteImpl` returning the same name for different files.
    at setModule (/Users/user/myapp/app/node_modules/jest-haste-map/build/index.js:569:17)
    at workerReply (/Users/user/myapp/app/node_modules/jest-haste-map/build/index.js:641:9)
    at process._tickCallback (internal/process/next_tick.js:68:7)
(node:4924) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 3)

Building iOS bundle
Error: jest-haste-map: Haste module naming collision:
  Duplicate module name: react-native
  Paths<EMAIL_ADDRESS>collides with /Users/user/myapp/app/node_modules/react-native/package.json

This error is caused by `hasteImpl` returning the same name for different files.
    at setModule (/Users/user/myapp/app/node_modules/jest-haste-map/build/index.js:569:17)
    at workerReply (/Users/user/myapp/app/node_modules/jest-haste-map/build/index.js:641:9)
    at process._tickCallback (internal/process/next_tick.js:68:7)

Hello @appjitsu ,
Do you still have this error ? Did you try to update RN ?

I have different problem but I believe the root cause is the same. The problem is that react-native-toastify includes all react and react-native stuff as direct dependencies. How this should be done is through peer dependencies instead.
I think package.json of this library should look something like this:
"dependencies": {
    "prop-types": "15.x"
  },
"peerDependencies": {
    "react": "16.x",
    "react-dom": "16.x",
    "react-native": "0.59.x"
}

Hello @ronkot ,
Could you please test this<EMAIL_ADDRESS>version and let me know if it's now ok. 🙏

I confirm you that's working well:

Nice, super speed fix 😄  🎉
Using exact version numbers as a peer dependency will cause version mismtach warnings for most users, but it should not affect the behavior. If you want to refine the fix further, just use peer dependency version range as I suggested in https://github.com/rimiti/react-native-toastify/issues/11#issuecomment-668392449.
Anyway, super work. Thanks for this library! 💪

Aha!
Thanks for your contribution 🙏
New PR related to your last comment. #20


Is it possible to link multiple states?

Is it possible to link a change event to multiple objects in state?
In my use case, there are three state objects that have 3 inputs in my app but a special case requires me to keep them in sync against one input object.
P.S. Thanks for building this.

Currently, I am doing something as ugly as
onTitleChange={
                  type === "CAREER"
                    ? e => {
                        e.persist();
                        this.setState(prevState => {
                          return {
                            ...prevState,
                            version: {
                              ...prevState.version,
                              title_de: e.target.value,
                              title_en: e.target.value,
                              title_cn: e.target.value
                            }
                          };
                        });
                      }
                    : linkState(this, "version.title_de")
                }

but I wonder if this can be made better by composed linkState or something.


directive implemented

Hi team,
This PR is a declination of click-away.
This one is specific for inputs avoiding to lose focus when clicking down within input and releasing the click outside.

:tada: This PR is included in version 1.4.0-rc.5 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update migration guide feedback link to the working group

I've update all the warning banners to point to this discussion in the working group:

https://github.com/reactwg/react-native-new-architecture/discussions/8

what do you think?

Yup let's do that 👍


Problem: The indexer doesn't have a concept of a production release

Follow the Filesystem Heirachy Standard for production releases.

locked.cvs, genesis block and ledger should be read from /usr/share/mina-indexer/data
Indexer database stored in /var/lib/mina-indexer/database
mina-indexer binary in /usr/bin

Maybe we should use something along the lines of https://docs.rs/clap_conf/latest/clap_conf/ to unify the CLI args, env variables and config files?

I think we need to set default values conditionally in clap. Production values point to the standard FHS otherwise maintain status quo.

@trevorbernard I think that the 'nix build' generates a package that does indeed follow the FHS, and is usable as a production release. Are there any remaining directories or files to add? Here is what I have:

|-- bin
|   `-- mina-indexer
|-- usr
|   `-- share
|       `-- mina-indexer
|           `-- data
|               |-- locked.csv
|               |-- mainnet-1-3NKeMoncuHab5ScarV5ViyF16cJPT4taWNSaTLS64Dp67wuXigPZ.json
|               `-- mainnet.json
`-- var
    |-- lib
    |   `-- mina-indexer
    `-- log
        `-- mina-indexer


temp config for edge-view with configitem

Signed-off-by: Naiming Shen<EMAIL_ADDRESS>
a temp solution to allow testing edge-view on the EVE device before the zedcloud config/UI are fully supported.

@eriknordmark right. I don't have much description on the 'edge-view' itself. 'edge-view' will be installed as a dom0 container service, and has the /run/edge-view mounted to access to read this data from. This patch is to write the authentication data into it for near term testing.
the reading part is a container script:
#!/bin/sh
while true;
do
sleep 5
PID=$(pgrep /usr/bin/edge-view)
if [ -z "$PID" ]; then
if [ -f /run/edgeview/edge-view-token ]; then
TOKEN=cat /run/edgeview/edge-view-token
WSADDR=cat /run/edgeview/edge-view-wss-addr
/usr/bin/edge-view -server -ws "$WSADDR" -token "$TOKEN" &
PID=$(pgrep /usr/bin/edge-view)
echo "started edge-view with pid $PID"
fi
else
if [ ! -f /run/edgeview/edge-view-token ]; then
kill -9 $PID
echo "edge-view killed"
fi
fi
done

@rvs understood. lets hold on this PR until the main portion is in later.

No need for this PR. The temporary config will be supported in  Edge-View API and JWT #2427 . Close this.


impl not works fine when compressed

rusted.impl checks whether method is associated function (=static method) or not by seeing (function).toString().
If !((function).toString()).match(/^function\*?\s*[a-zA-Z0-9_$]*\(self[),\s]/) was true, the passed function were attached as static method.
The problem is, when we compress code, a first argument of the function will turn into simple name (like a) even if we wrote self as first argument, and all functions are attached as static method.

Fixed in 1.0.0


rbd: add support to create clone in different pools

Add support to restore a pvc into a different pool.
Assuming there are 2 pools namely "replicapool" and "testpool"
Workflow:

Create a PVC in a replicapool.
For cloning, a snapshot gets created in replicapool.
PVC restore operation can be done in a new pool named testpool.

Co-authored-by: Madhu Rajanna<EMAIL_ADDRESS>Updates: #1838

/retest ci/centos/mini-e2e-helm/k8s-1.19

/retest ci/centos/mini-e2e-helm/k8s-1.19

rook deployment failed with
X Exiting due to GUEST_PROVISION: Failed to start host: creating host: create: Error creating machine: Error in driver during machine creation: IP not available after waiting: machine minikube didn't return IP after 1 minute

CI failure due to #2146

/retest all

@Yuggupta27 As discussed please get the comments addressed in other PR . will get this in for now! Thanks :+1:

/retest all

/retest ci/centos/mini-e2e/k8s-1.19

/retest ci/centos/mini-e2e/k8s-1.19

rook deployment failure

/retest all

@Mergifyio rebase


#187 Added @10up/babel-preset-default to dev dependencies.

Description of the Change
Adds @10up/babel-preset-default to dev dependencies
Closes #187
How to test the Change

Note and test the repeatable steps on #187 to see the error on the trunk branch
Switch to this branch and run: npm install; npm run build
Build should complete successfully

Changelog Entry

Fixed - Missing dependency

Credits
Props @jamesmorrison
Checklist:

[x] I agree to follow this project's Code of Conduct.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my change.
[ ] All new and existing tests pass.

@jamesmorrison is this still relevant?

I don't think so... this shoulnd't be needed and I haven't seen reports of this problem.

This can be closed; I opened the PR because I had the same issue on multiple projects, but haven’t had any issues with this in recent releases.


Support for separate debug symbol files when using uprobes?

Just a quick question / feature request: it seems that separate debug files are not supported when using bpftrace with uprobes. The stripped library binary I'm tracing does contain the .gnu_debuglink section, and I tried with the debug symbol file in the same directory as the .so file as well as behind Ubuntu's standard /usr/lib/debug/... path, but to no avail. So should this work and I just did something wrong, or is this something that might be supported in the future?

Some support for debuginfo symbols is supposed to work, but when I tried it didn't work either. Maybe we're missing something. We defer to libbcc for symbol lookups; relevant change:
https://github.com/iovisor/bpftrace/commit/1132d426004faa7fa465ceb4b58d539062afc096

+1 for this feature. Use-case: want to trace already-running code in a container which is part of a standard "debug" version distro, except the debug files are separate from the main executable. As temporary workaround, I merged the debug symbols back into the executable via elf-utils eu-unstrip command, but this was cumbersome in my case.
BTW I can use bpftrace -l 'uprobe:path-to-debug-file:symbol' and find the symbol of interest, but when I try to trace this symbol in a script using same  'uprobe:path-to-debug-file:symbol' it never triggers. I'd expect to just trace 'uprobe:path-to-stripped-binary:symbol' and let bpftrace find the debug file. Does bpftrace make some assumptions where the debug file is? In my case its in the  /usr/lib/debug/.build-id/01/ directory, and gdb finds it automatically.
Thanks!

BTW I can use bpftrace -l 'uprobe:path-to-debug-file:symbol' and find the symbol of interest, but when I try to trace this symbol in a script using same 'uprobe:path-to-debug-file:symbol' it never triggers.

Right, this makes sense b/c debug file is never actually executed.

I'd expect to just trace 'uprobe:path-to-stripped-binary:symbol' and let bpftrace find the debug file.

I agree. This should work.

Does bpftrace make some assumptions where the debug file is? In my case its in the /usr/lib/debug/.build-id/01/ directory, and gdb finds it automatically.

I haven't looked at the details but this would probably require BCC changes. Shouldn't be too complicated. cc @davemarchevsky

Thanks for the responses!

What is the current status of this?

@chrispsommers

+1 for this feature. Use-case: want to trace already-running code in a container which is part of a standard "debug" version distro, except the debug files are separate from the main executable. As temporary workaround, I merged the debug symbols back into the executable via elf-utils eu-unstrip command, but this was cumbersome in my case.
BTW I can use bpftrace -l 'uprobe:path-to-debug-file:symbol' and find the symbol of interest, but when I try to trace this symbol in a script using same 'uprobe:path-to-debug-file:symbol' it never triggers. I'd expect to just trace 'uprobe:path-to-stripped-binary:symbol' and let bpftrace find the debug file. Does bpftrace make some assumptions where the debug file is? In my case its in the  /usr/lib/debug/.build-id/01/ directory, and gdb finds it automatically.
Thanks!

Never triggering can also be because the path of the executable somehow doesn't match with how the symbol is invoked. You can test this by artificially invoking the symbol. I couldn't find the exact specs for this executable path argument.

+1 for this feature. Use-case: want to trace already-running code in a container which is part of a standard "debug" version distro, except the debug files are separate from the main executable. As temporary workaround, I merged the debug symbols back into the executable via elf-utils eu-unstrip command, but this was cumbersome in my case.
BTW I can use bpftrace -l 'uprobe:path-to-debug-file:symbol' and find the symbol of interest, but when I try to trace this symbol in a script using same 'uprobe:path-to-debug-file:symbol' it never triggers. I'd expect to just trace 'uprobe:path-to-stripped-binary:symbol' and let bpftrace find the debug file. Does bpftrace make some assumptions where the debug file is? In my case its in the  /usr/lib/debug/.build-id/01/ directory, and gdb finds it automatically.
Thanks!

This issue is quite old now, but in case anybody stumbled across it with a similar use case --
Since v0.26.0, bcc looks for an env variable BCC_DEBUGINFO_ROOT. If you want to run bpftrace on a process running in a container from outside, the variable can set to the location withing the process's root. For example:
export BCC_DEBUGINFO_ROOT="/proc/14110/root/lib/debug"

You can then list and use uprobes with the same root path:
bpftrace -l "uprobe:/proc/14110/root/bin/dpkg:*"


Fail to build Apk

Hey, I am getting below error message when I am building apk-
command used- flutter build apk --target-platform=android-arm64 --no-tree-shake-icons or flutter build apk --split-per-abi --no-tree-shake-icons
version- flutter_login_facebook 0.4.0+1
FAILURE: Build failed with an exception.

* What went wrong:
A problem was found with the configuration of task ':flutter_login_facebook:compileReleaseJavaWithJavac'.
> File '/home/yash/Programming/flutter/appName/build/flutter_login_facebook/intermediates/annotation_processor_list/release/annotationProcessors.json' specified for property 'processorListFile' does not exist.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Please let me know if you need more info.

Hey!
@ycv005 can you please write about problem and how it was solved? In case if any who will face this problem in future.

hey, I solved by following this -https://stackoverflow.com/questions/61493529/how-to-fix-processorlistfile-does-not-exist-when-building-appbundle-in-flutte


Wrong message in a cyclic dependency scenario

Scenario
Project A has a Foo trait and project B has a Bar trait. Foo has the Bar bound associated with it (Foo: Bar), therefore, project A depends on project B ([dependencies] b = { path = "../b" }). Now, project B depends on project A as a development dependency ([dev-dependencies] a = { path = "../a" }) and the following code:
#[cfg(test)]
mod tests {
    struct Something;
    impl crate::Bar for Something {}
    impl a::Foo for Something {}
}

Triggers an erroneous message of this cyclic dependency: the trait 'a::Foo' is not implemented for 'tests::Something'.
Not sure if cyclic dependencies are allowed with development crates but the showed message in this case is obviously wrong.
Notes
Output of cargo version: cargo 1.40.0-nightly (a429e8cc4 2019-10-04)

Thanks for the report. I think this is essentially the same as #6765, so I'm going to close in favor of that.

Thanks. They are indeed the same


Bypass Sentinel file check with a "none" policy

Context
Following last Syncup Meeting (Tuesday April 18), we are now targeting multiple new features :

short term : bypassing Sentinel file check with a "none" policy
mid term : working on a alternate qemu-guest-agent usage to check file
long term : making the whole SSH logic optional (for keygen & cloud-init management...) with something like a Sentinel File check mode selector in spec

This Issue tracks short term item 1.
Feature Description
Define & implement a Sentinel Check file mode selector.
By default, this selector must preserve current CAPK behavior (SSH check)
We need to add a new "None" mode, which bypass Sentinel file check and act like machine were always bootstrapped.

SSH keys are still managed and provisionned all the time on the VMs, even if Sentinel file is not checked.
Configuration should be tested & flexible enough for future enhancements (Actions items 2. & 3. )

CRD Change Proposal
Adding a new optional string field in KubevirtMachine (& KubevirtMachineTemplate) CR.
This string would describe how CAPI Sentinel File is checked for a single Machine.
Since this value is set on the machine, multiple check strategies can live in the same cluster without any problem.
Sanity checks and default value should be implemented to filter values & to make SSH the default option.
Expected value would be : none and ssh. Empty value will fallback to ssh, unexpected values would fails the KubevirtMachine reconciliation (or maybe fallback to ssh too , but it really can be risky and deceiving for the end user).
New KubevirtMachine.spec field :
virtualMachineBootstrapCheck:
  checkStrategy: [ "none" | "ssh" ]

Example in a template :
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha1
kind: KubevirtMachineTemplate
metadata:
  name: capi-cluster1-cp
  namespace: capi
spec:
  template:
    spec:
      virtualMachineBootstrapCheck:
        checkStrategy: none
      virtualMachineTemplate:
        metadata:
          namespace: capi
        spec:
          runStrategy: Always
          template:
            spec:
              terminationGracePeriodSeconds: 60
              evictionStrategy: External
              [...]

virtualMachineBootstrapCheck could also be named virtualMachineBootstrap. This is probably shorter.

fixed by #239


problem with 'allow_smaller_final_batch' and 'beam_search_decode'

Hi there, I encountered an error when trying the seq2seq_attn example with iwslt14 dataset. The full error log is appended at the end of the post.
The error occurs when operating this line:
https://github.com/asyml/texar/blob/9c699e8143fd8ecb5d65a41ceef09c45832b9258/examples/seq2seq_attn/seq2seq_attn.py#L125
It indicates that the training stage is ok, and the bug occurs in the validation stage.
Here are two pieces of error logs:
2018-09-11 16:04:10.567407: W tensorflow/core/framework/op_kernel.cc:1318] OP_REQUIRES failed at tensor_array_ops.cc:1122 : Invalid argument: TensorArray bidirectional_rnn_encoder_2/bidirectional_rnn/fw/fw/dynamic_rnn/input_0_32362: Could not write to TensorArray index 0 because the value shape is [23,256] which is incompatible with the TensorArray's inferred element shape: [32,256] (consider setting infer_shape=False).
2018-09-11 16:04:10.567928: W tensorflow/core/framework/op_kernel.cc:1318] OP_REQUIRES failed at tensor_array_ops.cc:1122 : Invalid argument: TensorArray bidirectional_rnn_encoder_2/bidirectional_rnn/bw/bw/dynamic_rnn/input_0_32364: Could not write to TensorArray index 0 because the value shape is [23,256] which is incompatible with the TensorArray's inferred element shape: [32,256] (consider setting infer_shape=False).
......

Caused by op 'attention_rnn_decoder_5/tile_batch_1/Reshape', defined at:
  File "seq2seq_attn.py", line 161, in <module>
    main()
  File "seq2seq_attn.py", line 93, in main
    train_op, infer_outputs = build_model(batch, train_data)
  File "seq2seq_attn.py", line 77, in build_model
    max_decoding_length=60)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/texar/modules/decoders/beam_search_decode.py", line 193, in beam_search_decode
    cell = decoder_or_cell._get_beam_search_cell(beam_width=beam_width)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/texar/modules/decoders/rnn_decoders.py", line 545, in _get_beam_search_cell
    memory_seq_length, beam_width)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/contrib/seq2seq/python/ops/beam_search_decoder.py", line 122, in tile_batch
    return nest.map_structure(lambda t_: _tile_batch(t_, multiplier), t)
......

As there is no problem in training stage, I guess there might be something wrong in the implementation of beam_search_decode.
The error can be described as: the tensor expects a dimension of 32 while we feed 23 instead.
And I find that the batch size is 32, and there are 887 validation examples in valid.de, where 887 % 32 == 23.
Also, add 'allow_smaller_final_batch': False to the val and test item of config_iwslt14.py can get rid of the error.
But this "fix" is not what we really want. Theoretically, we are supposed to run validation and test on all the dev/test samples.
I am using tensorflow 1.8.
Please let me know if I need to provide any other environment information.
The full logs:
$ python seq2seq_attn.py --config_model config_model --config_data config_iwslt14
2018-09-11 15:50:03.793617: I tensorflow/core/platform/cpu_feature_guard.cc:140] Your CPU supports instructions that this TensorFlow binary was not compiled to use: SSE4.1 SSE4.2 AVX AVX2 FMA
2018-09-11 15:50:04.038875: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1356] Found device 0 with properties:
name: Tesla P40 major: 6 minor: 1 memoryClockRate(GHz): 1.531
pciBusID: 0000:02:00.0
totalMemory: 22.38GiB freeMemory: 22.21GiB
2018-09-11 15:50:04.038945: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1435] Adding visible gpu devices: 0
2018-09-11 15:50:04.384688: I tensorflow/core/common_runtime/gpu/gpu_device.cc:923] Device interconnect StreamExecutor with strength 1 edge matrix:
2018-09-11 15:50:04.384752: I tensorflow/core/common_runtime/gpu/gpu_device.cc:929]      0
2018-09-11 15:50:04.385091: I tensorflow/core/common_runtime/gpu/gpu_device.cc:942] 0:   N
2018-09-11 15:50:04.385631: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1053] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 21549 MB memory) -> physical GPU (device: 0, name: Tesla P40, pci bus id: 0000:02:00.0, compute capability: 6.1)
step=0, loss=481.5847
step=500, loss=101.2404
step=1000, loss=75.9185
step=1500, loss=102.7388
step=2000, loss=81.9897
step=2500, loss=64.7623
step=3000, loss=76.1445
step=3500, loss=81.1186
step=4000, loss=48.0918
step=4500, loss=54.7355
step=5000, loss=74.8126
2018-09-11 16:04:10.567407: W tensorflow/core/framework/op_kernel.cc:1318] OP_REQUIRES failed at tensor_array_ops.cc:1122 : Invalid argument: TensorArray bidirectional_rnn_encoder_2/bidirectional_rnn/fw/fw/dynamic_rnn/input_0_32362: Could not write to TensorArray index 0 because the value shape is [23,256] which is incompatible with the TensorArray's inferred element shape: [32,256] (consider setting infer_shape=False).
2018-09-11 16:04:10.567928: W tensorflow/core/framework/op_kernel.cc:1318] OP_REQUIRES failed at tensor_array_ops.cc:1122 : Invalid argument: TensorArray bidirectional_rnn_encoder_2/bidirectional_rnn/bw/bw/dynamic_rnn/input_0_32364: Could not write to TensorArray index 0 because the value shape is [23,256] which is incompatible with the TensorArray's inferred element shape: [32,256] (consider setting infer_shape=False).
Traceback (most recent call last):
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/python/client/session.py", line 1322, in _do_call
    return fn(*args)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/python/client/session.py", line 1307, in _run_fn
    options, feed_dict, fetch_list, target_list, run_metadata)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/python/client/session.py", line 1409, in _call_tf_sessionrun
    run_metadata)
tensorflow.python.framework.errors_impl.InvalidArgumentError: Input to reshape is a tensor with 230 values, but the requested shape has 320
	 [[Node: attention_rnn_decoder_5/tile_batch_1/Reshape = Reshape[T=DT_INT32, Tshape=DT_INT32, _device="/job:localhost/replica:0/task:0/device:GPU:0"](attention_rnn_decoder_5/tile_batch_1/Tile/_4547, attention_rnn_decoder_5/tile_batch_1/concat)]]
	 [[Node: attention_rnn_decoder_6/decoder/while/LoopCond/_4655 = _HostRecv[client_terminated=false, recv_device="/job:localhost/replica:0/task:0/device:CPU:0", send_device="/job:localhost/replica:0/task:0/device:GPU:0", send_device_incarnation=1, tensor_name="edge_790_attention_rnn_decoder_6/decoder/while/LoopCond", tensor_type=DT_BOOL, _device="/job:localhost/replica:0/task:0/device:CPU:0"](^_cloopattention_rnn_decoder_6/decoder/while/BeamSearchDecoderStep/next_beam_word_ids/y/_4501)]]

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "seq2seq_attn.py", line 161, in <module>
    main()
  File "seq2seq_attn.py", line 149, in main
    val_bleu = _eval_epoch(sess, 'val')
  File "seq2seq_attn.py", line 125, in _eval_epoch
    sess.run(fetches, feed_dict=feed_dict)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/python/client/session.py", line 900, in run
    run_metadata_ptr)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/python/client/session.py", line 1135, in _run
    feed_dict_tensor, options, run_metadata)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/python/client/session.py", line 1316, in _do_run
    run_metadata)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/python/client/session.py", line 1335, in _do_call
    raise type(e)(node_def, op, message)
tensorflow.python.framework.errors_impl.InvalidArgumentError: Input to reshape is a tensor with 230 values, but the requested shape has 320
	 [[Node: attention_rnn_decoder_5/tile_batch_1/Reshape = Reshape[T=DT_INT32, Tshape=DT_INT32, _device="/job:localhost/replica:0/task:0/device:GPU:0"](attention_rnn_decoder_5/tile_batch_1/Tile/_4547, attention_rnn_decoder_5/tile_batch_1/concat)]]
	 [[Node: attention_rnn_decoder_6/decoder/while/LoopCond/_4655 = _HostRecv[client_terminated=false, recv_device="/job:localhost/replica:0/task:0/device:CPU:0", send_device="/job:localhost/replica:0/task:0/device:GPU:0", send_device_incarnation=1, tensor_name="edge_790_attention_rnn_decoder_6/decoder/while/LoopCond", tensor_type=DT_BOOL, _device="/job:localhost/replica:0/task:0/device:CPU:0"](^_cloopattention_rnn_decoder_6/decoder/while/BeamSearchDecoderStep/next_beam_word_ids/y/_4501)]]

Caused by op 'attention_rnn_decoder_5/tile_batch_1/Reshape', defined at:
  File "seq2seq_attn.py", line 161, in <module>
    main()
  File "seq2seq_attn.py", line 93, in main
    train_op, infer_outputs = build_model(batch, train_data)
  File "seq2seq_attn.py", line 77, in build_model
    max_decoding_length=60)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/texar/modules/decoders/beam_search_decode.py", line 193, in beam_search_decode
    cell = decoder_or_cell._get_beam_search_cell(beam_width=beam_width)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/texar/modules/decoders/rnn_decoders.py", line 545, in _get_beam_search_cell
    memory_seq_length, beam_width)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/contrib/seq2seq/python/ops/beam_search_decoder.py", line 122, in tile_batch
    return nest.map_structure(lambda t_: _tile_batch(t_, multiplier), t)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/python/util/nest.py", line 375, in map_structure
    structure[0], [func(*x) for x in entries])
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/python/util/nest.py", line 375, in <listcomp>
    structure[0], [func(*x) for x in entries])
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/contrib/seq2seq/python/ops/beam_search_decoder.py", line 122, in <lambda>
    return nest.map_structure(lambda t_: _tile_batch(t_, multiplier), t)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/contrib/seq2seq/python/ops/beam_search_decoder.py", line 90, in _tile_batch
    ([shape_t[0] * multiplier], shape_t[1:]), 0))
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/python/ops/gen_array_ops.py", line 6113, in reshape
    "Reshape", tensor=tensor, shape=shape, name=name)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/python/framework/op_def_library.py", line 787, in _apply_op_helper
    op_def=op_def)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/python/framework/ops.py", line 3392, in create_op
    op_def=op_def)
  File "/home/luban/miniconda3/envs/tf18/lib/python3.6/site-packages/tensorflow/python/framework/ops.py", line 1718, in __init__
    self._traceback = self._graph._extract_stack()  # pylint: disable=protected-access

InvalidArgumentError (see above for traceback): Input to reshape is a tensor with 230 values, but the requested shape has 320
	 [[Node: attention_rnn_decoder_5/tile_batch_1/Reshape = Reshape[T=DT_INT32, Tshape=DT_INT32, _device="/job:localhost/replica:0/task:0/device:GPU:0"](attention_rnn_decoder_5/tile_batch_1/Tile/_4547, attention_rnn_decoder_5/tile_batch_1/concat)]]
	 [[Node: attention_rnn_decoder_6/decoder/while/LoopCond/_4655 = _HostRecv[client_terminated=false, recv_device="/job:localhost/replica:0/task:0/device:CPU:0", send_device="/job:localhost/replica:0/task:0/device:GPU:0", send_device_incarnation=1, tensor_name="edge_790_attention_rnn_decoder_6/decoder/while/LoopCond", tensor_type=DT_BOOL, _device="/job:localhost/replica:0/task:0/device:CPU:0"](^_cloopattention_rnn_decoder_6/decoder/while/BeamSearchDecoderStep/next_beam_word_ids/y/_4501)]]

Hi, the seq2seq_attn example works fine (both training and validation) on my side, with either tf-1.8 or 1.10.
Make sure you use the "dynamic" batch_size for start_tokens, as here: https://github.com/asyml/texar/blob/master/examples/seq2seq_attn/seq2seq_attn.py#L68
allow_smaller_final_batch is True by default (e.g., if it is not explicitly set to False in config files).

@ZhitingHu , hi, but I didn't change anything in the example. I can reproduce the same error on both my PC and workstation.
As there is no problem with toy_copy dataset, I compared their config file and found the only difference is that allow_smaller_final_batch is set to False.
https://github.com/asyml/texar/blob/9c699e8143fd8ecb5d65a41ceef09c45832b9258/examples/seq2seq_attn/config_iwslt14.py#L10
I also print the shapes of batch for both dataset.
https://github.com/asyml/texar/blob/9c699e8143fd8ecb5d65a41ceef09c45832b9258/examples/seq2seq_attn/seq2seq_attn.py#L91
The shapes are like (32,?) with iwslt14 dataset while (?,?) with toy_copy dataset.
Since tensorflow uses static graph, the decoder (cell), which is contructed with dependency on batch['source_length'],
https://github.com/asyml/texar/blob/9c699e8143fd8ecb5d65a41ceef09c45832b9258/examples/seq2seq_attn/seq2seq_attn.py#L53
expects to recieve the input with a shape of (32,?). There is no problem in training stage for all the batch size is 32 ('allow_smaller_final_batch'=False).
But when it comes to the last batch in validation/test stage, the actual batch size is not 32 (23 in this case). As we use the "dynamic" batch_size for start_tokens, we actually feed the start_tokens with a shape of (23,). Therefore, the decoder refuses the input and produces such error logs.
Honestly, I am curious why there is no problem on your side. IMO, it is not a bug that relates to environment or tf version.
The reason of the bug seems obvious on my side😄. I can easily reproduce or get rid of it by swithing allow_smaller_final_batch.

Hmm.. Printing batch I got:
{
    'source_text': <tf.Tensor 'IteratorGetNext:1' shape=(?, ?) dtype=string>,
    'source_text_ids': <tf.Tensor 'IteratorGetNext:2' shape=(?, ?) dtype=int64>,
    ...
}

both on iwslt14 and toy_copy, w/ or w/o 'allow_smaller_final_batch'=False, with tf1.10 and tf1.8. So batch_size is dynamically determined.
Not sure why you got different results. But you may still run by setting 'allow_smaller_final_batch'=True for iwslt14 training data.

@ZhitingHu , emm I got it. That's interesting.
Thanks for helping me investigate this.
I will update once I find further useful details.

@ZhitingHu
On my local, the item of dataset.output_shapes change from (?,) to (32,) after this line:
https://github.com/asyml/texar/blob/9c699e8143fd8ecb5d65a41ceef09c45832b9258/texar/data/data/text_data_base.py#L69
I check the source of tensorflow 1.8, 1.9 and 1.10, there are no changes on the calling path among different versions.
padded_batch_and_drop_remainder calls _filter_irregular_batches (or w/o the underscore in tf1.8) and set the first demension to constant after these lines:
https://github.com/tensorflow/tensorflow/blob/4dcfddc5d12018a5a0fdca652b9221ed95e9eb23/tensorflow/contrib/data/python/ops/batching.py#L467-L474

Thanks for the helpful investigation. I guess I've digged it out..
tx.data.DataIterator "randomly" picks one of train/val/test datasets for creating the TF iterator. On my machines, it picks the test dataset which has a dynamic batch size dimension (i.e., ?); while on yours I guess it happens to pick the training dataset which has a static constant batch size dimension (due to the _filter_irregular_batches as you pointed). This explains the different observations we had.
I've eliminated the randomness of picking a dataset inside tx.data.DataIterator, by always picking the 1st dataset (sorted by the dataset names)---This is just for fixing the inconsistent outcomes across platforms. One still needs to be careful when using allow_smaller_final_batch=True cuz it results in static batch_size dimension. Suggestions are welcome to better avoid the pit. :)

@ZhitingHu
Ownsome! It makes sense to me.
Cheers 🥂

Suggestions are welcome to better avoid the pit.

I think the key is avoiding the constant batch size ddimension when allow_smaller_final_batch=False. We don't need a static dimension.
A direct (but maybe ugly) solution is manually setting the dimension as dynamic after the padded_batch_and_drop_remainder transformation. But I don't think it is a best practice ...
I am not an expert of the tensorflow dataset API, but IMO the "bad design" of padded_batch_and_drop_remainder is more likely to blame.
Please let me know if there is anything else I can help. I am more than happy to make a contribution. 😄Texar is an amazing tool for NLP research and I enjoy using it these days.

Thanks for the suggestion. We tend to not change the semantics of padded_batch_and_drop_remainder so at this point we may just leave it as-is.
Contributions are always welcome! For example, we hope to continuously add more examples including both popular and cutting-edge models/algorithms (e.g., from your research;), and, if necessary, abstract out sub-modules to add to the Texar library for more people to use in other tasks.


why not improve the eosio build script?

when compiling the eosio by using eosio_build.sh, we found the erorr below
Checking LLVM with WASM support installation...
Installing LLVM with WASM...
!! Unable to create directory /tmp/llvm-compiler !!
Actually ,It's a long journey for building eosio, and then an error happen with such problem
I mean why not remove the /tmp/llvm-compiler first and then create a new one so that the journey would go on ?

Well it really should make a unique temporary directory name instead.

Have you tried "sudo ./eosio_build.sh"?

Actually , it's ok for me . I just need to remove the /tmp/llvm-compiler and run it again . I mean, maybe we can improve this script. just remove the tmp/llvm-compiler and then continue the step. I don't think it will cause anything

sudo ?


Fixed #111 - PR Template

Added a PR Template as discussed in issue #111

@ZapeeoSheikh Merging this PR closes issue #111

Thank you so much for contributing !!


Fix aquarium demo

Fix AccumulativeShadows and RandomizedLight intensity
Fix useMask not working as mentioned in this issue
https://github.com/pmndrs/drei/issues/1949

[x] ready for merge?

this one should have the CI failed (because this demo has a visual test defined) -- but it didn't and make me realise that the CI still needs tweaks: https://github.com/pmndrs/examples/pull/34
so I keep it open until I've fixed this ;)


fixes kindnetd manifest (again)

Issue #, if available:
Description of changes:
This should be a better fix for the kindnetd manifest situation.
Background We handle the kind image and kindnetd a bit special compared to other images across the platform.  Originally we only supported cilium on any eks-a cluster, including docker/capd ones.  When adding (experimental) arm64 support our build of cilium only support amd64.  To work around I added basic support for kindnetd cni when creating a capd cluster.
Kind images embed a number of container images, to support offline workflows as well as just less runtime downloading of containers.  EKS-A has always followed model so the kindnetd cni container image, along with its manifest are embedded in the kind node image. Again this the upstream behavior which we just inherit.  Its important to remember that we use the same kind image/process for our bootstrap cluster as we do a full capd based cluster.
We have always used kindnetd when creating a bootstrap cluster, I say always but really originally we used cilium pre-ga but ran into issues which looked like ebpf overwriting each other between the bootstrap cluster and the actual eks-a/capd cluster.  At that time we decided to use kindnetd on bootstrap and cilium on capd.
Due to the way our releases and image tagging work, we do not know the image tag of an image at build time, its decided much later on during releases.  To allow kindnetd to work in the bootstrap cluster, we, at build time, modify the embedded kindnetd manifest file to point to an image tag, such as public.ecr.aws/eks-anywhere/kubernetes-sigs/kind/kindnetd:v0.18.0 but you will notice this image does not exit in ecr.  This is admittedly confusing and odd, but we rely on the kindnetd image being embeded into the kind node image so that tag does not really matter since its never requested from ecr.
When kindnetd "support" for capd clusters was added, the manifest was pulled out of the node image at build time and uploaded to s3 as a yaml file for the cli to use when installing the cni.  A while back, over a year ago, I changed the kind build to build images and binaries separately.  This change had the side effect of breaking the kindnetd manifest because it was only generated during the image build but it was the binary build that actually did the uploading to s3. This resulted in an empty manifest being upload (for other also strange reasons I dont want to go into).
About 6 months ago I changed the kind build here to use a checked in manifest file with the (good) intention of having us just manage it during version bumps manually.  Well that didnt work... the very first update we did after we forgot to change the manfiest to point to the new 0.20.0 version.
This PRs looks to take us back to a version similar to how we used to do it, but instead of pulling the manifest out of the image, we pull it out of the go file where it is defined as a const.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

This will fix: https://github.com/aws/eks-anywhere/issues/7264

/lgtm
/approve


Add UatX Project Nodes.

UatX Project provides fast rpc server clusters:
For China: https://rpc.uatvo.com
For Global: https://global.uat.cash

nodes have been added: https://github.com/jay-bch/smartbch-explorer/commit/f1b95780da9216b1e4043f563466024c957a2350


Display the satellites on the website

Use instanced rendering for this, descibed here: https://github.com/SOEP-Group/SOEP-Visualizer/pull/14#issuecomment-2366728839

have to calculate relative position to our earth, make sure dimensions are correct, or re-map our coordinate system so satellites positions can be directly used as they are saved in database


Improve WebAssembly test output

The WebAssembly test at https://github.com/dotnet/corert/blob/master/tests/src/Simple/HelloWasm/Program.cs currently only prints for tests that pass and always returns a success result (100). This should be refactored to print whether each test passes or fails and return a non-success result if a test fails. That will improve the likelihood of catching bugs during builds and make the output more readable.

I think we can close this with https://github.com/dotnet/corert/pull/7049.  I dont have permissions, @MichalStrehovsky  would you mind?


Python/Swift CLI generates images get Error with CPU_AND_NE + controlNet

Hi, I met error when using python cli generate images on my M1 Macbook Air.
When computeUnit=CPU_AND_GPU + controlNet, it works fine.
When computeUnit=CPU_AND_NE + controlNet, it errors as below log.
When computeUnit=CPU_AND_NE no controlNet, it works fine.
The same command and model files on other Macbook (M2, M2 Pro), it works fine.
I understand that this is a specific scenario, but I still feel it's necessary to report it.
Traceback (most recent call last):
    ....
  ml-stable-diffusion/python_coreml_stable_diffusion/coreml_model.py", line 79, in __call__
    return self.model.predict(kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/coremltools/models/model.py", line 573, in predict
    return self.__proxy__.predict(data)
RuntimeError: {
    NSLocalizedDescription = "Unable to compute the prediction using ML Program. It can be an invalid input data or broken/unsupported model.";
    NSUnderlyingError = "Error Domain=com.apple.CoreML Code=0 \"E5RT: ANE inference operation failed with error message = Error Domain=com.apple.appleneuralengine Code=8 \"processRequest:model:qos:qIndex:modelStringID:options:error:: ANEProgramProcessRequestDirect() Failed with status=0x1 : statusType=0x9: Program Inference error\" UserInfo={NSLocalizedDescription=processRequest:model:qos:qIndex:modelStringID:options:error:: ANEProgramProcessRequestDirect() Failed with status=0x1 : statusType=0x9: Program Inference error} (11)\" UserInfo={NSLocalizedDescription=E5RT: ANE inference operation failed with error message = Error Domain=com.apple.appleneuralengine Code=8 \"processRequest:model:qos:qIndex:modelStringID:options:error:: ANEProgramProcessRequestDirect() Failed with status=0x1 : statusType=0x9: Program Inference error\" UserInfo={NSLocalizedDescription=processRequest:model:qos:qIndex:modelStringID:options:error:: ANEProgramProcessRequestDirect() Failed with status=0x1 : statusType=0x9: Program Inference error} (11)}";

Also, I tried the Swift-CLI using OpenPose-SE  with DreamShaper_v5_split-einsum_cn  Core ML model converted by jrrjrr.
Using Macbook air M1 will still get error.
swift run StableDiffusionSample "photorealistic, 8k, a japanese girl" --negative-prompt "BadDream, UnrealisticDream" --resource-path DreamShaper_v5_split-einsum_cn --compute-units cpuAndNeuralEngine --seed<PHONE_NUMBER> --step-count 35 --guidance-scale 7 --controlnet OpenPose-SE --controlnet-inputs openpose.png

Building for debugging...
Build complete! (0.20s)
Loading resources and creating pipeline
(Note: This can take a while the first time using these resources)
Sampling ...
Error: Unable to compute the asynchronous prediction using ML Program. It can be an invalid input data or broken/unsupported model.

I tried Mochi Diffusion and it got the same error message as above. I will have a screen capture later.

Here the Mochi Diffusion happen the same issue.

From your Mochi screen cap, it looks like you are not using a Scribble ControlNet model that was converted for use with Split-Einsum (unless you renamed it).
With Split-Einsum and CPU and GPU, you don't really need a ControlNet model converted specifically for Split-Einsum.  An Original that is 512x512 (5x5) will work.
But with CPU and Neural Engine, at least in Mochi, you must use a ControlNet model converted for Split-Einsum.  The list of available models for download uses -SE for Split-Einsum versions.

YES, I tried with SE on Mochi Diffusion works fine. So this might still the python CLI or Swift CLI issue? I will continue to try this.

It is very possible that the behavior is different between Mochi and a Swift / Python-CoreML CLI.  Mochi was built using an ml-stable-diffusion commit that is different (older) from the current version you would get from cloning the ml-stable-diffusion git repo today.  And there also seemed to be a divergence mentioned in the PR pending for the SDXL refiner between the Swift CLI and the Diffusers app, in some instance, I think, which would imply a bug somewhere as the 2 should behave the same.

From the Refiner PR #227:
"I noticed that trying to run inference on the CLI wasn't working quite right, and I figured out that it needed the Unet to be float32 precision to work. I'm not sure why this happens, and the refiner works perfectly fine when running through the Diffusers app."

Thank you for your notice. I fallback my diffusers project to older version and the controlnet works great with NerualEngine.

Yes, some thing or things that changed in the past month or so in ml-stable-diffusion, coremltools, and/or diffusers is causing model mis-matches all over the place.  With all the changes, I have been unable to isolate the source of the issues.  Different pipelines throw different errors at different points in different packages.  It is near impossible to tell now whether an error is from the conversion pipeline or the inference pipeline.
So I gave up trying to make sense of things.  I am just sticking with older packages and conda environments that work consistently for 1.5 type models.  I will likely stay there until Sonoma is released and stable, and the SDXL changes are debugged.


Broken in IE 11

The project used to work (last I tried was 0.11.2), but when I upgraded to 0.18.3 it no longer works in IE11. I haven't been able to figure out the root cause but it could be babel / es6-promise related as we se Promise is undefined errors every once in a while.

I decided not to support polyfills in library code, it's on user to add polyfills unsupported by browsers he need.

OK clear, in which version did you remove the polyfills? I can check which we need and serve to them to the correct browsers.

in which version did you remove the polyfills?

Have no idea ;-), sorry have no time to parse history

I'm using
var Promise = require('es6-shim').Promise;
var GoogleMap = require('google-map-react').default;

and it works with IE11, Windows 10.

Thanks @thunderkid.
@istarkov I made a PR documenting this: #231


Use existing sendRequestWithRetry for putPostDocumentImpl

This PR tries to fix Issue #1038.
Use existing sendRequestWithRetry for putPostDocumentImpl if in an existing multistatement transaction.

Just noticed there is another putPostDocument method. I'm going to refactor that tomorrow.

Closing this PR because commit bb721fa2a5c1e438dde2da2c08c55b16f22cdf8a already fixed it.


Later response headers override earlier response headers

If the server sends duplicate headers, e.g. set-cookie then the resulting headers table will only contain the value of the last time the header appeared.
The headers table either needs to contain nested tables or the values should be concatenated using a comma:
see RFC 7230#3.2.2

We'll probably go with folding, in order not to break code expecting headers in single level table. That could too potentially break some code checking the value of headers (and not checking for folded values)

Yes, I guess making it a multi level table would be too much of a BC break here.

This issue should be fixed now. We fold the headers when sending client requests, don't do any folding for responses.

I'm not sure I'm happy with the current implementation for responses. If there's a single occurrence of a response header I'll receive a string. If there's multiple occurences I'll receive a table. This requires me to check the return type. I feel like single headers should also be returned as a (single-item) table.
I would be fine with configuring the behavior by passing a special argument when using send, e.g.:
local response, err = http.head{
  url = "…",
  headers = headers,
  response_header_behavior = "fold" | "table" | "mixed",
}

I understand your pain, it's not fun to write the same code again and again.
Both, Request and Response objects now share the same format for .headers attribute (i.e for "multi headers" table value is also a table); when sending requests or responses these tables are handled automatically.
However, for header examination, it would be nice to have other options, so how about these two iterators, if it works for you, we'll add them as methods to request/response classes:
local hdrs = {
    blah = "first",
    doh = {"second", "third", "fifth"},
    wassup = "fourth",
    zz = {"sixth"}
}

--
-- HTTP headers iterator
--
-- Iterator returns key/value pairs for header names/values, making sure
-- that returned values are always of string type
-- (if necessary, it folds multiple headers with same name)
--
-- @param hdrs Headers table as received by http.get and friends
--
-- @return headers iterator suitable for usage in "for" loops
local function get_headers(hdrs)
    local function iter(tbl, k)
        local v
        k, v = next(tbl, k)

        if v ~= nil then
            if type(v) == "table" then
                return k, table.concat(v, ",")
            else
                return k, v
            end
        end
    end

    return iter, hdrs, nil
end

--
-- HTTP headers iterator
--
-- Returns key/value pairs for header names/values, for multiple headers
-- with same name it will return every name/value pair
-- (e.g. this is suitable to process responses with 'Set-Cookie' header)
--
-- @param hdrs Headers table as received by http.get and friends
-- @return headers iterator suitable for usage in for l
local function iget_headers(t)
    if t == nil then
        return function() end
    end

    local k
    local idx = 0
    local v_in

    return function ()
        local v
        if idx == 0 then
            k, v = next(t, k)
            if k == nil then return end
        else
            idx, v = next(v_in, idx)

            if idx == nil then
                idx = 0
                k, v = next(t, k)
            end
        end

        if k == nil then return end

        if type(v) == "table" then
            if fold then
                return k, table.concat(v, ",")
            else
                v_in = v
                idx = idx + 1
                return k, v[idx]
            end
        else
            -- if idx > 0 then
            --     idx = idx + 1
            -- end
            return k, v
        end
    end
end

print("---")
print("Folded headers:")

for k, v in get_headers(hdrs) do
    print(k, v)
end

print("---")
print("Unfolded headers:")

local next_header = iget_headers(hdrs)

while true do
    local hdr, hdr_val = next_header()
    if hdr == nil then break end
    print(hdr, hdr_val)
end

so how about these two iterators, if it works for you, we'll add them as methods to request/response classes:

get_headers is looking good for this feature request: https://github.com/TimWolla/haproxy-auth-request/pull/13. However I would also need a function where I can retrieve single string for a header name in O(1) time. I'm currently having this:
https://github.com/TimWolla/haproxy-auth-request/blob/f5e7b395aa86050316e947147f5d66b20dcd8b1f/auth-request.lua#L106
However since your latest patch I am not guaranteed that I get a string back if the backend sends two location response headers for whatever reason there might be. In that case the code would set a variable to a table which is not going to work.
The following functions should solve I use cases I believe.

get_headers(hdrs): Returns an iterator for all headers, duplicate headers are folded.
iget_headers(hdrs): Returns an iterator for all headers, duplicate headers are duplicated.
get_header(hdrs, hdr): Returns a the value for a single header, duplicates are folded.
iget_header(hdrs, hdr): Returns the last value for a single header.

For the location header I would then use txn:set_var("txn.auth_response_location", iget_header(hdrs, "location")). To generate variables for arbitrary response headers I would then use get_headers(hdrs) to receive folded headers.

Great, we're getting somewhere :-)
iget_header() is kinda ugly (I'm really missing generator functions && yield from Python here), I'll try to improve/simplify it.
As for other two functions, get_header(name, fold) method for Request/Response objects would be handy and mostly O(1). It would also lowercase the header name before searching (since internally, they are stored in lowercase)
Will get back with another iteration tomorrow morning.

I'm sure you'll figure out something good based off my requirements :smiley: Looking at the function examples above you are definitely more experienced in Lua than I am.
btw: Have you seen my email regarding the GitHub action for easy HAProxy + VTest installation<EMAIL_ADDRESS>With all the added functionality automated tests are starting to become interesting.

I think the latest commit in the master 4ac4483 wraps this discussion nicely. I think helper functions will make our life easier.
Thanks for the vtest pointer, I'll definitely use that, but first things first, we should add some docs and examples.

And the iterator ist also working well: https://github.com/TimWolla/haproxy-auth-request/pull/24
No more complaints from my side. I guess this issue can be closed. Thanks.


Add freeCodeCamp

We need to add freeCodeCamp under 'Beginner-Friendly Repositories'.
Details:
Name: freeCodeCamp
Link: https://github.com/freeCodeCamp/freeCodeCamp

okay


Use fnameescape to quote filenames for :badd.

When you move a file in NERDTree's FS menu, and a buffer is already open with it, you're prompted to delete the old buffer and replace it with a new buffer pointing to the file's new location. This wasn't working correctly for me: because the new filename is passed to badd quoted with single quotes, Vim just created a new buffer pointing to a file called '/Users/zack/.../filename' with the quotes. See the odd results of this when trying to rename a file in the nerdtree source tree:

This patch uses the fnameescape() function to do the filename escaping, rather than just surrounding with single quotes. I've tested it and it fixes the error seen in the above screenshot.

👍  I've noticed this before. Thanks for the fix, @zacharyvoase.


KYLIN-3665 Partition time column may never be added

Fixed [KYLIN-3665]: Partition time column may never be added.

Can one of the admins verify this patch?

Pull Request Test Coverage Report for Build 3883

10 of 14 (71.43%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.002%) to 25.918%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

core-metadata/src/main/java/org/apache/kylin/metadata/model/PartitionDesc.java
10
14
71.43%

Files with Coverage Reduction
New Missed Lines
%

core-cube/src/main/java/org/apache/kylin/cube/inmemcubing/MemDiskStore.java
1
78.12%

Totals

Change from base Build 3871:
0.002%

Covered Lines:
17652

Relevant Lines:
68107

💛  - Coveralls

Hi Francis, the change looks good. While the commit message didn't comply with Apache's style. Could you please update the commit message to "KYLIN-3665 Partition time column may never be added" (start with JIRA ID, no [] needed). Thank you!

Just did it. Thanks for the information!


Fix formatting & slightly polish Cloudflare deploy guide

What kind of changes does this PR include?

Minor content fixes (broken links, typos, etc.)
New or updated content

Description
While reviewing a translation PR I noticed some formatting was off in the Cloudflare deploy guide. This PR fixes that.
While there I also tried to polish the page structure a little. Notably the “How to deploy an SSR site” does not actually cover deploying a site, only how to configure the adapter. I haven’t updated that subheading but do now say to use the other deployment approaches in the intro for that section.

LGTM @delucis!


Cannot read property 'accountName' of undefined

The Error Popup comes whenever I press alt+t to see the tasks

Atom Version: 1.12.4
Electron Version: 1.3.9
System: Microsoft Windows 10 Pro
Thrown From: imdone-atom package, v2.0.17
Stack Trace
Uncaught TypeError: Cannot read property 'accountName' of undefined
At C:\Users\Akash\.atom\packages\imdone-atom\lib\plugins\plugin.coffee:49

TypeError: Cannot read property 'accountName' of undefined
    at ConnectorPlugin.module.exports.ConnectorPlugin.addMetaKeyConfig (file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/plugins/plugin.coffee:49:53)
    at new ConnectorPlugin (file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/plugins/plugin.coffee:20:6)
    at file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/views/imdone-atom-view.coffee:314:22
    at file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/services/connector-manager.coffee:45:7
    at ConnectorManager.module.exports.ConnectorManager.getProducts (file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/services/connector-manager.coffee:36:14)
    at ConnectorManager.module.exports.ConnectorManager.getProduct (file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/services/connector-manager.coffee:44:6)
    at Repository.repo.getProduct (file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/services/imdoneio-store.coffee:286:56)
    at ImdoneAtomView.module.exports.ImdoneAtomView.addPlugin (file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/views/imdone-atom-view.coffee:308:17)
    at ImdoneAtomView.module.exports.ImdoneAtomView.addPluginByProvider (file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/views/imdone-atom-view.coffee:325:6)
    at file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/views/imdone-atom-view.coffee:266:54
    at Function.module.exports.Emitter.simpleDispatch (C:\Users\Akash\AppData\Local\atom\app-1.12.4\resources\app.asar\node_modules\event-kit\lib\emitter.js:25:14)
    at PluginViewInterface.module.exports.Emitter.emit (C:\Users\Akash\AppData\Local\atom\app-1.12.4\resources\app.asar\node_modules\event-kit\lib\emitter.js:129:28)
    at Repository.<anonymous> (file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/views/imdone-atom-view.coffee:122:25)
    at emitOne (events.js:96:13)
    at Repository.emit (events.js:188:7)
    at file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/services/imdoneio-store.coffee:279:12
    at ConnectorManager.module.exports.ConnectorManager.getProducts (file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/services/connector-manager.coffee:36:14)
    at Repository.repo.initProducts (file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/services/imdoneio-store.coffee:277:22)
    at ImdoneAtomView.module.exports.ImdoneAtomView.initImdone (file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/views/imdone-atom-view.coffee:374:19)
    at file:///C:/Users/Akash/.atom/packages/imdone-atom/lib/views/imdone-atom-view.coffee:61:13
    at C:\Users\Akash\.atom\packages\imdone-atom\node_modules\imdone-core\lib\mixins\repo-fs-store.js:257:9
    at C:\Users\Akash\.atom\packages\imdone-atom\node_modules\async\lib\async.js:52:16
    at replenish (C:\Users\Akash\.atom\packages\imdone-atom\node_modules\async\lib\async.js:306:28)
    at C:\Users\Akash\.atom\packages\imdone-atom\node_modules\async\lib\async.js:326:29
    at C:\Users\Akash\.atom\packages\imdone-atom\node_modules\async\lib\async.js:44:16
    at C:\Users\Akash\.atom\packages\imdone-atom\node_modules\imdone-core\lib\mixins\repo-fs-store.js:253:11
    at C:\Users\Akash\.atom\packages\imdone-atom\node_modules\imdone-core\lib\mixins\repo-fs-store.js:105:51
    at FSReqWrap.oncomplete (fs.js:123:15)

Commands
 39x -3:44.1.0 core:backspace (atom-text-editor.editor.is-focused)
     -3:35.3.0 core:save (atom-text-editor.editor.is-focused)
     -3:28.2.0 linter:next-error (atom-workspace.workspace.scrollbars-visible-always.panel-shadows.panel-contrast.use-animations.theme-flatwhite-syntax.theme-atom-material-ui.seti-ui-no-icons.paint-cursor.compact-tab-bar.tinted-tab-bar.has-custom-icons)
     -3:22.7.0 editor:newline (atom-text-editor.editor.is-focused)
     -3:22.2.0 core:move-up (atom-text-editor.editor.is-focused)
     -3:21.4.0 core:paste (atom-text-editor.editor.is-focused.hyperclick)
     -3:16 core:backspace (atom-text-editor.editor.is-focused)
 13x -3:14.3.0 core:move-left (atom-text-editor.editor.is-focused)
  2x -3:00.6.0 core:backspace (atom-text-editor.editor.is-focused)
     -2:59.1.0 core:save (atom-text-editor.editor.is-focused.autocomplete-active)
     -2:50.3.0 editor:newline (atom-text-editor.editor.is-focused)
     -2:49.5.0 core:paste (atom-text-editor.editor.is-focused)
  4x -2:48.6.0 core:move-left (atom-text-editor.editor.is-focused)
 39x -2:47.7.0 core:backspace (atom-text-editor.editor.is-focused)
  2x -2:42.3.0 core:save (atom-text-editor.editor.is-focused)
     -0:15.1.0 imdone-atom:tasks (atom-text-editor.editor.is-focused)

Config
{
  "core": {
    "autoHideMenuBar": true,
    "ignoredNames": [
      ".git",
      ".hg",
      ".svn",
      ".DS_Store",
      "._*",
      "Thumbs.db",
      ".gitignore",
      ".gitattributes"
    ],
    "projectHome": "E:\\Study",
    "telemetryConsent": "limited",
    "themes": [
      "atom-material-ui",
      "flatwhite-syntax"
    ]
  }
}

Installed Packages
# User
ariake-dark-syntax, v0.0.5 (inactive)
atom-beautify, v0.29.13 (active)
atom-material-syntax, v0.4.6 (inactive)
atom-material-syntax-light, v0.4.5 (inactive)
atom-material-ui, v1.3.6 (active)
atom-runner, v2.7.1 (active)
autocomplete-python, v1.8.12 (active)
blessed-dark-syntax, v0.3.0 (inactive)
file-icons, v1.7.25 (active)
flatwhite-syntax, v0.8.0 (active)
fonts, v1.7.0 (active)
git-plus, v5.25.3 (active)
github-atom-dark-syntax, v0.2.0 (inactive)
github-atom-light-syntax, v0.2.0 (inactive)
hyperclick, v0.0.39 (active)
imdone-atom, v2.0.17 (active)
linter, v1.11.18 (active)
linter-pylama, v0.8.7 (active)
nord-atom-syntax, v0.3.0 (inactive)
nord-atom-ui, v0.8.0 (inactive)
python-indent, v1.0.0 (active)
atom-dark-syntax, v0.27.0 (inactive)
atom-dark-ui, v0.52.0 (inactive)
atom-light-syntax, v0.28.0 (inactive)
atom-light-ui, v0.45.0 (inactive)
base16-tomorrow-dark-theme, v1.3.0 (inactive)
base16-tomorrow-light-theme, v1.3.0 (inactive)
one-dark-ui, v1.6.2 (inactive)
one-light-ui, v1.6.2 (inactive)
one-dark-syntax, v1.5.0 (inactive)
one-light-syntax, v1.5.0 (inactive)
solarized-dark-syntax, v1.0.5 (inactive)
solarized-light-syntax, v1.0.5 (inactive)
about, v1.7.0 (active)
archive-view, v0.62.0 (active)
autocomplete-atom-api, v0.10.0 (active)
autocomplete-css, v0.13.1 (active)
autocomplete-html, v0.7.2 (active)
autocomplete-plus, v2.31.4 (active)
autocomplete-snippets, v1.11.0 (active)
autoflow, v0.27.0 (inactive)
autosave, v0.23.1 (active)
background-tips, v0.26.1 (active)
bookmarks, v0.42.0 (active)
bracket-matcher, v0.82.2 (active)
command-palette, v0.39.0 (active)
deprecation-cop, v0.54.1 (active)
dev-live-reload, v0.47.0 (active)
encoding-selector, v0.22.0 (active)
exception-reporting, v0.40.0 (active)
find-and-replace, v0.202.2 (inactive)
fuzzy-finder, v1.4.0 (active)
git-diff, v1.1.0 (active)
go-to-line, v0.31.0 (inactive)
grammar-selector, v0.48.2 (active)
image-view, v0.60.0 (active)
incompatible-packages, v0.26.1 (active)
keybinding-resolver, v0.35.0 (active)
line-ending-selector, v0.5.0 (active)
link, v0.31.2 (inactive)
markdown-preview, v0.158.8 (active)
metrics, v1.1.2 (active)
notifications, v0.65.1 (active)
open-on-github, v1.2.1 (inactive)
package-generator, v1.0.1 (inactive)
settings-view, v0.243.1 (active)
snippets, v1.0.4 (active)
spell-check, v0.68.4 (active)
status-bar, v1.4.1 (active)
styleguide, v0.47.2 (active)
symbols-view, v0.113.1 (inactive)
tabs, v0.103.0 (active)
timecop, v0.33.2 (active)
tree-view, v0.210.0 (active)
update-package-dependencies, v0.10.0 (active)
welcome, v0.35.1 (active)
whitespace, v0.35.0 (active)
wrap-guide, v0.38.2 (active)
language-c, v0.54.0 (active)
language-clojure, v0.22.1 (active)
language-coffee-script, v0.48.0 (active)
language-csharp, v0.13.0 (active)
language-css, v0.40.1 (active)
language-gfm, v0.88.0 (active)
language-git, v0.15.0 (active)
language-go, v0.43.0 (active)
language-html, v0.46.1 (active)
language-hyperlink, v0.16.1 (active)
language-java, v0.24.0 (active)
language-javascript, v0.122.0 (active)
language-json, v0.18.3 (active)
language-less, v0.29.6 (active)
language-make, v0.22.2 (active)
language-mustache, v0.13.0 (active)
language-objective-c, v0.15.1 (active)
language-perl, v0.37.0 (active)
language-php, v0.37.3 (active)
language-property-list, v0.8.0 (active)
language-python, v0.45.1 (active)
language-ruby, v0.70.2 (active)
language-ruby-on-rails, v0.25.1 (active)
language-sass, v0.57.0 (active)
language-shellscript, v0.23.0 (active)
language-source, v0.9.0 (active)
language-sql, v0.25.0 (active)
language-text, v0.7.1 (active)
language-todo, v0.29.1 (active)
language-toml, v0.18.1 (active)
language-xml, v0.34.12 (active)
language-yaml, v0.27.1 (active)

# Dev
No dev packages

Looks like a bug.  I just published a fix for this.  Should be working now.


Crash on startup caused by ITLT

The game crash on startup with the pack version "Dimensions and Dungeoneering-0.15.zip"
The error is

java.lang.NullPointerException: Registry Object not present: conjuring:soul_alloy_sword

but when removing the conjurer file, the error is :

Mod File: itlt-1.16.x-2.0.0.jar
Failure message: It's The Little Things (itlt) has failed to load correctly
java.lang.ExceptionInInitializerError: null
Mod Version: 2.0.0
Mod Issue URL: https://github.com/zlepper/itlt/issues
Exception message: java.lang.NumberFormatException: For input string: "7,1"

Changing the conjuring mod version lead to the same first crash report.
Removing the itlt file seems to resolve the problem.
I am using the GDLauncher v1.1.11 with java 1.8.0_291
crash-2021-07-17_13.41.54-client.txt

Hmmm, not much I can do with this issue until ITLT fixes it, as I haven't be able to experience it myself. Might have something to do with your java version so try updating that if you can. I'll leave this issue open until ITLT patches it, but if you continue to experience this issue just remove the mod as ITLT doesn't add any content to the pack.

Fixed in V0.17


Settings nvs backend, settings/src test integration

Blocked by:
#18891
#18924

@kapi-no, I am a bit puzzled by seeing base64 encoding. Is this supported by the nvs backend ? If not, you could just have a raw test for nvs.

@Laczen, I think that the base64 encoded data are prepared before they are passed to the NVS backend. The backend just receives a raw buffer, so you don't need any more logic in the backend to support base64 encoding.
I am aware that base64 is going to be deprecated in the future, but I added the tests for it nonetheless because they required no effort from my side. I reused common tests that are run for other backends. They should be removed when we get rid of base64 support in the Settings.

@kapi-no, could you recheck this, I think the base64 encoding is only supported in nffs and fcb using the settings_line() method that defines how data is saved (including using base64 or not). The nvs backend does not use the settings_line method but directly saves the data in nvs using a different method (to avoid double writing of variable names), it does not have the need or the possibility to store using base64 encoding. I agree that you should reuse the common tests that are used for the other backends, but for the nvs backend it should only do the raw version testing. It would be confusing for users to do a test with base64 encoding while it really does nothing.

@Laczen, okay, I will remove it.
Although I didn't analyze base64 related tests, it seems quite strange that they pass for the NVS backend.

It passes base64 tests because enabling or disabling base64 is only a settings flag. The test is not checking the internal format of the data.

I set up an artificial failure in one of the tests just to see if this is actually executed in the Zephyr CI.

@kapi-no ^^ yo u can remove this failure.

@nvlsianpu, done. This PR is ready for merging

@carlescufi Can this be merged?

@nvlsianpu, @carlescufi, I believe this PR is finally ready for merging

@MaureenHelm @nashif are you happy with this in its current state?


Fix localhost version of Mobile.GetMobileDocumentsPath

Postcard app is now generating string error with Mobile.GetMobileDocumentsPath in 'mockmobile.js'
TypeError: Arguments to path.join must be strings

For cross-platform, you could do something like:
var os = require('os'); // This to the top of the file
return os.tmpdir();

This is supposed to be resolved by #63

@vjrantal - I submitted the update as a PR


feat: fix compilation on new Android arch

https://primerapi.atlassian.net/browse/ACC-4531
https://primerapi.atlassian.net/browse/ACC-4511

Don't merge until branch-sdk-refactor is merged to primer-sdk-android/master.
TODO: Update primer-sdk-android version.


bug(markdown) adding blockquote on table removes leading pipes

Describe the bug
Using the Markdown editor, if you try to quote a table the leading pipes are removed on all lines except the separator row.
It ends up looking like this:
>
> Column A | Column B |
> | -------- | -------- |
> Cell 1   | Cell 2   |
> Cell 3   | Cell 4   |
>

Expected behavior
Don't remove the pipes
Desktop (please complete the following information):
Windows 11 Chrome 103
Additional context
https://meta.stackexchange.com/a/380331/51

Duplicate of #70


wrong output of ":map" after using "mapset()"

Describe the bug
The output of :map is sometimes wrong after restoring a mapping via mapset().
To Reproduce
Run this shell command:
vim -Nu NONE +"call mapset('n', 0, {'lhs': '<C-B>', 'mode': 'n', 'rhs': 'xxx'})"

Then, run this Ex command:
:map <C-B>

The output is:
No mapping found

Expected behavior
The output is:
n  <C-B>           xxx

Environment

Vim version: 8.2 Included patches: 1-812
OS: Ubuntu 16.04.6 LTS
Terminal: XTerm(322)

Additional context
The issue is due to the control modifier.  If I remove the angle brackets around C-B, the output of :map is correct:
vim -Nu NONE +"call mapset('n', 0, {'lhs': 'C-B', 'mode': 'n', 'rhs': 'xxx'})"
:map C-B
n  C-B           xxx

Describe the bug
The output of :map is sometimes wrong after restoring a mapping via mapset().
To Reproduce
Run this shell command:
$ vim -Nu NONE +"call mapset('n', 0, {'lhs': '<C-B>', 'mode': 'n', 'rhs': 'xxx'})"

Then, run this Ex command:
:map <C-B>

The output is:
No mapping found

Expected behavior
The output is:
n  <C-B>           xxx

Environment

Vim version: 8.2 Included patches: 1-812
OS: Ubuntu 16.04.6 LTS
Terminal: XTerm(322)

Additional context
The issue is due to the control modifier.  If I remove the angle brackets around C-B, the output of :map is correct:
$ vim -Nu NONE +"call mapset('n', 0, {'lhs': 'C-B', 'mode': 'n', 'rhs': 'xxx'})"
:map C-B
n  C-B           xxx

It turns out that maparg() always returns the simplified form of the
mapping.  There can be another mapping for the non-simplified form, at
that then doesn't get restored.
We need to have maparg() find both mappings and return their info in the
dict.  If both were coming from the same :map command then the entries
would be the same, except for "lhs".
However, if one of them was overwritten, the arguments can be different:
nmap  xxx
nmap <02> yyy
In the second command <02> is entered by typing CTRL-V x02
You can check with:
nmap
nmap <02>
This doesn't reflect the actual list of mapping, when listing mappings
only the not simplified form is used.  Thus maparg() actually finds the
wrong one.
--
Microsoft says that MS-Windows is much better for you than Linux.
That's like the Pope saying that catholicism is much better for
you than protestantism.
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Fixed by https://github.com/vim/vim/commit/9c65253fe702ea010afec11aa971acd542c35de2.


[QUESTION] Fastify already includes pino, and I want to configure it on Adapter level, and use this config for logger

I don't quite understand the explanation on why i should not use useExisting .
Can you rephrase it ? or explain it better to me ?
From what i understand, you said this logger is not using for lifecycle events and application level logging in NestJS apps based on fastify , i should not use it since my app is a NestJS App based on fastify as http server.
What should i do then ? i shall have 2 differents loggers ?

If you don't need startup logs and out of request context logs to use the same config that you are already provide in fastify then you are good to go. This notion is only about either duplicating config for those cases or have inconsistent config for those cases

Ok let me explain my problem.
I use genReqId in both loggers.
I want the same reqId to be set. How do i do that ?
All the application context logs are logged with nestjs-pino EXCEPT one : https://github.com/Eomm/mercurius-logging
I need this to be able to log the graphql query.

I'm not into fastify plugins, sorry, but I believe useExisting should work for you. There is test that checks that passed to fastify params are used for logging from request context


Numpy . implement numpy  op exp2 with tvm

as title.
(https://docs.scipy.org/doc/numpy-1.15.0/reference/generated/numpy.exp2.html)

@yzhliu


Unit testing with Right(List()) does not work

There seems to be an issue with unit testing lists of Right().
the following both work
expect(Right(1), equals(Right(1)));
expect(([1, 2, 4]), equals(([1, 2, 4])));

but this does not work
expect(Right([1, 2, 4]), equals(Right([1, 2, 4])));

Error Message is:
ERROR: Expected: Right<dynamic, List<int>>:<Right([1, 2, 4])>
  Actual: Right<dynamic, List<int>>:<Right([1, 2, 4])>

The problem is that dart does not use value equality as a default :S So the following will only compare references: (taken from either.dart)
@override bool operator ==(other) => other is Right && other._r == _r;

I figured out a decent enough workaround. Feel free to just close this issue
final result = Right([1,2,3]).getOrElse(() => throw Exception());

and then simply
expect(result, [1,2,3]);

works.


Student views Tutor's info

As a Student, I want to see information about my tutor in the cooperation, so that I can stay informed about tutor’s expertise
Acceptance criteria:

Student should be able to see  the following short summary about the Tutor in the cooperation:

First Name
Last Name
Location
Average rating
Profile photo

Student should be able to switch from the short summary view to the Tutor's profile page.

Student should be able to easily access the chat with the Tutor within the cooperation.

The tutor's information should be kept up-to-date in real-time to reflect any changes or updates made by the student.

The acceptance criteria for this user story have been merged with Student views cooperation details #1261


Availability on CLJSJS

Hi,
Any plan to make it available on CLJSJS for ClojureScript users?
Thanks 👍

Hey @teawaterwire, thanks for the idea - this isn't something we've used before - do you think you'd be able to prepare a PR with the required changes?

If I end up integrating MangoPay into my app I'll try and do it at the same time 💃

Ok, that would be great, thank you :-)

 Add kit to CLJS.js


[1pt] PR: Extend outlet levelpath(s) outside HUC

Extends outlet levelpath(s) outside HUC.
Previously, levelpaths at the outlet of a HUC may not extend to the buffered WBD that is used to clip the DEM, and during pit-filling this results in reverse flow which can cause DEM-derived reaches to deviate from the channel in the DEM and may result in dropped catchments where the midpoint of the reaches exceeds the snap distance from the NWM stream lines.
This PR extends outlet levelpaths in two ways:

Segments of levelpaths that terminate in waterbodies are removed from the levelpath (#671). If there is a waterbody downstream of the HUC then the outlet reaches may be trimmed such that the outlet no longer reaches the edge of the DEM, which causes a number of cascading issues originating in the pit-filling such that reverse flow in the DEM-derived reaches can result in erroneous flowlines and inundation. This stops trimming levelpaths outside of the HUC. This was originally a separate PR (#1284) but has been merged into this PR. Fixes #1280 and closes #1284.
Dissolved outlet levelpaths may terminate downstream outside of the HUC (e.g., at a confluence with a larger river) at a point that is within the buffered WBD. These levelpaths are extended by adding on the downstream segment(s) of the HUC's nwm_subset_streams layer. The extended levelpath(s) are saved in a new file that is used to create the boolean raster stream network. Closes #1299

Changes

config/

deny_unit.lst, deny_branch_zero.lst, and deny_branches.lst: Adds new file to deny lists

src/

derive_level_paths.py:  Adds WBD as an input to stream_network.trim_branches_in_waterbodies() and adds new argument for new filename.
run_unit_wb.sh: Adds new argument for new filename.
stream_branches.py: Selects only segments intersecting the WBD as candidates for removal if they end in waterbodies and adds downstream segment(s) to outlet levelpath(s).

Testing
Tested lake fix on branch<PHONE_NUMBER> of HUC 12010005. Tested extending levelpath on branch<PHONE_NUMBER> of HUC 08020302.
Deployment Plan (For developer use)
How does the changes affect the product?

[x] Code only?
[ ] If applicable, has a deployment plan be created with the deployment person/team?
[ ] Require new or adjusted data inputs? Does it have start, end and duration code (in UTC)?
[ ] If new or updated data sets, has the FIM code been updated and tested with the new/adjusted data (subset is fine, but must be a subset of the new data)?
[ ] Require new pre-clip set?
[ ] Has new or updated python packages?

Issuer Checklist (For developer use)
You may update this checklist before and/or after creating the PR. If you're unsure about any of them, please ask, we're here to help! These items are what we are going to look for before merging your code.

[x] Informative and human-readable title, using the format: [_pt] PR: <description>
[x] Links are provided if this PR resolves an issue, or depends on another other PR
[x] If submitting a PR to the dev branch (the default branch), you have a descriptive Feature Branch name using the format: dev-<description-of-change> (e.g. dev-revise-levee-masking)
[x] Changes are limited to a single goal (no scope creep)
[x] The feature branch you're submitting as a PR is up to date (merged) with the latest dev branch
[x] pre-commit hooks were run locally
[x] Any change in functionality is tested
[x] New functions are documented (with a description, list of inputs, and expected output)
[x] Placeholder code is flagged / future todos are captured in comments
[x] CHANGELOG updated with template version number, e.g. 4.x.x.x
[x] Add yourself as an assignee in the PR  as well as the FIM Technical Lead

Merge Checklist (For Technical Lead use only)

[ ] Update CHANGELOG with latest version number and merge date
[ ] Update the Citation.cff file to reflect the latest version number in the CHANGELOG
[ ] If applicable, update README with major alterations

I think we had some weirdness on this against the CDN and Mexico border, so we hard cut those borders, didn't we? Not sure. But I wonder how this change might affect those, as we do see quite a few rivers crossing the US / Mexican border. Might be worth double checking. Your call though.

A comparison of  the current dev (left) and this feature branch (right). The outlet levelpath in green is now extended to the edge of the DEM (brown area), correcting the flow direction and delineation of DEM-derived reaches. Note the difference between the NWM streamline (green) and the DEM-derived reaches (red dotted line) circled in red as well as the missing DEM-derived reaches circled in gray.

A comparison of the current dev (left) and this feature branch (right). On the left image, downstream of where the levelpath (black) exits the HUC (green), there is a confluence with a larger river that ends the black levelpath. This occurs in the WBD buffer so the levelpath is terminated before it reaches the WBD buffer which is where the DEM is clipped. Because of this, the DEM-derived reaches (red lines) can deviate from the levelpath or be missing as a result of deviating beyond the crosswalk snap distance. Where the red lines are missing, the catchments (gray shading) are also missing. In the image on the right, the levelpath has been extended by the black line segment which fixes the DEM-derived reaches to align with the levelpath and the catchment coverage is complete.

The yellow lines indicate levelpath segments that have been added by this PR. The red segments show the end of the outlet levelpath. The green shaded area is the HUC area and the dark green line is the WBD buffered polygon which is used to clip the DEM. The image on the right illustrates both the extending of levelpaths where they were previously terminated at the lake, and also extending multiple levelpath outlets.

Ultimately, the difference can be seen in the DEMs. The top row is the current dev (v<IP_ADDRESS>) and the bottom row is this PR.  When the levelpaths don't reach the edge of the DEM (green line), they can be filled in during pit filling such that essentially undoes the streamline burning process and can result in erroneous reverse direction stream networks.

I ran fim_pipeline.sh and checked HUCs 04100006, 05080003, 07110002, 08020302, 11010007, 11010011, and 12010005. I did run synthesize_test_cases.py but only one HUC (07110002) had validation data: MCC and CSI for IFC was identical and ras2fim was only very slightly different.

I tested this PR for couple of HUCs and it works as it expected. This is an example of HUC 08020302, branch<PHONE_NUMBER>8.

This PR improved CSI for BLE and NWS but decreased for RAS.


tutorial.cc isn't what is described

So, the startup guid says this:

Open the file examples/tutorial.cc, this is where you'll be adding your code. It is already setup with the necessary include paths and links the api.

The said cc is this:
int main(int /*argc*/, char* /*argv*/[]) {
    return 0;
}

I feel like it's missing a couple of things. :P

Are you trying to say it's missing include paths and links? I think it's taking about that cmake is already set up to compile it correctly. That is, it has your include paths set up and links the correct API targets against the tutorial.

Oooh, I see. The linker is setup to create the executable and things like that. I misunderstood that part than. Thanks.


Assume jQuery (or assume $)

I'd love to see an option to assume jQuery (or another library using $) is available.
Chances are good that code being run through JSHint might use the $ function that has been defined in another file somewhere, and it would be nice to have it as an option to turn off the errors from $ being undefined.

This option (user supplied list of assumed global variables) is still not available on web page jshint.com :(

It is there: http://cl.ly/3t1a3U122x1l1m0B0r2m

Oh, sorry. I was actually concerned about possibility of user-supplied list of global identifier. Original jslint.com have a input field, which allow you to add any assumed global variabled. It is missing at jshint.com.


fix: make things compile with Quarkus 2.8

Fixes #310, though, hopefully, Quarkus 2.8.1 will allow us to avoid this fix.

any plans to get this merged? Quarkus 2.8.1 is already released.

any plans to get this merged? Quarkus 2.8.1 is already released.

Actually, using Quarkus 2.8.1 doesn't require this fix anymore.

@metacosm you're totally right, upgrading to 2.8.1 makes it work with 3.0.7, thanks a lot


[fix](invert index) fix the error issue in the unit test remove_element_only_in_table

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Changed "AL Code" to "AL" only

Ref. issue #4916 and this comment
Changed "AL Code" to "AL" as the language is called "AL" only. The naming will now be consistent between Github and Azure DevOps.

Thanks!  I think the " Code" was added when I pulled from Microsoft's repo when building the original language files.  This is a good change, 100%.

Ref. issue #4916 and this comment
Changed "AL Code" to "AL" as the language is called "AL" only. The naming will now be consistent between Github and Azure DevOps.


Hacked away until buildable and runnable with Tendermint 0.8.0

This gets feature-tendermint_0.8.0 to a state where:

Tendermint and its transitive dependencies are upgraded 0.8.0
All reference to tmsp have been converted to abci references
Our partial support for out-of-process tmsp has been removed (we can add back in the abci server stuff if we want)
EventSwitch has been changed to an interface throughout
A Tendermint node can start but fails on making the cs_wal_dir

feature-tendermint_0.8.0 is a WIP branch with failing tests. So this is potentially mergeable despite failing tests. We may be able to find a way to divide work at this point, or it may be easier for me to try and get a bit further.

I will merge release-0.16 into eris-ltd:feature-tendermint_0.8.0; so that this PR gives a clearer picture of what has been done and where we are

have rebased against eris-ltd/feature-tendermint_0.8.0


[YUNIKORN-28] Support validating conf via REST API

As discussed in https://github.com/apache/incubator-yunikorn-k8shim/pull/81, we need to validate conf via REST API in scheduler core.

LGTM, merging this now.