[NEED TESTS] Add a public "has" method to the Controller class, to check the existence of a given controller

I haven't written any test. The npm install failed here and I've been unable to test anything. (Seems like it fails on gyp-rebuild with my WIndows 8.1...)
The PR is quite small. if someone with a proper setup could just add some test for it, it would be nice.
https://github.com/angular/angular.js/issues/13951

I left a couple of minor comments. There are also some styling issues that JSCS complains about (you can take a look here).
Could you also add Fixes #13951 at the end of your commit message ? This way, the related issue will be automatically closed when this PR is merged.
--
Regarding npm install:
Indeed gyp-rebuild will throw lots of read in your face, while trying to rebuild some modules on Windows. This doesn't necessarily mean the installation failed (it will just fall back to pre-built artifacts).
Are you sure npm install failed ? (Even if it has, the gyp-rebuild failures might not be the cause.)
Regarding tests:
Even if you are not able to run the tests locally, you could still add them and push the changes to this PR, so CI can run them for you. It's not necessary though (and it's tooo slow and obviously less than ideal :smiley:).

@gkalpak Thanks for feedback. I've pushed changes. I'm installing the environment on an Ubunutu now. I don't know what happened about gyp-rebuild but many node modules weren't properly installed after the red messages, I assumed it didn't go well. :)
(I forgot about Fixes #13951 but since I'll eventually have to rebase -i I'll add it later anyway.

Great ! The code LGTM. Let us know if you run into any difficulties setting up the testing environment.

I just pushed some tests, hope they'll pass. Not sure aboute the it messages though.
I definitely ran into issues with the setup, I got red messages again after a npm install, but all packages seemed to be installed, then the whole node_modules folder got deleted. I really don't get it. Seems like an exception has been thrown somewhere and the whole thing got cancelled, I tried twice, same result.
So, CI's got to do the testing part :)

Are you by any chance using npm >=3.0.0 ? That would explain the node_modules/ directory getting deleted after modules are installed. It's because the execution order of pre/post-install scripts wrt to other operations has changed in npm 3.
Our setup is currently not compatible with npm 3 (and even if you worked around that, I doubt all our dependencies are). This is tracked in #13505 btw.

There were some failures :smiley:
Taking a closer look...

@Vadorequest, do you think it would be useful to have the method available on $controller as well ?

@gkalpak No, I don't think the controller needs to have a has method, the provider makes much more sense.

Tests passed :) Cool.
And yes, I'm using node 5.5, that's why it fails during the setup.

Using node 3.3.1 it worked well, I've been able to run the tests and everything looks good.
The PR has been squashed and is ready to be merged.

@Vadorequest, only a minor clean-up comment. LGTM otherwise :+1:

Th @Vadorequest :+1:
Backported to v1.5.x as bb9575d.

Thanks to you @gkalpak :)
Does that mean that it can be used in the latest version righ now?

It will be available from the upcoming v1.5.1 release onwards. Right now you can try it out with the latest snapshot, which is basically the code urrently on master.
(NOTE: The snapshot changes with every commit to master and might contain breaking changes. It is not recommened for use in production :smiley: - it's just an easy way to try something out before it's released.)

Thanks ;)


Update placeholder extension

Description

Refactoring codebase, updated code style
Updated dependencies
Removed axios in favor of node-fetch

Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

@j3lte Good job! LGTM!


Can't find module "vue-good-table" Typescript

