Added support for Discounts (Shopify Plus)

I asked for this at Unite and was told to just simply do a pull request so here it is :+1:
Tests passed on my end with Bundler:

Get a discount
Get all discounts
Delete a discount
Enable a discount
Disable a discount

JSON pulled from Shopify docs.

Added newlines to JSON resources.

Thanks!


Error: Suite title should be a "string" but "function" was given instead.

Hi,
I using 'istanbul' to create coverage for 'mocha' unit testing, the unit testing is successes each time before adding istanbul but after adding it mocha test failed each time
  1) skip
  2) only

  2 failing

  1)  skip:
     Error: Suite `title` should be a "string" but "function" was given instead.

  2)  only:
     Error: Suite `title` should be a "string" but "function" was given instead.

and I don't use skip and only in my test!
I tried to downgrade mocha as some one suggest but this don't solve this issue
I currently using mocha 3.2.0

take a look https://github.com/Polymer/web-component-tester/issues/532


llama awq4 result is wrong!

System Info

GPU:L40S
Tensorrt-llm:0.11.0.dev2024060400
cuda:cuda_12.4.r12.4/compiler.34097967_0
driver:535.129.03
os:DISTRIB_DESCRIPTION="Ubuntu 22.04.4 LTS"(docker)

Who can help?
No response
Information

[x] The official example scripts
[ ] My own modified scripts

Tasks

[ ] An officially supported task in the examples folder (such as GLUE/SQuAD, ...)
[x] My own task or dataset (give details below)

Reproduction
# my mmproject need 576*2
MAX_MULTIMODAL_LEN=$((576 *2* BATCH_SIZE))
function llama_to_engine(){
    model_name=$1
    if [ ! -d ${CHECKPOINT_PATH} ];then
       python $convert --model_dir $HF_MODEL \
                                --output_dir $CHECKPOINT_PATH \
                                --dtype $dtype \
                                --tp_size 1
    fi
    if [ ! -d ${ENGINE_PATH} ];then
        message "尝试转换checkpoint为TensorRT Engine"
        trtllm-build --checkpoint_dir $CHECKPOINT_PATH \
                    --output_dir $ENGINE_PATH \
                    --enable_debug_output \
                    --gemm_plugin float16 \
                    --use_fused_mlp \
                    --max_batch_size $BATCH_SIZE \
                    --max_input_len 2048 \
                    --max_output_len 512 \
                    --gather_all_token_logits \
                    --max_multimodal_len $MAX_MULTIMODAL_LEN \
                    --gemm_plugin $dtype
    fi
function llama_to_quant_engine(){
    model_name=$1
    checkpoint_dir=$2
    engine_dir=$3

    if [ ! -d ${checkpoint_dir} ];then
    message "Try to extract $model_name to $checkpoint_dir"
    python $quantize --model_dir $model_name \
            --output_dir $checkpoint_dir \
            --dtype $dtype \
            --qformat int4_awq \
            # --qformat w4a8_awq \
            --awq_block_size 128 \
            --calib_size 32
    fi

    if [ ! -d ${engine_dir} ];then
    message "Try to convert $checkpoint_dir to $engine_dir"
    trtllm-build --checkpoint_dir $checkpoint_dir \
            --output_dir $engine_dir \
            --gpt_attention_plugin $dtype \
            --gemm_plugin $dtype \
            --max_batch_size 8 \
            --max_input_len 2048 \
            --paged_kv_cache enable
            else
                message "${engine_dir} 已经存在"
    fi
}
# Inference is similar to llava

I trained a new llava model using vit, llama3, and my own mmprojectors. I found that after converting to tensorrt, the output under float16 was almost identical to hf, but after quantization, the results were completely incorrect. I ran some metrics on the evaluation set, and the metrics dropped from 80% to 20%. I want to know what caused this difference.
image:https://github.com/360CVGroup/360VL/blob/master/docs/008.jpg
prompt:请描述一下图片的内容
float16（right  result）：
这张照片的特点是一个年轻的亚洲男性角色，可能来自动画或漫画，穿着正式的服装，包括一件蓝色夹克，白色衬衫和红色领结。他的头发是黑色的，向后梳着，戴着一副黑框眼镜。这个角
  有一个突出的鼻子和一个紧张的表情，表现为他睁大的眼睛和微张的嘴巴。他的眼睛是蓝色的，眉毛上扬，给人一种惊讶或关切的感觉。背景是模糊
```
w4a8_awq(wrong)：
```
这张照片描绘了一个充满活力的城市景观，高耸的摩天轮和现代化的建筑物体占据了天际。天际线上，各种交通工具如飞机、火车和汽车在运送着人们。下面，熙熙攘攘的街道上，人们在忙着各种活动。
```
int4_awq(wrong):
```
这张照片显示了一个宁静的湖泊，湖面平静，周围绿树。
```

My Questions:
1. I noticed that the dataset used for quantitative calibration is cnd_dailymail, and I am not sure if it is reasonable to use it to calibrate a multimodal model. If it is not reasonable,how should we construct a calibration dataset to calibrate llm? After quantifying LLM with AutoAWQ at 4 bits, I found that the output of the same problem before and after quantization 2. is almost identical. Is there any way to convert AutoAWQ's model into an Engine?
3. Is TensorRT's AWQ algorithm and AutoAWQ algorithm exactly the same?

@Barry-Delaney could u please take a look this issue?

@bleedingfight thanks for the feedback. I think one possible reason is incorrect calibration dataset for multimodal tasks.
Regarding your questions:
A1. For using your own calibration datasets, please pass the directory through calib_dataset.
A2. For support AutoAWQ produced checkpoints, please refer to the GPTQ support in the load_weights_from_gptq function, as they are supposed to be similar.
A3. I think this question is left for modelopt team. cc @nv-guomingz.

@Barry-Delaney What I want to know is how to construct this dataset? My training data is a image text pair, but I only quantify LLM, so theoretically, I should only calibrate LLM. Is my calibration data an embedding input for llama? Or is it the part where the text is extracted from the image text alignment?

https://github.com/NVIDIA/TensorRT-Model-Optimizer/blob/main/llm_ptq/README.md#model-support-list


Split out enum trait generation

This change makes the generation of EnumTraits configurable. With this
change we can see reductions in code size by over 1MB. Example file
size changes:

File
src (KB)
.h (KB) before
.h (KB) after

hci_events.emb
76
5356
3884

hci_commands.emb
108
5612
4268

hci_vendor.emb
32
1748
1304

hci_common.emb
32
644
368

hci_data.emb
4
152
104

l2cap_frames.emb
4
48
40

hci_h4.emb
4
8
4

This is also helpful for embedded users who couldn't use emboss due to
dependencies on string libraries and functions like sscanf.
This change is split out into a series of patches to make it easier to review:

Add forward declarations for text helpers - Cleanup in preparation for the following changes. This allows us to remove the dependency on emboss_text_util.h from the core runtime files.
Split out enum trait generation - This is the main change, it adds a configuration flag that controls whether or not enum trait and various text helpers are generated
Add --no-cc-enum-traits param adds a CLI flag for toggling the internal configuration
Add bazel support for disabling enum traits adds an attribute to the emboss_cc_library to control the enum traits configuration as well as tests to make sure it works

This is part of #128

Note: this builds on top of PR #133, the relevant changes start at the Add forward declarations for text helpers patch. FYI @robrussell


Fix some Thai translations

I fixed some typos and change one translation to a better understandable one (Crew man).

Thanks for accepting my pull request! Me and my friend loves playing your game 😀
Will it be deployed on spyfall.crabhat.com?

Thanks for the updated translation! It should now be live on spyfall.crabhat.com :-)


Challenges show green tick but test cases show Red crosses

Hi ,
I am facing this issue all around. All the challenges i have completed show as green and faded ie completed. But when i go into the code, I see that the code i have written seems to be lost. also test cases which were passed are now red crosses or failed.
Where can i see my completed code. I need to urgently revisit the code for some project i am involved in.

@kpbeng you can revisit your challenge solutions on your FreeCodeCamp profile at https://www.freecodecamp.com/YOURUSERNAME where YOURUSERNAME if whatever username you have chosen for FreeCodeCamp. I hope this helps.


Type 'SignalClient' does not conform to protocol 'WebSocketDelegate'

I have some problems - in SignalClient file
"Type 'SignalClient' does not conform to protocol 'WebSocketDelegate'"
http://joxi.ru/BA0Leg0HJw1zXA
Xcode want to add only
func websocketDidReceiveData(socket: WebSocketClient, data: Data)
But all protocol methods are implemented.
Can you help me please?

Click on the button (red with white in the middle) and get some more details, and perhaps an automatic fix.

my same case, I give in the fix button and a few moments later xcode sends me the same message again

Don't call it "WebSocketClient". This seem to clash with some Starscream stuff. Call it SocketClient and good


Remove the 20px offset below the topbar

Screenshots, for A/B comparisions. First is this PR.

It probably isn't super obvious from the screenshots, but everything on the page is like, 20px higher.

Maybe those 20px gaps are historical and not needed anymore?

The original calculation with +20px was added in https://github.com/pydata/pydata-sphinx-theme/pull/286
Now I also don't remember why it was needed there (this doesn't change that you can tweak the header-height itself), and I agree that it looks better after this change :)
Thanks @pradyunsg !


bug:  animation of marquee-vertical might have some error

module.exports = {
  theme: {
    extend: {
      animation: {
        marquee: "marquee var(--duration) linear infinite",
        "marquee-vertical": "marquee-vertical var(--duration) linear infinite",
      },
      keyframes: {
        marquee: {
          from: { transform: "translateX(0)" },
          to: { transform: "translateX(calc(-100% - var(--gap)))" },
        },
        "marquee-vertical": {
          from: { transform: "translateY(0)" },
          to: { transform: "translateY(calc(-100% - var(--gap)))" },
        },
      },
    },
  },
};```

in the component provided above I think

instead of ```   "marquee-vertical": "marquee-vertical var(--duration) linear infinite",```

   ```marquee-vertical: "marquee-vertical var(--duration) linear infinite" ```, This should be the the go to code and it might create some errors

sorry can you please clarify the difference? @rahulsingh3526

closing issue for now as it works locally


sum/reduce op does not work for random inputs

Describe the bug
The sum op (reduce) has large error for non integer inputs. Currently in test_sum.py only the summation of integers is tested - this is not sufficient and fails for random fp32 and bfloat16 inputs.
I added a test that uses random inputs and different data formats, and compares using comp_allclose. This test should pass.
What I see:
BF16 shape = (1, 1, 32, 32)
ref vs tt = Max ATOL Delta: 0.0625, Max RTOL Delta: 0.068359375, PCC: 0.9999956409523759, Allclose check failed
FP32 shape = (1, 1, 32, 32)
ref vs tt = Max ATOL Delta: 0.05738258361816406, Max RTOL Delta: 0.02300325594842434, PCC: 0.9999959183719673, Allclose check failed
BF16 shape = (1, 1, 32, 1024)
ref vs tt = Max ATOL Delta: 2.75, Max RTOL Delta: 0.279296875, PCC: 0.9998845309940628, Allclose check failed
FP32 shape = (1, 1, 32, 1024)
ref vs tt = Max ATOL Delta: 1.9558944702148438, Max RTOL Delta: 0.3209826350212097, PCC: 0.9998569160517634, Allclose check failed
Even adding two numbers fails:
Two input numbers: 1.9297, 1.4844 (all other numbers in tensor are zero)

Sum over that dim:
Torch reference (bf16): 3.4062
Torch reference (fp32): 3.4141
FP32: 3.4219
BF16: 3.4219
BFP8_B: 3.4375
BFP4_B: 3.0

For larger shapes, e.g. [32, 1024] or [2048, 1024], this error accumulates to very large numbers.
To Reproduce
Steps to reproduce the behavior:

Checkout jrock/reduce-issue
Run pytest tests/tt_eager/python_api_testing/unit_testing/misc/test_sum.py::test_sum

The issue also exists with different reduction dims:
Two input numbers: 1.9297, 1.4844
dtype=bfloat16
sum_global
torch: 3.4062
tt: 3.4219
grep -Rnw 'built' -e 'REDUCE_DIM'
built/2052/kernels/reduce_w/4495494718154647535/defines_generated.h:2:#define REDUCE_DIM ReduceDim::REDUCE_ROW
built/2052/kernels/reduce_h/15874065893775173914/defines_generated.h:2:#define REDUCE_DIM ReduceDim::REDUCE_COL
Sum in H
torch: 3.4062
tt: 3.4219
grep -Rnw 'built' -e 'REDUCE_DIM'
built/2052/kernels/reduce_h/15874065893775173914/defines_generated.h:2:#define REDUCE_DIM ReduceDim::REDUCE_COL
Sum in W
torch: 3.4062
tt: 3.4219
grep -Rnw 'built' -e 'REDUCE_DIM'
built/2052/kernels/reduce_w/4495494718154647535/defines_generated.h:2:#define REDUCE_DIM ReduceDim::REDUCE_ROW

fyi: @uaydonat

by taking a quick look at the impl it seems that reduce in metal doesn't support 32 bit acc (no matter which tensors are passed in)

Repro

branch: cglagovich/fp32_slow_reduce

pytest -svv  tests/tt_eager/python_api_testing/unit_testing/misc/test_sum.py::test_sum[shape_dim0-BFLOAT16]

ref vs tt = Max ATOL Delta: 0.0625, Max RTOL Delta: 0.068359375, PCC: 0.9999956409523759, Allclose check failed
expect:  tensor([  6.9688,  -4.8750,   2.3125,   6.0000,   5.6562,  -7.2188,   4.8438,
          2.4688,  -0.8047,  -2.2500,   2.7656,   3.6875,  -1.5156,  -0.0605,
          0.7969,  -4.5938,  -6.1562,   5.8125,  -3.6562,   6.2812,  -6.8125,
          6.2188,   6.9062,   4.6562,  -6.0000,  -4.7188,   3.6094, -12.6250,
          6.2188,  -2.2188,  -9.8125,   7.0938], dtype=torch.bfloat16)
got:  tensor([  7.0000,  -4.8750,   2.3281,   6.0000,   5.6562,  -7.2188,   4.8750,
          2.4688,  -0.7812,  -2.2500,   2.7656,   3.7031,  -1.5234,  -0.0564,
          0.7891,  -4.5938,  -6.1562,   5.8125,  -3.6562,   6.2812,  -6.8125,
          6.2188,   6.9062,   4.6562,  -6.0000,  -4.7500,   3.6094, -12.5625,
          6.2500,  -2.2344,  -9.8125,   7.0938], dtype=torch.bfloat16)

Now I modify the reduce_w.cpp file to make the unpacker perform reduce_sum with fp32 accumulation.
These are the results with fp32 accumulation:
ref vs tt = Max ATOL Delta: 0.0625, Max RTOL Delta: 0.0069580078125, PCC: 0.9999964480552922, Allclose check failed
expect:  tensor([  6.9688,  -4.8750,   2.3125,   6.0000,   5.6562,  -7.2188,   4.8438,
          2.4688,  -0.8047,  -2.2500,   2.7656,   3.6875,  -1.5156,  -0.0605,
          0.7969,  -4.5938,  -6.1562,   5.8125,  -3.6562,   6.2812,  -6.8125,
          6.2188,   6.9062,   4.6562,  -6.0000,  -4.7188,   3.6094, -12.6250,
          6.2188,  -2.2188,  -9.8125,   7.0938], dtype=torch.bfloat16)
got:  tensor([  6.9688,  -4.8438,   2.3125,   5.9688,   5.6250,  -7.2188,   4.8125,
          2.4688,  -0.8008,  -2.2344,   2.7656,   3.6875,  -1.5156,  -0.0605,
          0.7969,  -4.5938,  -6.1562,   5.7812,  -3.6406,   6.2500,  -6.7812,
          6.2188,   6.9062,   4.6562,  -6.0000,  -4.7188,   3.5938, -12.5625,
          6.2188,  -2.2188,  -9.7500,   7.0625], dtype=torch.bfloat16)

All I can say with this result is that the reduce_tile impl lacking fp32 accumulation does not have an impact on single tile reductions. I would have to see if this holds for larger inputs.

https://github.com/tenstorrent/tt-metal/tree/pjosipovic/reduce32_hack
I've hacked here an implementation for 32 bit (other data formats won't work), I'm getting significantly better absolute error with this one.
So our FPU supports only TF32 on input which is 19bit so you will get some error here converting from 32 -> 19 bits,
but accumulation for sum will be in 32 bit.

