Fix Sym=False,  new checkpoint_format = gptq_v2

@qwopqwop200  This is the rebase of your PR at #559 with some modifications. Should be ready soon after we verify quantize, inference, and add some tests.
Reason For PR:
sym=False was practically unusable due to post-quantization avg_loss per layer/PPL vs sym=True . @qwopqwop200 fixed the bad/suboptimal math. Now sym=False will most likely match or decrease avg_loss/layer vs sym=True and improve post-quant PPL for many models.
Core Changes:

Rebase PR #559 with main: allow usable sym=False quantization and use checkpoint_format=gptq_v2 to store new checkpoint format. Compat runtime dynamic convert of all checkpoint_format=gptq to gptq_v2 on load.

Misc Changes not directly related to sym=False code:

Complete Todo: Use accelerate 0.29.2 to load checkpoint.
Consistency: Move cohere/starcoder2 to 4.39.0 release check
Usability: Catch and alert user on how to fix quant/torch error caused by low damp/nsamples #572 as this happens much more frequently than I had expected. Ran into 2-3 instances of this error on multiple models during testing for this PR when using low nsamples  + low damp=0.005 to speed up quants.
Simplify: optimized packing regression alert message/code to user
Feature: Quant Stat Log 1/2:  store per layer quant stats (layer #, module name, avg loss, duration)  in dict/slice and return to user va quant_log = model.quantize()
Feature: Quant Stat Log 2/2:  pass saved quant_log to quantize(quant_log=saved_quant_log) to generate auto-avg_loss diff in progress. Sample diff output in later messages of this discussion.
Usability: Use tqdm for layer loop so users can have an estimate of quant remaining time.

TODO:

[x] Add sym=False tests
[x] Validate and fix failing tests
[x] Failed: Check if third party vllm/sglang needs kernel modification for the new gptq_v2 format
[x] Check if third party vllm/sglang needs kernel modification for the new gptq (v1) format using sym=False in this PR

PASSING TESTS:

[x] Compat: vllm/sglang compatible  with gptq (v1) generated with this PR
[x] Compat load of checkpoint_format=gptq(v1)
[x] sym=False consistently generate lower avg_loss than sym=True
[x] Regression Test: sym=True in PR generates same math/avg_loss for layers as sym=True in main
[x] test_serialization.py
[x] test_quantization.py
[x] test_shared_loading.py
[x] test_awq_compatibility_generation.py  (note: awq cache generated by main is not compatible with pr. fixed with version file name adding v2)
[x] test_q4.py

FAILING TESTS:

[x] compat: vllm/sglang not compatible gptq_v2
[x] test_triton.py (never got this to work on main)
[x] test_repacking.py (never got this to work on main)

Original PR #559 notes duplicated here for ref:

[x]  check work marlin
[x]  check work exllama
[x]  check work exllama2
[x]  check work qigen
[x]  check work triton
[x]  check work cuda
[x]  ~check work cuda old~(There is a bug in autogptq's main unrelated to this pr, so it cannot be confirmed.)
[x]  check work cuda pytorch
[x]  check work cuda old pytorch
[x]  check support old version save
[x]  check support old version load
[x]  check support new version save
[x]  check support new version load

I am removing this line because it is not only computationally unnecessary, but also makes sym=False impossible. However, it breaks backwards compatibility, so I making it the default to use the old save format.
related pr
#354
#325
I removed the following line: https://github.com/AutoGPTQ/AutoGPTQ/blob/main/auto_gptq/nn_modules/qlinear/qlinear_cuda.py#L169 This is an unnecessary line. And this line makes it impossible to sym='False' If sym='False' I get a reduction in ppl.
opt-125m(act-order)	Bits	group-size	Wikitext2
sym=True	4	128	29.875
sym=False	4	128	29.221
llama2(act-order)	Bits	group-size	Wikitext2
sym=True	4	128	5.254
sym=False	4	128	5.214

Misc Changes (wip notes) not directly related to sym=False code:

Safetensor forced on save_pretrain() + save_quantized(). removed .bin option.
Use accelerate 0.29.2 to load checkpoint. Remove todo
Move cohere/starcoder2 to 4.39.0 release check
Catch and alert user on how to fix quant/torch error caused by low damp/nsamples

TODO:

Add tests
Validate and fix failing tests
Check if third party vllm/sglang needs kernel modification for the new gptq_v2 format

TinyLlama 1.1B sym=True
+---------+------------------+------------+----------+-----------------+-------------+
|   layer | name             |   avg_loss |     time |   diff_avg_loss |   diff_time |
+=========+==================+============+==========+=================+=============+
|       1 | self_attn.k_proj |   0.006130 | 0.585682 |        0.003079 |   -0.599414 |
+---------+------------------+------------+----------+-----------------+-------------+
|       1 | self_attn.v_proj |   0.000175 | 0.463799 |        0.000033 |   -0.609846 |
+---------+------------------+------------+----------+-----------------+-------------+
|       1 | self_attn.q_proj |   0.010899 | 0.471033 |        0.005346 |   -0.425677 |
+---------+------------------+------------+----------+-----------------+-------------+
|       1 | self_attn.o_proj |   0.000005 | 0.470546 |        0.000001 |   -0.652694 |
+---------+------------------+------------+----------+-----------------+-------------+
|       1 | mlp.up_proj      |   0.005891 | 0.471234 |        0.001170 |   -0.642720 |
+---------+------------------+------------+----------+-----------------+-------------+
|       1 | mlp.gate_proj    |   0.006253 | 0.473800 |        0.001450 |   -0.630586 |
+---------+------------------+------------+----------+-----------------+-------------+
|       1 | mlp.down_proj    |   0.000042 | 1.307003 |        0.000009 |   -1.763714 |
+---------+------------------+------------+----------+-----------------+-------------+
|       2 | self_attn.k_proj |   0.029761 | 0.470537 |        0.011130 |   -0.630198 |
+---------+------------------+------------+----------+-----------------+-------------+
|       2 | self_attn.v_proj |   0.001209 | 0.467803 |        0.000209 |   -0.617392 |
+---------+------------------+------------+----------+-----------------+-------------+
|       2 | self_attn.q_proj |   0.067034 | 0.470898 |        0.020041 |   -0.430467 |
+---------+------------------+------------+----------+-----------------+-------------+
|       2 | self_attn.o_proj |   0.000054 | 0.464447 |        0.000011 |   -0.616824 |
+---------+------------------+------------+----------+-----------------+-------------+
|       2 | mlp.up_proj      |   0.013213 | 0.473601 |        0.002401 |   -0.613731 |
+---------+------------------+------------+----------+-----------------+-------------+
|       2 | mlp.gate_proj    |   0.014810 | 0.469599 |        0.002817 |   -0.609236 |
+---------+------------------+------------+----------+-----------------+-------------+
|       2 | mlp.down_proj    |   0.000067 | 1.304770 |        0.000014 |   -1.699867 |
+---------+------------------+------------+----------+-----------------+-------------+
|       3 | self_attn.k_proj |   0.027362 | 0.465101 |        0.007338 |   -0.615543 |
+---------+------------------+------------+----------+-----------------+-------------+
|       3 | self_attn.v_proj |   0.000914 | 0.465002 |        0.000160 |   -0.613301 |
+---------+------------------+------------+----------+-----------------+-------------+
|       3 | self_attn.q_proj |   0.057088 | 0.468296 |        0.011540 |   -0.478751 |
+---------+------------------+------------+----------+-----------------+-------------+
|       3 | self_attn.o_proj |   0.000079 | 0.468615 |        0.000015 |   -0.612965 |
+---------+------------------+------------+----------+-----------------+-------------+
|       3 | mlp.up_proj      |   0.024809 | 0.470201 |        0.004419 |   -0.614573 |
+---------+------------------+------------+----------+-----------------+-------------+
|       3 | mlp.gate_proj    |   0.027832 | 0.471135 |        0.004975 |   -0.604681 |
+---------+------------------+------------+----------+-----------------+-------------+
|       3 | mlp.down_proj    |   2.708260 | 1.299222 |        1.965734 |   -1.705520 |
+---------+------------------+------------+----------+-----------------+-------------+
|       4 | self_attn.k_proj |   0.036803 | 0.469426 |        0.006950 |   -0.608829 |
+---------+------------------+------------+----------+-----------------+-------------+
|       4 | self_attn.v_proj |   0.001792 | 0.464624 |        0.000247 |   -0.614279 |
+---------+------------------+------------+----------+-----------------+-------------+
|       4 | self_attn.q_proj |   0.085306 | 0.469892 |        0.015617 |   -0.479200 |
+---------+------------------+------------+----------+-----------------+-------------+
|       4 | self_attn.o_proj |   0.000033 | 0.466727 |        0.000008 |   -0.613243 |
+---------+------------------+------------+----------+-----------------+-------------+
|       4 | mlp.up_proj      |   0.034699 | 0.469619 |        0.005476 |   -0.615357 |
+---------+------------------+------------+----------+-----------------+-------------+
|       4 | mlp.gate_proj    |   0.040107 | 0.467804 |        0.006557 |   -0.611297 |
+---------+------------------+------------+----------+-----------------+-------------+
|       4 | mlp.down_proj    |   0.000104 | 1.309098 |        0.000017 |   -1.697408 |
+---------+------------------+------------+----------+-----------------+-------------+
|      10 | self_attn.k_proj |   0.048844 | 0.468561 |        0.008955 |   -0.608376 |
+---------+------------------+------------+----------+-----------------+-------------+
|      10 | self_attn.v_proj |   0.003229 | 0.463883 |        0.000639 |   -0.612935 |
+---------+------------------+------------+----------+-----------------+-------------+
|      10 | self_attn.q_proj |   0.123073 | 0.469848 |        0.024918 |   -0.488955 |
+---------+------------------+------------+----------+-----------------+-------------+
|      10 | self_attn.o_proj |   0.000151 | 0.467359 |        0.000032 |   -0.611210 |
+---------+------------------+------------+----------+-----------------+-------------+
|      10 | mlp.up_proj      |   0.076759 | 0.470483 |        0.014432 |   -0.612712 |
+---------+------------------+------------+----------+-----------------+-------------+
|      10 | mlp.gate_proj    |   0.112788 | 0.468013 |        0.021772 |   -0.605751 |
+---------+------------------+------------+----------+-----------------+-------------+
|      10 | mlp.down_proj    |   0.000636 | 1.312896 |        0.000129 |   -1.661242 |
+---------+------------------+------------+----------+-----------------+-------------+
|      22 | self_attn.k_proj |   0.057187 | 0.461225 |        0.012757 |   -0.069699 |
+---------+------------------+------------+----------+-----------------+-------------+
|      22 | self_attn.v_proj |   0.021670 | 0.461217 |        0.003897 |   -0.080796 |
+---------+------------------+------------+----------+-----------------+-------------+
|      22 | self_attn.q_proj |   0.170942 | 0.463462 |        0.044763 |   -0.073541 |
+---------+------------------+------------+----------+-----------------+-------------+
|      22 | self_attn.o_proj |   0.007679 | 0.468042 |        0.001327 |   -0.068797 |
+---------+------------------+------------+----------+-----------------+-------------+
|      22 | mlp.up_proj      |   0.324943 | 0.464848 |        0.071946 |   -0.067675 |
+---------+------------------+------------+----------+-----------------+-------------+
|      22 | mlp.gate_proj    |   0.516380 | 0.461897 |        0.114707 |   -0.074716 |
+---------+------------------+------------+----------+-----------------+-------------+
|      22 | mlp.down_proj    |   0.653858 | 1.284941 |        0.157109 |   -0.211105 |
+---------+------------------+------------+----------+-----------------+-------------+

TinyLlama 1.1B sym=True + checkpoint_format=gptq_v2 of PR (diff is vs sym=True of main)
Regression test passed. There is no math/avg_loss diff between PR and main when sym=True.
+---------+------------------+------------+----------+-----------------+-------------+
|   layer | name             |   avg_loss |     time |   diff_avg_loss |   diff_time |
+=========+==================+============+==========+=================+=============+
|       1 | self_attn.k_proj |   0.406458 | 0.628311 |        0.000000 |    0.000592 |
+---------+------------------+------------+----------+-----------------+-------------+
|       1 | self_attn.v_proj |   0.002031 | 0.522467 |        0.000000 |    0.006760 |
+---------+------------------+------------+----------+-----------------+-------------+
|       1 | self_attn.q_proj |   0.503623 | 0.514812 |        0.000000 |    0.005269 |
+---------+------------------+------------+----------+-----------------+-------------+
|       1 | self_attn.o_proj |   0.000061 | 0.522506 |        0.000000 |    0.020049 |
+---------+------------------+------------+----------+-----------------+-------------+
|       1 | mlp.up_proj      |   0.108624 | 0.522778 |        0.000000 |    0.008349 |
+---------+------------------+------------+----------+-----------------+-------------+
|       1 | mlp.gate_proj    |   0.115655 | 0.520952 |        0.000000 |    0.013677 |
+---------+------------------+------------+----------+-----------------+-------------+
|       1 | mlp.down_proj    |   0.000160 | 1.442813 |        0.000000 |    0.029875 |
+---------+------------------+------------+----------+-----------------+-------------+
|      11 | self_attn.k_proj |   1.037582 | 0.513118 |        0.000000 |    0.014547 |
+---------+------------------+------------+----------+-----------------+-------------+
|      11 | self_attn.v_proj |   0.064296 | 0.510034 |        0.000000 |    0.011178 |
+---------+------------------+------------+----------+-----------------+-------------+
|      11 | self_attn.q_proj |   2.442628 | 0.510062 |        0.000000 |    0.012037 |
+---------+------------------+------------+----------+-----------------+-------------+
|      11 | self_attn.o_proj |   0.005665 | 0.513529 |        0.000000 |    0.013509 |
+---------+------------------+------------+----------+-----------------+-------------+
|      11 | mlp.up_proj      |   1.633932 | 0.519150 |        0.000000 |    0.015929 |
+---------+------------------+------------+----------+-----------------+-------------+
|      11 | mlp.gate_proj    |   2.260344 | 0.515065 |        0.000000 |    0.010460 |
+---------+------------------+------------+----------+-----------------+-------------+
|      11 | mlp.down_proj    |   0.012365 | 1.441533 |        0.000000 |    0.050790 |
+---------+------------------+------------+----------+-----------------+---------
|      21 | self_attn.k_proj |   1.126530 | 0.511904 |        0.000000 |    0.006600 |
+---------+------------------+------------+----------+-----------------+-------------+
|      21 | self_attn.v_proj |   0.337632 | 0.512384 |        0.000000 |    0.004558 |
+---------+------------------+------------+----------+-----------------+-------------+
|      21 | self_attn.q_proj |   3.222927 | 0.514188 |        0.000000 |    0.004995 |
+---------+------------------+------------+----------+-----------------+-------------+
|      21 | self_attn.o_proj |   0.056764 | 0.515278 |        0.000000 |    0.005255 |
+---------+------------------+------------+----------+-----------------+-------------+
|      21 | mlp.up_proj      |   6.612084 | 0.518280 |        0.000000 |    0.000549 |
+---------+------------------+------------+----------+-----------------+-------------+
|      21 | mlp.gate_proj    |   8.599123 | 0.514044 |        0.000000 |    0.000147 |
+---------+------------------+------------+----------+-----------------+-------------+
|      21 | mlp.down_proj    |   0.427881 | 1.425859 |        0.000000 |    0.011282 |
+---------+------------------+------------+----------+-----------------+-------------+
|      22 | self_attn.k_proj |   1.190292 | 0.512079 |        0.000000 |    0.002728 |
+---------+------------------+------------+----------+-----------------+-------------+
|      22 | self_attn.v_proj |   0.454321 | 0.512852 |        0.000000 |    0.006104 |
+---------+------------------+------------+----------+-----------------+-------------+
|      22 | self_attn.q_proj |   3.392396 | 0.512543 |        0.000000 |    0.000779 |
+---------+------------------+------------+----------+-----------------+-------------+
|      22 | self_attn.o_proj |   0.098364 | 0.521686 |        0.000000 |    0.010890 |
+---------+------------------+------------+----------+-----------------+-------------+
|      22 | mlp.up_proj      |   7.234830 | 0.516273 |        0.000000 |    0.000210 |
+---------+------------------+------------+----------+-----------------+-------------+
|      22 | mlp.gate_proj    |  11.574709 | 0.510233 |        0.000000 |    0.000868 |
+---------+------------------+------------+----------+-----------------+-------------+
|      22 | mlp.down_proj    |   2.122912 | 1.403076 |        0.000000 |   -0.021529 |
+---------+------------------+------------+----------+-----------------+-------------+

@qwopqwop200  The cuda old tests was not passing was likely caused by caching of auto-marlin conversion. It also failed for me in test_q4 and magically disappeared when I updated the cache file name so caches from pre-pr is never loaded.
@fxmarty  The caching of dyamic awq/marlin processing is becoming a more of a problem. I ran into 2 more cases of the caching causing silent fails: 1) test_q4 old cuda (same problem as @qwopqwop200) and awq compat test failing (also caused by incompatible cache file).

@qwopqwop200  Right now the only remaining tests failing is test_q4 triton. Setting use_tritonv2=False makes the tests pass.  I  do not have cuda/triton skills to find the cause this issue. Need your assistance to track down this problem. Thanks.
# run triton test only
pytest test_q4.py::TestsQ4Triton

FAILED test_q4.py::TestsQ4Triton::test_generation_no_act_order - AssertionError: '<s> I am in Paris and<unk><unk><unk><unk><unk><unk><unk><unk><[255 chars]unk>' != '<s> I am in Paris and I am going to the Louvre Museum. What ti[161 chars] get'
FAILED test_q4.py::TestsQ4Triton::test_generation_with_act_order - AssertionError: '<s> I am in Paris and<unk><unk><unk><unk><unk><unk><unk><unk><[255 chars]unk>' != '<s> I am in Paris and it is a beautiful day. I am sitting in a[203 chars] and'

remove this line https://github.com/AutoGPTQ/AutoGPTQ/blob/main/auto_gptq/nn_modules/qlinear/qlinear_tritonv2.py#L146
and this line
https://github.com/AutoGPTQ/AutoGPTQ/blob/main/auto_gptq/nn_modules/triton_utils/dequant.py#L79
I think this will probably work.

@qwopqwop200  Thank you! triton tests passed. I will re-run full test_q4.

If bit=8, it has this bug? I see all the changes is about 4 bit, what about 8 bit?

If bit=8, it has this bug? I see all the changes is about 4 bit, what about 8 bit?

This PR will affect all bits that gptq supports. [ 2, 4, 8 ]. The tests only validates that there are no errors with 4 bit quants since that is the most popular bit version for balance of speed and quality. You can compare the PPL and/or avg-loss values between this PR and main on 8bit as well.

@qwopqwop200 @Qubitium thanks a lot for fixing this. I will review & merge hopefully today/in the coming days, and do a release thereafter.

@Qubitium I'll push some modifs if that's fine to you

@Qubitium I'll push some modifs if that's fine to you

Feel free to push changes as you see fit.

@fxmarty My last todo (vllm/sglang compat) just completed and there is a compat problem with third party inference engine such as vllm. Maybe prudent to change to default to save in gptq (v1) format. Also, I have not yet tested saving sym=False to gptq v1 format and checking its compat with vllm.

Lots of users user autogptq and only a quant tool and not an inference engine so we need be careful about vllm like compat. Right now gptq_v2 failed so likely kernel mod is required there too. gptq (v1) with sym=False  test pending..

[x] Failed: Check if third party vllm/sglang needs kernel modification for the new gptq_v2 format
[ ] Check if third party vllm/sglang needs kernel modification for the new gptq (v1) format using sym=False in this PR

Switching to draft mode so it doesn't get accidentally merged while I push some changes regarding packing (thread regression) for my team to test.

@Qubitium Do you think we should by default save models in the old gptq format?

@Qubitium Do you think we should by default save models in the old gptq format?

Actually my team is testing this right now.  If gptq_v2 to gptq (v1) conversion has no issue and plays well with vllm, then we should default save to gptq (v1) for compat since almost no inference lib will support v2 without some kind of kernel mod.

@fxmarty  @qwopqwop200
Here is our test result. Based on this, we may need to consider the option to never expose gptq_v2 as savable format and only use it as internal format with dynamic/runtime convert. So always save to gptq (v1) or at the very least have gptq (v1) as default save since the benefit for saving to gptq_v2 is minimal and applies only if you also inference with autogptq tool itself.
Note on columns:

Quant is quantized model with sym value and Autogptq version that made the quant.
Next 3 is inference engine running the quant.
NO means unsupported or inference coherence is unusable.
YES means load ok and inference quality compared to baseline is normal.
+YES means closest to baseline.

| Quant                     | AutoGPTQ Main | AutoGPTQ PR640 | VLLM (main) |
| :------------------------ | ------------: | :------------: | :---------: |
| Sym=True gptq (v1) Main   |           YES |      YES       |     YES     |
| Sym=True gptq (v1) PR640  |           YES |      YES       |     YES     |
| Sym=False gptq (v1) PR640 |          +YES |     +YES       |    +YES     |
| Sym=True gptq_v2 PR640    |            NO |      YES       |      NO     |
| Sym=False gptq_v2 PR640   |            NO |     +YES       |      NO     |

We had baseline of non-quant and compared to baseline, sym=False was the closest to baseline which is good. Notable is that sym=False in this PR but saved to gptq (v1) also runs on the main branch and vllm with same inference quality/output.
sym=False saved to gptq (v1) using this PR retrains same quality and backward compatible with autogptq main and third party vllm/sglang.
So our question becomes, why even bother saving to gptq_v2 on disk? Only benefit I see for now is slightly faster loading time but incompatible with older autogptq and all 3rd gptq based inference libs.
My vote is to keep gptq_v2 an internal native format.
Disclaimer: model tested is TinyLlama-1.1B-intermediate-step-1341k-3T and we only used one example prompt to test inference output quality. Different models, quants, prompts results may vary.

@Qubitium yes, the issue is maybe underflow in https://github.com/Qubitium/AutoGPTQ/blob/9d88639600d263e46cec73fe5d03cc609bf3705b/auto_gptq/modeling/_utils.py#L192-L201

If sym=False you should force it to be saved in v2 format. It won't work in v1.
https://github.com/AutoGPTQ/AutoGPTQ/pull/559/files#diff-f4f987d3fa40acd4e45fc6fcd85d17228a61466910d12dfec21c918674979bacR105

The thing is that e.g. vllm kernels have not been updated accordingly & won't load v2 models.

If sym=False you should force it to be saved in v2 format. It won't work in v1. https://github.com/AutoGPTQ/AutoGPTQ/pull/559/files#diff-f4f987d3fa40acd4e45fc6fcd85d17228a61466910d12dfec21c918674979bacR105

On TinyLlama-1.1B-intermediate-step-1341k-3T the underflow percentage of all qzero.data tensor elements is ~13% for convert_v2_to_v1() with sym=False.
@qwopqwop200 During my tests, despite the 13% underflows, the inference output generate is still good to great with forced convert_v2_to_v1() for sym=False. In theory, this should never work right? But can we assume the errors (underflows) are not affecting the model execution as expected?

Failed Test

[x] Yi9B with sym=False and gptq_v2. This bug is caused by #614

@qwopqwop200  @fxmarty  Added underflow check for testing in https://github.com/AutoGPTQ/AutoGPTQ/pull/640/files#diff-426b34df9e6c820d8f15217a86004977116ade694a921b73edb49a4023622b30R201-R236
With TinyLlama-1.1B-intermediate-step-1341k-3T and sym=Fase and saved to gptq (v1) via convert_v2_to_v1(). The inference result is coherent and same as pre-quant model. However, if tweak the commit and skip the underflow math for tensor.items that underflow, the result is incoherent. So underlow is better than skip.
TinyLlama-1.1B-intermediate-step-1341k-3T
original model (pre-quant)
-- prompt: <s> My name is Lewis and I like to
-- output: <s> My name is Lewis and I like to play football.
I'm a 16 year old boy who loves playing football, but also enjoys other sports such as basketball, tennis etc.</s>

-- prompt: <s> Once upon a time,
<s> Once upon a time, there was an old man who lived in the forest. He had two sons and one daughter. The oldest son married a beautiful princess named Princess Ariel. They were happy together for many years until they decided to have children of their own. One day, when he went out hunting with his friends, the youngest son found himself alone in the woods.
The youngest son's name is Peter Pan. He has magical powers that allow him to fly through the air at will. Whenever he flies away from home, no matter how far it may be, he always comes back safely.
My favorite foods are pizza, chicken nuggets, and hotdogs.</s>

-- prompt: <s> Once upon a time,
<s> Once upon a time, there was an old man who lived in the forest. He had no family and he didn't have any friends either. One day, his friend came to visit him. The old man said that he would be happy if they could meet again one day.
The next morning, when the old man woke up, he found himself surrounded by flowers. They were so beautiful that it made him feel very sad. "What are you doing here?" asked the old man as he looked at them.
"I am your flower," replied the flowers. "You can come back whenever you want."
That night, the old man

@fxmarty  At a fork (figurative) right now. Need to decide how to enforce this underflow safety check. My tests shows that underflow is not turning model is unusable. In fact, sym=False is good with or without underflow (gptq v1 underflow vs gptq_v2) and better than sym=True.

Should we outright ban saving sym=False as gptq v1 as @qwopqwop200 suggested since math wise, this doesn't make sense if underflow happens.
Or allow with huge warnings?
Or allow only with manual override in .quantize(allow_unsafe_math=True)?

There are still some testing I would like to do but personally, based on what I have seen, I would still want to use/allow sym=False and save to gptq (v1).

# yi9b
Underflow Summary: underflow count 973756, 12.006737294823232%

# command-r-v01
Underflow Summary: underflow count 3897083, 12.135666827766263%

# llama3-8B

Underflow Summary: underflow count 875563, 12.846183776855469%

So tested 4 models and all points to a trend of underflow prob of <= 13% when doing sym=False and saving to gptq v1 via unsafe math convert_from_v2_to_v1() code path.

@fxmarty  @qwopqwop200
I do not understand why the <=13% underflow/overflow is not corrupting the model to an extend that make it the model unusable. In fact, my testing with 4 different models (tinyllama 1.1b, yi9b, command-r-v01, llama3-8b) shows that the underflow/overflow still result in stable generation with stable ppl that is onpar or better than sym=True with zero under/overflow saving to gptq v1.
Commit: https://github.com/AutoGPTQ/AutoGPTQ/pull/640/commits/005a9422b78d326db51761a0fd4f89a75fe262d1 disable unsafe math (under/overflow) operations: 1) sym=False loading from gptq v1 and 2) sym=False saving to gptq v1.  But I also added use_unsafe_math argument to from_quantized() and save_quantized() to allow such unsafe ops for advanced users who understand the ramifications and risks involved.

I can't validate this idea at the moment as huggingface is throwing a 504.
It's easy to verify: check if the weights of qzeros in the v2 model and the v2 -> v1 -> v2 model are different.
Underflow may not be a problem. In C++, I simply underflowed an int32 and re-added it, and found that it returned to the normal weight value.
However, I suspect that negative values could potentially be an issue, which could be solved by using uint32.

from transformers import AutoTokenizer, TextGenerationPipeline
from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig
import logging

logging.basicConfig(
    format="%(asctime)s %(levelname)s [%(name)s] %(message)s", level=logging.INFO, datefmt="%Y-%m-%d %H:%M:%S"
)

pretrained_model_dir = "facebook/opt-125m"
quantized_model_dir = "opt-125m-4bit"

tokenizer = AutoTokenizer.from_pretrained(pretrained_model_dir, use_fast=True)
examples = [
    tokenizer(
        "auto-gptq is an easy-to-use model quantization library with user-friendly apis, based on GPTQ algorithm."
    )
]

quantize_config = BaseQuantizeConfig(
    bits=4,  # quantize model to 4-bit
    group_size=128,  # it is recommended to set the value to 128
    sym=False,
    desc_act=False,  # set to False can significantly speed up inference but the perplexity may slightly bad
    checkpoint_format='gptq'
)

# load un-quantized model, by default, the model will always be loaded into CPU memory
model = AutoGPTQForCausalLM.from_pretrained(pretrained_model_dir, quantize_config,resume_download=True)

# quantize model, the examples should be list of dict whose keys can only be "input_ids" and "attention_mask"
model.quantize(examples)

# save quantized model
model.save_quantized(quantized_model_dir, use_unsafe_math=True)

# load quantized model to the first GPU
model2 = AutoGPTQForCausalLM.from_quantized('./opt-125m-4bit/', device="cuda:0")

assert id(model) != id(model2), 'this model is same'

for i in range(len(model.model.model.decoder.layers)):
    z0 = model.model.model.decoder.layers[i].self_attn.k_proj.qzeros.to('cpu')
    z1 = model2.model.model.decoder.layers[i].self_attn.k_proj.qzeros.to('cpu')
    print(z0[z0 != z1])
    z0 = model.model.model.decoder.layers[i].self_attn.v_proj.qzeros.to('cpu')
    z1 = model2.model.model.decoder.layers[i].self_attn.v_proj.qzeros.to('cpu')
    print(z0[z0 != z1])
    z0 = model.model.model.decoder.layers[i].self_attn.q_proj.qzeros.to('cpu')
    z1 = model2.model.model.decoder.layers[i].self_attn.q_proj.qzeros.to('cpu')
    print(z0[z0 != z1])
    z0 = model.model.model.decoder.layers[i].self_attn.out_proj.qzeros.to('cpu')
    z1 = model2.model.model.decoder.layers[i].self_attn.out_proj.qzeros.to('cpu')
    print(z0[z0 != z1])
    z0 = model.model.model.decoder.layers[i].fc1.qzeros.to('cpu')
    z1 = model2.model.model.decoder.layers[i].fc1.qzeros.to('cpu')
    print(z0[z0 != z1])
    z0 = model.model.model.decoder.layers[i].fc2.qzeros.to('cpu')
    z1 = model2.model.model.decoder.layers[i].fc2.qzeros.to('cpu')
    print(z0[z0 != z1])

I have verified that both overflow and underflow issues do not occur.
Here's the test code.
import torch
values = {'2': 0b01010101010101010101010101010101,
 '3-1': 0b00100100100100100100100100100100,
 '3-2': 0b10010010010010010010010010010010,
 '3-3': 0b01001001001001001001001001001001,
 '4': 0b00010001000100010001000100010001,
 '8': 0b00000001000000010000000100000001,}
int_range = (-2147483648,<PHONE_NUMBER>)

for name, value in values.items():
    a = torch.arange(int_range[0], int_range[1] + 1, dtype=torch.int32)
    b = (a - value) + value
    print(name, 'underflow')
    print(a[a != b])
    del a,b

    a = torch.arange(int_range[0], int_range[1] + 1, dtype=torch.int32)
    b = (a + value) - value
    print(name, 'overflow')
    print(a[a != b])
    del a,b

Below is PPL of a private model using command-r-v01. We tested ppl using vllm to show that even with the uncorrected underflow of v2 -> v1 for sym=False, the ppl/generation is very stable. @qwopqwop200 Showed the the underflow in save will be autocorrected/negated with overflow in autogptq loading.  In our testing, even without the auto-correction, saved gptq (v1) models with sym=False is quite good and offers full compat with 3rd party libs.
model: command-r-v01-trained
bfloat16
vllm ppl: 1.6494
transformers ppl: 1.7075

gptq(v1), sym=False
vllm ppl: 1.6515
autogptq ppl: 1.7084

marlin, sym=True
vllm load: 1.6541,
autogptq load: 1.7139

Failed Test

[x]  Yi9B with sym=False and gptq_v2. This bug is caused not by this PR changes but [BUG] Regression in quantized inference when paired with Transformers >= 4.39.0 #614

This test now passing due to PR fix https://github.com/huggingface/transformers/pull/30380

@qwopqwop200  @fxmarty
To summarize the underflow/overflow situation.  Please correct me if anything is wrong here.

If saving sym=False using autogptq, v2 -> v1 in save, then v1 -> v2 on load also using autogptq, this path is stable and safe.
If saving sym=False using autogptq v2->1 in save, then load via 3rd party lib such as vllm, my tests show this is also stable (for all 4 diff models I have tried) though I cannot explain why it works despite the uncorrected underflows.
Loading sym=False from quanted models pre-PR behavior is undefined and we currently do not have a way to check if v1 model is from pre-PR or post-PR (need another meta/info variable like tool/tool_version in quantized_config.json).

Yes. It would be nice to have some additional information in the config, like tool version or format version.
and
I think this code should be cleaned up later, as the underflow issue seems to be fixed for now.
https://github.com/AutoGPTQ/AutoGPTQ/pull/640/files#diff-426b34df9e6c820d8f15217a86004977116ade694a921b73edb49a4023622b30R203-R258

I think this code should be cleaned up later, as the underflow issue seems to be fixed for now. https://github.com/AutoGPTQ/AutoGPTQ/pull/640/files#diff-426b34df9e6c820d8f15217a86004977116ade694a921b73edb49a4023622b30R203-R258

Underflow stat code removed now that we have done all the testing and know what to expect.

Convert v1/v2 now faster with fix at https://github.com/AutoGPTQ/AutoGPTQ/pull/640/commits/ac63033eec3effc1c33eb2e283541b1231708917
test_q4 now completes 40% faster on my zen3 dev env. 1000s vs 1650s.
This is the same thread limit used on pack(): https://github.com/AutoGPTQ/AutoGPTQ/pull/642 Whatever auto-penalization torch/cublas is doing should be disabled.

@fxmarty  Read to re-review.
Even though v2->v1 then v1->v2 is validated safe, we can't be sure quant model will be loaded/inferenced with autogptq. User may quant v2 -> v1 and then use the v1 model on vllm or another. As such, the use_unsafe_math parameter is still needed to cautious.
Loading behavior of v1 pre-pr quanted with sym=False is undefined. We can only disable this code path with extra meta fields in quantized_config.json but I think it should be in another pr.

@qwopqwop200  @fxmarty  I am going to inject new meta code into this PR to complete the final missing piece of preventing the auto convertion of v1 to v2 when loading models not quantized by pre-PR code.  The new code is minimal. https://github.com/AutoGPTQ/AutoGPTQ/pull/640/commits/a6d64e99756e5fd9ff1753c6595a25096f4af9d6
# sample new field meta (dic) with "quantizer" as the field holding autogptq fingerprint + version
meta={'quantizer': 'autogptq:0.8.1.dev0'}

There are many paths to add meta info. Here is my take:

Use a meta dict to hold all new properties that is not directly involved the autogptq quantization and/or loading/inference of the model
meta.quantizer field has format of tool name:version separted by : => "autogptq:0.8.1"
Fields like timestamps, who made the quant, git commit hah of model, urls. etc.
Anyone can add to it via meta_set and meta_get methods to BasedQuantrizedConfig

This way, we have a single meta property field that can be used us and others without polluting the top level vars. Intel's autoround (gptq) comes to mind as they inject lots of stuff into quantized_config.json with vars only related to their tooling that should go into meta.

Fixed meta json save and added meta field validation to test_quantization
@fxmarty Another pkg depend added packaging: since we need a python native version string checker and distutils is deprecated in favor of packaging.version.

Fixed awq pack/unpack thread regression in https://github.com/AutoGPTQ/AutoGPTQ/pull/640/commits/cddbe23b17de64e16b7c06e674f23f089dc57dbc
unpack/packing to awq in test_awq now ~2.6x faster. 2m12s vs 5m46s.

All tests passing with transformers 4.40.1

[x] test_q4
[x] test_quantization
[x] test_serialization
[x] test_shareded_load
[x] test_awq_compat

Remove highly flaky Mixtral-Tiny model, that doesn't exist in any production environment, and test that 1) fails at a very high rate 2) input/output are nonsensical and no human can understand what this is testing. Only the model creator (hf) knows what inside this black genie bottle in terms of weights.
https://github.com/AutoGPTQ/AutoGPTQ/pull/640/commits/811ca399f8c770143640c624ce115f7b32d800d6

Removed all use_unsafe_math code and default save to gptq (v1)format for max compat with minimal loss vs saving to v2 as tested in our internal ppl tests across 4 different models.
@fxmarty  Feel free to edit at will and revert the last commit if you want to go the conservative route. https://github.com/AutoGPTQ/AutoGPTQ/pull/640/commits/528a8fce5aa92917db6b7f9a772eec68f67b2d70

Intel/auto-round by default uses sym=False and save to gptq (v1) format by importing autogptq lib and directly calling pack() . As it stands, we are going to reject loading this model. I need to test this. My lord, testing for this PR never ends. I am going to pull my hair out.
{
  "bits": 4,
  "group_size": 128,
  "damp_percent": 0.01,
  "desc_act": false,
  "static_groups": false,
  "sym": false,
  "true_sequential": false,
  "model_name_or_path": null,
  "model_file_base_name": "model",
  "quant_method": "gptq",
  "checkpoint_format": "gptq",
  "meta": {
    "quantizer": "intel/auto-round:0.1",
    "iters": 10,
    "lr": 0.1,
    "minmax_lr": 0.1,
    "enable_minmax_tuning": true,
    "use_quant_input": true,
    "scale_dtype": "torch.float16"
  }

}

Intel/auto-round by default uses sym=False and save to gptq (v1) format by importing autogptq lib and directly calling pack() . As it stands, we are going to reject loading this model. I need to test this.

[x] Autoround compat confirmed with Intel/auto-round compatibility confirmed. Needs this https://github.com/intel/auto-round/pull/87 and tested with both sym=True/False.

Add meta.packer so it is clear who is doing what. Autoround is doing the quantization and autogptq (imported code) is doing the packing to v1.
autoround model config with sym=False
{
  "bits": 4,
  "group_size": 128,
  "damp_percent": 0.01,
  "desc_act": false,
  "static_groups": false,
  "sym": false,
  "true_sequential": false,
  "model_name_or_path": null,
  "model_file_base_name": "model",
  "quant_method": "gptq",
  "checkpoint_format": "gptq",
  "meta": {
    "quantizer": "intel/auto-round:0.1",
    "packer": "autogptq:0.8.0.dev1",
    "iters": 20,
    "lr": 0.05,
    "minmax_lr": 0.05,
    "enable_minmax_tuning": true,
    "use_quant_input": true,
    "scale_dtype": "torch.float16"
  }
}

Commit/Refractor https://github.com/AutoGPTQ/AutoGPTQ/pull/640/commits/59be4b35b09fa42a7fab9ede5d5cad9c4dce199c
Tooling is now broken down to  meta.quantizer and meta.packer as evident by intel/auto-round usage of autogptq packer but quantization is done by auto-round. Medels quanted by autogptq does not set meta.packer.  v1 checks both meta.quantizer and meta.packer to see if it was either quantized or packed by autogptq.
 "meta": {
    "quantizer": "intel/auto-round:0.1",
    "packer": "autogptq:0.8.0.dev1",
}

We found a significant discrepancy between the real quantized model and the QDQ model at W2G32 asym. However, for the sym and W4G128 asym, there doesn't seem to be severe issue.
As this PR also supports the v2 format and we are not familiar with the details, we're unsure if we can test it directly or if we need to merge the PR in Autoround.

This is our the results, we used autoround to generate the qdq model and real autogptq model by "--deployment_device fake,gpu", then we could evaluate the both model. lm-eval 0.4.2 is used
asym at w2g32
qdq:   lambada_openai: 0.5405   winogrande: 0.6417
gpu:   lambada_openai: 0.2505   winogrande: 0.6006
sym at w2g32
qdq:   lambada_openai: 0.3501  winogrande: 0.5817
gpu:   lambada_openai: 0.3629   winogrande: 0.5856
reference command
git clone https://github.com/intel/auto-round.git
cd auto-round/examples/language-modeling
pip install -r requirements.txt
python3 main.py --model_name /data5/llama3_8b_instruct/ --bits 2 --group_size 32 --n_samples 512 --iters 200 --deployment_device fake,gpu --disable_eval --seqlen 512 --minmax_lr 0.01 --scale_dtype fp32  --train_bs 4 --output_dir "./tmp_signround"

we also find large discrepancy for phi-2 at W4G128 asym. Shall I create a new issue for this?

@qwopqwop200  For various reasons my team has forked and refractored AutoGPTQ into new GPTQModel project. This bug fix/feature PR has been merged there. I have done plenty of testing and validation for this PR and it works, not perfectly but it works. Default save to v1 for max compat.

@qwopqwop200 This is the rebase of your PR at #559 with some modifications. Should be ready soon after we verify quantize, inference, and add some tests. 这是您在 #559 处的 PR 的变基，并进行了一些修改。在我们验证量化、推理并添加一些测试后应该很快就可以准备好。
Reason For PR: 公关理由：
sym=False was practically unusable due to post-quantization avg_loss per layer/PPL vs sym=True . @qwopqwop200 fixed the bad/suboptimal math. Now sym=False will most likely match or decrease avg_loss/layer vs sym=True and improve post-quant PPL for many models.由于每层后量化 avg_loss/PPL 与 sym=True 相比， sym=False 实际上无法使用。修复了错误/次优的数学问题。现在， sym=False 很可能会与 sym=True 相比匹配或减少 avg_loss/layer，并提高许多模型的量化后 PPL。
Core Changes: 核心变化：

Rebase PR remove (zeors -= 1) #559 with main: allow usable sym=False quantization and use checkpoint_format=gptq_v2 to store new checkpoint format. Compat runtime dynamic convert of all checkpoint_format=gptq to gptq_v2 on load.使用 main 重新设置 PR remove (zeors -= 1) #559 ：允许可用的 sym=False 量化并使用 checkpoint_format=gptq_v2 存储新的检查点格式。 Compat 运行时在加载时将所有 checkpoint_format=gptq 动态转换为 gptq_v2 。

Misc Changes not directly related to sym=False code:
其他与 sym=False 代码不直接相关的更改：
4. Complete Todo: Use accelerate 0.29.2 to load checkpoint.完成Todo：使用accelerate 0.29.2加载检查点。
5. Consistency: Move cohere/starcoder2 to 4.39.0 release check一致性：将 cohere/starcoder2 移至 4.39.0 版本检查
6. Usability: Catch and alert user on how to fix quant/torch error caused by low damp/nsamples [BUG] torch._C._LinAlgError: linalg.cholesky always raised #572 as this happens much more frequently than I had expected. Ran into 2-3 instances of this error on multiple models during testing for this PR when using low nsamples  + low damp=0.005 to speed up quants.可用性：捕获并提醒用户如何修复由低阻尼/n样本 [BUG] torch._C._LinAlgError: linalg.cholesky always raised #572 引起的定量/火炬错误，因为这种情况发生的频率比我预期的要高得多。在测试此 PR 期间，使用低 nsamples + 低 damp=0.005 来加速量化时，在多个模型上遇到了 2-3 个此错误实例。
7. Simplify: optimized packing regression alert message/code to user简化：向用户优化打包回归警报消息/代码
8. Feature: Quant Stat Log 1/2:  store per layer quant stats (layer #, module name, avg loss, duration)  in dict/slice and return to user va quant_log = model.quantize()功能：定量统计日志 1/2：将每层定量统计信息（ layer # 、 module name 、 avg loss 、 duration ）存储在 dict/ 中切片并返回给用户 va quant_log = model.quantize()
9. Feature: Quant Stat Log 2/2:  pass saved quant_log to quantize(quant_log=saved_quant_log) to generate auto-avg_loss diff in progress. Sample diff output in later messages of this discussion.功能：Quant Stat Log 2/2：将保存的 quant_log 传递到 quantize(quant_log=saved_quant_log) 以生成正在进行的自动 avg_loss diff。本讨论后面的消息中的示例 diff 输出。
10. Usability: Use tqdm for layer loop so users can have an estimate of quant remaining time.可用性：使用 tqdm 进行层循环，以便用户可以估计定量剩余时间。
TODO: 去做：

[x]  Add sym=False tests  添加 sym=False 测试
[x]  Validate and fix failing tests验证并修复失败的测试
[x]  Failed: Check if third party vllm/sglang needs kernel modification for the new gptq_v2 format 失败：检查第三方 vllm/sglang 是否需要内核修改以适应新的 gptq_v2 格式
[x]  Check if third party vllm/sglang needs kernel modification for the new gptq (v1) format using sym=False in this PR 检查第三方 vllm/sglang 是否需要使用此 PR 中的 sym=False 进行内核修改以适应新的 gptq (v1) 格式

PASSING TESTS: 通过测试：

[x]  Compat: vllm/sglang compatible  with gptq (v1) generated with this PR Compat：vllm/sglang 与此 PR 生成的 gptq (v1) 兼容
[x]  Compat load of checkpoint_format=gptq(v1) checkpoint_format=gptq 的兼容负载 (v1)
[x]  sym=False consistently generate lower avg_loss than 始终生成低于sym=True sym=False 始终生成低于 sym=True 的 avg_loss
[x]  Regression Test: sym=True in PR generates same math/avg_loss for layers as sym=True in 回归测试：在 PR 中为各层生成相同的数学/main 回归测试：PR 中的 sym=True 为层生成与 main 中的 sym=True 相同的数学/ avg_loss
[x]  test_serialization.py
[x]  test_quantization.py
[x]  test_shared_loading.py
[x]  test_awq_compatibility_generation.py  (note: awq cache generated by main is not compatible with pr. fixed with version file name adding v2) test_awq_compatibility_generation.py （注意： main 生成的awq缓存与pr不兼容。已修复版本文件名添加 v2 ）
[x]  test_q4.py

FAILING TESTS: 失败的测试：

[x]  compat: vllm/sglang not compatible gptq_v2 兼容：vllm/sglang 不兼容 gptq_v2
[x]  test_triton.py (never got this to work on main) test_triton.py （从来没有让它在 main 上工作）
[x]  test_repacking.py (never got this to work on main) test_repacking.py （从来没有让它在 main 上工作）

Original PR #559 notes duplicated here for ref:原始 PR #559 注释复制于此以供参考：

[x]   check work marlin 检查工作马林鱼
[x]   check work exllama 检查工作埃拉玛
[x]   check work exllama2 检查工作 exllama2
[x]   check work qigen 检查工作启根
[x]   check work triton 检查工作 Triton
[x]   check work cuda 检查工作 cuda
[x]   ~check work cuda old~(There is a bug in autogptq's main unrelated to this pr, so it cannot be confirmed.)check work cuda old（autogptq的main中有一个与此pr无关的bug，因此无法确认。）
[x]   check work cuda pytorch检查工作 cuda pytorch
[x]   check work cuda old pytorch 检查 cuda 旧 pytorch 的工作
[x]   check support old version save检查支持旧版本保存
[x]   check support old version load 检查支持旧版本加载
[x]   check support new version save 检查支持新版本保存
[x]   check support new version load 检查支持新版本加载

I am removing this line because it is not only computationally unnecessary, but also makes sym=False impossible. However, it breaks backwards compatibility, so I making it the default to use the old save format.
related pr
#354
#325
I removed the following line: https://github.com/AutoGPTQ/AutoGPTQ/blob/main/auto_gptq/nn_modules/qlinear/qlinear_cuda.py#L169 This is an unnecessary line. And this line makes it impossible to sym='False' If sym='False' I get a reduction in ppl.
opt-125m(act-order)	Bits	group-size	Wikitext2
sym=True	4	128	29.875
sym=False	4	128	29.221
llama2(act-order)	Bits	group-size	Wikitext2
sym=True	4	128	5.254
sym=False	4	128	5.214

I wonder how to fix what you have said, specifically when i let attention_mask mask the insturctions of the calibration dataset?
"Usability: Catch and alert user on how to fix quant/torch error caused by low damp/nsamples https://github.com/AutoGPTQ/AutoGPTQ/issues/572 as this happens much more frequently than I had expected. Ran into 2-3 instances of this error on multiple models during testing for this PR when using low nsamples + low damp=0.005 to speed up quants."
this really annoy me


merge devel

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

35 of 36 (97.22%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.5%) to 95.936%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

node.go
21
22
95.45%

Totals

Change from base Build<PHONE_NUMBER>:
0.5%

Covered Lines:
897

Relevant Lines:
935

💛  - Coveralls


This project doesn't work with the latest version of Angular.

I see nothing but errors in the console.

I wouldn't expect Angular to necessarily work in a "Create React App" project. Can you explain more?


NSDictionary category has a method without prefix

Here it is: https://github.com/Adyen/adyen-cse-ios/blob/master/AdyenCSE/NSDictionary+AdyenUtil.h#L13
Apple recommends to prefix such methods.

Hi @nikolaykasyanov,
Thanks for reporting this! I've fixed this in https://github.com/Adyen/adyen-cse-ios/commit/541fe8ea8734c5420462b2ea9cd7555641a9d700. A new release will be published next week.
Best,
Joost

@joostvandijk thank you!


Terms with long and short annotation should be handled as equal

let short = CvTerm.create("DPBO:1000164","plant growth protocol","DPBO")
let long = CvTerm.create("http://purl.org/nfdi4plants/ontology/dpbo/DPBO_1000164","plant growth protocol","DPBO")

short = long

returns false, but should IMO return true.

Don't understand... you want to have the URI directly transformed into the respective ID or, that .Compare() does that only on comparison? @HLWeil

In the example above, I create two ontology term objects that are equal, as they both depict the same ontology term "DPBO:1000164", just in different formats.
But logic is missing which covers this. Therefore there can be validation cases which only work against one of the two formats.

I should use the same logic as in ARCtrl. @omaus

https://github.com/nfdi4plants/ARCtrl/blob/68a42b78dac16a0dd01f56ad04cf00cb57de91ac/src/Core/OntologyAnnotation.fs#L52


different signatures in oauth.authorize

Hello,
In the example oauth.authorize is passed with two different signatures, the first one is (request, reply, function ... ) and the second one is (function ...), was that an error? Because when token() is called, the following error is raised:
TypeError: Uncaught error: Cannot read property 'lazy' of undefined
at Object.internals.convertToExpress (/path/to/node_modules/hapi-oauth2orize/index.js:202:20)
function authorize(request, reply) {
  oauth.authorize(request, reply, function (req, res) {
    reply.view('oauth', {transactionID: req.oauth2.transactionID});
  }, function (clientID, redirect, done) {
    server.helpers.find('client', clientID, function (docs) {
      done(null, docs[0], docs[0].redirect_uri);
    });
  });
};

function decision(request, reply) {
    oauth.decision(request, reply);
};

function token(request, reply) {
  oauth.authorize(function (clientID, redirect, done) {
    done(null, clientID, redirect);
  });
};

Also I wonder if it's possible to include authentication in the example. Should I use hapi-auth-cookie to handle authentication with oauth2orize?

I think I found the answer to my own question. The second oath.authorize should actually be oauth.token. I have forked this repo at https://github.com/midnightcodr/hapi-oauth2orize with a minor update to index.js and the example shown in README.md. This post https://hnryjms.github.io/2014/07/oauth2/ helped me a lot in figuring out the solution.

Thanks!  The docs need a lot of work, and we'd definitely take the help.  Can you explain the change you made to index.js?

Hey @midnightcodr  i am getting same error:
Debug: internal, implementation, error
TypeError: Uncaught error: Cannot read property 'lazy' of undefined
at Object.internals.convertToExpress (/Users/Lutfor/Documents/test-api/node_modules/hapi-oauth2orize/index.js:201:20)
at Object.internals.authorize (/Users/Lutfor/Documents/test-api/node_modules/hapi-oauth2orize/index.js:83:29)
what was your fix?

@midnightcodr
no issue(Uncaught error: Cannot read property 'lazy' of undefined
) after using your index.js file and example.  but i am getting another error when i am calling with curl command. I appreciate any kind of help from community to resolve this issue.
curl -XPOST "http://localhost:3000/oauth/token" -d "grant_type=password&client_id=abc123&client_secret=ssh-secret&username=bob&password=secret"
Debug: internal, implementation, error
TypeError: Uncaught error: Cannot read property 'find' of undefined
at token (/Users/Lutfor/Documents/test-api/dist/index.js:196:17)
at Object.exports.execute.internals.prerequisites.internals.handler.callback [as handler] (/Users/Lutfor/Documents/vincari-api/node_modules/hapi/lib/handler.js:96:36)
at /Users/Lutfor/Documents/test-api/node_modules/hapi/lib/handler.js:30:23
at internals.Protect.run.finish [as run] (/Users/Lutfor/Documents/test-api/node_modules/hapi/lib/protect.js:64:5)
at exports.execute.finalize (/Users/Lutfor/Documents/test-api/node_modules/hapi/lib/handler.js:24:22)
at each (/Users/Lutfor/Documents/test-api/node_modules/hapi/lib/request.js:383:16)
at iterate (/Users/Lutfor/Documents/test-api/node_modules/hapi/node_modules/items/lib/index.js:36:13)
at done (/Users/Lutfor/Documents/test-api/node_modules/hapi/node_modules/items/lib/index.js:28:25)
at internals.Auth.test.internals.Auth.payload.finalize (/Users/Lutfor/Documents/test-api/node_modules/hapi/lib/auth.js:223:16)
at each (/Users/Lutfor/Documents/test-api/node_modules/hapi/lib/request.js:383:16)
at iterate (/Users/Lutfor/Documents/test-api/node_modules/hapi/node_modules/items/lib/index.js:36:13)
at done (/Users/Lutfor/Documents/test-api/node_modules/hapi/node_modules/items/lib/index.js:28:25)
at onParsed (/Users/Lutfor/Documents/test-api/node_modules/hapi/lib/route.js:409:20)
at /Users/Lutfor/Documents/test-api/node_modules/hapi/lib/route.js:430:20
at next (/Users/Lutfor/Documents/test-api/node_modules/hapi/node_modules/subtext/lib/index.js:43:16)
at /Users/Lutfor/Documents/test-api/node_modules/hapi/node_modules/subtext/lib/index.js:164:20


Avoid ⎇ + Shift + 7 on German keyboard

GitLens Version: 5.1.0
VSCode Version: 1.16.1
OS Version: OSX 10.12.6

Steps to Reproduce:

use shortcut Alt+Shift+7 on German keyboard to enter the backslash char (\)

When this shortcut is overridden, it's not possible to enter the backslash char on German keyboard (which is used quite frequently in some programming languages).

Apple did a terrible job with the German keyboard layout. I have no idea what they smoked back then when they decided to go completely non-standard with the placement of the curly braces, brackets, the pipe symbol, the backslash, the tilde, and the at sign. Even worse, none of these characters except the at sign are even printed onto the keys.
I just stumbled over this Alt-Shift-7 issue today when recording a screencast after having installed gitlens yesterday (a great tool btw).
As a temporary workaround, I disabled the shortcut by copying the keybinding over to the user's keybindings file and placing a "-" before the command (which is what the VSCode doc recommends for disabling a shortcut):
{
		"key": "shift+alt+7",
		"command": "-gitlens.showCommitSearch",
		"when": "gitlens:enabled"
	},

This is the same with a french keyboard. To enter a backslash, you need to hit alt+shift+: because / is placed on shift+:.
But showCommitSearch (that have alt+/) is triggered.

As you can see, showCommitSearch is exactly what I need to hit to print a backslash.

Let's move this conversation over to https://github.com/eamodio/vscode-gitlens/issues/104 since these are ultimately the same thing


"Union[List, Dict]" breaks the C# SDK generation

The most recent fix  https://github.com/pollination/queenbee/commit/41fb857c2f2658f390e0eab5a787616266d91791 breaks the C# SDK generation. List is not recognized inside Union (AnyOf) during the translation.
So why do we need make value to be List type when we have DAGArrayInput, DAGArrayInputAlias, FunctionArrayInput, FunctionArrayInputAlias, etc. that are design for lists?
@AntoineDao @mostaphaRoudsari

This was meant to give more flexibility for writing recipes. @AntoineDao, if you can point me to the task that needed this change I can try to change the recipe to Array type and we can revert this change.

This was meant to give more flexibility for writing recipes. @AntoineDao, if you can point me to the task that needed this change I can try to change the recipe to Array type and we can revert this change.

Ah that makes sense. Can I propose the following steps to fix this:

Reset the JSONObject types to be only Dict
Deprecate (not remove) the JSONObject types in favour of a Dict or Map  or Object type. Calling it JSONObject really insinuates that it should support Arrays and Dicts at the same time. I prefer calling it Object type as that is what it's called in the JSON Schema and OpenAPI schema.
Replace the incorrect JSONObject type in the daylight-factor recipe to Array type
Add some more flexible type casting primitives when translating Run Step parameters (ie: if a JSONObject type is actually an Array don't throw an error but instead cast it to an Array type)

Let me know what you guys think and I'll get started on work to fix this ASAP 😀

Ah that makes sense. Can I propose the following steps to fix this:

Reset the JSONObject types to be only Dict
Deprecate (not remove) the JSONObject types in favour of a Dict or Map  or Object type. Calling it JSONObject really insinuates that it should support Arrays and Dicts at the same time. I prefer calling it Object type as that is what it's called in the JSON Schema and OpenAPI schema.
Replace the incorrect JSONObject type in the daylight-factor recipe to Array type
Add some more flexible type casting primitives when translating Run Step parameters (ie: if a JSONObject type is actually an Array don't throw an error but instead cast it to an Array type)

Let me know what you guys think and I'll get started on work to fix this ASAP 😀

Thank @AntoineDao! Can we leave the step 2 for later? It used to be called Object before and it become confusing for @MingboPeng and that's how/why we changed it to JSONObject. I like the proposal and fixing the recipes to work with the current set up should be easy to do. I agree that we should have an object that supports any valid JSON object either if it translates to a dictionary, list or a string in Python.

Thank @AntoineDao! Can we leave the step 2 for later? It used to be called Object before and it become confusing for @MingboPeng and that's how/why we changed it to JSONObject. I like the proposal and fixing the recipes to work with the current set up should be easy to do. I agree that we should have an object that supports any valid JSON object either if it translates to a dictionary, list or a string in Python.

Sounds like a plan. Is it ok if I fix this tomorrow so I can finish deploying our production environment today?

Sounds like a plan. Is it ok if I fix this tomorrow so I can finish deploying our production environment today?

Sure! If you give me a lead on where the recipe is broken I can fix it on the recipe side and revert back the changes on queenbee.

Sure! If you give me a lead on where the recipe is broken I can fix it on the recipe side and revert back the changes on queenbee.

Actually, I think I know where the issue is. It is in the Function itself and not the recipe. This should be set to a list here: https://github.com/pollination/pollination-honeybee-radiance/blob/master/pollination_honeybee_radiance/grid.py#L21-L24
Assuming Chris has followed a similar pattern I think there is a similar case in the one for energy simulation which I also need to fix. On the luigi side since both of these are parsed from a JSON file it doesn't really make a difference.

Actually, I think I know where the issue is. It is in the Function itself and not the recipe. This should be set to a list here: https://github.com/pollination/pollination-honeybee-radiance/blob/master/pollination_honeybee_radiance/grid.py#L21-L24
Assuming Chris has followed a similar pattern I think there is a similar case in the one for energy simulation which I also need to fix. On the luigi side since both of these are parsed from a JSON file it doesn't really make a difference.

Yep happy with either or 😀

Yep happy with either or 😀


Create custom describe for kubectl get cnp and kubect get cep

https://blog.jetstack.io/blog/hidden-gems-1.10/#custom-kubectl-get-and-describe-output

@eloycoto is this work completed? I know it was added for CEP in #5161 .


Playground summary field

I have a request, How can I write a description to the result area of a playground component?

For example, I just want to comment on this yellow marked section.

Hi @HakanKaraoglu, we have a feature request on our roadmap about that, please vote there's :v:
http://feedback.docz.site/roadmap/p/integration-with-jsdocs

Hi @pedronauck ,
I'm voted. I will be waiting for developments
Thank you 👍


PHPStan Rule Levels

We are currently operating on PHPStan rule level 0 (this lowest possible level). We should be working toward level 9, with level 3 being the minimum we would need (I believe) for constant types.
I am going to use this issue as a list of things we need to update to achieve level 3. The one question we have to answer, is what we do with the app directory. Because of views, PHPStan complains about undefined properties (see: app/Views/base.php). I'd love to have a permanent solution for this in the long run so that PHPStan doesn't complain about that.

Doesn't PHPStan take @mixin into account?


Permission to upload ebook Request

github user name:wyleon
mail<EMAIL_ADDRESS>thanks a lot.

OK


fix: 修复画布行列容器组件中的分割工具位置错误的问题

English | 简体中文
PR
PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our Commit Message Guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)
[ ] Built its own designer, fully self-validated

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

Background and solution
修改画布相对位置时引入的一个Bug，导致布行列容器组件中的分割工具位置错误
What is the current behavior?

What is the new behavior?

重构了画布坐标系
优化了画布右键菜单

和引入Bug前的UI保持一致

Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Other information

纵向分割大于2的时候报错：


Fix TextBlock.LineHeight

What does the pull request do?

This PR makes sure text stays centered if the custom LineHeight surpasses the regular LineHeight
What is the current behavior?

What is the updated/expected behavior with this PR?

How was the solution implemented (if it's not obvious)?

Checklist

[x] Added unit tests (if possible)?
[ ] Added XML documentation to any related classes?
[ ] Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Breaking changes

Obsoletions / Deprecations

Fixed issues

@Gillibald This might fix https://github.com/AvaloniaUI/Avalonia/issues/10658 although I haven't tested myself.
TextBox always worked correctly and TextBlock worked fine with some fonts.


Add a quick note about state version values

Here's that part of #146 that I didn't get in fast enough.

LGTM

@rh-atomic-bot r+ 79b0610


Scrolling Issues with Touchpad Scrolling

VSCode Version: Latest
OS Version: Win10

Steps to Reproduce:
Not sure if this is an issue due to Electron.io or VSCode itself but I cannot scroll down/up in the text editor using my touchpad (Microsoft Surface Book)

Seems like after restarting VSCode it was fixed.


Create a Postgres configuration

Currently the app is using H2
Create a Postgres docker image and sort out volumes for the database files.

Done


Update

Add some libs that can be useful for the people.

I'm not sure whether these packages should be listed as separate packages.


feat: remove image segmenters

@nan-wang can u approve and merge these PRs to remove crafters that are actually segmenters?

@nan-wang can u approve and merge these PRs to remove crafters that are actually segmenters?


(GH-446) Updates documentation with important info

In the current CONTRIBUTING documentation, the method documented for adding the remote assumes that the user is using ssh agent forwarding.  However, most users are going to be using HTTPS cloning when they add the remote to the forked repo.  I modified the CONTRIBUTING documentation to include the appropriate command to run when adding the remote using HTTPS cloning.
Without this change, users who want to contribute to the project will not be able to follow the instructions outlined in the documentation, as an Access Denied error will occur when running git fetch if the remote is added using SSH agent forwarding.
Description
I modified the Contributing.md document so that it included the command to add the remote using https cloning, as most users looking to contribute to the project will be using this method.
Related Issue
Fixes #446
Motivation and Context
I ran into an issue trying to follow the documentation when I was trying to submit a contribution, and had to reach out to @gep13 on gitter to provide the correct method.  I wanted to add this documentation so that others would not run into the same issue.
How Has This Been Tested?
NA
Screenshots (if appropriate):
Types of changes
NA
Checklist:
NA

Thanks!


batching/dynamic batching

Thanks for the amazing work! It really is super fast at bs=1.
Can batch usecases, or dynamic batching be supported?

It is not so difficult to modify it to support batch usecases, but supporting dynamic batching is quite a bit more work.
If you really want continuous batching I would suggest looking at projects like vllm or TensorRT-LLM for now.

For anyone interested in this issue, we have successfully integrated torch.compile into a dynamic batching serving system: https://github.com/sgl-project/sglang.
We use flashinfer for attention kernels and torch.compile for all other parts. We found this combination makes it faster than TensorRT-LLM and original gpt-fast. It is also much faster than vLLM. It supports all other features such as contignous batching.
You can give it a try
python -m sglang.launch_server --model-path meta-llama/Meta-Llama-3-8B --enable-torch-compile


ConnectionType is missing in v12

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
A class for ConnectionType is not available and thus more control over the return connection type as described in the documentation is not possible.  Also, ConnectionType is internal so currently you are restricted to completely implementing IConnectionType again in order to do this.
Steps to reproduce
Try to use
descriptor.Type<ConnectionType>()
as per the documentation
Relevant log output
No response
Additional Context?
No response
Product
Hot Chocolate
Version
12.0.0

Along with ConnectionType, please consider making EdgeType public also.  In my case I need to fully reimplement that from interface for the ConnectionType reimplementation.

I'll have to update the documentation for this, as this type has indeed been removed.
However you can still customize the pagination:
descriptor.Field("test").UsePaging<IdType>().Resolve(ctx =>
{
    return new Connection<string>(new[] { new Edge<string>("hello", "abc"), new Edge<string>("world", "def") },
            new ConnectionPageInfo(false, false, "abc", "abc", 2), _ => ValueTask.FromResult(0));
});

This would produce the following schema:
type TestConnection {
  pageInfo: PageInfo!
  edges: [TestEdge!]
  nodes: [ID]
}

type TestEdge {
  cursor: String!
  node: ID
}

Let me know if this doesn't cover your use case.

Hi Tobias,
Thanks for getting back.  I really want to make the Connection a non nullable type.  I don't that is possible currently?
type Query {
   test: TestConnection!
}

Its best practice in GraphQL to not make connections non-null. The first GraphQL version actually had everything nullable. If you think about the execution algorithm and the schema update implications its logical to be careful with non-null types. That is why non-nullability is opt-in which is the reverse to C# where you express when something is nullable.
Consider that in case of an error a non-nullable field can cause your complete result to be erased through the non-null propagation. Further, making an output field nullable is a breaking change bit the reverse is not. So, everywhere, where something could go wrong the type should be nullable which in the case of fetching a paginated its is warranted.
In general ... should composite types be nullable and leaf types where appropriate non-null.

Maybe this is a good starting point to understand why nullability in GraphQL is better in the case of connection:
https://medium.com/@calebmer/when-to-use-graphql-non-null-fields-4059337f6fc8

Hi Michael,
I see you point and the articles of course, protobuf etc follow similar styles and are great for version evolution.
However, still it is (IMHO) common practise to have non nullable connections, even githubs graphql connections are all non nullable as per https://docs.github.com/en/graphql/reference/queries . I'm successfully using HotChocolate with non nullable connections in v11 and this will be a breaking change for me if i upgrade.  The choice should be mine even if there is some debate on the approach, but in this case the option to allow a nullable connection seems to be locked away.
Is there a way to modify the Type once it has been set or someother approach I can take?  All I want to do is upgrade to v12 asap without any schema changes.
Many thanks

For in the unlikely event anyone else has a similar problem I devised this hack to:

make the connection non nullable
make the connection name same as in v11

(Be aware this only handles my limited use case, it's not generic code by any means)
public static IObjectFieldDescriptor UsePaging<TNodeType>(
            this IObjectFieldDescriptor descriptor) where TNodeType : class, IOutputType
        {
            descriptor
                .UsePaging<TNodeType>(null, null, GetConnectionName(typeof(TNodeType)))
                .Extend()
                .OnBeforeCreate((context, definition) =>
                {
                    if (definition.Type is SyntaxTypeReference typeReference)
                    {
                        definition.Type = typeReference.With(
                            new NonNullTypeNode((INullableTypeNode)typeReference.Type),
                            typeReference.Context,
                            typeReference.Scope,
                            typeReference.Factory);
                    }
                });

            return descriptor;
        }

        private static string GetConnectionName(Type value)
        {
            var nodeType = value;
            if (nodeType.GetGenericTypeDefinition() == typeof(NonNullType<>))
            {
                nodeType = nodeType.GetGenericArguments().First();
            }

            if (nodeType.BaseType?.GetGenericTypeDefinition() == typeof(ObjectType<>))
            {
                nodeType = nodeType.BaseType.GetGenericArguments().First();
            }

            return nodeType.Name;
        }


Safari 6 revamps Web Audio API - check whether you can avoid preloading sound

...right now in Safari all sounds are preloaded. Which means that the time-to-launch time is quite long and loads of memory is used (and never released by the way, Safari tends to leak memory).
If the new Web Audio API implementation works like in Chrome, then maybe sounds can be loaded dynamically just like in Chrome?

if we get #241 merged then this should be sorted

think this is no longer an issue either. mentioned PR was merged and the web audio API is not generally better in all the browsers.


We can not move cursor to edit inputted value in text boxes in mobile website in FireFox mobile Browser

Hello,
We are not able to move cursor by holding mobile key board cursor from one place to another for edit text.
It Only not works in Mobile Fire fox version. Please let me know if any solution is there for this.
You can check that issue by visiting below website in Mobile FireFox browser.
https://material.angularjs.org/1.0.5/demo/input
Note: for support questions, please use one of these channels: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#question. This repository's issues are reserved for feature requests and bug reports.
Do you want to request a feature or report a bug?
What is the current behavior?
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://plnkr.co or similar (template: http://plnkr.co/edit/tpl:yBpEi4).
What is the expected behavior?
What is the motivation / use case for changing the behavior?
Which versions of Angular, and which browser / OS are affected by this issue? Did this work in previous versions of Angular? Please also test with the latest stable and snapshot (https://code.angularjs.org/snapshot/) versions.
Other information (e.g. stacktraces, related issues, suggestions how to fix)

Hi, your issue sounds like an issue for Angular Material. Please open an issue here: https://github.com/angular/material/issues

Okay, i submitted issue there. Thanks for Quick reply.


Is it possible to disable part of segment index?

I need to disable part of segment index and change as disable mode.. is it possible in this

No @iosdroid , this is currently not possible.


Version mismatched in the API

Hello,
it seems that is a version mismatch returned by the API.
For the version 2.33.1 , the API /__admin/docs/swagger returns 2.32.0.
This is probably the file to be fixed.
https://github.com/wiremock/wiremock/blob/2.33.1/src/main/resources/swagger/wiremock-admin-api.json
Thanks

I think there is also a problem with https://github.com/wiremock/wiremock/blob/2.33.1/ui/package.json
{
  "name": "wiremock-ui-resources",
  "version": "2.32.0",


README: Typos, formatting, clarity cleanups and updates.

Fix markdown formatting and a few typos. Use consistent case and naming
patterns (e.g. Xiongmai vs XM). Also, add XM550 support, based on recent
commits.
Signed-off-by: Paul Sokolovsky<EMAIL_ADDRESS>

Thanks !


templating load error "Too much recursion" when using aurelia-bootstrapper 2.2.0

I'm submitting a bug report

Library Version:
1.0.0-rc.2.0.0

Please tell us about your environment:

Operating System:
Windows 10

Node Version:
7.4.0

NPM Version:
5.3.0

JSPM OR Webpack AND Version
Aurelia CLI 0.31.3

Browser:
Chrome 64.0.3282.167
Firefox 58.0.2 (64-bit)
Edge 41.16299.15

Language:
TypeScript 2.7.1

Current behavior:
Unable to load app due to templating error for Aurelia-dialog.  This worked fine with Aurelia-bootstrap version 2.1.1. Updated to Aurelia-bootstrap 2.2.0 and now get the following error in Firefox.  Similar "recursive errors" show up in Edge and Chrome as well.
DEBUG [templating] importing resources for aurelia-dialog/ux-dialog-footer
Array []
vendor-bundle.js:14042:8
Unhandled rejection InternalError: too much recursion
_compileElement@http://localhost:9000/scripts/vendor-bundle.js:21438:9
_compileNode@http://localhost:9000/scripts/vendor-bundle.js:21252:18
_compileNode@http://localhost:9000/scripts/vendor-bundle.js:21274:28
compile@http://localhost:9000/scripts/vendor-bundle.js:21221:7
compile@http://localhost:9000/scripts/vendor-bundle.js:22695:37
_compileElement@http://localhost:9000/scripts/vendor-bundle.js:21528:16
_compileNode@http://localhost:9000/scripts/vendor-bundle.js:21252:18
_compileNode@http://localhost:9000/scripts/vendor-bundle.js:21274:28
compile@http://localhost:9000/scripts/vendor-bundle.js:21221:7
compile@http://localhost:9000/scripts/vendor-bundle.js:22695:37
_compileElement@http://localhost:9000/scripts/vendor-bundle.js:21528:16
_compileNode@http://localhost:9000/scripts/vendor-bundle.js:21252:18
_compileNode@http://localhost:9000/scripts/vendor-bundle.js:21274:28
compile…
vendor-bundle.js:1398:13
Expected/desired behavior:
The templating to load the Aurelia-dialog-footer without the recursion error
To reproduce update the Aurelia-bootstrapper to version 2.2.0 in a project that has the Aurelia-dialog working with Aurelia-bootstrapper 2.1.1

What is the expected behavior?
For the Aurelia-dialog to import its resources properly without error

What is the motivation / use case for changing the behavior?

Same here... Serious bummer.

If you look at changes between 2.1.1 and 2.2.0, only the dependencies changed
https://github.com/aurelia/bootstrapper/compare/c781a80515d35c9ab2f571138fe916d2bfe47d1f...master

Try a clean install of the dependencies.

Will do. I think this means I just delete node_modules folder and run npm install? If not, how does one perform a clean install of dependencies

Yes, delete and install.

That did the trick. I did update NPM to version 5.6.0 in the meantime

I am running into this issue and a clean install didn't help me.  I'm using NPM 5.7.1


FR: Allow other languages than english

I am a German guy and I write nearly all of my notes in German. I think it would helpful for a lot of people to be able to switch to the most common languages (using different language models for POS tagging in the background)

second that.
could you please let people select the language via YAML Frontmatter?
language: de
for example for the german language.

Suggetion: One language as the default, YAML for the exception. ;-)

Similar, it would go a long way to support most languages.
This likely could be done quite easily by enabling dictionary support:
Look up work in a dictionary, get type of speech, use that as default. When more context dependent info can be determined, update. E.g., some words might be multiple types but by choosing a default or use basic analysis to get a more accurate result would be better than nothing. When compromise gets more languages added then that can be used to fine tune the basic models.

I second that.
But i would also like to be able to customize- say if the plugin used a list of words in plaintext we could acess, changes could be made- from adittion and removals to users thenselves using auto-translate or pasting dictionaries/lists from whichever source/language they want.
I would also love 1 extra category: custom. A color for a custom list of words... or a button to add however many more as custom.


Bottom sheet sometimes crashes

https://issuetracker.google.com/issues/348468116

Setting Color.Unspecified for now to avoid crashing. Will revisit if the Issue Tracker is ever shuffled to done.


Not able to send notification to teams channel

Describe the Bug with repro steps
I am trying to send alert I get through http request to Teams channel. But, it's not working in any case. We have a prod release next week.
Please keep it on priority
What type of Logic App Is this happening in?
Consumption (Portal)
Are you using new designer or old designer
New Designer
Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg
Yes
Workflow JSON
No response
Screenshots or Videos
No response
Browser
chrome
Additional context
No response

Can you please provide some more information or repro steps on what is happening? I'm actually going to close this because there really isn't anything to go off of here. If it's an urgent production level issue I highly recommend opening an Azure Support case so our support team can help get the information we need to help.


General option is bug

[ ] I believe this to be a bug, not a question about using URL Auto Redirector.

My OS

[ ] I am on (or have tested on) Windows 10+

My Chrome Version

[ ] The rules do not work.

My Reproduction Steps

Step 1
Option: "Redirect in current tab" dont work.

Step 2
Try other option: "Redirect in new tab" is work a new tab with 2 open?

Step 3
Suggestion: first new tab is close and second tab ok

Redirect in current tab: will redirect in current tab with new URL
Redirect in new tab: you will not only open the unredirected URL in current tab, but also open a new tab for the redirect URL

I didn't find anything wrong on my computer and I guess I misunderstand what u describe


K8SPXC-279 Add operator admin user

Test name
Status

recreate
failed

scaling
failed

init-deploy
failed

storage
failed

big-data
failed

scaling-proxysql
failed

self-healing
failed

restore-to-encrypted-cluster
failed

limits
failed

monitoring
failed

upgrade
failed

demand-backup
failed

self-healing-advanced
failed

upgrade-consistency
failed

operator-self-healing
failed

scheduled-backup
failed

security-context
failed

monitoring-2-0
failed

demand-backup-encrypted-with-tls
failed

affinity
failed

one-pod
failed

auto-tuning
failed

proxysql-sidecar-res-limits
failed

Test name
Status

storage
passed

recreate
passed

scaling
failed

big-data
failed

init-deploy
passed

scaling-proxysql
passed

self-healing
passed

limits
passed

restore-to-encrypted-cluster
failed

monitoring
passed

upgrade
failed

demand-backup
passed

upgrade-consistency
passed

self-healing-advanced
failed

monitoring-2-0
passed

security-context
passed

affinity
passed

one-pod
failed

auto-tuning
passed

operator-self-healing
failed

scheduled-backup
passed

proxysql-sidecar-res-limits
passed

demand-backup-encrypted-with-tls
passed

Test name
Status

init-deploy
failed

scaling
passed

big-data
failed

storage
passed

recreate
passed

limits
passed

scaling-proxysql
passed

monitoring
passed

upgrade
failed

self-healing
failed

restore-to-encrypted-cluster
passed

self-healing-advanced
passed

monitoring-2-0
passed

operator-self-healing
passed

affinity
passed

demand-backup
passed

one-pod
passed

auto-tuning
passed

proxysql-sidecar-res-limits
passed

scheduled-backup
failed

demand-backup-encrypted-with-tls
passed

upgrade-consistency
failed

Test name
Status

scaling
passed

init-deploy
failed

big-data
failed

storage
passed

recreate
failed

limits
passed

self-healing
failed

self-healing-advanced
passed

restore-to-encrypted-cluster
passed

monitoring
passed

scaling-proxysql
passed

operator-self-healing
passed

upgrade
failed

monitoring-2-0
passed

demand-backup
passed

affinity
passed

scheduled-backup
passed

one-pod
failed

auto-tuning
passed

proxysql-sidecar-res-limits
passed

demand-backup-encrypted-with-tls
failed

upgrade-consistency
failed


Mergeable Removal of test spam

Subset of https://github.com/zulip/zulip/pull/15769 which is mergeable. Solves part of #1587
Testing Plan:
GIFs or Screenshots:

@timabbott Please review.

Merged as b2745f6e41708ac45b3a15fdb08a888826d462a5, after squashing all the test_auth_backends changes into one commit.  Thanks @thedeveloperr!


The set-output command is deprecated and will be disabled soon

Describe the feature
The ::set-output:: function is deprecated in favor of using the GITHUB_OUTPUT environment file
Use Case
The set-output function is insecure according to this notification: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

@donfirst Thx!
Migrate in https://github.com/poad/aws-cloudformation-stack-status-checker/commit/c54c023400b4ada8be212fc667d9e782e4a24542

@poad  Can you create a new release, please :-)
The current one doesn't have your fix

@poad all good :-) thank you


Support Live Streamed Videos

Downloading streams is the same process as downloading videos.
The problem was that our function to get all of a channels videos doesn't
get all videos under /streams so I just added another sub process call to
yt-dlp using the same flags but with /streams instead of /videos

nice solution


Add length-normalized DPO

What does this PR do?
This PR adds the length-normalized DPO used in Tulu-3 and introduced in the SimPO paper under dpo_norm loss type. This implementation and naming were inspired by the Open-Instruct implementation [1] [2].
Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[x] Did you read the contributor guideline,
Pull Request section?
[ ] Was this discussed/approved via a GitHub issue? Please add a link
to it if that's the case.
[ ] Did you make sure to update the documentation with your changes? Here are the
documentation guidelines.
[ ] Did you write any new necessary tests?

Who can review?
Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

Hey, thanks for contributing!
Is it really a loss type? It seems to me that it can be combined with any loss type, no?
What about having a new arg in DPOConfig? maybe length_normalize?
Also, I'd add a test for this


Android O: Remove dependency on manifest receivers for implicit broadcasts

Remove all dependencies on implicit broadcasts to manifest receivers.

Fixed in #434


Remove deprecated trainer_optimizer_mixin

What does this PR do?
Remove deprecated API.
Before submitting

[x] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you make sure to update the documentation with your changes? (if necessary)
[ ] Did you write any new necessary tests? (not for typos and docs)
[ ] Did you verify new and existing tests pass locally with your changes?
[ ] Did you list all the breaking changes introduced by this pull request?
[x] Did you update the CHANGELOG? (not for typos, docs, test updates, or minor internal changes/refactors)

PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing, make sure you have read the review guidelines. In short, see the following bullet-list:

[ ] Is this pull request ready for review? (if not, please submit in draft mode)
[ ] Check that all items from Before submitting are resolved
[x] Make sure the title is self-explanatory and the description concisely explains the PR
[ ] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
Make sure you had fun coding 🙃

I haven't deleted the trainer/optimizer.py which should be deleted since it doesn't have anything to be used. Let me know if you want me to delete it


Cast directly to String

The typeof check is kind of unnecessary, String(str) is just str.

The conditional there was based on some results from: https://jsperf.com/string-wrapping-overhead
Which actually showed a biggered difference in Chrome at least, when I ran it before. I should make a new benchmark with the conditional as well.

My old benchmark was mostly just to show that casting is better than passing non-string values to textContent.
I created a new benchmark that tests conditionally casting vs always casting in three scenarios:

Inputs are mostly strings
Inputs are mostly numbers
Inputs are equally often strings and numbers

https://jsperf.com/string-wrapping-overhead-again
Results in Chrome seem somewhat random to me, with no significant difference in performance. In Firefox always casting is (significantly) faster. Probably best to save the bytes and just always cast, but just to make sure someone should run the benchmark other browsers too, since it clearly does impact performance, and this is probably one of the hot paths.

  string += typeof value === String ? value : String(value);

Should be typeof value === 'string'

So I realize that String and new String are quite different, and I was thinking of the differences between string primitives and String objects returned from the String constructor. This isn't that and String(s) can obviously do a typeof equivalent check internally. So this looks good to me.
Also, jsperf was failing to save my edits to the micro benchmark 😡

Good point about the typeof check, I'll fix it and re-run. Unfortunately
jsperf is super unreliable in editing. :(
On Thu, Sep 20, 2018, 05:52 Justin Fagnani<EMAIL_ADDRESS>wrote:

So I realize that String and new String are quite different, and I was
thinking of the differences between string primitives and String objects
returned from the String constructor. This isn't that and String(s) can
obviously do a typeof equivalent check internally. So this looks good to me.
Also, jsperf was failing to save my edits to the micro benchmark 😡
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Polymer/lit-html/pull/497#issuecomment-423031681, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEEyowwePmXOoZ5W19yDR_6D3gs_3UTks5ucxENgaJpZM4Wml9Y
.

I had to create a new benchmark again because jsperf borked. Here is a proper version that also runs in all browsers:
https://jsperf.com/string-wrapping-overhead-fixed/1
Takeaway is that the String() cast DOES add a considerable overhead if the source was already a string. Probably because String('someString') does not return the same object, but constructs a new String object in memory that is a copy of the input, and returns that.
The condition check also adds some overhead, but less than casting. Ofcouse if the input is mostly non-string values, the performance of the conditional is worse because it's just added overhead, but if the input is mostly strings, the conditional version is significantly faster (~10% on most browsers).
My testing indicates that always casting is the most consistent method, regardless of the type of inputs. When the input is mostly strings, conditionally casting is universally faster. When the ratio of strings vs non-strings becomes too low, the conditional becomes slower. The tipping point is browser dependent.
I estimate the minimum ratio of Strings to make the conditional faster to be around 50% in Chrome, 20% in Edge, and 0% in IE11 (conditional is always faster in IE11). Note that the tests are a little flaky and variance is high, so you have to re-run the tests several times to get a reasonable indicator. I tested Chrome, Edge, and Internet Explorer.
I expect most inputs to be strings, so generally I think performance will be better with the conditional.

@ruphin I wanted to come back to this but JS Perf is broken again. Would you mind putting your benchmark up at https://esbench.com/ ?

JSperf deleted all my tests unfortunately. I'm trying to rewrite them from memory on esbench.

I updated the benchmark:
https://esbench.com/bench/5bc87f53f2949800a0f6217d
I think the results are the same as my previous tests. String() has an overhead cost, so always casting is not 'free'. From the benchmarks, even in scenarios where most of the values are non-string, checking before casting performs nearly equal to always casting, and when ~20% or more of the values are strings, checking before casting becomes significantly more efficient.

I'm also pretty sure there's some memory efficiency in checking before casting, since String(<string>) will create a new string object, and it's cheaper to just use the existing reference (I think).


Added models and descriptions for 4-poly triangular pyramids to visualisation documentation.

Added 2 new models and descriptions for triangular pyramids.
related to this FLAMEGPU-visualiser PR: https://github.com/FLAMEGPU/FLAMEGPU2-visualiser/pull/91

Thanks for fixing the rogue period too.

Ha, I couldn't help myself.

Will merge this when I get around to testing Vis.

Awesome :)


Ajax jsonp calls to /graph/neighbors returns different JSON structure

When writing an ajax call with the client I am expecting back a JSON blob in the BBOP graph format; however, I'm getting a different JSON structure @ccondit suspects it may be serializing the tinkergraph.
For example:
    {"vertices":[{"id":"78968","propertyKeys":["category","http://zfin/definition/source_information",...

Is it possible to add an option to return a specified format or return the bbop graph format as a default?

Added CORS for now. Look into fixing the default JSONP response or removing the JSONP functionality.

I am occasionally seeing this error on my client:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://geoffrey.crbs.ucsd.edu:9000/scigraph/graph/neighbors/HP:0012638.json?depth=1&blankNodes=false&relationshipType=subClassOf&direction=INCOMING&project=*. (Reason: CORS header 'Access-Control-Allow-Origin' does not match 'http://localhost:8080').
It seems to work sometimes and sometimes not.  Could this be an issue with my client or is this related to the cors settings on the scigraph server?

Is it some call in particular or it just happens intermittently?

I haven't been able to reproduce the issue so it may have been related to being on the OHSU network.  I'll test again on Monday.

Please reopen if this is still an issue.


Browser support

I haven't been able to found more detail, so pardon this question via issue. As this is a websocket solution, this should enable all gRPC features over websocket, including bidirectional / client streaming.
So, I'd like to ask, are there any browser (JS) client implementation for this implementation of gRPC-WebSocket?
If there isn't (yet), is there any plan to develop one?
As modern web frameworks are rapidly evolving and more things can be achieved in-browser, being able to use gRPC in browser would be awesome, as IMO restricting gRPC for server-to-server only is quite a limiting view.

I'm definitely no browser nor JS expert, bit it sounds like the full gRPC features cannot currently be done in the browser due to gRPC's reliance on HTTP/2.
Unfortunately I do not know of any gRPC protocol which supports client-side nor bi-di streams. From what I can tell, the official gRPC-Web protocol is just going to wait for the whatwg streams API. It seems like even https://github.com/improbable-eng/grpc-web does not plan on implementing this until the streams API is available (though, there was a POC at one point). I know we do not plan on implementing this because it is not needed for the StackRox project.
I'm sorry I was unable to respond with any good news for you, but hopefully that streams API will come into fruition soon!