I am newbie to either typescript and Vue.js ; and I am experiencing an issue that related with using the Vue-good-table componant inside a typescript file like this;
import VueGoodTable from 'vue-good-table';
import 'vue-good-table/dist/vue-good-table.css'
TS compiler throws a compile error (Can't find module "vue-good-table").Can anyone help me please ?

Problem is actual. I tried to add this:
shims.d.ts
declare module 'vue-good-table' {
  import VueGoodTable from 'vue-good-table';
}

my-component.ts
import Vue from 'vue';
import Component from 'vue-class-component';
import VueGoodTable from 'vue-good-table';

@Component({
  components: {
    VueGoodTable
  }
})
export default class MyComponent extends Vue {
  //my code
}

Compiler has no errors, but runtime has error:

[Vue warn]: Failed to mount component: template or render function not defined.

Can someone give more specific advice with short example?

@Dried09 @AhmedElbatt component export should now be fixed with v2.8.1
Install instruction for your ref:
https://xaksis.github.io/vue-good-table/guide/#installation

Do you have a solution?

@rafaelgov95 umm... yeah... v2.8.1 should have a fix to the problem stated here...

@xaksis follows what @Dried09 said but does not work.

I figured out this problem, but... it's actually not a good solution
add vue-good-table.d.ts file anywhere in project, for example, and add into it:
declare module 'vue-good-table' {
    export = VueGoodTable;
}
declare const VueGoodTable: any;

Then in some component add import:
import * as VueGoodTable from 'vue-good-table';
And finally in this component add global import:
Vue.use(VueGoodTable.default);
After that table component should work.
P.S. To my mind - it's not a solution, just ugly crutch, but it works at least for now
Hope on typescript support improvements in future.

@Dried09 with 2.8.1 you should be able to do what you were doing before:
shims.d.ts
declare module 'vue-good-table' {
  import { VueGoodTable } from 'vue-good-table'; // notice the syntax change
}

my-component.ts
import Vue from 'vue';
import Component from 'vue-class-component';
import VueGoodTable from 'vue-good-table';

@Component({
  components: {
    VueGoodTable
  }
})
export default class MyComponent extends Vue {
  //my code
}

can you confirm that this doesn't work for you?

Nope, still not :(
shims.d.ts src Module ''vue-good-table'' has no exported member 'VueGoodTable'.

I don't use typescript so someone else can help you better here but it seems like you need to export it from your shim too like:
declare module "*.vue" {
    import Vue from "vue";
    export default Vue;
}

so following that logic, your shim might need to be:
declare module 'vue-good-table' {
  import { VueGoodTable } from 'vue-good-table';
  export default VueGoodTable;
}

make sure you're on 2.8.1 because 2.8.1 exports VueGoodTable versions before don't.
https://github.com/xaksis/vue-good-table/blob/master/src/index.js#L15

Without claiming to understand much of all this, I did get it working by
creating a folder src/types/vue-good-table
creating a file src/types/vue-good-table/index.d.ts
containing
declare module 'vue-good-table';

Make sure typescript is set to include that file. My tsconfig.json says
"include": [
    "src/**/*.ts",
    ....

Now, in my view component, I can write
<script lang="ts">
    ....

    import 'vue-good-table/dist/vue-good-table.css';
    import { VueGoodTable } from 'vue-good-table';
    ....
    export default {
        ....
        components : {
            VueGoodTable
        },
        ....
        data() {
            return {
                columns :...
                rows: ....

and
<template>
    <vue-good-table
         :columns="columns"
          :rows="rows"/>

and compilling it doesn't complain and works.


CUDA error: out of memory

What is the issue?
When I try the llama3 model I get out of memory errors. I have 64GB of RAM and 24GB on the GPU.
❯ ollama run llama3:70b-instruct-q2_K  --verbose "write a constexpr GCD that is not recursive in C++17"
Error: an unknown error was encountered while running the model CUDA error: out of memory
  current device: 0, in function alloc at /go/src/github.com/ollama/ollama/llm/llama.cpp/ggml-cuda.cu:233
  hipMalloc((void **) &ptr, look_ahead_size)
GGML_ASSERT: /go/src/github.com/ollama/ollama/llm/llama.cpp/ggml-cuda.cu:60: !"CUDA error"

 journalctl -u ollama.service -f shows
Apr 19 22:43:30 box ollama[641298]: llama_new_context_with_model: n_ctx      = 2048
Apr 19 22:43:30 box ollama[641298]: llama_new_context_with_model: n_batch    = 512
Apr 19 22:43:30 box ollama[641298]: llama_new_context_with_model: n_ubatch   = 512
Apr 19 22:43:30 box ollama[641298]: llama_new_context_with_model: freq_base  = 500000.0
Apr 19 22:43:30 box ollama[641298]: llama_new_context_with_model: freq_scale = 1
Apr 19 22:43:30 box ollama[641298]: llama_kv_cache_init:      ROCm0 KV buffer size =   488.00 MiB
Apr 19 22:43:30 box ollama[641298]: llama_kv_cache_init:  ROCm_Host KV buffer size =   152.00 MiB
Apr 19 22:43:30 box ollama[641298]: llama_new_context_with_model: KV self size  =  640.00 MiB, K (f16):  320.00 MiB, V (f16):  320.00 MiB
Apr 19 22:43:30 box ollama[641298]: llama_new_context_with_model:  ROCm_Host  output buffer size =     0.52 MiB
Apr 19 22:43:30 box ollama[641298]: ggml_backend_cuda_buffer_type_alloc_buffer: allocating 1088.45 MiB on device 0: cudaMalloc failed: out of memory
Apr 19 22:43:30 box ollama[641298]: ggml_gallocr_reserve_n: failed to allocate ROCm0 buffer of size<PHONE_NUMBER>
Apr 19 22:43:30 box ollama[641298]: llama_new_context_with_model: failed to allocate compute buffers

Sometimes I get past this, then it fails a few lines later. It then shows a stacktrace, if that helps:
Apr 19 22:44:49 box ollama[691627]: 0x00007f17e17d9fa3 in wait4 () from /lib64/libc.so.6
Apr 19 22:44:49 box ollama[691627]: #0  0x00007f17e17d9fa3 in wait4 () from /lib64/libc.so.6
Apr 19 22:44:49 box ollama[691627]: #1  0x00000000024e8084 in ggml_cuda_error(char const*, char const*, char const*, int, char const*) ()
Apr 19 22:44:49 box ollama[691627]: #2  0x00000000024fc062 in ggml_cuda_pool_leg::alloc(unsigned long, unsigned long*) ()
Apr 19 22:44:49 box ollama[691627]: #3  0x00000000024fc790 in ggml_cuda_pool_alloc<__half>::alloc(unsigned long) ()
Apr 19 22:44:49 box ollama[691627]: #4  0x00000000024f2ccf in ggml_cuda_mul_mat(ggml_backend_cuda_context&, ggml_tensor const*, ggml_tensor const*, ggml_tensor*) ()
Apr 19 22:44:49 box ollama[691627]: #5  0x00000000024ebae3 in ggml_backend_cuda_graph_compute(ggml_backend*, ggml_cgraph*) ()
Apr 19 22:44:49 box ollama[691627]: #6  0x00000000024b3888 in ggml_backend_sched_graph_compute_async ()
Apr 19 22:44:49 box ollama[691627]: #7  0x00000000023d2819 in llama_decode ()
Apr 19 22:44:49 box ollama[691627]: #8  0x00000000022df081 in llama_server_context::update_slots() ()
Apr 19 22:44:49 box ollama[691627]: #9  0x00000000022e10ba in llama_server_queue::start_loop() ()
Apr 19 22:44:49 box ollama[691627]: #10 0x00000000022c4e02 in main ()
Apr 19 22:44:49 box ollama[691627]: [Inferior 1 (process 691260) detached]

OS
Linux
GPU
AMD
CPU
AMD
Ollama version
0.1.32

Hey there,
I seem to be encountering a similar issue with the command-r function. Every time I invoke it, I experience a loading process followed by the following error message:
ollama run command-r
Error: llama runner process no longer running: 1 error:failed to create context with model '/usr/share/ollama/.ollama/models/blobs/sha256-8a9611e7bca168be635d39d21927d2b8e7e8ea0b5d0998b7d5980daf1f8d4205'

Additionally, I've noticed the following log entries:
Apr 21 23:57:39 132-145-209-225 ollama[26073]: .......................................................................................
Apr 21 23:57:39 132-145-209-225 ollama[26073]: llama_new_context_with_model: n_ctx      = 2048
Apr 21 23:57:39 132-145-209-225 ollama[26073]: llama_new_context_with_model: n_batch    = 512
Apr 21 23:57:39 132-145-209-225 ollama[26073]: llama_new_context_with_model: n_ubatch   = 512
Apr 21 23:57:39 132-145-209-225 ollama[26073]: llama_new_context_with_model: freq_base  = 8000000.0
Apr 21 23:57:39 132-145-209-225 ollama[26073]: llama_new_context_with_model: freq_scale = 1
Apr 21 23:57:39 132-145-209-225 ollama[26073]: llama_kv_cache_init:      CUDA0 KV buffer size =  2560.00 MiB
Apr 21 23:57:39 132-145-209-225 ollama[26073]: llama_new_context_with_model: KV self size  = 2560.00 MiB, K (f16): 1280.00 MiB, V (f16): 1280.00 MiB
Apr 21 23:57:39 132-145-209-225 ollama[26073]: llama_new_context_with_model:  CUDA_Host  output buffer size =     1.01 MiB
Apr 21 23:57:39 132-145-209-225 ollama[26073]: ggml_backend_cuda_buffer_type_alloc_buffer: allocating 516.00 MiB on device 0: cudaMalloc failed: out of memory
Apr 21 23:57:39 132-145-209-225 ollama[26073]: ggml_gallocr_reserve_n: failed to allocate CUDA0 buffer of size 541065216
Apr 21 23:57:39 132-145-209-225 ollama[26073]: llama_new_context_with_model: failed to allocate compute buffers

It's worth noting that I can successfully run command-r-plus, which is three times larger, without any issues.
My system specs are as follows:
Linux OS
NVIDIA A10 GPU
192GB of RAM
Furthermore, here's the nvcc output.
nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2023 NVIDIA Corporation
Built on Tue_Aug_15_22:02:13_PDT_2023
Cuda compilation tools, release 12.2, V12.2.140
Build cuda_12.2.r12.2/compiler.33191640_0

I had this issue last week when loading some extra large models. It seems that when ollama is offloading layers to gpu it does not consider the vram for other stuff like the KV cache or there is a bug that makes it calulate incorrectly?
As the error  in the log shows:

Apr 19 22:43:30 box ollama[641298]: ggml_backend_cuda_buffer_type_alloc_buffer: allocating 1088.45 MiB on device 0: cudaMalloc failed: out of memory

Apr 21 23:57:39 132-145-209-225 ollama[26073]: ggml_backend_cuda_buffer_type_alloc_buffer: allocating 516.00 MiB on device 0: cudaMalloc failed: out of memory

You need more vram. So the way I solve this issue is that manually change the model file and offload less layer to the gpu. (To free up some vram)
To change the model file, see the issue here.

Thanks a lot for the response and the workaround solution. I'll definitely give it a shot.

probably you can reduce the n_batch to 256, or smaller to get rid of this OOM error

probably you can reduce the n_batch to 256, or smaller to get rid of this OOM error

I edited the modelfile and tried different settings for num_batch, and PARAMETER num_batch 32 seems to work. Anything above crashes.

All my problems seem to disappear when I limit the amount of memory for ollama. My 7900 XT has 20GB, so I have limited it now to 18GB like so using sudo systemctl edit ollama.service:
[Service]
Environment="OLLAMA_MAX_VRAM=19327352832"

Now all models work. Also, previously my graphics card started to stutter in the KDE UI when a large model is loaded, that's now gone as well! I'm now a happy user again :)
=> I think the the max VRAM should be a bit more limited by default

All my problems seem to disappear when I limit the amount of memory for ollama. My 7900 XT has 20GB, so I have limited it now to 18GB like so using sudo systemctl edit ollama.service:
[Service]
Environment="OLLAMA_MAX_VRAM=19327352832"

Now all models work. Also, previously my graphics card started to stutter in the KDE UI when a large model is loaded, that's now gone as well! I'm now a happy user again :)
=> I think the the max VRAM should be a bit more limited by default

Can confirm, this is the only solution I've gotten to work.

We've made various fixes/improvements in the memory prediction algorithm recently.  Please give the latest RC of 0.1.33 a try and let us know how it goes.
https://github.com/ollama/ollama/releases

I've removed my OLLAMA_MAX_VRAM setting, then downloaded the latest RC with
curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION="0.1.33-rc7" sh

Unfortunately there's not much differnce for me. llama3:70b-instruct crashes with CUDA OOM, and e.g. nous-hermes2-mixtral works but uses so much memory that the desktop environment becomes unusable (even when ollama is idle, the only way to get rid of the stuttering is to unload the model)

@martinus can you share your server log so we can see where the calculations went wrong?

Sure, I ran it 3 times, first run it gave me an error quite early and the CLI just hang, the other 2 runs looked the same and gave me this error in the CLI:
❯ ollama run llama3:70b-instruct "tell me 10 important rules about software development"
Error: an unknown error was encountered while running the model CUDA error: out of memory
  current device: 0, in function alloc at /go/src/github.com/ollama/ollama/llm/llama.cpp/ggml-cuda.cu:233
  hipMalloc((void **) &ptr, look_ahead_size)
GGML_ASSERT: /go/src/github.com/ollama/ollama/llm/llama.cpp/ggml-cuda.cu:60: !"CUDA error"

Output gathered from sudo journalctl -u ollama.service:

llama3_70b-instruct.1.txt
llama3_70b-instruct.2.txt
llama3_70b-instruct.3.txt

Would it be possible to try again on 0.1.34? A few improvements went in for memory allocation, especially with larger models such as Llama 3 70b. Let me know if that doesn't fix it and we can re-open the issue!

I gave it a try, and get the same crashes. But I discovered something: I usually have the Steam client running in the background, and when I close it, ollama run llama3:70b-instruct consistently works (other big models still fail though). So ist seems to me that Steam needs some GPU memory.
I did not look at ollama's code, but both when Steam is running or not the logs concerning the memory allocation look exactly the same:
May 10 07:52:21 box ollama[7395]: ggml_cuda_init: GGML_CUDA_FORCE_MMQ:   no
May 10 07:52:21 box ollama[7395]: ggml_cuda_init: CUDA_USE_TENSOR_CORES: yes
May 10 07:52:21 box ollama[7395]: ggml_cuda_init: found 1 ROCm devices:
May 10 07:52:21 box ollama[7395]:   Device 0: AMD Radeon Graphics, compute capability 11.0, VMM: no
May 10 07:52:21 box ollama[7395]: llm_load_tensors: ggml ctx size =    0.74 MiB
May 10 07:52:31 box ollama[7395]: llm_load_tensors: offloading 39 repeating layers to GPU
May 10 07:52:31 box ollama[7395]: llm_load_tensors: offloaded 39/81 layers to GPU
May 10 07:52:31 box ollama[7395]: llm_load_tensors:      ROCm0 buffer size = 17903.44 MiB
May 10 07:52:31 box ollama[7395]: llm_load_tensors:        CPU buffer size = 38110.61 MiB
May 10 07:52:32 box ollama[7395]: ..................................................................................................
May 10 07:52:32 box ollama[7395]: llama_new_context_with_model: n_ctx      = 2048
May 10 07:52:32 box ollama[7395]: llama_new_context_with_model: n_batch    = 512
May 10 07:52:32 box ollama[7395]: llama_new_context_with_model: n_ubatch   = 512
May 10 07:52:32 box ollama[7395]: llama_new_context_with_model: freq_base  = 500000.0
May 10 07:52:32 box ollama[7395]: llama_new_context_with_model: freq_scale = 1
May 10 07:52:32 box ollama[7395]: llama_kv_cache_init:      ROCm0 KV buffer size =   312.00 MiB
May 10 07:52:32 box ollama[7395]: llama_kv_cache_init:  ROCm_Host KV buffer size =   328.00 MiB
May 10 07:52:32 box ollama[7395]: llama_new_context_with_model: KV self size  =  640.00 MiB, K (f16):  320.00 MiB, V (f16):  320.00 MiB
May 10 07:52:32 box ollama[7395]: llama_new_context_with_model:  ROCm_Host  output buffer size =     0.52 MiB
May 10 07:52:32 box ollama[7395]: llama_new_context_with_model:      ROCm0 compute buffer size =  1104.45 MiB
May 10 07:52:32 box ollama[7395]: llama_new_context_with_model:  ROCm_Host compute buffer size =    20.01 MiB
May 10 07:52:32 box ollama[7395]: llama_new_context_with_model: graph nodes  = 2566
May 10 07:52:32 box ollama[7395]: llama_new_context_with_model: graph splits = 455

So it seems to me that ollama doesn't take other applications into account that might already use GPU memory?
I stopped ollama, and had a look with nvtop about the GPU's memory usage:

0.957Gi/19.984Gi without Steam
1.348Gi/19.984Gi with Steam running

We're calculating available VRAM based on the linux kernel reporting from the amd driver.  From what you describe, it sounds like the upstream kernel driver may not report this accurately compared to the latest amd specific driver.
Is it possible for you to try to upgrade to the amd specific driver?

I have Fedora 40, and as far as I know have all ROCm libraries installed. I can run rocm-smi --showmeminfo vram which shows the RAM and used RAM:
============================ ROCm System Management Interface ============================
================================== Memory Usage (Bytes) ==================================
GPU[0]          : VRAM Total Memory (B):<PHONE_NUMBER>4
GPU[0]          : VRAM Total Used Memory (B):<PHONE_NUMBER>
==========================================================================================
================================== End of ROCm SMI Log ===================================

I ran strace to see what the command is actually reading, and see that it reads these two files:

/sys/class/drm/card1/device/mem_info_vram_used
/sys/class/drm/card1/device/mem_info_vram_total

And these seem to contain the correct numbers

Thanks @martinus!  It does look like that path may prove more reliable than /sys/class/kfd/kfd/topology/nodes/*/mem_banks/*/used_memory
I'll need to restructure a bit of the amd discovery code, but I'll try to get a fix up in the next release.

Hi! It's the same for nvidia graphic cards on windows. I can confirm both on rtx 4090 laptop and rtx 3060 laptop other VRAM consumers are not detected at all so available VRAM is higher than it should be. If the usage of other consumer is high ollama_llama_server.exe will freeze. Temporary workaround is setting num_gpu to lower number of layers.

@JemsonDev I'll be closing this issue out with the amd fix.
I believe you're probably hitting #4599 which is a different issue related to how windows does VRAM paging.

All my problems seem to disappear when I limit the amount of VRAM for ollama. My 7900 XT has 20GB, so I have limited it now to 18GB like so using sudo systemctl edit ollama.service:
[Service]
Environment="OLLAMA_MAX_VRAM=19327352832"

Now all models work. Also, previously my graphics card started to stutter in the KDE UI when a large model is loaded, that's now gone as well! I'm now a happy user again :)
=> I think the max VRAM should be a bit more limited by default

i have exact same card and i had set exactly as you mentioned and it didn't work for me( still getting this error


5 simple questions for the user

HTML questions for the user
Effort: 3

I decided i didn't want to work on this right now.

Have created the 5 questions and was able to added it to show at the bottom of the page.


[OAP-1631][Doc]Update MLlib Doc for OAP 1.0

What changes were proposed in this pull request?
Fix: #1631
How was this patch tested?

@xwu99 Please have a review and help merge it.

@HongW2019 thanks for your effort! merged!


Disable Power10 optimized chacha20 on all big-endian platforms

It fails most tests on a linux-ppc64-power10 host. I suspect this was never tested on a Power10 BE host, thus it has been disabled on AIX and darwin. However, the macro guards do not cover ppc64 linux (or openbsd if used there).
Update the guard to explicitly enable this only for little-endian hosts. This passes all tests on a linux-ppc64-power10 host running debian unstable.
Fixes #25451
CLA: trivial

OK with CLA: trivial

ok with trivial


Add support for BrokerK8sInsecure to subctl

Submariner can disable certificate verification when contacting the broker; this is configured using BrokerK8sInsecure in the Submariner object. subctl should allow enabling this, and apply the setting to itself when contacting the broker.

@skitt I assume this should be moved out of 0.12?


Add qc check excluded subclass of provenance

This PR:

adds a QC check that ensures that all "excluded_SubClassOf" axioms have provenance
adds a QC check that ensures that the range of all excluded subclass axioms is always an ontology IRI (see #7414)
adds an update query to add @nicolevasilevsky orcid to 300 excluded subclass of axioms that currently do not have provenance

@matentzn do I need to do something for this PR?

You can review the mondo-edit.obo file now! If QC passes this is ready to be merged. Should not wait for too long, as the diff is extensive and can easily lead to conflicts.

I spot checked a few of these and it looks good, thanks @matentzn!


How can I map §/± key to `/~ key?

I often switch between the laptop keyboard and an external ANSI keyboard. I want to permanently map §/± to  `/~. I cannot find the §/± key in the the dropdown for basic mapping.

I tried this on the latest release (12.0.0) and it doesn't work?
                  {
                        "description": "§ -> `",
                        "manipulators": [
                            {
                                "from": {
                                    "key_code": "6"
                                },
                                "to": [
                                    {
                                        "key_code": "grave_accent_and_tilde"
                                    }
                                ],
                                "type": "basic"
                            }
                        ]
                    }

Usually, § key is non_us_backslash.
What's key name shown in EventVIewer when you press § key?

Ah, thanks, that does work.


nodeJS speech to text errors initial silence timeout.

I have problem about nodeJS speech to text errors initial silence timeout.
Steps to reproduce the behavior:

node index.js speech
(recognized)  Reason: NoMatch NoMatchReason: InitialSilenceTimeout

MacOS
Node v10.18.1

@glharper @rhurey Please check.

@hungltph03955 Thanks for the feedback. Could you attach test13.wav so that we can reproduce this issue?

@glharper thank you for reply. This is the file I used in nodeJS speech to text.
test13.wav.zip

@hungltph03955 Your file is a 44.1 kHz stereo wav file. Currently only 16 kHz mono wav files are supported for the nodeJS SDK. From the quickstart (link), note the line:
var filename = "YourAudioFile.wav"; // 16000 Hz, Mono
Thanks.

@hungltph03955 Please use this code to create the PushStream for a 44.1 kHz stereo file:
var format = sdk.AudioStreamFormat.getWaveFormatPCM(44100, 16, 2); //44.1 kHz, 16-bit, 2-channel
var pushStream = sdk.AudioInputStream.createPushStream(format);

@glharper
thank you!!
I have converted the text with test13.wav file. But when I test vs this file test9.wav, I got the InitialSilenceTimeout error. Because there are 5 seconds not saying.
Is there any way to fix it? Thank you so much
test9.wav.zip

@hungltph03955 Set the InitalSilenceTimeout property using the code below:
speechConfig.setProperty(sdk.PropertyId.SpeechServiceConnection_InitialSilenceTimeoutMs, "10000"); // 10000ms
Thanks.

Hi @glharper
I have convered the text but it seems n is missing text. Is there a way to fix it or am I missing that parameter?

Thanks.

@hungltph03955 You will have to use startContinuousRecognitionAsync instead of recognizeOnceAsync. Look through Speech Recognition Tests  for examples of the correct workflow for your use case.
I'm closing this issue now as the original question has been answered.


Update deployment-types.md

Which question does this answer? Is it not obvious that a bot communicating with Telegram is a Telegram bot?
Using a much longer term will inevitably make the entire ASCII drawing wider, so it may no longer fit as well on all screens. We try to keep these illustrations as narrow as possible.


Added logic apps operations

Added logic apps operations that are proxied through the web apps RP. I'm not sure why this PR is showing deletions. Neither of my commits remove any existing stuff from the definition. I think it's just the diff tool getting a bit confused as I insert stuff in the middle of the file?
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[x] Other, please clarify I am adding routes for logic apps that are proxied directly from the RP front end into customer's running apps, so they are not added in the normal swagger generation step

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month. The functionality is already live
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month. We will publish in the ANT97 release this PR is open against
If updating an existing version, please select the specific language SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

@alexkarcher-msft there is huge diff in webapps.json.
Make sure it is sorted up, then add ARM review.

@weidongxu-microsoft I have sorted through all of the PR validation errors that appear to be unique to my additions. Let me know how to add ARM for review.

@alexkarcher-msft
You should not change package-lock.json
I've no idea why there is 10k+ change on webapps.json. But if you are ready, just check " Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest." checkbox in description.
Due to this huge change on webapps.json, I would need Navy's approval for this PR as well (or we might mess his branch).

Whoops, forgot to revert package-lock before sending the prettier updates. Will check those boxes and get the review underway.
I'm not quite sure why my ~5k lines added to web-apps.json with no deletions is showing up as a 10k+ diff with a ton of deletions. It's a mystery we can all ponder together this April.

@weidongxu-microsoft Seems like the wait for ARM review tag was added 20 days ago and it was not reviewed. Should @alexkarcher-msft remove and re-add the tag to retrigger the review process?

@edwin-msft
Please see https://github.com/Azure/azure-rest-api-specs/pull/18604#issuecomment-1098561987
You can email the group to notify them.

Thank you for the information, @weidongxu-microsoft
@alexkarcher-msft Can you please email<EMAIL_ADDRESS>as per Weidong's instructions? https://github.com/Azure/azure-rest-api-specs/pull/18604#issuecomment-1098561987

Sent an email for review. Thanks for the clarification.

      "nextLinkName": null

This does not have a nextLink?

Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:21784 in 6926d75. [](commit_id = 6926d7553fad0cfe979d9202a84157d2a227972f, deletion_comment = False)

      "nextLinkName": null

Same question here, no nextLink?

Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:22144 in 6926d75. [](commit_id = 6926d7553fad0cfe979d9202a84157d2a227972f, deletion_comment = False)

      "202": {

202 is used for async, should this post call be a async operation?

Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:22581 in 6926d75. [](commit_id = 6926d7553fad0cfe979d9202a84157d2a227972f, deletion_comment = False)

      },

Same here, is this post async or sync?

Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:22695 in 6926d75. [](commit_id = 6926d7553fad0cfe979d9202a84157d2a227972f, deletion_comment = False)

      "202": {

202 is used for async, should this post call be a async operation?
Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:22581 in 6926d75. [](commit_id = 6926d75, deletion_comment = False)

For this run workflow action, the underlying workflow is something created by the customer and can be async or synchronous depending on how they've configured their workflow.

      },

Same here, is this post async or sync?
Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:22695 in 6926d75. [](commit_id = 6926d75, deletion_comment = False)

For the resubmit action, it's a bit of a confusing operation to document. In order to call this API you need to have all the same context you need to get the run status. After you resubmit the run, the status of that run can then be checked using the same trigger name, history name, etc.
Is there anything explicit you're looking to have added to indicate that it's an async operation?

      "nextLinkName": null

Same question here, no nextLink?
Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:22144 in 6926d75. [](commit_id = 6926d75, deletion_comment = False)

Good catch with both of these! I've updated these two and a few other instances where that value was missing.

    "x-ms-pageable": {

Generally POST APIs are for actions, there are exceptions where you can return item(s) when you are aggregating datasources to construct a response and this process takes more than 2 seconds (at which point it becomes an async API). Also, using list*** prefix and POST method means that you can enable ARM Template support (e.g. listSecrets), is this your intention? also, are you paginating the result?

Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:21716 in fd01151. [](commit_id = fd011516eac6508d47c66d353c5a4251ef5e4ea1, deletion_comment = False)

    "x-ms-pageable": {

Same as above, are you planning on paginating the response?

Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:21926 in fd01151. [](commit_id = fd011516eac6508d47c66d353c5a4251ef5e4ea1, deletion_comment = False)

    "x-ms-pageable": {

Generally POST APIs are for actions, there are exceptions where you can return item(s) when you are aggregating datasources to construct a response and this process takes more than 2 seconds (at which point it becomes an async API). Also, using list*** prefix and POST method means that you can enable ARM Template support (e.g. listSecrets), is this your intention? also, are you paginating the result?
Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:21716 in fd01151. [](commit_id = fd01151, deletion_comment = False)

Hi Jorge,
I checked in the code and those APIs are not currently returned paged results. However, the source APIs that they are proxying are also listed as pageable. I notice that that doesn't seem to then be translated into our documentation. However, I'm fine removing that annotation if it's causing problems. https://github.com/Azure/azure-rest-api-specs/blob/main/specification/logic/resource-manager/Microsoft.Logic/stable/2019-05-01/logic.json#L1923
For the POST, I couldn't find anyone with any idea of why that endpoint is POST instead of GET. It has been like that since 2016, and is already interfacing with very mature portal code. If it is a problem I can make a work item to look at updating the API for both our older original RP and this newer proxied version.
Right now we're just looking to document what's already been deployed to production, as it's already been in production for years with no documentation or SDK/CLI support.

@zizw123
I think it is the recommended to add x-ms-pageable with nextLink=null to those APIs that could potentially be pageable in future, especially for SDK (as adding x-ms-pageable would be breaking changes to SDK).
Though if service know there will never be such pagination in future, they are no necessary.

@weidongxu-microsoft
Sweet! In that case I'd love to keep the pageable links in there, as we may add that functionality in the future. We have "nextLinkName": "nextLink" instead of nextLink:null, but that is consistent though out the whole WebApps.json definition.

      "202": {

+1, you need x-ms-long-running-operation if this method is async. If it's sync, the status code should be 200 or 204.

In reply to:<PHONE_NUMBER>

Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:22581 in 6926d75. [](commit_id = 6926d7553fad0cfe979d9202a84157d2a227972f, deletion_comment = False)

      },

+1, x-ms-long-running-operation if async, remove 202 if sync.

In reply to:<PHONE_NUMBER>

Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:22695 in 6926d75. [](commit_id = 6926d7553fad0cfe979d9202a84157d2a227972f, deletion_comment = False)

      "202": {

202 is used for async, should this post call be a async operation?
Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:22581 in 6926d75. [](commit_id = 6926d75, deletion_comment = False)

For this run workflow action, the underlying workflow is something created by the customer and can be async or synchronous depending on how they've configured their workflow.

Does your API implement the standard ARM async pattern when the customer workflow is async? If so, you need to mark the method with the x-ms-long-running-operation extension and implement the operationStatuses or operationResults APIs. Ref: https://github.com/Azure/azure-resource-manager-rpc/blob/master/v1.0/async-api-reference.md#asynchronous-api-reference and https://github.com/Azure/autorest/blob/main/docs/extensions/readme.md#x-ms-long-running-operation.

      },

Same here, is this post async or sync?
Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:22695 in 6926d75. [](commit_id = 6926d75, deletion_comment = False)

For the resubmit action, it's a bit of a confusing operation to document. In order to call this API you need to have all the same context you need to get the run status. After you resubmit the run, the status of that run can then be checked using the same trigger name, history name, etc.
Is there anything explicit you're looking to have added to indicate that it's an async operation?

I replied earlier in both non-quoted and quoted comment,s duplicating here so it doesn't get overlooked. You need x-ms-long-running-operation to describe the standard Azure async pattern. Previous comment included links to the wiki that describe it in detail.

@alexkarcher-msft - I revisited ARM review comments and found a few still unaddressed. I expanded on those to help clarify. To respond back, please apply the WaitForARMFeedback label again.

Hi @mentat9 ,
Added x-ms-long-running to those two async API calls. For this entire PR, we are proxying an API that is already in production and already has its own ARM approved definition deployed here: https://github.com/Azure/azure-rest-api-specs/tree/main/specification/logic/resource-manager/Microsoft.Logic/stable/2019-05-01
If you need additional functional updates we can create a work item on our side and work to get funding to make those changes. Since updates will apply to both routes this API is surfaced, it will likely involve breaking changes to existing customers.
At this time I'd like to document what we have and circle back around after the fact and make any updates to our API surface.

      "202": {

I think you still need an additional 200 or 204 here. The API must return a final result that isn't 202, right? However, based on your other comments that this is to document an existing production API, I won't withhold ARM approval. ARM review is to apply principles to new APIs. Anything that improves the fidelity of specs for APIs already in production is welcome.

In reply to:<PHONE_NUMBER>

Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:22581 in 6926d75. [](commit_id = 6926d7553fad0cfe979d9202a84157d2a227972f, deletion_comment = False)

    "x-ms-pageable": {

FYI, I don't think x-ms-pageable actually does anything for POST methods.

In reply to:<PHONE_NUMBER>

Refers to: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/WebApps.json:21716 in fd01151. [](commit_id = fd011516eac6508d47c66d353c5a4251ef5e4ea1, deletion_comment = False)

Hi @mentat9 ,
Added x-ms-long-running to those two async API calls. For this entire PR, we are proxying an API that is already in production and already has its own ARM approved definition deployed here: https://github.com/Azure/azure-rest-api-specs/tree/main/specification/logic/resource-manager/Microsoft.Logic/stable/2019-05-01
If you need additional functional updates we can create a work item on our side and work to get funding to make those changes. Since updates will apply to both routes this API is surfaced, it will likely involve breaking changes to existing customers.
At this time I'd like to document what we have and circle back around after the fact and make any updates to our API surface.

@alexkarcher-msft - Thank-you for the additional context. Given that your goal is to match this spec to APIs already in production, ARM recommendations are mostly moot. I've left a couple more comments related to that goal (final status code for one of the POST methods, and x-ms-pageable on POST), but ARM signoff really shouldn't be needed here. I've removed the WaitForARMFeedback label.

I should be able to merge after conflict resolved.

Thanks for the heads up! Resolved merge conflicts

@weidongxu-microsoft , feel free to merge whenever you have a chance :)


Make it easier to create a Value from owned or erased external types

This PR allows consumers to work around Value's required lifetime constraints in two ways:

allowing us to create a value with any lifetime from some owned primitive, like u8, bool etc. This is what the Primitive type is all about.
allowing us to create a value from some type that can produce a concrete value we can use, but doesn't guarantee it will live as long as the value itself. This is what the Fill and Slot types are all about.

The Fill API is a more advanced initialization strategy (it's actually a kind of visitor that just tries very hard to look like initialization), so it isn't exported from the log::kv module. Instead, this PR makes the value module public and leaves Fill and Slot in there. We need something like this to be able to translate a &'kvs dyn tracing::Value into a log::kv::Value<'kvs>.

I'll be a good citizen and add some tests for Fill...


KeyError: 'completion tokens'

Our chat bot would occasionally run into this error:
e.py", line 65, in generate
    new_results = self._generate(missing_prompts, stop=stop)
  File "/home/ubuntu/.cache/pypoetry/virtualenvs/lm-bot-w2c4PdJl-py3.8/lib/python3.8/site-packages/langchain/llms/openai.py", line 151, in _generate
    token_usage[_key] = response["usage"][_key]
KeyError: 'completion_tokens'

huh good to know - i had thought those would always be returned but ill open a pr to handle it more safely


Import/export glass shatter maps

Prior art: https://github.com/soryy708/Shatter-Map-Utility-Tool
This is a JavaScript utility which converts back and forth between CodeWalker's shatter map and BMP images.
encoding
decoding

Awesome, we will definitely use this! We're just gonna have to convert to Python and we will need to figure out how to import the image data to Blender. Blender doesn't allow the use of any external Python libraries which is a challenge.
I would consider compiling an exe without the UI that takes in command line arguments to run the exe through Python, but then there will be issues with the exe not being incompatible with some machines.


Resolve all the lv2lint issues

Since the macro conditional logic began to get intricate, I have factored the code in the exporter such that there needn't be so much care taken regarding the syntax, and reduce error possibilities. ed1572a

It's a starting point so I can add and remove extension data easily, and I verified the examples manifests before/after using diff. Apart from some whitespace, it was identical.

Licenses were changed to URI. 4cfa3d3
At the same time, cairoUI's metadata was put in consistency with the rest of examples.

Missing extension data were added. I checked it against LV2 wrappers source code.
I found the KX program Interface to be mistaken for UIInterface and fixed it.

Implemented the worker's response function. It's not supposed to be null.
Implementation does nothing.

Reviewing this, I like the approach, but I do not like changing the license text to be a URL.
In DPF, the license can be a short string (like "MIT" or "GPLv2") or a full URL.
Not everyone is going to know the proper URL for each license, DPF should make it easier.
In cases of licenses like "MIT" where they are common and known, we can map that to a full URL when exporting LV2 data.
I am going to merge the PR manually, but skipping that change. We can figure out a nice way to handle it in another PR or ticket.


Sample bots doesn't work

Are they ok? )

I have a problem with my server so bots are down now.
But if you are talking about the code, please check samples(and Wiki) in games branch. Due to bugs in Telegram.Bot project, I haven't merged that code into master yet.

@a-a-k Samples are working now.

SampleEchoBot is not working. Getting build error.


Configuration, folder history, and favorite folders on a per-project basis

I wish ANF's configuration was set up so I could have aliases, default directories, etc, all on a per-project basis.
It would also be nice to have a project-specific history of most-recently-used folders (not files) and a way to set project-specific favorite folders, both available in a "drop-down" directly in the ANF dialog.
The global configuration as it currently stands is much more limited.
I don't expect this is an easy change, but it would be really cool  :)

Settings are supported on a per project basis. See https://github.com/skuroda/Sublime-AdvancedNewFile#project-specific-settings.
A history of some sort would be possible I think, though not in the way you describe. There's now way (that I know of) to create a drop down menu from within the input field. That being said, I'll leave this open to investigate further.

Ah! It seems all plugins can have their configuration on a per-project basis then. That changes things.
Thank you for the great plugin.

Project-specific configuration combined with aliases is pretty sweet. Both my requests seem to have suddenly become less important. Thanks again.


Create a FHIR patient bundle for testing and script to add patient to SMART sandbox

An existing patient uploading script exists at https://github.com/AHRQ-CDS/AHRQ-CDS-Connect-PAIN-MANAGEMENT-SUMMARY/blob/master/src/utils/uploadTestPatients.js and we can use 2 example patients.
Suggestion 1
For instance:
https://github.com/AHRQ-CDS/AHRQ-CDS-Connect-PAIN-MANAGEMENT-SUMMARY/blob/fbb53d4cd35c07ed386211aa16e53ece41fb7a9d/src/utils/uploadTestPatients.js#L8-L14
can be changed to
const SMART_HEALTH_IT_ENDPOINT = 'https://r4.smarthealthit.org';
const MOONSHOT_ENDPOINT = 'http://moonshot-dev.mitre.org:4006/baseR4';

// R4
upload('R4', SMART_HEALTH_IT_ENDPOINT, path.join(__dirname, 'r4_test_patients'));
upload('R4', MOONSHOT_ENDPOINT, path.join(__dirname, 'r4_test_patients'));

where one can comment out the upload calls however they see fit.
If we want to reuse this script in our repo, additional dependencies would be added like so in package.json:
https://github.com/mcode/clinical-trial-matching-app/blob/a5ab398bcd056c8c76da2c8958150cf74c639fb3/package.json#L36
    "react-query": "^3.23.2",
    "request": "^2.34",
    "request-promise-native": "^1.0.9",
    "mkdirp": "^1.0.4"

And in the .gitignore:
https://github.com/mcode/clinical-trial-matching-app/blob/a5ab398bcd056c8c76da2c8958150cf74c639fb3/.gitignore#L19
.DS_Store
/test_patient_dump

Additionally, a ./src/utils/r4_test_patients directory must be created (this stores the JSON patient bundles).
Suggestion 2
Alternatively, one could

Clone the repo at https://github.com/AHRQ-CDS/AHRQ-CDS-Connect-PAIN-MANAGEMENT-SUMMARY
Install only the needed dependencies for running the patient upload script by running the command

yarn add request-promise-native request mkdirp

Change https://github.com/AHRQ-CDS/AHRQ-CDS-Connect-PAIN-MANAGEMENT-SUMMARY/blob/fbb53d4cd35c07ed386211aa16e53ece41fb7a9d/src/utils/uploadTestPatients.js#L8-L14
to

const SMART_HEALTH_IT_ENDPOINT = 'https://r4.smarthealthit.org';
const MOONSHOT_ENDPOINT = 'http://moonshot-dev.mitre.org:4006/baseR4';

// R4
upload('R4', SMART_HEALTH_IT_ENDPOINT, path.join(__dirname, 'r4_test_patients'));
upload('R4', MOONSHOT_ENDPOINT, path.join(__dirname, 'r4_test_patients'));

Add the desired FHIR Version 4 patient bundles to ./src/utils/r4_test_patients/
Run yarn upload-test-patients

I think the first suggestion makes sense for our needs.

I'll make a PR shortly then. Do you think it's a good idea for me to convert the script to TypeScript as well?

Yes please!


[SPARK-40044][SQL] Fix the target interval type in cast overflow errors

What changes were proposed in this pull request?
In the PR, I propose to fix the incorrect target type in the error message of the cast overflow. For example:
spark-sql> select CAST(9223372036854775807L AS INTERVAL YEAR TO MONTH);
org.apache.spark.SparkArithmeticException: [CAST_OVERFLOW] The value<PHONE_NUMBER>854775807L of the type "BIGINT" cannot be cast to "INTERVAL MONTH" due to an overflow.

The target type is "INTERVAL MONTH" instead of "INTERVAL YEAR TO MONTH".
Why are the changes needed?
To improve user experience with Spark SQL, and do not confuse users by incorrect error messages.
Does this PR introduce any user-facing change?
Yes, it changes user-facing error messages.
After the changes, for the example above:
spark-sql> select CAST(9223372036854775807L AS INTERVAL YEAR TO MONTH);
org.apache.spark.SparkArithmeticException: [CAST_OVERFLOW] The value<PHONE_NUMBER>854775807L of the type "BIGINT" cannot be cast to "INTERVAL YEAR TO MONTH" due to an overflow.

How was this patch tested?
By running new test:
$  build/sbt "test:testOnly *QueryExecutionErrorsSuite"

Merging to master. Thank you, @HyukjinKwon for review.


Fix typical usage in README

Update import statement in the typical usage shown in README.
Using the older import results in the following error:
Traceback (most recent call last):
File "./test-fdt.py", line 8, in
dtb = pyfdt.FdtBlobParse(infile)
AttributeError: 'module' object has no attribute 'FdtBlobParse'

@superna9999 Is this PR ready to merge/close?

Yes it's ok, thanks !


Promises

May be use promises here https://github.com/antirek/voicer/blob/master/handler.js#L173 ?

No. Now use npm async.


Example 1 simply not working.

Now TPL just create a short-running thread or it doesn't really treat it as an async one.
Or the continue doesn't work well when the task is already completed.
The delegate of Console.WriteLine doesn't work as expected.

https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/chaining-tasks-by-using-continuation-tasks

Thanks for reporting this issue, @crazygao. I apologize that it's taken so long to respond to you. The basic problem with the example -- as well as one other in the article -- is that it terminated before the continuation finished execution. We've addressed the issue in dotnet/samples#318 by adding a call to the Task.Wait method.


Tidy up extension, add support for trigger modes and info only

Adds support for different trigger modes, and a switch to control the exit code for gating or information only. Tidy up arg names, update README

Hi folks, just checking if we can get this merged ? I'm writing a blog post about Tilt which is kind of blocked behind these changes ..

Hi folks, just checking if we can get this merged ? I'm writing a blog post about Tilt which is kind of blocked behind these changes ..

@mattj-io : Going to merge as @landism is okay as is from previous comment.

@mattj-io : Going to merge as @landism is okay as is from previous comment.


scrolling concepts

[ ] initial canvas size matches scroll pane size
[ ] extend canvas by dropping classes near borders
[ ] extend the canvas when the whole path view screen is resized
[ ] extend canvas when scrolling out of current canvas (no scrollbars for that, but extending arrows)
[ ] only show extending arrows when cursor is near the borders of the scrolling pane

Tests to write:

[ ] center of scroller should equal center of scroll pane when initializing

Things to consider when resizing:

[ ] extend underlying scroller by difference in size, when the bounding box of class morphs is extended

Constraints:

Class Diagram Morph extent >= ScrollPane extent


add limit to getDuration() in spring function to avoid infinite loops

The way the getDuration() method in the spring() function is setup it doesn't have any way of stopping an infinite loop. I added a INTINITE_LOOP_LIMIT of 10,000 to stop possible infinite loop situations.

Shouldn't this be named INFINITE_LOOP_LIMIT (with an f instead of t)?

Also maybe it would be an idea to use Number.MAX_SAFE_INTEGER instead of 10,000?

I think there are times people would want an infinite loop, though...

While calculating the spring the for loop can sometimes encounter infinite loops, that cause the browser to freeze, I've run into this problem a couple times.

While calculating the spring the for loop can sometimes encounter infinite loops, that cause the browser to freeze, I've run into this problem a couple times.

That is true, but I hope there is an alternative method added, to allow things like my example, to work.

While calculating the spring the for loop can sometimes encounter infinite loops, that cause the browser to freeze, I've run into this problem a couple times.

That is true, but I hope there is an alternative method added, to allow things like my example, to work.

What you're looking for is different from what this pr is aiming to fix

While calculating the spring the for loop can sometimes encounter infinite loops, that cause the browser to freeze, I've run into this problem a couple times.

That is true, but I hope there is an alternative method added, to allow things like my example, to work.

What you're looking for is different from what this pr is aiming to fix, but yeah I agree with you, it would be cool if animejs supported blinking animation

Yeah, just making sure it doesn't break what I am using it for lol.

While calculating the spring easing, the for loop can sometimes encounter infinite loops that cause the browser to freeze, I've run into this problem a couple times. I choose 10,000 because it was the value that allowed for the most accurate spring easings while avoiding the browser freezing for extended periods of time.

Could you post the code which freezes the browser please? Maybe there's another solution to the problem.

@RafaelKr There was something wrong with this pr, it seems the branch repo the changes were located in were deleted, so, I had to recreate a new pr.


Unable to create firewall rule for the IP address ID=## as IP is not associated with any network and no networkId is passed in

Hi there,
Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.
Terraform Version
Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.
Terraform v0.11.3

provider.cloudstack v0.1.4

Affected Resource(s)
Please list the resources as a list, for example:

cloudstack_firewall

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.
Terraform Configuration Files
# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

# Full config at: https://gist.github.com/icornett/4bb51d43bf49891357f58cc39d09b618

resource "cloudstack_ipaddress" "k8s-ip" {
   network_id = "${cloudstack_network.k8s.id}"
   vpc_id     = "562142c9-5f70-4fd5-a4e1-eb73245011ac"
   is_portable   = false
}

resource "cloudstack_firewall" "k8s-firewall" {
   ip_address_id = "${cloudstack_ipaddress.k8s-ip.id}"
   managed       = true

   rule {
       cidr_list = ["<IP_ADDRESS>/0"]
       protocol  = "tcp"
       ports     = ["22", "2200-2202"]
   }
}

Debug Output
Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.
https://gist.github.com/icornett/4bb51d43bf49891357f58cc39d09b618
Panic Output
If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.
Expected Behavior
What should have happened?
Cloudstack Firewall should have built with passed-in IP address ID
Actual Behavior
What actually happened?

cloudstack_firewall.k8s-firewall: 1 error(s) occurred:

cloudstack_firewall.k8s-firewall: 1 error(s) occurred:

CloudStack API error 431 (CSExceptionErrorCode: 4350): Unable to create firewall rule for the IP address ID=25 as IP is not associated with any network and no networkId is passed in

Steps to Reproduce
Please list the steps required to reproduce the issue, for example:

terraform apply

Important Factoids
Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?
Cloudstack <IP_ADDRESS>
References
Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

Hi @icornett, it looks like you're using the wrong resource for your setup. It's not very clear from the docs (or from the CloudStack API docs for that matter), but the cloudstack_firewall resource only work for IP addresses associated with a guest network.
As you are using a VPC network, the solution is to connect a cloudstack_network_acl to your network and then use the cloudstack_network_acl_rule resource to configure your rules.
Let me know if this approach does work as expected...

Hi @svanharmelen, that did it!  That isn't very well documented anywhere, but that seems to be the way with Cloudstack in general.   Thanks for the assist, this can be closed.


[Analytics] Throttled requests per app

Description:
Throttled requests per app

Duplicated with https://github.com/wso2/product-apim/issues/1787


Revert "Release/182.0.0"

Reverts https://github.com/MetaMask/core/pull/4597/files
We need to redo this release since I missed some CI config/naming and this did not go out 🤦🏾 , apologies!

Yeah, again, sorry for this. Will retry.


Minor fixups vs tarball

The asv tarball is missing some files, the license file and an image file in the docs.
The publish_docs.sh script is obsolete, as the docs are on rtd.
Also, add links to Github & PyPi to the front page of the docs --- currently navigating to these is not so easy from the readthedocs page
(This PR is based on the merge-base of the stable&master, so should be mergeable to both. The v0.1.x and stable branches however don't seem to be in sync currently on github.)

Thanks.  Looks like it needs a rebase, then I think this is ready to merge.

Ok, merged


USHIFT-1845: Avoid overwriting existing build cache contents in S3 on upload

/lgtm

/override ci/prow/metal-periodic-test
The failure is not relevant for the change.


Lean HAMT implementation

Hey, merry Christmas
Great work on your data structures, love them :)
have you seen this:
https://bendyworks.com/leveling-clojures-hash-maps/
Maybe it's time for another fork of HAMT to top the benchmark ;) ?

Thanks. I had not heard about this and will investigate further after the holidays.
The current HAMT implementation doesn't even store the key value pairs together like the baseline they tested against. Some of the optimizations may be jvm specific but I will be interested to see if similarly impressive gains are shown across different JavaScript engines.

Hi,
I don't mean to reopen a dead issue here if it is, but I just came across this.
I've been working of champ/lean maps, which is still pretty far from production ready, but showing some promising benchmarks.
If your looking for a starting base or open to some collobaration let me know

@wishfoundry Cool to see someone looking into this. Let me know if there are any specific ways you think I may be able to help out


Minutes from Alibaba Test Contributions Meeting

Presentation from Alibaba team on next steps:

enable more platforms
new external test targets (netty, spring)
Unsafe Checker tool demo
Q&A about open perf testing

In our subsequent discussion, the following links/issues/enhancements were noted:

“AQA You Are Soaking in It” presentation from early 2020

External tests to consider adding: #172 (I have added netty and spring to this list, so we do not need a separate issue, just PRs to incorporate those)

Identify and prioritize open perf benchmarks: #1112

Add external_custom target (potentially getting help from students on this item): https://github.com/AdoptOpenJDK/openjdk-tests/issues/2076

Necessary enhancement to support vendor specific tests: https://github.com/AdoptOpenJDK/TKG/issues/115

Discussion/enhancement issue for discussing where best to contribute "unsafe checker" tool: https://github.com/AdoptOpenJDK/openjdk-tests/issues/2077

If I am missing key points, please add them as comments to this issue (which serves only as a way to capture notable parts of the discussion.
We can plan to meet regularly (monthly? or as needed), to discuss updates to open perf testing and tools, decisions/discussion on how best to provide control and config of certain tests that require multi-machine setup, improvements/ideas to stabilize external test targets, running tests via dynamic parallelization or any other topics that may be useful.  If we do meet regularly, we can consider it an AQAvit meeting for timezones that can not comfortably attend the bi-weekly Wednesday AQAvit meetings.

Create then close this issue as a record of today's discussion (with handy links to related issues).  Attendees invited to add any missing notes as comments to the closed issue.


[itk,libsamplerate,libsndfile] Apply some Visual Studio 2019 version 16.9 preview 1 workarounds

[libsamplerate,libsndfile] Update sources to libsndfile/ org on GitHub.
Note that the previous erikd/libsndfile is being forwarded by GitHub itself to libsndfile/libsndfile.
I checked that the tar.gz for libsamplerate match for the old and new sources.
[itk] Apply workaround for VS2019 version 16.9 nightly builds defining lrintf as an intrinsic.
Upstream has already fixed this.

itk test pass, error C2169 disappeared. Thanks~


qtbase: Remove overlapping PACKAGECONFIGs

Signed-off-by: Tariq Ansari<EMAIL_ADDRESS>

Fixes jira ticket https://luxproject.luxoft.com/jira/browse/OAI1209-271


[SPARK-17963][SQL][Documentation] Add examples (extend) in each expression and improve documentation with arguments

What changes were proposed in this pull request?
This PR proposes to change the documentation for functions. Please refer the discussion from https://github.com/apache/spark/pull/15513
The changes include

Re-indent the documentation
Add examples/arguments in extended where the arguments are multiple or specific format (e.g. xml/ json).

For examples, the documentation was updated as below:
Functions with single line usage
Before

pow
Usage: pow(x1, x2) - Raise x1 to the power of x2.
Extended Usage:
> SELECT pow(2, 3);
 8.0

current_timestamp
Usage: current_timestamp() - Returns the current timestamp at the start of query evaluation.
Extended Usage:
No example for current_timestamp.

After

pow
Usage: pow(expr1, expr2) - Raise expr1 to the power of expr2.
Extended Usage:
    Arguments:
      expr1 - a numeric expression.
      expr2 - a numeric expression.

    Examples:
      > SELECT pow(2, 3);
       8.0

current_timestamp
Usage: current_timestamp() - Returns the current timestamp at the start of query evaluation.
Extended Usage:
    No example/arguemnt for current_timestamp.

Functions with (already) multiple line usage
Before

approx_count_distinct
Usage: approx_count_distinct(expr) - Returns the estimated cardinality by HyperLogLog++.
    approx_count_distinct(expr, relativeSD=0.05) - Returns the estimated cardinality by HyperLogLog++
      with relativeSD, the maximum estimation error allowed.

Extended Usage:
No example for approx_count_distinct.

percentile_approx
Usage:
      percentile_approx(col, percentage [, accuracy]) - Returns the approximate percentile value of numeric
      column `col` at the given percentage. The value of percentage must be between 0.0
      and 1.0. The `accuracy` parameter (default: 10000) is a positive integer literal which
      controls approximation accuracy at the cost of memory. Higher value of `accuracy` yields
      better accuracy, `1.0/accuracy` is the relative error of the approximation.

      percentile_approx(col, array(percentage1 [, percentage2]...) [, accuracy]) - Returns the approximate
      percentile array of column `col` at the given percentage array. Each value of the
      percentage array must be between 0.0 and 1.0. The `accuracy` parameter (default: 10000) is
      a positive integer literal which controls approximation accuracy at the cost of memory.
      Higher value of `accuracy` yields better accuracy, `1.0/accuracy` is the relative error of
      the approximation.

Extended Usage:
No example for percentile_approx.

**After**

  - `approx_count_distinct`

    ```sql
    Usage:
        approx_count_distinct(expr[, relativeSD]) - Returns the estimated cardinality by HyperLogLog++.
          relativeSD defines the maximum estimation error allowed.

    Extended Usage:
        Arguments:
          expr - an expression of any type that represents data to count.
          relativeSD - a numeric literal that defines the maximum estimation error allowed.
    ```

  - `percentile_approx`

    ```sql
    Usage:
        percentile_approx(col, percentage [, accuracy]) - Returns the approximate percentile value of numeric
          column `col` at the given percentage. The value of `percentage` must be between 0.0
          and 1.0. The `accuracy` parameter (default: 10000) is a positive integer literal which
          controls approximation accuracy at the cost of memory. Higher value of `accuracy` yields
          better accuracy, `1.0/accuracy` is the relative error of the approximation.
          When `percentage` is an array, each value of the percentage array must be between 0.0 and 1.0.

    Extended Usage:
        Arguments:
          col - a numeric expression.
          percentage - a numeric literal or an array literal of numeric type that defines the
            percentile. For example, 0.5 means 50-percentile.
          accuracy - a numeric literal.

        Examples:
          > SELECT percentile_approx(10.0, array(0.5, 0.4, 0.1), 100);
           [10.0,10.0,10.0]
          > SELECT percentile_approx(10.0, 0.5, 100);
           10.0
    ```

## How was this patch tested?

Manually tested

**When examples are multiple**

```sql
spark-sql> describe function extended reflect;
Function: reflect
Class: org.apache.spark.sql.catalyst.expressions.CallMethodViaReflection
Usage: reflect(class, method[, arg1[, arg2 ..]]) - Calls a method with reflection.
Extended Usage:
    Arguments:
      class - a string literal that represents a fully-qualified class name.
      method - a string literal that represents a method name.
      arg - a boolean, string or numeric expression except decimal that represents an argument for
        the method.

    Examples:
      > SELECT reflect('java.util.UUID', 'randomUUID');
       c33fb387-8500-4bfa-81d2-6e0e3e930df2
      > SELECT reflect('java.util.UUID', 'fromString', 'a5cf6c42-0c85-418f-af6c-3e4e5b1328f2');
       a5cf6c42-0c85-418f-af6c-3e4e5b1328f2

When Usage is in single line
spark-sql> describe function extended min;
Function: min
Class: org.apache.spark.sql.catalyst.expressions.aggregate.Min
Usage: min(expr) - Returns the minimum value of `expr`.
Extended Usage:
    Arguments:
      expr - an expression of any type.

When Usage is already in multiple lines
spark-sql> describe function extended percentile_approx;
Function: percentile_approx
Class: org.apache.spark.sql.catalyst.expressions.aggregate.ApproximatePercentile
Usage:
    percentile_approx(col, percentage [, accuracy]) - Returns the approximate percentile value of numeric
      column `col` at the given percentage. The value of `percentage` must be between 0.0
      and 1.0. The `accuracy` parameter (default: 10000) is a positive integer literal which
      controls approximation accuracy at the cost of memory. Higher value of `accuracy` yields
      better accuracy, `1.0/accuracy` is the relative error of the approximation.
      When `percentage` is an array, each value of the percentage array must be between 0.0 and 1.0.

Extended Usage:
    Arguments:
      col - a numeric expression.
      percentage - a numeric literal or an array literal of numeric type that defines the
        percentile. For example, 0.5 means 50-percentile.
      accuracy - a numeric literal.

    Examples:
      > SELECT percentile_approx(10.0, array(0.5, 0.4, 0.1), 100);
       [10.0,10.0,10.0]
      > SELECT percentile_approx(10.0, 0.5, 100);
       10.0

When example/argument is missing
spark-sql> describe function extended rank;
Function: rank
Class: org.apache.spark.sql.catalyst.expressions.Rank
Usage:
    rank() - Computes the rank of a value in a group of values. The result is one plus the number
      of rows preceding or equal to the current row in the ordering of the partition. The values
      will produce gaps in the sequence.

Extended Usage:
    No example/argument for rank.

Test build #67733 has started for PR 15677 at commit 2b437fe.

cc @srowen, @rxin, @jodersky, @gatorsmile . I closed the previous one and reopened it here.

@gatorsmile I double-checked the type ones again and tried to describe the types more specifically. Could you please take another look?

BTW, I hope we can fix up all the minor comments together once as a final look if each does not block each other.

Test build #67733 has finished for PR 15677 at commit 2b437fe.

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

Merged build finished. Test PASSed.

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

Since this PR is 2000+ line changes, I am unable to quickly go over all of them. Normally, creating such a big PR is not welcomed, because it is hard for reviewers to read throught all the changes.
I hope my comments can trigger you to think more and fix all the related issues, instead of pointing them out by me one by one.
For example, my most recent comment is about the complex type support. Have you tried the nested types?
BTW, when my teammates do anything like this PR, I always tell them to write test cases if they are not 100% sure. Do not submit a PR without verification. I hope we can do the document changes more carefully, because the external users will not read the source codes. They might easily lose patience.

Hey @gatorsmile, I am not rushing to review and also I didn't mean to find every one. I meant I can wait for all the reviews and then sweep it if they are only minors and each does not block each other.
As I said, for testing, I have tested one by one when I was in doubt. I have tested most of them (I admit it wasn't all for every type). So, I guess mostly the argument types were correct. The recent changes include minor changes such as except map.
In the case of this PR, basically, it introduces new sections in documentation. I guess fixing the same instances in single PR is reasonable. At least, I asked @rxin and @srowen first before/after making this PR. I also said several times this would be big and I guess I got approved.
There are always rooms for improvements for changes. We can't make something perfect at once. Also, I guess we have still a lot time to fix them more. For example, we can add all the test cases in a folllowup. This would even not be released right after this PR. Other guys still can take a look for this and submit another PR.
Please let us just focus on this topic.

I am feeling sorry, but I have to say I will not merge the PR if the quality is not good enough. Maybe my standard is too high. If the other Committers have different opinions, they can merge it without considering my comments.
I do not think the changes are minor. Without except map, the argument descriptions are incorrect. When we writing the document like this, we should be more careful.
Writing the documents are the same as writing the source codes. Sometimes, documents might be more important, because users might read it. If the documents do not match the behaviors, users normally first doubt the quality.

@gatorsmile OK, so, your concern is about potentially inaccurate types and typos. If you are really worried, maybe I can split this PR into several ones.

Not sure whether the other reviewers have the same feeling like me. 2000+ LOC is too big, imo. The focus of this PR should be on the newly added argument types, descriptions and examples.

@gatorsmile yes, this is why I suggested earlier that we stop and commit the changes we had in the last PR. We have to break this up to make it manageable in this case, because of the size. There are important doc fixes here that we do need to commit. You have indeed asked for a different additional set of logical changes, and now we're mostly down that path, which has led to one big bang PR. I don't think it's useful to question now whether it should be committed!
We can commit a change that is a coherent improvement, which does not make the docs worse. We do not have to commit a change that improves or even fixes everything in the existing docs. Some of the problems you're highlighting were there already. Some are improvements to new docs, where there was simply no information before.
Re-skimming this large change, it seems like it makes a coherent improvement to the docs (modulo a few more fixes you suggested). If the issue is down to type info, do you believe anything here is actually wrong-er than it was before? If so, let's zero in on those essential changes and make them, and merge this. If not let's merge this. If there is more to discuss, it will be much easier to address in a second pass, I think. We won't have a release in between the two PRs.

@srowen If the newly added contents are not right, should we commit them and fix them later?
If this PR does not add argument descriptions, I am fine to merge it (after one more pass) because this is an incremental improvement, as what you said.

How about splitting this PR to two parts? One is the document improvement (fixing typos and adding examples). Another is to add argument descriptions (many parts are not clearly defined. More discussions are needed).

@gatorsmile, I guess the changes here are roughly correct and accurate and make sense. This does not mean "not right" or "wrong".
For example, if users run describe function extended reverse; (the one you pointed out right above)
Before
Function: reverse
Class: org.apache.spark.sql.catalyst.expressions.StringReverse
Usage: reverse(str) - Returns the reversed given string.
Extended Usage:
> SELECT reverse('Spark SQL');
 'LQS krapS'

After
Function: reverse
Class: org.apache.spark.sql.catalyst.expressions.StringReverse
Usage: reverse(str) - Returns the reversed given string.
Extended Usage:
    Arguments:
      str - a string expression.

    Examples:
      > SELECT reverse('Spark SQL');
       LQS krapS

Do you think this is completely incorrect and what users might easily lose patience at? I guess this is an improvement. Sure, we can improve them more and make them more correct but I guess this might not be the reason to block this change.

Could I please ask your opinion @rxin ? I would rather simply follow the majority.

Test build #67779 has started for PR 15677 at commit b46404b.

Test build #67779 has finished for PR 15677 at commit b46404b.

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

Merged build finished. Test PASSed.

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

    val df2 = Seq((2.0f, 345)).toDF("a", "b")
    checkAnswer(
      df2.select(reverse($"a"), reverse($"b")),
      Row("0.2", "543"))

The argument of reverse is not limited to String. Thus, str - a string expression. is not right.
However, the complex type we should block. We also need to fix it in the code.

Based on my review in this PR, I think we need to resolve the following three major issues when we document the argument type:

First, implicit type casting should be clearly explained when we document the argument types. I am not comfortable if we just let external users figure it out by themselves. They do not know the rules.

Second, null handling of function arguments should also be documented. For most function arguments, it is null intolerant. However, we still have a few exceptions. For example, sentences.

Third, the arguments also need to use different terms for literal/constant, foldable expressions and non-foldable expressions.

@gatorsmile I suggest we handle all of that as a follow-on PR, because this has already become a series of good related changes that has nevertheless become a very big change. Each of those were existing issues in the docs so I don't think this makes it worse.

I am still uncomfortable about the newly added contents regarding the argument types, if we do not resolve the above three general issues.
If this were merged, basically, in the follow-up PR, we need to rewrite almost all the argument types.

That's fine, they can be changed soon after. Put it this way: do you feel the same argument applies separately to the existing documentation? if it wasn't a 'regression' in this PR i think it's separable.

If the existing way to document argument types is not right, why we still want to merge it into the master branch?
Why not removing them from this PR, if we care the PR grows too big?

The argument would be: because it's not less-right? (I'm not even judging whether your points are right but I presume they are.)
I think we did originally not have nearly this much change regarding types and I wanted to merge the last PR, so yes I had the same question before. But we're here now, so what's the simplest path forward?
The review has been dragging on, which is OK if it's converging, but now you're suggesting you want to abandon this change. I don't think that's the right outcome. I'd rather resolve the stall by breaking down the change instead. I don't hear that you're arguing that the docs are wrong, just as incomplete in some ways as they were before.
More practically, it's hard for you to ask for a hundred changes in comments. It's hard for me to track whether the changes affect what I've previously reviewed. I think we have to draw this to a checkpoint and so I'm asking the narrower question, whether this is actually making anything worse? it makes a number of different things better, according to its original purpose.

IMO, when we add the argument types in the function descriptions, we should deliver the corresponding test cases in the same PRs. Otherwise, I do not think how we can know the argument types are right or wrong, especially when we have to consider the implicit type conversion. Strictly speaking, the newly added argument types are wrong.
I think we just need to remove the argument types from this PR. That is just part of this PR.

https://github.com/apache/spark/pull/15690 is to resolve the behaviors of a few string-to-string expressions, including reverse. After rethinking about it, I think we should not support implicit casting for these expressions. Thus, we need to fix the source codes.
Before documenting the argument types, we really need to check the behaviors. If anything is inappropriate, we should correct it. Please remember to deliver the document changes with the corresponding test cases.
Generally, discipline is needed for document changes, if we really want to attract more enterprise customers to use Spark in their production systems.

However, the complex type we should block. We also need to fix it in the code.

It does not support complex types already but only AtomicType[1].
spark-sql> SELECT reverse(array(1));
Error in query: cannot resolve 'reverse(array(1))' due to data type mismatch: argument 1 requires string type, however, 'array(1)' is of array<int> type.; line 1 pos 7;
'Project [unresolvedalias(reverse(array(1)), None)]
+- OneRowRelation$

spark-sql> SELECT reverse(map(1, 1));
Error in query: cannot resolve 'reverse(map(1, 1))' due to data type mismatch: argument 1 requires string type, however, 'map(1, 1)' is of map<int,int> type.; line 1 pos 7;
'Project [unresolvedalias(reverse(map(1, 1)), None)]
+- OneRowRelation$

spark-sql> SELECT reverse(struct(1, 1));
Error in query: cannot resolve 'reverse(struct(1, 1))' due to data type mismatch: argument 1 requires string type, however, 'struct(1, 1)' is of struct<col1:int,col2:int> type.; line 1 pos 7;
'Project [unresolvedalias(reverse(struct(1, 1)), None)]
+- OneRowRelation$

spark-sql> SELECT reverse(1);
1
Time taken: 0.049 seconds, Fetched 1 row(s)
spark-sql> SELECT reverse(12);
21
Time taken: 0.053 seconds, Fetched 1 row(s)
spark-sql> SELECT reverse(12.0D);
0.21
Time taken: 0.046 seconds, Fetched 1 row(s)
spark-sql> SELECT reverse(12BD);
21
Time taken: 0.035 seconds, Fetched 1 row(s)
spark-sql> SELECT reverse(12L);
21
Time taken: 0.034 seconds, Fetched 1 row(s)
spark-sql>

[1]https://github.com/apache/spark/blob/39e2bad6a866d27c3ca594d15e574a1da3ee84cc/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/analysis/TypeCoercion.scala#L685-L720

I guess we can improve them in followups if a change does not make something worse. This introduces a general format to follow too.
Can I just follow the majority if this can't be unanimous - @rxin?

Sorry, I am confusing the merging standards. Why can we accept merging something incorrect?
Just like reverse, to the external users, the argument type of str is not a string expression. How can our users know some types are implicitly casted but some other types are not able to cast? This is not the only example. We have many cases like this.
Anyway, if this PR is merged, I hope we keep the same standard in the other PRs. Based on my observations, we reversed multiple PRs that improved the codes but did not perfectly resolved the problem.

My answer to that is https://github.com/apache/spark/pull/15677#issuecomment-257137604. It seems the discussion goes in a loop.

I did not say the other changes are wrong. The only concern is argument types. Like what I said above, if we remove the newly added argument types, I am fine to merge this as a document improvement.

@gatorsmile Taking your example, before, the user gets no information at all about the type, except that it looks maybe string-like. Now at least we say it's a 'string expression' which suggests, correctly, that you can't send it a number. I understand that 'string expression' isn't tightly defined. But it wasn't defined at all before; it's 'incorrect' now, if you like, and less so after.
Are you essentially saying remove all of the "Arguments" sections? If that would unblock the discussion, OK, that's an option. @HyukjinKwon how do you feel about that. @gatorsmile would you be willing to follow this up then with a PR to restore Arguments sections with whatever you believe should be said about them?
It's a big change, it's an important change, I am looking forward to getting these updates in place.

I am fine and willing to follow the majority. We have anyway the same goal. I hope the followup is open as soon as possible after this one though if we decide to remove argument parts here.

@srowen @HyukjinKwon I can submit PRs to add the argument sections and cc you to review. However, I might not submit a huge PR for adding all of them in the same one. Like what I said before, I would like to add the arguments with the corresponding test cases, which can help reviewers understand whether the argument types are right. In addition, it can also capture the potential changes that could affect the external users.
Of course, if @HyukjinKwon wants to do it, I also can review it at my best.

To be honest I myself would never submit such a large pr without strong likelihood of it just getting committed in one or two shots; otherwise it is just impossible to get it merged with conflicts piling up everyday.

BTW this is a cool change. We should try to get it in for 2.1.0.

Okay, @gatorsmile could you maybe submit a small one first please? Will refer yours and then I can work together (we can divide the files or packages to deal with I guess).

@HyukjinKwon Sure, I can try it.
Actually, we might need to find multiple typical function APIs as examples to discuss what are the best way to document/specify the argument/parameter types. If all the people agree on it, we can continue to enhance the remaining APIs.

Alright, then will try to get rid of the arguments part. Thank you all very much sincerely and I apologise the noise I caused. @gatorsmile I will keep in mind you comments too.

Thank you for your work!
I might offend you in my previous comments. That's certainly not my intention. Previously, I worked for the infrastructure software on mainframe. IMO, Spark is also an essential infrastructure software. Sometimes, I am pretty conservative on the changes we made in Spark. I always believe the quality of a software is dependent on the test case coverage. Thus, when I review your changes, I normally try it and verify it in my local system. Anyway, let us do our best to improve Spark. Thanks!

Test build #67891 has started for PR 15677 at commit 7c2959d.

OK, if this is basically the same change we've been reviewing minus the 'arguments' sections, then LGTM. I'll skim once more.

Oh, let me please push another one.

Test build #67892 has started for PR 15677 at commit 57153d6.

(PR description is updated too.) Thank you @srowen.

Test build #67891 has finished for PR 15677 at commit 7c2959d.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #67900 has started for PR 15677 at commit 0bfbaee.

Test build #67892 has finished for PR 15677 at commit 57153d6.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class Skewness(child: Expression) extends CentralMomentAgg(child)

Merged build finished. Test PASSed.

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

Test build #67900 has finished for PR 15677 at commit 0bfbaee.

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

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

Merged build finished. Test PASSed.

I finished the last pass. Thanks for your work!

Test build #67946 has started for PR 15677 at commit a6b50eb.

Test build #67946 has finished for PR 15677 at commit a6b50eb.

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

Merged build finished. Test PASSed.

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

Test build #67962 has started for PR 15677 at commit b2fb5e6.

Test build #67962 has finished for PR 15677 at commit b2fb5e6.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

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

Merged build finished. Test FAILed.

Test build #67964 has started for PR 15677 at commit d25abca.

Test build #67964 has finished for PR 15677 at commit d25abca.

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

Merged build finished. Test PASSed.

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

@gatorsmile @HyukjinKwon do you both feel like this is ready to merge?

Thanks for asking. I think yes it is ready.

LGTM except one minor comment.
Thanks for your work!

Test build #68027 has started for PR 15677 at commit cd0c810.

Test build #68031 has started for PR 15677 at commit 4ed9d03.

Thanks @gatorsmile and @srowen. It seems ready.

Test build #68033 has started for PR 15677 at commit 6ad2068.

LGTM pending test.

Test build #68031 has finished for PR 15677 at commit 4ed9d03.

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

Merged build finished. Test PASSed.

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

Test build #68033 has finished for PR 15677 at commit 6ad2068.

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

Merged build finished. Test PASSed.

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

Test build #68027 has finished for PR 15677 at commit cd0c810.

This patch passes all tests.
This patch does not merge cleanly.
This patch adds no public classes.

Build finished. Test PASSed.

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

(https://github.com/apache/spark/pull/15677#issuecomment-258050659 was on the past commit. I resolved the conflicts twice.)

Merging to master and 2.1! Thanks!

@HyukjinKwon why did we add backticks to surround all parameters? It looks pretty weird actually.

Some of them already had backricks in the description and others did not. Matching it up with backticks was initially suggested by https://github.com/apache/spark/pull/15513#discussion_r84820066. I could not find the concrete reason to not follow. I can remove all of them if you confirm.

Normally, most RDBMS docs are using Italic fonts for the parameter/argument names. Linux man is using underscore to highlight argument names in descriptions. I also saw another way
``expr1''

I do not know which ways are better in our function descriptions.

These function docs are printed onto the console.

True. That is why I do not know which is the best way for us to show the argument/parameter names.


Updated README

Fixed this-
https://github.com/MarkPieszak/aspnetcore-angular2-universal/issues/114

Thank you!! 💯


Cannot import settings

File -> Import has no function or effect.
I can export settings without a problem, but when I go File -> Import, nothing happens.
Running 1.0.11-alpha

Ope, had a bad line in there, good find.  Fixed in v1.0.12-alpha


Feature Request: Add option to use <iframe> to edit full page

Currently, the editor inherits all CSS on the page where it is added. If shown in an "admin" area, it's possible some CSS will reach in to the editor causing undesired side-effects.
If you use an <iframe> for the editing area, you can get not only 1) better sandboxing, but also 2) full-page editing.
It would be cool to see this editor support full page editing, where it can accept a <!doctype html><html>...</html> value and preserve the entire structure.

Hi @sirlancelot
Does this mean that the "iframe" should cover the all area of the editor?

In the implementation I've seen (CKEditor), the content under edit is in an iframe. All other UI/Editing elements surround the iframe.

Yup, I understand.
The old version was <iframe>.
I'll add an <iframe> mode to the option.
Thank you. 👍

Here's an example: https://www.froala.com/wysiwyg-editor/examples/full-page

Hi @sirlancelot
Updated in v2.19.0
Thank you : )


Update MD file on new branch 2017-24-13_15-11-07

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestCon.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Refine handling of illegal characters in userinfo

Coverage increased (+0.007%) to 87.891% when pulling 4dede44bfd89c303c179dfde3dd1321e3b21eed9 on validator:illegal-chars-in-userinfo-update into 1e647f6bfd1f2a95b71b59d41f010ce14dbf8c71 on smola:master.

@sideshowbarker Thanks!
Would you mind adding a test for this in ParseIssueTest? I'm about to push a major rewrite of the parser and I'm having a hard time maintaining validation errors.

@smola I added a test for this back at https://github.com/smola/galimatias/commit/5e68451a0e8b3f7175ff3f5330fb356d098e53d4#diff-d044dce65d9dfb982ad24b58dabeb501. So that test is now already on the master branch at https://github.com/smola/galimatias/blob/master/src/test/resources/data/urltestdata_whatwg.txt#L331 (the last test in that file).
Should I also add it in ParseIssueTest?
Anyway, to be clear: That test passes both before and after this change. In other words, the patch in this PR doesn’t change the behavior of the existing test when run under the test harness here.
However, it can change the behavior of tests run by consuming code. For example, the test suite I use for the HTML checker (validator) has the following test: https://github.com/web-platform-tests/wpt/blob/master/conformance-checkers/html/elements/a/href/userinfo-username-contains-pile-of-poo-novalid.html. When I run that test without the patch in this PR/branch applied, it incorrectly reports the problem character as "?". But when I run that test with the patch applied, it correctly reports the problem character as "💩".

OK, added a test in the amended commit  https://github.com/smola/galimatias/pull/70/commits/669641291115a07b5158ce3719a0241d7460d92 and (force-)pushed to the branch