@pavlejosipovic Could you please post your concrete results in here?

It looks like tt_metal/common/bfloat16.hpp converts fp32 to bf16 with truncation. Another thing we can try is to use round to even to see if we match pytorch in bf16

I tested Pavles hack to use F32 accumulation + FP32 reduce scalar versus what we have in main.
I have:

BF16 and FP32
shape0 = [1,1,32,32], shape2=[1,1,2048,1024] <-- this is what we use in falcon40b/llama2

Here's the numbers:
Pavles hack:
tests/tt_eager/python_api_testing/unit_testing/misc/test_sum.py::test_sum[shape_dim0-FLOAT16]
ref vs tt = Max ATOL Delta: 0.0625, Max RTOL Delta: 0.0069580078125, PCC: 0.9999964480552922

tests/tt_eager/python_api_testing/unit_testing/misc/test_sum.py::test_sum[shape_dim2-FLOAT16]
ref vs tt = Max ATOL Delta: 7.0, Max RTOL Delta: 146.0, PCC: 0.999613593394302

tests/tt_eager/python_api_testing/unit_testing/misc/test_sum.py::test_sum[shape_dim0-FLOAT32]
ref vs tt = Max ATOL Delta: 0.01207733154296875, Max RTOL Delta: 0.05839734151959419, PCC: 0.999999920943286

tests/tt_eager/python_api_testing/unit_testing/misc/test_sum.py::test_sum[shape_dim2-FLOAT32]
ref vs tt = Max ATOL Delta: 1.0089340209960938, Max RTOL Delta: 11.569167137145996, PCC: 0.9999937538630723

Main:
pytest tests/tt_eager/python_api_testing/unit_testing/misc/test_sum.py::test_sum[shape_dim0-BFLOAT16]
ref vs tt = Max ATOL Delta: 0.0625, Max RTOL Delta: 0.068359375, PCC: 0.9999956409523759

pytest tests/tt_eager/python_api_testing/unit_testing/misc/test_sum.py::test_sum[shape_dim2-BFLOAT16]
ref vs tt = Max ATOL Delta: 4.25, Max RTOL Delta: 177.0, PCC: 0.9998324133471583

pytest tests/tt_eager/python_api_testing/unit_testing/misc/test_sum.py::test_sum[shape_dim0-FLOAT32]
ref vs tt = Max ATOL Delta: 0.05738258361816406, Max RTOL Delta: 0.02300325594842434, PCC: 0.9999959183719673

pytest tests/tt_eager/python_api_testing/unit_testing/misc/test_sum.py::test_sum[shape_dim2-FLOAT32]
ref vs tt = Max ATOL Delta: 4.801029205322266, Max RTOL Delta: 33.93199157714844, PCC: 0.9998304449987134

Conclusions:

Pavles hack improves FP32 reduction around 5x.
It also seems to increase error on BF16 for some number ranges? (see shape2 BF16 Pavles hack vs. main) @pavlejosipovic Is this expected based on the hard coded reduce factor? Or is that still surprising to be worse rather than the same?

I've also tested:

Pushing data to device and back to host has 0 error for FP32 and BF16 (independent whether first converted to bf16 in torch or not)
Error for FP32 through casting to TF32 in the SFPU seems to be ~ 0.0019 absolute / ~0.0009 relative

why do I think so:
fp32 random tensor adding zeros (ttnn.add) gives Max ATOL Delta: 0.0019366741180419922, Max RTOL Delta: 0.0008975895470939577, PCC: 0.999999973943056
the error should come exclusively from casting in the SFPU, right?

BF16 pytorch vs FP32 pytorch:

shape0:
ref fp32 vs ref bf16 = Max ATOL Delta: 0.03125, Max RTOL Delta: 0.1328125, PCC: 0.9999988663652715

shape2:
ref fp32 vs ref bf16 = Max ATOL Delta: 0.5, Max RTOL Delta: 2.03125, PCC: 0.9999964523498722

So in almost all cases the pytorch difference between FP32 vs. BF16 is a lot less than the difference between pytorch and TT devices in the same dataformat.

In my version only 32 bit works, disregard everything else. In the final solution we can make all cases work.

It looks like tt_metal/common/bfloat16.hpp converts fp32 to bf16 with truncation. Another thing we can try is to use round to even to see if we match pytorch in bf16

In the following test I compared what happens if we push the input to device and just read it back without doing anything else with it:
inputs: pytorch ref fp32 vs pytorch ref bf16 = Max ATOL Delta: 0.015438079833984375, Max RTOL Delta: 0.0039054155349731445, PCC: 0.9999986212624355
inputs: pytorch ref fp32 vs tt fp32 = Max ATOL Delta: 0.0, Max RTOL Delta: 0.0, PCC: 1.0
inputs: pytorch ref bf16 vs tt bf16 conversion in TT, when pushing to device = Max ATOL Delta: 0.0, Max RTOL Delta: 0.0, PCC: 1.0
inputs: pytorch ref bf16 vs tt bf16 conversion in torch, then pushed = Max ATOL Delta: 0.0, Max RTOL Delta: 0.0, PCC: 1.0

So looks like the issue shouldn't be in the conversion, since pushing to device and reading it back is fine. So pytorch is probably doing the same?

In my version only 32 bit works, disregard everything else. In the final solution we can make all cases work.

Would you still expect an improvement for BF16 with your hack when generalized? Due to the FP32 accumulate I suppose?

Yes there would be some
On Thu, Jul 11, 2024, 3:41 PM Johanna Rock @.***> wrote:

In my version only 32 bit works, disregard everything else. In the final
solution we can make all cases work.
Would you still expect an improvement for BF16 with your hack when
generalized? Due to the FP32 accumulate I suppose?
—
Reply to this email directly, view it on GitHub
https://github.com/tenstorrent/tt-metal/issues/9908#issuecomment-2222972930,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADFR5JTEIEKLQ35DP6ANPN3ZL2DPDAVCNFSM6AAAAABKJJA4KCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRSHE3TEOJTGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

@pavlejosipovic Could you take over the more general implementation for this? Or should we ask someone else for it?

Is it the case that the scalar dataformat must be the same as the input dataformat for reduce_tiles?

If input is 32bit than scalar has to be 32bit to avoid converting input to 16 bit in the kernel.
For other input data types 16bit is fine.

@uaydonat @yieldthought What error do you think is realistic/expected here? How should we continue on this issue?

My understanding is that fp32 accum helps with the error. Because our inputs are fp16, we do not need the scalar->fp32 fix.
What's next?

port fp32 accum to SDPA kernel? see if pcc is fixed?
port fp32 accum to distributed layernorm? see if bad output tokens are fixed?

Raising priority since multiple tasks  are blocked by this.

I think the reason Johanna started looking into this is because her fp32 accum reduce_sum in distributed layernorm was producing more error than expected. In that case we need more data on this reduce_w test case to see if the error for bf16 inputs, fp32 accum makes sense

Correct. In distributed layernorm I'm passing in fp32 accumulation as argument but the error is still higher than expected and that's when I took a look at the test_sum test to double check.

what's the next step?

do we have more investigation to do? what exactly? e.g. do we need Pavle's hack but with bf16 inputs?
do we need to apply the hack to other kernels?

So Pavles hack was basically two things:
(A) use fp32 accumulation and
(B) use fp32 as reduce scalar.
(A) is (somewhat) helpful for both bf16 inputs and fp32 intputs but we've tried this also in e.g. distirbuted layernorm and the error is still large and more than we'd expect. So this is already used in other kernels and was only missing in the reduce op itself (but is used already in distributed layernorm and I believe in SDPA too).
(B) only helps in case of fp32 inputs but not for bf16 inputs.
I think we should
(1) At some point add Pavles hack for fp32 inputs (using the fp32 reduce scalar in that case improved the error 5x), but in my opinion that's not super high priority because we are not really interested in using fp32 inputs.
(2) Investigate further why we are still seeing so large error for both fp32 and especially bf16 inputs

@pavlejosipovic  is looking into this right now, he has learned that the reduce uses a matmul under the hood (and not SFPU as previously assumed) so it essentially does a dot product with all ones. This means there's more complexity than just adding two numbers including more configuration possibilities (e.g. HiFi settings make a difference there while they don't on SFPU). He's looking at a case where all numbers should be representable though bf16/fp32 and with fp32 accumulation there should in theory be no loss in precision - but he's also there seeing non negligible error there.

I'm still looking into this.
My new conclusion is that reduce sum works ok on dim 2 (reduce column), but reduce sum on dim 3 (reduce row) has issues with 32 bit accumulation and is loosing precision.
So depending on your use case if you are using dim 2 precision should be ok if you enable fp32 acc.
If you are using dim 3 there are precision issue and I'm working with @ttmtrajkovic to see if we can do something about it.

@johanna-rock-tt check out this branch https://github.com/tenstorrent/tt-metal/tree/pjosipovic/reduce_via_matmul_32bit_acc
I've enabled 32bit acc by default for reduce h/w
And I've changed the implementation for reduce sum on w dimension to use matmul llk instead of reduce llk.
I'm seeing a lot better precision with this.
I don't have any support for 32 bit inputs on this branch


mpi_cluster constructor with communicator arguments

Submission Checklist

[x] Run unit tests: ./runTests.py test/unit
[x] Run cpplint: make cpplint
[x] Declare copyright holder and open-source license: see below

Summary:
Addresses #939 , to allow mpi_cluster to be constructed with user-specified communicator, by adding constructor
  mpi_cluster(const MPI_Comm & comm, boost::mpi::comm_create_kind kind) :
    world_(comm, kind)
  {}

where comm could be a communicator other than MPI_COMM_WORLD.
Intended Effect:
New constructor of mpi_cluster
How to Verify:
unit test
Side Effects:
n/a
Documentation:
doxygen
Copyright and Licensing
Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company):
Metrum Research Group, LLC
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

I don't think we can move forward with this PR until we have figured out how this interacts with the use of MPI in stan-math in general. We used to discuss this is in issue's comments, but we should probably do this on discourse. What I am not yet understanding is how this interacts wit map_rect which essentially allocates the whole cluster once it starts. Are you suggesting to have a nesting system with 1 level? Anyway, I think a discussion on discourse will help us to get an idea of what needs to be done.

This ticket is more for pointing out direction. I agree it should be part of a bigger design. Besides I can always access MPI controls in PDE routines, so no problem.
In the meantime, I'd like to keep this issue open until resolution.

@yizhang-cae, I'm closing this PR because the issue is still open and will continue to stay open.


uv tree in workspaces including packages in dependency groups

Running uv version uv 0.4.28 (debe67ffd 2024-10-28)
I have two questions:

Why do I need an exclude for ["src/*.egg-info"]
Why is uv tree --no-dev including packages of the workspace

Also generally not quite sure how to structure my project; essentially a AWS CDK project with a bunch of Lambdas that need to be packages (each with only their own dependencies). https://github.com/jackvreeken/uv-export-test/tree/e0af8ba899a58f1ec326796f9fce36355301c5c2
My goals are to

Have a single uv sync install all the dependencies, including those required to mock-run the lambdas locally
Make it easy to export the requirements.txt for a specific lambda (need this format for CDK) Simplified setup of that here:

Project structure
.
├── pyproject.toml
├── src
│   ├── lambda_a
│   │   ├── __init__.py
│   │   ├── handler_a.py
│   │   └── pyproject.toml
│   └── lambda_b
│       ├── __init__.py
│       ├── handler_b.py
│       └── pyproject.toml
└── uv.lock

root pyproject.toml
EDIT: Included the [project] section.
[project]
name = "uv-export-test"
dynamic = ["version"]
requires-python = "~=3.12"

[dependency-groups]
dev = [
    "pre-commit >= 4.0.1",
    "lambda-a",
    "lambda-b",
]

[tool.uv.sources]
lambda-a = { workspace = true }
lambda-b = { workspace = true }

[tool.uv.workspace]
members = ["src/*"]
exclude = ["src/*.egg-info"]

The issue
This results in uv sync installing all the dependencies, so that's great.
uv tree --no-dev includes the lambda-a and lambda-b subtrees, which I don't understand. Leaving out the --no-dev option adds the dep tree for pre-commit at the bottom.
uv-export-test v0.0.0
├── lambda-a v0.0.0 (group: dev)
│   ├── boto3 v1.35.52
│   │   ├── botocore v1.35.52
│   │   │   ├── jmespath v1.0.1
│   │   │   ├── python-dateutil v2.9.0.post0
│   │   │   │   └── six v1.16.0
│   │   │   └── urllib3 v2.2.3
│   │   ├── jmespath v1.0.1
│   │   └── s3transfer v0.10.3
│   │       └── botocore v1.35.52 (*)
│   ├── pydantic v2.9.2
│   │   ├── annotated-types v0.7.0
│   │   ├── pydantic-core v2.23.4
│   │   │   └── typing-extensions v4.12.2
│   │   └── typing-extensions v4.12.2
│   └── urllib3 v2.2.3
└── lambda-b v0.0.0 (group: dev)
    └── boto3 v1.35.52 (*)

Note that without lambda-a and lambda-b in the dev group, the output of uv tree shows lambda-a and lambda-b at the root level, which feels a little confusing.
lambda-a v0.0.0
├── boto3 v1.35.52
...
lambda-b v0.0.0
└── boto3 v1.35.52 (*)
uv-export-test v0.0.0
└── pre-commit v4.0.1 (group: dev)
...

Aside from that, I also wonder why I need the exclude = ["src/*.egg-info"]. For some reason a uv_export_test.egg-info folder is made in src/

To clarify, is that the entire pyproject.toml? The tree below suggests you have more content in it, like a [project] table.

Totally right! Also some other sections (tool.ruff), but didn't want to clutter too much. Apparently also deleted the [project] section in the process 🙈

I totally missed that you included a repro link. Thanks!

Ok, I've fixed it in https://github.com/astral-sh/uv/pull/8730. Though it's correct to still show lambda-a and lambda-b at the top-level. It's a little confusing, but uv tree shows you the entire workspace. So, in my test case, where project depends on child as a dev dependency, I get the following with --no-dev:
child v0.1.0
└── iniconfig v2.0.0
project v0.1.0
└── anyio v4.3.0
    ├── idna v3.6
    └── sniffio v1.3.1

If you want to see just the tree for project, you need to pass --project project (or --project child, etc.).


skeleton-typescript-webpack2: initial version

Here's a skeleton for Webpack 2, which allows for tree-shaking when bundling (mapped to use the es2015 builds of Aurelia packages) in TypeScript.
It's largely based on the Webpack 1 version by @martijnboland, only minor changes were required to make it work with v2 and with TypeScript.
Similarly to the Webpack v1 skeleton, I haven't figured out the tests fully yet, perhaps somebody who has greater experience with this combination (Webpack+Typescript) could help out?
Pretty good references are the Angular2 starter packages:

https://github.com/AngularClass/angular2-webpack-starter
https://github.com/preboot/angular2-webpack

Nice job was muddling through this myself.  I just downloaded your webpack2 branks and it works well except for a minor problem in the production run, it fails with Uglify errors. If I remove the -p it works fine.  Below are the error msgs
ERROR in 0-1.0.0-beta.1.2.0.js from UglifyJs
Unexpected token: name (Animator) [./~/aurelia-templating/dist/es2015/aurelia-templating.js:44,0]
ERROR in main-1.0.0-beta.1.2.0.js from UglifyJs
Unexpected character '`' [./~/aurelia-pal/dist/es2015/aurelia-pal.js:9,0]
Thanks.

This does seem to be a duplicate effort to a PR we have been evaluating and modifying for webpack TS support already. We'll have to investigate the differences and see which one we should merge. @Vheissu Can you take a look at this?

@EisenbergEffect This PR appears to be specifically for Webpack 2 which is not officially released yet. The current Webpack Skeleton PR is for version 1. While version 2 is not out yet, I believe when it is released the current Webpack plugin we have will not work. It looks like @niieani actually forked the "aurelia-webpack-plugin" repository and made changes for version 2, here.
This PR definitely has merit though, there is overlap with the other Webpack PR, but the versioning is what differentiates it.

Is there some way that we could support both versions with the same plugin?

@Vheissu is correct - this is not only Webpack + Typescript but Webpack 2 + Typescript.
@EisenbergEffect I believe it would be possible to have a unified plugin for V1 and V2. The only change I've made to the plugin so far is to change the hardcoded default import from the commonjs to es2015 folder, which enables webpack2 to do tree-shaking (purge parts of Aurelia code which are unused by the specific app). The rest are changes in the build files which are contained in the skeleton-navigation. The original Webpack Plugin has problems with dynamic imports in views (there's a bug open there about it), and in the light of the new capabilities of Webpack in the second version, those could be fixed. I suppose a configuration option given to the plugin could be made to select which underlying Webpack version should be used.
@delebash I'm unable to reproduce, I do get warnings related to Aurelia's code, but you can safely ignore them. No fatal errors that would prevent the production build. Can anyone else reproduce?

@EisenbergEffect @Vheissu   This is a new skeleton as it combines WebPack with Typescript.  I was originally using https://github.com/arjendeblok/skeleton-navigation/tree/master/skeleton-typescript-webpack which worked well as long as you did not target ES6 in the tsconfig using the current AureliaWebpackPlugin. I believe the changes in the official plugin to AureliaWebpackPlugin2 as well as updating to webpack2.x fixed the problem when trying to target ES6 in the tsconfig.json.

@delebash I'm double-targeting - ES5 for development (this disables tree-shaking) and ES6 + Babel post-processing to ES5 for production (ES6 step enables tree shaking, further transpilation to ES5 is required for the code to work on non-ES6 browsers). Once Typescript implements the possibility to compile to ES5 while retaining es2015 modules, it will be possible to stop using Babel as the second step of Typescript production builds.

@niieani Well it was a late night I must have messed something up and then reverted, I can't reproduce the problem either, sorry for the trouble.  One of my main reasons for changing target to ES6 vs ES5 was so I can use the ES6 style import statement vs require when importing modules that do not have a default export such as jquery just as an example bad jquery bad :).  So I am looking for native ES6 to ES5 compiling in typescript as well instead of having to rely on another compiler

@niieani
System Info
Windows 7x64
Node 5.7.1
Npm 3.8.5
I take that back, I forgot that I had removed the -p switch.  I re-downloaded your skeleton executed npm run prod and I still get the same errors.  Also the compile time is very slow, is this due to webpack 2.x beta?
Thanks

@niieani Would you be interested to first submit a PR to update our plugin so it works with both versions of webpack? We would want it to default to v1 but be able to be configured somehow for v2. If you can do that, then we can have a strategy for the skeleton work based on that. Let me know.

@EisenbergEffect the earliest I could go back to dealing with that would be the end of the month. If somebody else wants to do that before, feel free to give it a go.

@niieani Now that we have the update to the plugin to enable both versions, how does this PR fit in?

@EisenbergEffect I'll need to update it. Since there are only a few changes, perhaps it would make sense to add alternative .webpack2 files in the Webpack 1 skeleton?

If it's only a few files, that sounds pretty reasonable.

Closing this one as https://github.com/aurelia/skeleton-navigation/pull/440 supersedes it.


Feature: handling custom requests

Ported https://github.com/atom/atom-languageclient/pull/249 to the new repo.

added missing onCustomRequest method
renamed onCustom to onCustomNotification

The CI failure is fixed in #131

@laughedelic Could you take a look at the suggestions?

@aminya yes, thanks for the review! I'll try to address it tonight.

@laughedelic are you able to reword the commits to start with fix: a lowercase word? If you are away from the keyboard, I can do that.

@aminya is it ok if I just squash them into one with the right format?

I'd prefer separate commits because it gives us more flexibility later for a potential reverting.
You can use the following to reword all the commits one by one:
git rebase -i 488f0033e8e8698a68becce2d78f35745318545e

Then find and replace pick with r in the opened document, and reword, save the document, close one by one.


Windows MSI is Not Understood as an MSI by Windows

When building running the generated MSI for my project I get the following error:

The workflow is here and the release is here.

I think it's solved. I pushed a new version of you would like to test it out: https://github.com/tauri-apps/tauri-action/pull/46

Oh, sweet. I'll try it out soon.

Took longer to get to trying this than I though but...It works!!! :tada:
Thanks a lot. I have spent over a month trying to simply get a Windows build of my Tauri application and now I have it. It's a big deal for me. Thanks!


Range input: Add a workaround to enable track color

Description
Wanted to add a workaround to add some color on the track part on the range input. I would be fine if this is not planned in Bootstrap, but I couldn't spot any issue/PR about it.
Motivation & Context
Could help folks to implement this functionnality.
Type of changes

[x] New feature (non-breaking change which adds functionality)

Checklist

[x] I have read the contributing guidelines
[x] My code follows the code style of the project (using npm run lint)
[x] My change introduces changes to the documentation
[x] I have updated the documentation accordingly
[x] I have added tests to cover my changes
[x] All new and existing tests passed

Live previews

https://deploy-preview-37499--twbs-bootstrap.netlify.app/docs/5.2/forms/range#via-javascript

Related issues
NA

Do we still want this @julien-deramond?

Do we still want this @julien-deramond?

Might be some things to tweak here and there in this PR but on my side I like the idea to provide a solution for folks out there totally optional that isn't embedded directly within the library.

Tried rebasing this and making it work again, but ran into an issue with the custom color not working. Might've been a bad rebase or merge, but want to take a crack at it @louismaximepiton? Happy to see this section added.


Windows Guest Agent Automatic Logs Collection - Disable

Windows Guest Agent Automatic Logs Collection
Can this be disabled and enabled if needed for troubleshooting?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ab75f449-661d-bd1e-3ebd-61e2384a911a
Version Independent ID: e7c93a31-6076-26b8-a53d-d36df01ec6bc
Content: Azure Virtual Machine Agent Overview
Content Source: articles/virtual-machines/extensions/agent-windows.md
Service: virtual-machines-windows
GitHub Login: @axayjo
Microsoft Alias: akjosh

@lostdoco , Thanks for raising the issue. We will investigate and update you.

@lostdoco I think we cant disable that.
@axayjo @cynthn Please add your comments

@axayjo Can you please look into this and add your comments.
Thanks.

We are currently cleaning up old issues and closing out items that are greater than 90 days old. If an issue is still present, please open a new feedback item on the document so we can prioritize correctly.
#please-close


Stable hlo binary and

Add support for binary and and add tests to tt-xla and tt-torch

Blocked by https://github.com/tenstorrent/tt-mlir/issues/1232


GEODE-6174: move exists method into the validator

Co-authored-by: Kenneth Howe<EMAIL_ADDRESS>Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[ ] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[ ] Is your initial contribution a single, squashed commit?

[ ] Does gradlew build run cleanly?

[ ] Have you written or updated unit tests to verify your changes?

[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to<EMAIL_ADDRESS>

@Petahhh @onichols-pivotal

This provides a better division of responsibilities between the validator and mutator. Validator calls occur before the Config object is "realized" through the distributed function call to the servers. The Mutator handles persistence of the configuration after "realization".


[terra-form-select] - Fix select option width and styling

Summary

What was changed:

Changed the --terra-form-select-option-padding variable value to the orion-fusion-theme to match consistent padding so that the option name doesn't break to the next line.
Changed onHover style.

Why it was changed:

The padding variable value in the orion-fusion-theme is bigger than in the other themes and causes the option name to break to the next line in the middle of the word even if the option is the same as current option.
The onHover styling for the option looks rather like onFocus (dashed border), focus states cannot be the same as the hover states.

Testing

This change was tested using:

[ ] WDIO
[ ] Jest
[x] Visual testing (please attach a screenshot or recording)
[ ] Other (please describe below)
[ ] No tests are needed

Reviews
In addition to engineering reviews, this PR needs:

[ ] UX review
[x] Accessibility review
[ ] Functional review

Additional Details

This PR resolves:
UXPLATFORM-10121

Thank you for contributing to Terra.
@cerner/terra
Befor fix :

After fix :

Ensured that focus styling is now different from hover, both have background but only focus has dashed border in default, fusion and lowlight themes.
Menu items padding fixed in fusion theme.
LGTM

Yes, focus styling is now different from hover, we have matched same onHover and onFocus style as other terra components.

+1


Don't require SSH tunnels and Fabric for list/kill/submit commands

This PR is directly related with #96, it should solve the issue with SSH tunnels and Fabric requirements for the cases when we don't need it at all, particularly for the Docker case.
I added 2 additional boolean settings for config.json:

use_ssh_for_nimbus defines if we need to setup SSH tunnel to talk with Nimbus or we can just use Storm Thrift interface directly at the specified host-port pair
use_virtualenv defines if we need to activate and setup virtualenv (we can miss it if we want to avoid Fabric usage and everything needed is already installed and configured at supervisor nodes).
Both values are true by default, according to the current library behaviour.

From other changes:

tried to simplify submit_topology() function with saving all logic precisely.
fixed passing Nimbus host/port to StormSubmitter/submitTopology.

The corner case of this solution is that post_submit hooks are executing w/o SSH tunnel now (it's pretty obvious if we don't use it at all).
Any feedback is highly appreciated.

Thanks for the PR! I really look forward to reviewing this, as this is something I've wanted for a while.

This looks great to me! :+1:

Just noticed #98, which tried to do a similar thing with a context manager.  It seems a bit cleaner, so I'll probably cherry-pick that when merging.

@dan-blanchard I've seen that approach, and I'll be happy if you could simplify anything here as I'm interested in the final result mostly. Nonetheless, the approach using contextmanager doesn't pass Nimbus host/port params to the lein commands inside, and more than that - it knows nothing about it. And it doesn't work if we have an opened Thrift port on a remote host.


Describe membership roles

#6 has started a general conversation about the roles and membership of the brigade. Here's a first pass at an "official" description.

LGTM
I'd like to get access to Chef de partie, don't think I should be an owner.

@lamont-granquist welcome to the partie!

:+1:

:+1:

LGTM. Please can I get Chef de Partie access too?

:+1:
Next up we should write a doc describing how to transfer a cookbook into this org.

Yeah, I'm itching to make some comments on the ownership doc.

:+1: I think this set of roles is perfectly sufficient for us moving forward. If we start growing and require additional teams/permission sets then we can cross that bridge when we come to it.

As a side note, I think it would be valuable to include the names of the organization members and the roles that they currently occupy.

owners:  https://github.com/orgs/chef-brigade/teams/owners
partie-goers: https://github.com/orgs/chef-brigade/teams/chef-de-partie

I think this is enough to get started :+1:
There is no need to list the members. GitHub already does that. Perhaps in the future if more specific roles are needed.

@josephholsten time to push the big green button?


Dart2js crashes with RangeError on two co19 Generic-functions-as-type-args tests

Dart2js crashes with the following co19 tests in the recent roll:

LanguageFeatures/Generic-functions-as-type-args/class_A01_t01
LanguageFeatures/Generic-functions-as-type-args/class_A01_t02

Both tests pass with analyzer and CFE.
Here is a link to the log.
Here is a error message sample:
--- Command "dart2js" (took 01.000922s):
DART_CONFIGURATION=ReleaseX64 CHROME_PATH=/b/s/w/ir/third_party/browsers/chrome/chrome/google-chrome sdk/bin/dart2js_developer --enable-experiment=generic-metadata --enable-experiment=generic-metadata --sound-null-safety --test-mode --packages=/b/s/w/ir/.packages /b/s/w/ir/tests/co19/src/LanguageFeatures/Generic-functions-as-type-args/class_A01_t01.dart --libraries-spec=sdk/lib/libraries.json --platform-binaries=out/ReleaseX64/ --sound-null-safety --out=/b/s/w/ir/out/ReleaseX64/generated_compilations/dart2js-hostasserts-strong-linux-x64-chrome/tests_co19_src_LanguageFeatures_Generic-functions-as-type-args_class_A01_t01/class_A01_t01.js

exit code:
253

stdout:
tests/co19/src/LanguageFeatures/Generic-functions-as-type-args/class_A01_t01.dart:
Internal Error: The compiler crashed when compiling this element.

The compiler is broken.

When compiling the above element, the compiler crashed. It is not
possible to tell if this is caused by a problem in your program or
not. Regardless, the compiler should not crash.

The Dart team would greatly appreciate if you would take a moment to
report this problem at http://dartbug.com/new.

Please include the following information:

* the name and version of your operating system,

* the Dart SDK build number (build number could not be determined), and

* the entire message you see here (including the full stack trace
  below as well as the source location above).

The compiler crashed: RangeError (index): Invalid value: Only valid value is 0: 1
#0      List.[] (dart:core-patch/growable_array.dart:254:60)
#1      BinaryBuilder._readTypeParameterType (package:kernel/binary/ast_from_binary.dart:2945:52)
#2      BinaryBuilder.readDartType (package:kernel/binary/ast_from_binary.dart:2852:16)
#3      BinaryBuilder.readDartTypeList.<anonymous closure> (package:kernel/binary/ast_from_binary.dart:2803:55)
#4      new List.generate (dart:core-patch/array_patch.dart:63:28)
#5      BinaryBuilder.readDartTypeList (package:kernel/binary/ast_from_binary.dart:2803:16)
#6      BinaryBuilder._readFunctionType (package:kernel/binary/ast_from_binary.dart:2919:33)
#7      BinaryBuilder.readDartType (package:kernel/binary/ast_from_binary.dart:2848:16)
#8      BinaryBuilder._readTypeLiteralConstant (package:kernel/binary/ast_from_binary.dart:450:27)
#9      BinaryBuilder.readConstantTableEntry (package:kernel/binary/ast_from_binary.dart:366:16)
#10     BinaryBuilder.readConstantTable (package:kernel/binary/ast_from_binary.dart:334:50)
#11     BinaryBuilder._readOneComponent (package:kernel/binary/ast_from_binary.dart:825:5)
#12     BinaryBuilder.readComponent.<anonymous closure> (package:kernel/binary/ast_from_binary.dart:633:34)
#13     Timeline.timeSync (dart:developer/timeline.dart:163:22)
#14     BinaryBuilder.readComponent (package:kernel/binary/ast_from_binary.dart:603:21)
#15     SerializationStrategy.deserializeComponent (package:compiler/src/serialization/strategies.dart:42:29)
#16     Compiler.globalTypeInferenceResultsTestMode (package:compiler/src/compiler.dart:453:18)
#17     Compiler.compileFromKernel.<anonymous closure> (package:compiler/src/compiler.dart:483:13)
#18     CompilerTask.measureSubtask (package:compiler/src/common/tasks.dart:181:35)
#19     Compiler.compileFromKernel (package:compiler/src/compiler.dart:459:14)
#20     Compiler.runInternal (package:compiler/src/compiler.dart:298:13)
<asynchronous suspension>

/cc @johnniwinther

This is a CFE issue. We don't handle (de)serialization of type literals of generic typedefs with generic function type parameter bounds.
This only shows up on the dart2js bot because the other bots don't serialize and deserialize the AST which the dart2js bot does in --test-mode.


build: Update shader dependencies to latest

CI Vulkan-ExtensionLayer build queued with queue ID 226662.

CI Vulkan-ExtensionLayer build # 935 running.

CI Vulkan-ExtensionLayer build # 935 passed.


[Feature request] Support .tar.xz release archives

I recently tried to use publish-to-bcr for one of my rulesets, but it failed to publish because the release archive was an unsupported format.

Failed to publish entry for<EMAIL_ADDRESS>to the Bazel Central Registry.
Unsupported release archive format 3.tar.xz

Looking at src/domain/release-archive.ts, it seems that only .tar.gz is currently supported.
Could that code be made more flexible? Bazel supports quite a number of file extensions for tarballs (see download_and_extract docs), including .tar.bz2, .tar.xz, and .tar.zst.

Looking at some candidate NPM packages, this one seems promising: https://github.com/SteveSanderson/xzwasm?tab=readme-ov-file#what-about-tarxz-files

Rough work-in-progress branch of decompressing .tar.xz archives using liblzma (via WebAssembly): https://github.com/bazel-contrib/publish-to-bcr/compare/main...jmillikin:upstream__publish-to-bcr:xz-artifacts?expand=1
Summary:

Local branch of https://github.com/bazel-contrib/toolchains_llvm to support wasm32-unknown-unknown targets.
Local branch of https://github.com/bazelbuild/bazel-central-registry/tree/main/modules/xz to add a config.h (+ other small patches)
Wrote a thin wrapper around @xz//:lzma that exposes a Wasm-friendly API for decoding.
Modified release-archive.ts so it'll decompress .tar.xz files before passing them into tar.extract()
Checked in the compiled xzdec.wasm file because it's ~100 KB and the LLVM dependencies to build it are enormous.

What do the owners of this repository think of that branch? Should I try polishing it up to turn into a PR, or would you prefer a different approach?

I looked into the xzwasm package linked above, and it seems challenging from a maintenance standpoint:

The most recent version was v0.1.2, published three years ago, with no commits since then.
It's not using the standard xz library liblzma, but instead https://github.com/tukaani-project/xz-embedded which appears to be intended for use in the Linux kernel and says on its homepage "There are no release packages and no API/ABI stability guarantees".
It's shipping the WebAssembly module as part of a 20 KB xzwasm.min.js, which makes it difficult to review.
I couldn't find any way to limit the memory consumption of the decompressor, so it's potentially vulnerable to denial-of-service from malicious inputs.

There's a fork of that package at https://www.npmjs.com/package/xz-decompress with a slightly more active maintainer (v0.2.2 was published 4 months ago), but the other difficulties still apply.

Thanks for you work and investigation into this @jmillikin! I haven't used WebAssembly before. Just to confirm my understanding, you brought in Bazel just to get the necessary toolchains to generate the wasm binary? I would like to migrate this repo to use Bazel eventually, but I'm not quite there yet. I suppose we could just vendor the files you generated and leave the additional Bazel stuff in a separate branch in case we ever need to re-generate it?

I'd prefer to not have a separate branch for the build configuration, for technical and legal reasons. How about I put the Bazel configuration under src/infrastructure/xzdec/? Then if the overall build ever migrates to Bazel, the xzdec config can just be moved up to the top level.

I'd prefer to not have a separate branch for the build configuration, for technical and legal reasons. How about I put all of the Bazel configuration into the main branch, but under src/infrastructure/xzdec/? Then if the overall build ever migrates to Bazel, the xzdec config can just be moved up to the top level.

That works. Let's move the bazel module under src/domain/xzdec, then use a write_source_file target to write it to the source tree.

Thanks again for your contribution @jmillikin! Your work has been deployed to prod.


Add rebase to the CONTRIBUTING file

📓 Documentation Update
Adding the rebase step to the CONTRIBUTING file: It helps avoiding the forked repo diverging from the upstream repo.

Closed: Implemented in the PR #403


error 502 after secret_key change

I change secret_key with a random base64 one, and after restart gogs stop working!
Error 502 BadGateway
Help me please!

Hi there, thanks for your feedback, but Error 502 BadGateway sounds like you don't even start Gogs yet...

Tnks for your reply, but service tell me that is running

Are you running Nginx for reverse proxy?

OK i send you some news asap
Tnks, bit if don't work, can I remove and reinstall Gog's from zero?
How to make fresh install?

Tnks, bit if don't work, can I remove and reinstall Gog's from zero?

Yes, removes the directory where you set to store all repositories and gogs directory. (SSH key file as well if you added SSH key through Gogs)
Then download new one, which becomes a fresh install.

OK, come back home now tnks

No problem, so how's reinstall process going?

i'm arrived now, just do it now!

I'm heading to my class, leave your comments I'll reply ASAP. :blush:

ok, the problem is service, becouse after after removal keeps telling me that it is active...

Cool!

Not familiar with init.d thing, but I guess you should execute some commands to let daemon remove it.

look at web log after fresh install
[publickey.go:77 init·3()] [E] fail to create '/home/gogs/.ssh': mkdir /home/gogs: permission denied
gogs user already exist

I think it really means no permission to create .ssh directory

i know, i fix it create manually every dir, now open installer page but when finish to compile it...
Error 502 BadGateway
log error
[repo.go:113 NewRepoContext()] [E] Fail to set git user.name(exit status 255): error: could not lock config file /home/gogs/.gitconfig: Permission denied

i try to fix permission manually, but isn't normal

now work...tnks mate for you time
i hope for snipets or gist news lol

now i've the old repo(that don't exist jet) and recive error 500, and i'm unable to delete it....

ok delete manually from db old repo!


Preview in citation

I there.
Great  job you do !
Like you already did in Roster, it would be great if we can do a 'Preview in citation'.
That way we could see if it worth the pain to fully play the event or do a crew retrieval for a specific crew.
Something like temporary adding a level 100 FE one star crew and see how it fits in the Crew to cite table.
BTW, in Preview citation the column 'Remaining EV' is always equal to the column 'Final EV' and I guess it should decrease with each star we add up to be equal to EV Per citation for the last star.
I mean now we have : (not exactly that but so you get the idea)
Final EV    Remaining EV    EV per citation    (stars)
400            400                     100                        1
400             400                    133                        2
400             400                    200                        3
400              400                   400                        4
and we should have  :
400              400                    100                        1
400              300                     100                       2
400               200                    100                       3
400              100                      100                      4

This would be incredibly helpful, thank you. I requested this as well before:
https://github.com/stt-datacore/website/issues/392


To support PKCE in LINE login SDK in Go

Refer: https://developers.line.biz/en/news/2021/04/09/line-login-pkce-support/

Implement by d62bded1a080fdbc6a82923dc6243551b78a41a3


docs: add an entry about the setup-hook

The on_setup hook is currently undocumented, and it should gain some attention after https://github.com/williamboman/nvim-lsp-installer/pull/631

Maybe emphasize "this is principally for plugin developers, and overriding this without wrapping the original function may break external integrations with lspconfig"

would it make sense to have this setting per-server instead of being global?
diff --git a/lua/lspconfig/util.lua b/lua/lspconfig/util.lua
index 3febafc..3e57fde 100644
--- a/lua/lspconfig/util.lua
+++ b/lua/lspconfig/util.lua
@@ -14,11 +14,9 @@ M.default_config = {
   init_options = vim.empty_dict(),
   handlers = {},
   autostart = true,
+  on_setup = nil
 }

--- global on_setup hook
-M.on_setup = nil

it could then be renamed to pre_init or something, if on_setup is ambiguous here I forgot that before_init exists, can we not use that instead?

FWIW, I found use for this in my personal configs for making sure to apply a set of default configurations (primarily the ever so present on_attach and `capabilities).

Register a hook for applying defaults
Call setup while only having to pass server specific settings:
- https://github.com/williamboman/nvim-config/blob/9668609f2a52f3d4630c0cbb553e4be379035ed3/after/plugin/lsp/servers/pylsp.lua#L6)
-  https://github.com/williamboman/nvim-config/blob/9668609f2a52f3d4630c0cbb553e4be379035ed3/after/plugin/lsp/servers/jsonls.lua#L12-L6


Take a dictionary instead of a file

It would be fantastic if there was a way to replace copyright.  Given the limitations of the version field, it is useful to stuff that field with more information at build-time.  Thanks!

Can you please give a concrete example of what you want to achieve?
Copyright itself can be set in the YAML file with LegalCopyright. Do you want to set this value from the command line?

I'm actually directly calling pyinstaller_versionfile.create_file_version.MetaData as an API so that I can set things programmatically when pyinstaller runs.  But it just occurred to me that what I probably need to do is send an IO steam that contains my content rather than have a file on the side.

I will take a look at this - so for you it would be enough if the MetaData class would accept a file-like object instead of a filepath?

With a bit more playing, with the 1.0.2 version, this hack demonstrates what I'm looking to do.

So really: rather than taking a raw file or a stream, taking a structure would be much more flexible.

@aw-was-here I pushed a update to the develop branch. For issue #4 I wanted to separate the input of the metadata and creation of the output file anyway, and this should now also make what you want to do straightforward, as you can just create your own MetaData object directly.
Here would be a minimal example:
from pyinstaller_versionfile.metadata import MetaData
from pyinstaller_versionfile.writer import Writer

metadata = MetaData(version="<IP_ADDRESS>", legal_copyright="My Imaginary Company")  # all parameters are optional, just specify what you need
writer = Writer(metadata)
writer.render()
writer.save("versionfile.txt")

Would this solve your problem?
Note: this new version would become a V2.0.0 and will also drop support for Python < 3.6.

Would this solve your problem?

@DudeNr33 Just tried out the develop branch: yes! definitely!  This change makes it much easier to incorporate into the build.
Two things probably worth mentioning:

It looks like version validation/fixing isn't actually happening with < 4 digits.  I'd expect either a ValueError exception or for the code to just automatically fix version if it isn't 4 decimal places. e.g.:

metadata = MetaData(version='1.2.3', ...)

ends up being
filevers=(1,2,3),

which is obviously wrong.

This usage feels awkward, given I'm not sure what else I'd use the Writer object for:

writer = Writer(metadata)
writer.render()
writer.save("versionfile.txt")

Should save() just call render()? Should render() return the rendered text as well? Or perhaps you have other plans already and it will make more sense later. :+1:

Note: this new version would become a V2.0.0 and will also drop support for Python < 3.6.

That's fine for me.  I've already got code that requires 3.8 in use.
Thanks!

Thank you for your feedback!
Ad 1)
The MetaData class has two additional methods, that you may call from your calling code:

validate() - checks for invalid input. A version with less than 4 decimal places is not considered invalid, as the second method would take care of that:
sanitize - sanitizes the input, i.e. trimming whitespace and filling a version with less than four places with zeros.

I considered calling both methods directly in the __init__ method of the class. But I thought that if somebody imports and uses the code directly, he would probably also like a bit more control over what is happening, so I decided against it.
Ad 2)
render() takes care of rendering the output and handling rendering errors.
save() takes care of the saving the file and handling I/O errors.
I found it cleaner to separate those concerns into individual methods.
I think both issues could be addressed by providing a functional API in the __init__.py of the package, which would essentially implement the logic currently in main.py:main() for the two cases of file-based input and dictionary (or keyword arguments) input.
# __init__.py

def create_versionfile(version, company_name, ..., outfile):
    metadata = MetaData(version, company_name, ...)
    metadata.validate()
    metadata.sanitize()
    writer = Writer(metadata)
    writer.render()
    writer.save(outfile)

def create_versionfile_from_file(infile, outfile, version=None):
    metadata = MetaData.from_file(infile)
    metadata.validate()
    if version:
        metadata.set_version(version)
    metadata.sanitize()
    writer = Writer(metadata)
    writer.render()
    writer.save(outfile)

This would at least save you from calling all methods yourself in the correct order.
Having a second opinion is always great, so fell free to let me know what you think.

That all looks fantastic. Combined with pyinstaller taking the version file as a parameter these changes make it all very easy to do now.
Thanks!

V2.0.0 is now available on PyPI. Check the updated readme for the final function signature. 👍

Thanks!


Remove bringup from Windows build_tests shards

Context: https://github.com/flutter/flutter/commit/aff8ef13d428395725ce8f836ca771b8bf2d87db

Yeah, it looks like those PRs were just getting hit by unrelated flakes =(


Fix interfaces in architecture diagram

Small correction in KV interface: RPCDaemon/Silkrpc is the user side whilst TG/Silkworm is the realization side

In that case, the Consensus Engine interface also needs to be inverted. Core is the user and ConsensusEngine implements the interface

Sure


[FEATURE] Add glass effect

Description
Add a glass effect on the main content.
Screenshots

Additional information
No response

!assign

@bhattabhi013 Show me a screen record in the PR you'll be creating.


[firebase_auth] regarding of depecrated onAuthStateChanged

Describe the bug
error: The method 'map' isn't defined for the type 'Function'. (undefined_method).
The map method implements from Stream() which has get properties on onAuthStateChanged.
To Reproduce
Steps to reproduce the behavior:

Got the message "info: 'onAuthStateChanged' is deprecated and shouldn't be used. Deprecated in favor of authStateChanges. (deprecated_member_use)" in the latest updates.
Refactor to suggested authStateChanges.
See error above or incorrect behavior in the "Describe the bug" section.

Expected behavior
The refactoring message should be clear and concise.
Any alternative/suggested fix for below codes?
Additional context
Before the refactor:
  Stream<UserModel> get user {
   // fine
    return _firebaseAuth.onAuthStateChanged.map((
      firebaseUser,
    ) {
      return firebaseUser == null ? UserModel.empty : firebaseUser.toUser;
    });
  }

After the refactor:
  Stream<UserModel> get user {
   // error: The method 'map' isn't defined for the type 'Function'. (undefined_method)
    return _firebaseAuth.authStateChanges.map((
      firebaseUser,
    ) {
      return firebaseUser == null ? UserModel.empty : firebaseUser.toUser;
    });
  }

Flutter doctor
Run flutter doctor and paste the output below:
[√] Flutter (Channel beta, 1.20.2, on Microsoft Windows [Version 10.0.19042.450], locale id-ID)
    • Flutter version 1.20.2 at C:\Users\fuzuyx\AppData\Local\Flutter
    • Framework revision bbfbf1770c (5 days ago), 2020-08-13 08:33:09 -0700
    • Engine revision 9d5b21729f
    • Dart version 2.9.1
[√] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at C:\Users\fuzuyx\AppData\Local\Android
    • Platform android-29, build-tools 29.0.3
    • Java binary at: C:\Program Files\OpenJDK\openjdk-8u262-b10\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_262-b10)
    • All Android licenses accepted.
[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/windows#android-setup for detailed instructions).
[√] VS Code, 64-bit edition (version 1.48.0)
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension version 3.13.2
[√] Connected device (4 available)
    • ZenFone Max Pro M1 (mobile) • <IP_ADDRESS>:5555 • android-arm64  • Android 10 (API 29)
    • Web Server (web)            • web-server       • web-javascript • Flutter Tools
    • Chrome (web)                • chrome           • web-javascript • Google Chrome 84.0.4147.125
    • Edge (web)                  • edge             • web-javascript • Microsoft Edge 84.0.522.59
! Doctor found issues in 1 category.

Try:
  Stream<UserModel> get user {
   // error: The method 'map' isn't defined for the type 'Function'. (undefined_method)
    return _firebaseAuth.authStateChanges().map((
      firebaseUser,
    ) {
      return firebaseUser == null ? UserModel.empty : firebaseUser.toUser;
    });
  }

@PeterHdd Thanks it worked.
Anyway... would be any changes on the documentation soon?


Intoroduce PyComplex

For #224.
Now I implemented just 3 APIs for it, from_doubles, real, imag.
Some questions:

We should implement FromPyObject to num-complex? Since num-complex is very portable crate, I think it's good.
We should implement bindings for other APIs exposed when #[cfg(not(Py_LIMITED_API)]? Pesonally, I don't feel them so useful. Part of them are

PyAPI_FUNC(Py_complex) _Py_c_sum(Py_complex, Py_complex);
PyAPI_FUNC(Py_complex) _Py_c_diff(Py_complex, Py_complex);
PyAPI_FUNC(Py_complex) _Py_c_neg(Py_complex);
PyAPI_FUNC(Py_complex) _Py_c_prod(Py_complex, Py_complex);
PyAPI_FUNC(Py_complex) _Py_c_quot(Py_complex, Py_complex);
PyAPI_FUNC(Py_complex) _Py_c_pow(Py_complex, Py_complex);
PyAPI_FUNC(double) _Py_c_abs(Py_complex);

(https://github.com/python/cpython/blob/master/Include/complexobject.h), but we can do these operations in Rust side.

num-complex sounds like a good idea. I'd put it behind an off-by-default feature flag and mention it in the readme.
I think those functions should also be wrapped in rust. If we implement them using the Add, Sub, etc. traits we can use the normal +, -, etc. on PyComplex, which would be pretty neat.
Otherwise it's looking good!

Now ready to review :slightly_smiling_face:

Thank you, this looks great!
Your contributions have all been really good, so I've given you commit access :sparkles:


Java style guide: state whether to indent blank lines or not

Currently the style Guide does not say anything regarding if indentation should be applied to blank lines or not, to match the upper scope. The code examples seem to not intent blank lines, which also is what I prefer, but I think the style guide should state this explicitly

A blank line is blank. There should be no trailing whitespace.  Noone should be try to "indent" blank lines. But I don't think we mention "identing blank lines" in any style guide. That concept doesn't make sense.
The C++ style guide states "Never put trailing whitespace at the end of a line." which seems like reasonable statement for all language style guides to adopt.

The C++ style guide states "Never put trailing whitespace at the end of a line." which seems like reasonable statement for all language style guides to adopt.

Including that language solves this issue in a very unambiguous way.


feat: Add API for getting top artists

https://www.jiosaavn.com/api.php?__call=social.getTopArtists

I'm re-writing the API, this should be included in the update. You can checkout it here - https://github.com/sumitkolhe/jiosaavn-api/tree/dev

Okay bro thanks 👍🏻


Update endpoint-dlp-getting-started.md

I suggest we optimize towards mentioning windows 10 / 11 when setting context and in requirements and then leaving it at "Windows".
I dont think onboarding needs to mention Windows version unless there is a specific different for onboarding based upon Windows version.
@chrfox

@JohanFreelancer9 - kindly do the copy editor review for this PR. Thanks

@MasLibman Please implement the changes, if you agree. Thanks


Unable to get started

Sorry if this is not the smartest of questions.. but how do you get started?
Are you using RequireJS with Angular or something?
I have never seen the require being used to load a module and googling it has availed nothing useful.

No, not RequireJS. That require is CommonJS and is handled by Browserify or Webpack. If you're doin it old school and using script tags / concatenation, each tag has a UMD build which doesn't require any special build tool:
https://github.com/bendrucker/angular-stripe/releases
This isn't documented because Bower grabs code from tags. Even though it's a terrible package manager, it's still popular among Angular and front-enders in general. If you just want to copy and paste, you can download the ZIP files from that page.

Also, no intent to dismiss the confusion here. Rather than pollute every repo with 10 lines of installation instructions, I'd much rather write a blog post about how to properly publish and consume Angular modules. npm is the right tool in 2015, but I understand that can be a stumbling block and a fair comparison between all the options is the best way to help people make an informed decision.


Fix edge case importing RSA key

Description
Fixes edge case Exception importing private key when D is shorter in length than MODULUS by 8 bits or more.
If D is shorter, it is copied to the end of a new array with the same length as MODULUS. Naive, but this is a rare edge case.
Motivation and Context
This fixes issue #357 that I just ran into using an older Vonage application private key.
How Has This Been Tested?
Ran unit tests with old and new keys and published to our production server (which uses multiple private keys).

Hi @OronDF343,
Thanks for looking into this :clap: The problem didn't occur for a year so, as you said, it's probably related to older keys.
PemParse.cs is a tricky one as it was blatantly copied from an obscur source, without any sense of ownership or testing - which is why I tried to stay away from it.

@OronDF343,
I released v7.6.1, including your change.
Thanks again for contributing


Mio build broken on Haiku, no kpoll/kqueue

   Compiling parking_lot v0.9.0
   Compiling hyper v0.12.35
   Compiling aho-corasick v0.7.15
   Compiling addr2line v0.14.0
   Compiling idna v0.1.5
   Compiling idna v0.2.0
   Compiling mime_guess v2.0.3
   Compiling futures-cpupool v0.1.8
   Compiling bytes v0.4.12
   Compiling mio v0.6.23
error[E0432]: unresolved imports `self::unix::Events`, `self::unix::Selector`
 --> /boot/home/.cargo/registry/src/github.com-1ecc6299db9ec823/mio-0.6.23/src/sys/mod.rs:5:5
  |
5 |     Events,
  |     ^^^^^^ no `Events` in `sys::unix`
6 |     Io,
7 |     Selector,
  |     ^^^^^^^^ no `Selector` in `sys::unix`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `mio`

Nope. No support for either. We follow a pretty strict posix model

actually it looks like mio 0.8.0 just works.  The error above is on 0.6.23
/Data/Code/mio> cargo build
   Compiling libc v0.2.88
   Compiling log v0.4.11
   Compiling cfg-if v0.1.10
   Compiling mio v0.8.0 (/Data/Code/mio)
    Finished dev [unoptimized + debuginfo] target(s) in 2.63s
/Data/Code/mio> cargo test
   Compiling env_logger v0.6.2
   Compiling rand v0.4.6
   Compiling mio v0.8.0 (/Data/Code/mio)
    Finished test [unoptimized + debuginfo] target(s) in 5.95s
     Running target/debug/deps/mio-753c3d872fa80196

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/aio-ddb6b9e09505d866

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/close_on_drop-6b57ddb8ed3d603e

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/events-87c06669cab39f2d

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/interest-5f7b72ee86b2086e

running 4 tests
test add ... ok
test bit_or ... ok
test fmt_debug ... ok
test is_tests ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/poll-27c9e6654b4bc8ce

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/registering-9d474f45d2be8765

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/regressions-c6f11f684f3ee713

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/tcp-0f512657bc44fcb5

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/tcp_listener-0f8dda3615537eed

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/tcp_socket-7044b995f8501b4c

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/tcp_stream-97680294a5416030

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/udp_socket-2ac819aa49a263c1

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/unix_datagram-b6c07085797ca71d

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/unix_listener-757d9ceb365003bb

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/unix_pipe-c589c7bae56441bb

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/unix_stream-08968abdd23a4436

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/waker-6870a9f6e4095fa0

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target/debug/deps/win_named_pipe-ba42cb257be0764f

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests mio

running 21 tests
test src/event/events.rs - event::events::Events (line 20) ... ignored
test src/event/events.rs - event::events::Events::capacity (line 100) ... ok
test src/event/events.rs - event::events::Events::clear (line 164) ... ignored
test src/event/events.rs - event::events::Events::is_empty (line 114) ... ok
test src/event/events.rs - event::events::Events::iter (line 128) ... ignored
test src/event/events.rs - event::events::Events::with_capacity (line 86) ... ok
test src/event/events.rs - event::events::Iter (line 55) ... ignored
test src/event/source.rs - event::source::Source (line 41) ... ignored
test src/interest.rs - interest::Interest::add (line 61) ... ok
test src/interest.rs - interest::Interest::remove (line 77) ... ok
test src/lib.rs - guide (line 142) ... ignored
test src/lib.rs - guide (line 176) ... ignored
test src/lib.rs - guide (line 214) ... ignored
test src/poll.rs - poll::Poll (line 129) ... ignored
test src/poll.rs - poll::Poll (line 33) ... ignored
test src/poll.rs - poll::Poll::poll (line 263) ... ignored
test src/poll.rs - poll::Registry::deregister (line 573) ... ignored
test src/poll.rs - poll::Registry::register (line 428) ... ignored
test src/poll.rs - poll::Registry::reregister (line 506) ... ignored
test src/token.rs - token::Token (line 20) ... ignored
test src/waker.rs - waker::Waker (line 37) ... ignored

test result: ok. 5 passed; 0 failed; 16 ignored; 0 measured; 0 filtered out; finished in 0.97s

soo.. I guess close issue waiting on folks to update :-)

Building Mio without features basically builds everywhere because it's a non-implementation (see https://github.com/tokio-rs/mio/tree/58e589fddeac03453ffe60718c64e2a582c12275/src/sys/shell). But once you enable features we need actual OS support.
So what system calls does Haiku have that we can use? Note that poll and select are not good enough.

Weird.. to help me better determine if alternatives exist.. why are poll / select not good enough? select isn't polling and doesn't really waste CPU time.
We have a pretty unique  wait_for_objects call which might be a stand-in for epoll / kqueue:
https://github.com/haiku/haiku/blob/master/headers/os/kernel/OS.h#L634
It's experimental however.. and documentation could be (a lot) better.

Just found a simple usage example of wait_for_events here:
https://git.haiku-os.org/haiku/tree/src/servers/power/power_daemon.cpp#n118

The problem with poll and select is that you need all the file descriptors to make the call. With epoll/kqueue the OS allows us to register an interest in a file descriptor, which is done in mio::Registry::register. That allows us to keep no user-space state about what file descriptor we're actually polling.
If were to support poll/select we need a copy of all file descriptors that are registered. Which is possible, but would require a lot of work to support in Mio.

We have a pretty unique wait_for_objects call which might be a stand-in for epoll / kqueue:
https://github.com/haiku/haiku/blob/master/headers/os/kernel/OS.h#L634

Am I correct in thinking you still need to pass all the object_wait_info objects you're interested in for wait_for_objects? Because if so it's not good enough, see my previous comment.

Hm. Yeah. You build the list of objects and operate on them (aka stateless)
tldr; the design of mio assumes stateful file descriptor monitoring.
We have a GSoC session coming up.. one topic is adding io_uring support to Haiku.  This seemingly represents the "future" of fd monitoring on Linux and elsewher.  Any thoughts on the potential for mio to move to that model at some point in the future?
I was linked a great FOSDEM video here:
https://fosdem.org/2021/schedule/event/file_descriptor_monitoring/

Ok.  I went ahead and opened this ticket based on some discussions around this stuff:
https://dev.haiku-os.org/ticket/16846
We generally only implement POSIX stuff, but it feels like we're lacking here.
as for us targeting a io_uring API in the future, I feel like any discussions around io_uring would duplicate #923 so I won't bring them up :grin:     Part of 16846 above would be offering a epoll/kqueue compatibility API leveraging a native io_uring implementation.
With that said.. feel free to close this one if you deem it impractical for the moment.  Feel free to point any future people complaining about mio not working under Haiku here :laughing:
A lot of crates eventually depend on mio though tokio.. I guess i'm going to have to avoid leveraging anything that uses tokio for a while.   Thanks!

Feel free to reopen or create a new issue once something like https://dev.haiku-os.org/ticket/16846 is possible on Haiku.

https://dev.haiku-os.org/ticket/16846 is possible on Haiku.

This has been done by implementing a (subset of) kqueue, and it's now available on nightly builds, so this issue can be reopened.

https://dev.haiku-os.org/ticket/16846 is possible on Haiku.

This has been done by implementing a (subset of) kqueue, and it's now available on nightly builds, so this issue can be reopened.

Does Mio test suite pass on Haiku with kqueue?

I don't know, because I don't have a Rust setup on Haiku at the moment. @nielx or @kallisti5 may be more qualified to investigate.

Just in case it's helpful in the future, I had prototyped running mio tests on a haiku vm in github actions on https://github.com/tokio-rs/mio/pull/1602#issuecomment-1605237018
Commits and diff on GitHub: https://github.com/tokio-rs/mio/compare/1387b178629f80de65b112c416ce41f047447e9e...d4eef2f3735e8eb77b7f89586cbb0a5e69d435cf
If the commits eventually disappear (I deleted my fork), here's the full ci.yml and diff:
ci.yml
ci-diff.txt

For anyone still watching this issue. Mio v1 will support Haiku using the poll(2) and pipe(2) implementations. I don't know the state of epoll/kqueue of Haiku, I find can't find any manual for these kind of system calls other than a reference to the Posix standard. If an API like epoll/kqueue is ever support by Haiku we should switch to that as it would be far more efficient.

There is a basic kqueue implementation, so it is worth investigating if it has all the features to switch over. I'll add it to my list.

Has there been any update on this now that kqueue is a thing? I'd love to get ruffle working on haiku and tokio is what is currently preventing it


CLI Hacktoberfest Python

Make the cli more interactive and colourful. its boring !

can you assign this to me ? and also provide more description for how you want me to work on this ?

add a boundary and clean the terminal when entering the game
Add loading animation
add a game over screen like this -

⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣀⣠⡀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣤⣤⠀⠀⠀⢀⣴⣿⡶⠀⣾⣿⣿⡿⠟⠛⠁
⠀⠀⠀⠀⠀⠀⣀⣀⣄⣀⠀⠀⠀⠀⣶⣶⣦⠀⠀⠀⠀⣼⣿⣿⡇⠀⣠⣿⣿⣿⠇⣸⣿⣿⣧⣤
⠀⠀⢀⣴⣾⣿⡿⠿⠿⠿⠇⠀⠀⣸⣿⣿⣿⡆⠀⠀⢰⣿⣿⣿⣷⣼⣿⣿⣿⡿⢀⣿⣿⡿⠟⠛⠁
⠀⣴⣿⡿⠋⠁⠀⠀⠀⠀⠀⠀⢠⣿⣿⣹⣿⣿⣿⣿⣿⣿⡏⢻⣿⣿⢿⣿⣿⠃⣼⣿⣯⣤⣴⣶⣿⡤
⣼⣿⠏⠀⣀⣠⣤⣶⣾⣷⠄⣰⣿⣿⡿⠿⠻⣿⣯⣸⣿⡿⠀⠀⠀⠁⣾⣿⡏⢠⣿⣿⠿⠛⠋⠉
⣿⣿⠲⢿⣿⣿⣿⣿⡿⠋⢰⣿⣿⠋⠀⠀⠀⢻⣿⣿⣿⠇⠀⠀⠀⠀⠙⠛⠀⠀⠉⠁
⠹⢿⣷⣶⣿⣿⠿⠋⠀⠀⠈⠙⠃⠀⠀⠀⠀⠀⠁
⠀⠀⠈⠉⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣀⣤⣤⣴⣶⣦⣤⡀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣀⡀⠀⠀⠀⠀⠀⠀⠀⣠⡇⢰⣶⣶⣾⡿⠷⣿⣿⣿⡟⠛⣉⣿⣿⣿⠆
⠀⠀⠀⠀⠀⠀⢀⣤⣶⣿⣿⡎⣿⣿⣦⠀⠀⠀⢀⣤⣾⠟⢀⣿⣿⡟⣁⠀⠀⣸⣿⣿⣤⣾⣿⡿⠛⠁
⠀⠀⠀⠀⣠⣾⣿⡿⠛⠉⢿⣦⠘⣿⣿⡆⠀⢠⣾⣿⠋⠀⣼⣿⣿⣿⠿⠷⢠⣿⣿⣿⠿⢻⣿⣧
⠀⠀⠀⣴⣿⣿⠋⠀⠀⠀⢸⣿⣇⢹⣿⣷⣰⣿⣿⠃⠀⢠⣿⣿⢃⣀⣤⣤⣾⣿⡟⠀⠀⠀⢻⣿⣆
⠀⠀⠀⣿⣿⡇⠀⠀⢀⣴⣿⣿⡟⠀⣿⣿⣿⣿⠃⠀⠀⣾⣿⣿⡿⠿⠛⢛⣿⡟⠀⠀⠀⠀⠀⠻⠿
⠀⠀⠀⠹⣿⣿⣶⣾⣿⣿⣿⠟⠁⠀⠸⢿⣿⠇⠀⠀⠀⠛⠛⠁⠀⠀⠀⠀⠀⠁
⠀⠀⠀⠀⠈⠙⠛⠛⠛⠋⠁

Add colour to all this using colorama

Hey I'm working on the codebase for the game, and I noticed that the current version of the game doesn't have a way for players to quit the game, especially during user input stages (like choosing a number between 1 and 6 or during the toss).
Would it be okay if I add a quit functionality? This would allow users to exit the game by typing 'q' when they don't want to continue. I believe it would improve the user experience by providing a way to gracefully exit the game.

Sure

Hey, thanks for getting back to me!
I've implemented the ASCII art as you suggested and put it in separate files, then imported them into main.py. However, I ran into a bit of confusion because I noticed there are two main.py files: one under the game_files/ directory, which I was primarily working on, and another one in build/lib/game_files/, which remains unchanged.
To clarify, I made changes only to the main.py under the game_files/ directory, and to make the game run, I imported the features like this:
from boundary import clear_terminal, print_boundary
from loading import loading_animation
from animation import game_over_screen, goodbye_screen, show_bat, show_ball

Could you confirm which of the main.py files should be the primary one that I should be working on? Should I make changes to both? Just want to ensure that I follow the structure you envision for the project.

You just do it in the root file. The other is for pypi

Hey I have made pull request , do let me know if something needs changing?

Hey , I see it says on hacktoberfest website that this repo is not participating in hacktoberfest . can you add tag for "hacktoberfest accepted" so that it can be counted.


scat2gridgauss_zt always complains of irregular T axes

Reported by ansley b manke on 29 Mar 2012 18:24 UTC
Report from the Ferret Users List:
define axis/t=300:400:1 tax
define axis/z=0:300:1 zax
let chla_reg = scat2gridgauss_zt(dbar[i=1:5],date_new[i=1:5],chla[i=1:5],z[gz=zax],t[gt=tax],1.,1.,1.,0)
shade chla_reg

Bailing out of external function "scat2gridgauss_zt":
         output axes must be REGULARLY spaced
 **ERROR: error in external function

It turns out that the check for irregular destination axis is incorrect.  There is no test for this function in the benchmark suite; tests for all directions of the gridding functions should be added.
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/1929

Comment by ansley.b.manke on 27 Apr 2012 19:33 UTC
The bug is fixed, and a test for all the scat2grid* functions in 2D combinations of xyzt is added to the benchmark suite.


Set DEBUG=False in remote environments

I believe the debug setting is enabled because of static and media files support. Once #123 is handled, we can likely switch our static files to django-storages as well. Or use whitenoise

Think this got done in Jan (this might be related: https://github.com/djangonaut-space/wagtail-indymeet/pull/241)


 Never.
I didn't ask for it.
I don't need it.
Scenario

Take Dev.
Go Home.

Additional details
No response

Yes, it sounds strange, but it actually disappeared from my computer after my request here.
 Never.
I didn't ask for it.
I don't need it.
Scenario

Take Dev.
Go Home.

Additional details
No response

You kinda agreed when u wanted to use MS Services and Products

I paid for their operating system only. Not for testing their other software 🥲

Did you read the terms when you purchased the software. Probably not.

/dup #1615


chore/safe-app: Depend on NPM package for email/hosting/playground MAID-2332

r? @ustulation
(maidsafe_highfive has picked a reviewer for you, use r? to override)


lots of bug fixes

Bugs fixed:

fix accordion for selectpatient
fixed posiition of select patient header
edithealthconditions now goes back to selectpatient
editmedicalhistory now goes back to select patient
fixed broken create prescription ui on chrome
left justified create prescription button
fixed editing appointment link from select patient
fixed broken js in schedule appointment


add plv8

Thanks for adding plv8. Unfortunately this broke the aws_s3 extension and I have to no idea why. I have no idea on how to install it and haven't found any docs on that :-/
Applying migration `20220228201822_initial_migration`
Error: P3018

A migration failed to apply. New migrations cannot be applied before the error is recovered from. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve

Migration name:<PHONE_NUMBER>1822_initial_migration

Database error code: 58P01

Database error:
ERROR: could not open extension control file "/usr/share/postgresql/14/extension/aws_s3.control": No such file or directory

DbError { severity: "ERROR", parsed_severity: Some(Error), code: SqlState(E58P01), message: "could not open extension control file \"/usr/share/postgresql/14/extension/aws_s3.control\": No such file or directory", detail: None, hint: None, position: None, where_: None, schema: None, table: None, column: None, datatype: None, constraint: None, file: Some("extension.c"), line: Some(535), routine: Some("parse_extension_control_file") }

Just fyi, cmake also has binary versions available at: https://cmake.org/download/
Then we don't have to build it from source. But I guess this just has to be built once, and we'll soon switch away from it anyways, so nvm :)


Update docs to fix frontend build error

Fixes #111

I think this should be fixed now by @jcrossley3's PR #110 … which uses plain npm and also ensures it was called before running the build. Please re-open if I got that wrong.


dev: tree-sitter formal syntax definition?

The old cairo-lang repo comes with an EBNF definition of the Cairo syntax, which makes it easy to build and maintain the treesitter grammar, along with other benefits.
Maybe I missed it, but it looks like the new repo doesn't provide such a definition. Would be nice it exists. I'm trying to build the Cairo 1.0 treesitter grammar so that syntax hightlighting, folding, etc. work in editors that support it (Helix, nvim, etc.).

I was hoping most editors could use the syntax highlighting that comes from the language server. Perhaps I was too optimistic here, but I really wanted to only have one parser (note that we have a hand written parser).
Anyway, we have the cairo_spec.rs file that determines the structure of the AST.
Also, we plan to have an ebnf auto generated from the reference docs, but it won't always be up to date I guess.

I would argue they're for different use cases. Treesitter is a widely adopted format (iirc GitHub highlights sources using treesitter), and is very useful when the lsp isn't available (web, users don't want to install, or simply unsupported arch).
Cairo already has a community maintained ts grammar here. It's just for pre-cairo-1, and I want to help update it.
It's good to know the spec is coming!

Yeah, @spapinistarkware I think we will need following separate grammars implementations:

Compiler one we have
Tree sitter as @xJonathanLEI said
TextMate bundle which is present in VSCode format in lsp plugin. This format is also used by SublimeText and many other editors afaik
IntelliJ Grammar-Kit syntax def for possible future IntelliJ plugins

Hey,
I can confirm that a tree-sitter grammar would be awesome (and I would prioritize it over the others).

It's going to be great for toolbuilders building static analysis stuff (I'll use it for sure to build some toolz).
GitHub (advanced) code navigation and semantic highlighting are based on tree-sitter.
also you might even consider adapting the lsp to use tree-sitter for it's many benefits like it's blazing fast incremental parsing and https://crates.io/crates/tree-sitter-stack-graphs 😱 .
tree-sitter grammars can generally be version agnostic (accept multiple versions of the same language), making it easier to build downstream tools. My team builds https://github.com/ConsenSys/solc-typed-ast which provides the same comfort on top of the (all ways changing) solidity AST and tool builders seem to love it 🚀 .

It would be incredibly awesome if there was an officially maintained tree-sitter grammar.
I'm happy to contribute where possible! 🙌

For static analysis tools, we really hope builders will use our compiler as a library for these. It's designed with API is mind, so it is simple to integrate with.

Do you plan to keep the parser of the compiler backwards compatible with all versions > 1.0?
A custom rust parser is def useful (and I'll likely use it myself), but it doesn't fit all usecases. One of the things I really like about tree-sitter is the range of tools/ frameworks that already integrate with it.
An example is semgrep, which leverages tree-sitter to make it incredibly easy to write powerful static analysis rules / detectors. I know a couple of auditors that use this a lot.

As for lsp, our parser is pretty fast actually, and like i said before, it is important for us to have a hand written parser to allow for smart recovery and to supply as much semantic info as possible.

Hi, I'm the author of helix and the maintainer of tree-sitter-cairo 👋🏻

I was hoping most editors could use the syntax highlighting that comes from the language server.

I'm not a huge fan of the LSP highlighting spec because it results in a bunch of heavy back-and-forth traffic per keypress. Helix uses the grammar to also calculate indentation, text objects and a whole bunch of other smart features.
As @xJonathanLEI mentioned, the biggest benefit of an official tree-sitter grammar would be better language support on GitHub itself: currently the Atom grammar is used but this could be swapped out. In the future additional queries could be added that would support code navigation/go to definition on Github. As an example Elixir built an official grammar for this purpose.
I've been hoping to upstream my grammar so that I don't have to maintain it as cairo goes through breaking changes. It's going to be a headache to do so without a formal EBNF grammar and since I'm a third-party dev there's usually a gap after a Cairo release where I need to catch-up with the grammar.

My idea is to first have a working grammar for Cairo 1.0, in this repo, with good testing to make sure it is in line with our parser, then we could make sure it never breaks (in CI)
Maybe if you or some other community member would be willing to make this happen, then we could make sure to maintain ot with our parser.
But this needs to be discussed with the team, and I think we will want to wait with this until the first release at least (when we have less pressure).
@orizi ?

Sure, sounds good! I do recommend keeping a separate repository since most build systems (and github's linguist) end up pulling the grammar via a git repository, so having it split off from the main codebase makes it a smaller clone. I'm willing to transfer the repository under starkware-libs if that's OK with the team.

I'm willing to transfer the repository under starkware-libs if that's OK with the team.

It might make sense to keep this parser separate (maybe call it cairo-legacy), since v1.0 seems to diverge to such an extent that you might almost argue it's a new language.
I'll try to build an initial parser for v1.0 based on what I can learn from the rust parser here: https://github.com/JoranHonig/tree-sitter-cairo

@spapinistarkware still somewhat related to this thread I was wondering if you plan to keep the parser of the compiler backwards compatible with all versions > 1.0?

Allright, it works on all the examples in the repository.
A major thing that I haven't found out yet is all the different literal types.
I'll also do another pass over the parser to add nice node types, fields aliases etc, trying to stick as close as possible to the spec's structure here:
https://github.com/starkware-libs/cairo/blob/main/crates/syntax_codegen/src/cairo_spec.rs

IntelliJ Grammar-Kit syntax def for possible future IntelliJ plugins

Yup, I'm working on a Cairo plugin for IntelliJ and it would be great to have a BNF grammar in this repo.

Allright, it works on all the examples in the repository.
A major thing that I haven't found out yet is all the different literal types.
I'll also do another pass over the parser to add nice node types, fields aliases etc, trying to stick as close as possible to the spec's structure here:
https://github.com/starkware-libs/cairo/blob/main/crates/syntax_codegen/src/cairo_spec.rs

Alright, since I saw that your repo got outdated by some recent changes, I got into this weird project of automatically parsing Cairo's syntax (written in Rust) with tree-sitter, in order to produce a tree-sitter grammar for Cairo.
For now there are still quite a few errors, which seems to stem from the parsing of type clauses (they seem to allow any expression inside them, which therefore allows something like A>B, thus preventing tree-sitter from correctly parsing fn foo() -> Vec<A> {...}). From the comments in cairo_spec.rs, it seems that this "type clause expression" is a known issue however.

@JoranHonig does your Cairo tree sitter support Cairo2? I am looking for a cairo tree sitter to use for a Zed extension

@okhaimie-dev my tree-sitter parser is a bit outdated, it's on my todo list to revisit it and get it up to date with the latest and greatest in cairo

https://github.com/starkware-libs/tree-sitter-cairo


Restructure and tweaks

Hi there, I've made a bunch of small tweaks that, hopefully, will make themes more coherent. Also, I've reduced code duplication in italic/non italic versions of themes - now they use inheritance:
Night Owl.noitalic.color-theme.json
depends on:
Night Owl.color-theme.json
For now its implemented thru undocumented include property of theme files. Hopefully that will make theme tweaking easier.
Here is a bunch of small tweak, some of them may resolve opened issues:

Variables (definition, function arguments, etc.) now have coherent coloring
Object literals and properties now use the same coherent coloring as variables #206
Accessing object properties thru chain now has the same coloring as accessing the properties directly #200
Slightly switched coloring of the built-ins:

built-ins such as console.log, now use coherent function invocation coloring
keywords (for of this) now using coherent coloring

Light theme

class type tokens now have distinguishable pinkish coloring
built-ins such as console now have distinguishable greenish coloring

Here is screenshots of light/dark themes for comparison. "Before" on the left side.

Sorry, I'm happier with the before than the after :) A big part of the theme is contrast- some of the "inconsistencies" are not to keep keywords the same color but rather make them different in different contexts so that one might see them clearly. You can adjust your own version of the theme with workplace settings shown in the README. The CSS-Tricks article linked up explains the reason for these choices.


Update flake inputs

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/tweag-nix-dev-update-28/18645/1