SDPA has non-deterministic PCC

Watcher debug status causes non-deterministic PCC to be much more frequent. See bottom of thread for latest findings.
branch: cglagovich/sdpa_nd
This has the DEBUG_STATUS statements commented out in tt_metal/hw/ckernels/wormhole_b0/metal/llk_api/llk_unpack_AB_api.h and tt_metal/hw/ckernels/wormhole_b0/metal/llk_api/llk_unpack_AB_matmul_api.h which allows the test to pass with watcher enabled. To repro ND, undo the comments in those two files and run with watcher enabled.
Repro command:
pytest -svv tests/tt_eager/python_api_testing/unit_testing/misc/test_scaled_dot_product_attention.py::test_sdpa_nd_program_cache

ND:
compute_with_storage_grid_size=[8,5],
[1, 5, 1, 1024, 128],

ND:
compute_with_storage_grid_size=[8,5],
[1, 5, 1, 512, 128],
q_chunk = k_chunk = 64

ND:
compute_with_storage_grid_size=[8,4],
[1, 4, 1, 512, 128],
q_chunk = k_chunk = 64

ND:
compute_with_storage_grid_size=[8,3],
[1, 3, 1, 512, 128],
q_chunk = k_chunk = 64

ND:
compute_with_storage_grid_size=[8,2],
[1, 2, 1, 2048, 128],
q_chunk = 32, k_chunk = 64

8x1 failed once in 2000 iterations
compute_with_storage_grid_size=[8,1],
[1, 2, 1, 2048, 256],
q_chunk = 32, k_chunk = 64

Different PCCs
Max ATOL Delta: 18.58015251159668, Max RTOL Delta: inf, PCC: 0.3945546634642982, PCC check failed

With watcher enabled, this config has ND PCC on every single iteration
compute_with_storage_grid_size=[8,2],
[1, 2, 1, 2048, 128],
q_chunk = 32, k_chunk = 64

Watcher enabled: ND PCC on every iteration with
compute_with_storage_grid_size=[1,1],
[1, 1, 1, 2048, 128],
q_chunk = 32, k_chunk = 64

Watcher enabled, ND on every iteration
compute_with_storage_grid_size=[1,1],
[1, 1, 1, 512, 128],
q_chunk = 32, k_chunk = 64

Expecting ND with this config:
compute_with_storage_grid_size=[1,1],
[1, 1, 1, 512, 128],
q_chunk = 32, k_chunk = 64

With certain watcher features disabled:
export TT_METAL_WATCHER_DISABLE_ASSERT=1: still ND
&& export TT_METAL_WATCHER_DISABLE_PAUSE=1: still ND
&& export TT_METAL_WATCHER_DISABLE_RING_BUFFER=1: still ND
&& export TT_METAL_WATCHER_DISABLE_NOC_SANITIZE=1: still ND
&& export TT_METAL_WATCHER_DISABLE_STATUS=1: deterministic!

fyi @rtawfik01

This diff which moves around dst reg acquries and cb_wait_front reduces ND by a lot but it's still ND with DEBUG_STATUS enabled in llk_unpack_AB_matmul_api.h:
diff --git a/tt_eager/tt_dnn/op_library/sdpa/kernels/compute/sdpa.cpp b/tt_eager/tt_dnn/op_library/sdpa/kernels/compute/sdpa.cpp
index b0ce32e0c9..566c4db9bf 100644
--- a/tt_eager/tt_dnn/op_library/sdpa/kernels/compute/sdpa.cpp
+++ b/tt_eager/tt_dnn/op_library/sdpa/kernels/compute/sdpa.cpp
@@ -275,10 +275,10 @@ void matmul_blocks(const uint32_t& in0_cb, const uint32_t& in1_cb, const uint32_
     // postcondition: out_cb has M*N produced

+    cb_wait_front(in1_cb, K * N);
     mm_block_init_short(in0_cb, in1_cb, transpose /*transpose*/, subblock_w /*ct_dim*/, subblock_h /*rt_dim*/, in0_block_w /*kt_dim*/);

     unpack_reconfig_data_format(in1_cb, in0_cb);
-    cb_wait_front(in1_cb, K * N);

     uint32_t output_num_tiles = M * N;
     uint32_t out_subblock_num_tiles = subblock_h * subblock_w;
@@ -287,7 +287,9 @@ void matmul_blocks(const uint32_t& in0_cb, const uint32_t& in1_cb, const uint32_

     for (uint32_t in0_subblock = 0; in0_subblock < in0_num_subblocks; ++in0_subblock) {
         for (uint32_t in1_subblock = 0; in1_subblock < in1_num_subblocks; ++in1_subblock) {
+            cb_reserve_back(out_cb, out_subblock_num_tiles);
             tile_regs_acquire();
+            tile_regs_wait();

             uint32_t dst_index = 0;
             uint32_t in0_index = in0_index_offset;
@@ -299,13 +301,11 @@ void matmul_blocks(const uint32_t& in0_cb, const uint32_t& in1_cb, const uint32_
                 in1_index += N;

             }
-            tile_regs_commit();

-            cb_reserve_back(out_cb, out_subblock_num_tiles);
-            tile_regs_wait();
             for (uint32_t i = 0; i < out_subblock_num_tiles; i++) {
                 pack_tile(i, out_cb);
             }
+            tile_regs_commit();
             tile_regs_release();
             cb_push_back(out_cb, out_subblock_num_tiles);
             in1_index_offset += in1_subblock * subblock_w;
@@ -438,6 +438,7 @@ void MAIN {
                     reduce_c<PoolType::SUM, ReduceDim::REDUCE_ROW, cb_qk_im, cb_identity_scale_in, cb_cur_sum, Sq_chunk_t, Sk_chunk_t>();

                     /* OUT_IM = QK @ V_CHUNK */
+                    cb_wait_front(cb_qk_im, qk_chunk_tiles);
                     matmul_blocks(cb_qk_im, cb_v_in, cb_out_im, Sq_chunk_t, DHt, Sk_chunk_t, out_num_blocks, out_in0_num_subblocks, out_in1_num_subblocks, out_in0_block_w, out_subblock_h, out_subblock_w, false /*transpose*/);
                     unpack_reconfig_data_format_srca(cb_out_im);
                     cb_pop_front(cb_qk_im, qk_chunk_tiles);

A puzzle for LLK developers: The SDPA kernel has rare non-determinism. When I enable watcher debug status, PCC is non-deterministic on almost every iteration. Disabling DEBUG_STATUS in tt_metal/hw/ckernels/wormhole_b0/metal/llk_api/llk_unpack_AB_matmul_api.h, this frequent non-determinism goes away.
When I reenable DEBUG_STATUS in that file but I add a tensix sync in the following codeblock, the PCC is much more deterministic.
Do you see the issue?
void matmul_blocks(const uint32_t& in0_cb, const uint32_t& in1_cb, const uint32_t& out_cb, const uint32_t& M, const uint32_t& N, const uint32_t& K, const uint32_t& num_blocks, const uint32_t& in0_num_subblocks, const uint32_t& in1_num_subblocks,
                    const uint32_t& in0_block_w, const uint32_t& subblock_h, const uint32_t& subblock_w, const bool& transpose) {
    // precondition: in0_cb has M*K produced
    // preconditino: in1_cb has K*N produced
    // postcondition: in0_cb is full, in1_cb is empty
    // postcondition: out_cb has M*N produced

    mm_block_init_short(in0_cb, in1_cb, transpose /*transpose*/, subblock_w /*ct_dim*/, subblock_h /*rt_dim*/, in0_block_w /*kt_dim*/);

    unpack_reconfig_data_format(in1_cb, in0_cb);
    cb_wait_front(in0_cb, M * K);
    cb_wait_front(in1_cb, K * N);

    uint32_t output_num_tiles = M * N;
    uint32_t out_subblock_num_tiles = subblock_h * subblock_w;
    uint32_t in0_index_offset = 0;

    for (uint32_t in0_subblock = 0; in0_subblock < in0_num_subblocks; ++in0_subblock) {
        uint32_t in1_index_offset = 0;
        for (uint32_t in1_subblock = 0; in1_subblock < in1_num_subblocks; ++in1_subblock) {
            tile_regs_acquire();

            uint32_t dst_index = 0;
            uint32_t in0_index = in0_index_offset;
            uint32_t in1_index = in1_index_offset;

            for (uint32_t inner_dim = 0; inner_dim < in0_block_w; inner_dim++) {
                // tensix_sync(); // UNCOMMENT FOR DETERMINISM
                matmul_block(in0_cb, in1_cb, in0_index, in1_index, dst_index, transpose, subblock_w, subblock_h, in0_block_w);
                in0_index++;
                in1_index += N;

            }
            tile_regs_commit();

            cb_reserve_back(out_cb, out_subblock_num_tiles);
            tile_regs_wait();
            for (uint32_t i = 0; i < out_subblock_num_tiles; i++) {
                pack_tile(i, out_cb);
            }
            tile_regs_release();
            cb_push_back(out_cb, out_subblock_num_tiles);
            in1_index_offset += subblock_w;
        }
        in0_index_offset += subblock_h * in0_block_w;
    }
    cb_pop_front(in1_cb, K * N);
}

@TT-BrianLiu do you have an idea here?

@bbradelTT, thoughts?

Are we sure it's an issue with the compute? Is there some race in the reader that is causing the tiles passed to matmul_block to be different? I would print out the tiles going into matmul_block to confirm

Given the comment // tensix_sync(); // UNCOMMENT FOR DETERMINISM
My best guess is that the writes of multiple matmul_block() commands are in flight at once and can be saved in different order.
For lower levels of precision A+B+C and C+B+A can differ substantially in terms of error amounts.

@bbradelTT would this be explained by the fact that disrupting timing in llk_unpack_AB_matmul_api.h by adding DEBUG_STATUS statements leads to more non-determinism?

Further, I found that UNPACK(tensix_sync()); at that spot reduced ND, but MATH(tensix_sync()); did not. Does that tell you something?

I don't think I have made any conclusions on code based on the frequency of ND.  If there's a deterministic datapoint, that would be most useful.

I don't have a deterministic datapoint. What I was able to do was create a simpler repro.
This repro removes a lot of the functionality of the SDPA op to limit the kernel to the minimal number of operations which result in ND PCC. Note that PCC is expected to be low and inconsistent. If the ND was resolved, it would be the exact same low PCC every iteration.
This repro does effectively the following:
for i in range(num_chunks):
  cb_qk_im = cb_q_in @ cb_k_in
  cb_cur_sum = reduce_sum(cb_qk_im) # cb_cur_sum output is unused, but the execution of reduce_sum is necessary to cause ND PCC
  cb_out_accumulate_im += cb_qk_im @ cb_v_in

cb_out = cb_out_accumulate_im

branch: cglagovich/sdpa_nd2
command:
pytest -svv tests/tt_eager/python_api_testing/unit_testing/misc/test_scaled_dot_product_attention.py::test_sdpa_nd_program_cache

Expected output:
  0%|                                                                                | 0/100000 [00:00<?, ?it/s]
First iteration PCC: Max ATOL Delta: 1583.8631591796875, Max RTOL Delta: inf, PCC: 0.3370113879576181, PCC check failed
  0%|_                                                                                | 82/100000 [00:02<35:50, 46.46it/s]
2024-06-12 19:52:42.387 | INFO     | tests.tt_eager.python_api_testing.unit_testing.misc.test_scaled_dot_product_attention:run_test_sdpa_tt_ND:168 - failed ND PCC check on iter 85: Max ATOL Delta: 1583.8631591796875, Max RTOL Delta: inf, PCC: 0.3370075996909392, PCC check failed
  0%|_                                                                                | 98/100000 [00:03<34:10, 48.73it/s]
2024-06-12 19:52:42.725 | INFO     | tests.tt_eager.python_api_testing.unit_testing.misc.test_scaled_dot_product_attention:run_test_sdpa_tt_ND:168 - failed ND PCC check on iter 102: Max ATOL Delta: 1583.8631591796875, Max RTOL Delta: inf, PCC: 0.3369731619264583, PCC check failed

The strangest part is that my reduce_sum function

Produces output which isn't used anywhere else
Doesn't actually call reduce_tile

template<PoolType pool_type, ReduceDim reduce_dim, uint32_t in0_cb, uint32_t scale_cb, uint32_t out_cb, uint32_t rows, uint32_t cols>
void reduce_c() {

    reduce_init_delta<false, pool_type, reduce_dim>(pool_type, reduce_dim, in0_cb, scale_cb, out_cb);

    const uint32_t num_tiles = rows * cols;
    cb_wait_front(scale_cb, 1);
    cb_wait_front(in0_cb, num_tiles);
    cb_reserve_back(out_cb, rows);

    constexpr uint32_t reduce_dst_idx = 0;

    for (uint32_t i = 0; i < rows; i++) {
        acquire_dst(tt::DstMode::Half);
        for (uint32_t j = 0; j < cols; j++) {
            // reduce_tile<pool_type, reduce_dim>(in0_cb, scale_cb, i*cols+j, 0, reduce_dst_idx);
        }

        cb_reserve_back(out_cb, 1);
        // pack_tile(reduce_dst_idx, out_cb);
        cb_push_back(out_cb, 1);
        release_dst(tt::DstMode::Half);
    }

   reduce_revert_delta<reduce_dim>(out_cb);
}

Update:
I found this behavior on cglagovich/sdpa_nd2:
Q = torch.zeros()
K = torch.zeros()
V = torch.eye()
reduce_scalar = 1234

out = sdpa(Q, K, V, reduce_scalar)

> For most iterations, out = torch.zeros()
> Non-deterministically,
> out = [[[1234, 1234, 1234,... 0], [0...0]]]

Whatever value I put in reduce_scalar ended up in the first 32 elements of my output.
Adding tensix_sync() after reduce_revert_delta() made this ND go away.

So far, we have learned that UNPACK(tensix_sync()); is the minimal synchronization needed after reduce_revert_delta to get determinism.
TTI_STALLWAIT(p_stall::STALL_UNPACK, p_stall::UNPACK); as a stall method does not lead to determinism.

A similar nd pcc issue is encountered on the flash decode op #9510 at sequence long 16k to 20k, where adding UNPACK(tensix_sync()); at mul_block_inplace and mul_block_inplace would work around the issue (see commit 3e5119c). Both flash decode and sdpa shares the same main loop and debugging has narrowed down that the nd pcc comes from the main loop.

New repro for ND PCC in another variant of SDPA:
branch: cglagovich/flash_decode_ND
command:
pytest -svv tests/tt_eager/python_api_testing/unit_testing/misc/test_scaled_dot_product_attention.py::test_sdpa_decode

In the file sdpa_noncausal.cpp, uncomment the UNPACK STALL instructions to get determinism. Again, this seems to be related to reduce_sum.

Update to this issue in the debug process, while using this branch: cglagovich/sdpa_nd2 and this test:
pytest -svv tests/tt_eager/python_api_testing/unit_testing/misc/test_scaled_dot_product_attention.py::test_sdpa_nd_program_cache

The ND still happens after commenting out add_block_inplace(cb_out_accumulate_im, cb_out_im, out_chunk_tiles); and copy_block(cb_out_accumulate_im, cb_out, out_chunk_tiles);.
Replacing the reduce_c calls with binary calls for example, still causes the ND issues. And commenting out the functionality in this loop in reduce_c:

        for (uint32_t j = 0; j < cols; j++) {
            // reduce_tile<pool_type, reduce_dim>(in0_cb, scale_cb, 0, 0, 0);
        }

causes 10k loops to pass. So it is not reduce functionality dependent, some unpack + math calls just introduce the number of cycles necessary to cause or expose the ND.

The output value of matmul_blocks, contains the same values as in the reduce scalar buffer: cb_identity_scale_in.
If that value is changed in tt_eager/tt_dnn/op_library/sdpa/kernels/dataflow/writer_interleaved.cpp in this function:

generate_reduce_scaler(cb_identity_scale_in, 0xdeadbeef);

to any other hex value, that value propagates to the output.

If we add asserts to check the l1 values of the input buffers to matmul blocks:

matmul_blocks(cb_qk_im, cb_v_in, cb_out, Sq_chunk_t, DHt, Sk_chunk_t, out_num_blocks, out_in0_num_subblocks, out_in1_num_subblocks, out_in0_block_w, out_subblock_h, out_subblock_w, false /*transpose*/);,

the hex value from reduce scalar is never found.
5, If we add those same asserts to the output buffer, the hex value is found, so it is potentially a leftover state that is not cleared.
Next steps will be to dump out all of the L1 and check that the addresses of the hex values are what we expect, and second will force the matmuls blocks to clear src registers state and see if there is indeed a leftover state.
Will update you with more experiments @cglagovichTT

Another update:
I have added another debug commit here:cglagovich/sdpa_nd2 for the smallest reproducible case. Some notes:

For cb_identity_scale_in I have placed the value: 0x7F800000 which is the float16b value for inf. In the debug commit, I have changed the reduce to an eltwise binary function, with SrcA register having the input to reduce instead, and SrcB having the scalars similar to reduce. This fails ND, with the output the matmul blocks having the 0x7F800000 value in the output.
If I switch the operands above: SrcA register  = scalar of inf, SrcB = reduce input, test no longer has ND, output is all zeroes.
If I also change the binary operation, to a datacopy operation, with reduce input or scalars, it passes , and datacopy only uses SrcA, not SrcB.

So far it points to SrcB having a remaining state but:
If I add zerosrc functions:
                    UNPACK(TTI_UNPACR_NOP(SrcA, p_unpacr_nop::UNP_ZEROSRC_RESET_ALL_BANKS);)
                    UNPACK(TTI_UNPACR_NOP(SrcB, p_unpacr_nop::UNP_ZEROSRC_RESET_ALL_BANKS);)

to clear the source registers before every unpack instruction that the unpack matmul executes, the test still has ND outputs from matmul with infinity value.
2. Also if I remove the reduce_revert_delta<reduce_dim>(out_cb); function, that functionally does nothing in the debug code, and only affects the pack thread, the test passes again.
@cglagovichTT there are a few more experiments I'd like to try, but all in all I might need a wavedump and since metal doesnt haven't that functionality yet (hopefully coming soon), it will be difficult to know how exactly that infinity value is propagating through the ops.

Does this point to the issue being stale values in DST rather than srcB? What exactly is reduce_revert_delta doing - could it have an affect on the state of the FPU beside affecting timing of the packer?
Further debug possibilities:

we can select a specific V which shuffles the LHS input to prove that the matmul is applied on a stale srcB
we can inspect the disassembly to ensure that the compiler is not reordering your srcB clear instructions after the unpack calls

Should we loop anyone who wrote or debugged the matmul LLKs, reduce LLKs, and circular buffer APIs?

@ttmtrajkovic fyi

I pushed a commit to cglagovich/sdpa_nd2 which simplified the loop logic in the kernels. I verified that ND still exists in the test case.

Setting this to P0 since it may be interacting with a new issue https://github.com/tenstorrent/tt-metal/issues/11591 to make the current workaround no longer work. FYI @yieldthought

Confirming that even after some recent fixes which were introducing ND behaviour in some other tests, the issue in this problem still persists in the main branch till commit : commit 168e53a0a3e12ec567a6ad29c88ebc671a7ca8b5 done on Thu Aug 29 10:17:11 2024 -0400. But it does seem to be very hard to produce on the unmodified problem
Failed ND PCC check on iter 4: Max ATOL Delta: 0.426819771528244, Max RTOL Delta: inf, PCC:     0.9994296489218842
First iteration PCC: Max ATOL Delta: 0.09726965427398682, Max RTOL Delta: inf, PCC: 0.9996040143129393

Thank you @amahmudTT . I've found that with the unmodified problem, I typically have to sweep input shapes, hyperparameters, and grid sizes in order to find ND PCC. I believe that the modified problem is the underlying (or at least one underlying) cause of ND PCC showing up in the original op.

Wanted to verify if the asynchronous calls to noc were causing any problem or not.
Result : The reads are done on different NOCs thus not likely to introduce race conditions. The barriers are working properly through polling till the requests match the amount of work done.

I have not found the root cause of the bug but putting two TTI_NOPS in the function  llk_pack_reduce_mask_clear() which is eventually called by reduce_revert_delta, fixes the issue both in the reduced test case and the main test (ran for 1000 times for all scenarios, which amounts to around 24 thousand runs).  See the two TTI_NOPs added in line 285
274 inline void _llk_pack_reduce_mask_clear_() {
275     // By default, all packers are set to use TILE_ROW_SET_MAPPING_0 and
276     // mask is configured to pass through all the datums
277     pck_edge_offset_u pack_edge_offset = {.val = 0};
278     pack_edge_offset.f.mask = 0xffff;
279
280     // Initialize TMP registers with values we need to write in CFG registers
281     TTI_SETDMAREG(0, LOWER_HALFWORD(pack_edge_offset.val), 0, LO_16(p_gpr_pack::TMP0));
282     TTI_SETDMAREG(0, UPPER_HALFWORD(pack_edge_offset.val), 0, HI_16(p_gpr_pack::TMP0));
283
284     // Wait for packer to finish to avoid breaking its current configuration
285     TTI_STALLWAIT(p_stall::STALL_CFG, p_stall::PACK);
286
287     // Clear out packer configuration for reduce
288     TTI_WRCFG(p_gpr_pack::TMP0,  p_cfg::WRCFG_32b, PCK_EDGE_OFFSET_SEC0_mask_ADDR32);
289     TTI_WRCFG(p_gpr_pack::TMP0,  p_cfg::WRCFG_32b, PCK_EDGE_OFFSET_SEC1_mask_ADDR32);
290
291     TTI_NOP; TTI_NOP;   // Extra NOPs fixes issue #9370
292
293     // All mappings point to PCK_EDGE_OFFSET_SEC0_mask_ADDR32
294     TTI_WRCFG(p_gpr::ZERO,  p_cfg::WRCFG_32b, TILE_ROW_SET_MAPPING_0_row_set_mapping_0_ADDR32);
295     TTI_WRCFG(p_gpr::ZERO,  p_cfg::WRCFG_32b, TILE_ROW_SET_MAPPING_1_row_set_mapping_0_ADDR32);
296
297     TTI_NOP; TTI_NOP;
298 }

When nops fixes a kernel failure, this usually points to race condition in one of the registers that are configured in the kernel. It would make sense to see where else these registers are being accessed and if they have proper synchronization.

When nops fixes a kernel failure, this usually points to race condition in one of the registers that are configured in the kernel. It would make sense to see where else these registers are being accessed and if they have proper synchronization.

If I grep for the registers : p_gpr_pack::TMP0, PCK_EDGE_OFFSET_SEC0_mask_ADDR32, PCK_EDGE_OFFSET_SEC1_mask_ADDR32,  TILE_ROW_SET_MAPPING_0_row_set_mapping_0_ADDR32 and TILE_ROW_SET_MAPPING_1_row_set_mapping_0_ADDR32
I only find their references in packer files and see them defined in cfg_defines.h. With that in mind is there still any possibility of them being accessed from any thread other than the packer ?

Could it be the case that these register writes are sometimes reordered by the compiler or the hardware, so inserting NOPs is required in order to ensure their order?

Could it be the case that these register writes are sometimes reordered by the compiler or the hardware, so inserting NOPs is required in order to ensure their order?

Are the instructions dependent ? From arguments alone they do not seem to be dependent. But they could be doing some sort of handshake in the hardware that I may not be aware of.

@amahmudTT my understanding is that under the hood, matmul_block takes that dst_index, copies it, and internally increments it to populate dst with the various partials that it creates

Wonder if @tt-aho fix for unpacker init (094ea896) fixed this?

Wonder if @tt-aho fix for unpacker init (094ea89) fixed this?

No it did not.

Wonder if @tt-aho fix for unpacker init (094ea89) fixed this?

When I was debugging it seemed that unpacker race was a different/separate issue from this, and only potentially affected this issue due to timing.

ok.  idle musing: wonder if we have another register getting globally inited and then locally overridden that could affect this...

We recently had a SFPNOP related issue fixed where the compiler was not emitting NOPs where needed.
In the writer code of the reduced test case I see this block of code. The compute thread does not have an sfpu instruction in the reduced test case. I  do not know when this gets executed and if it does get executed are we missing NOPs after the sfplutfp32 instructions ?
527 Disassembly of section .ldm_data:
528
529 ffb006e0 <__ldm_data_start>:
530 ffb006e0:       202a2a2a                sfppopc 10
531 ffb006e4:       45544e49                ttsetadcxy      2, 42, 1, 1, 6, 18
532 ffb006e8:       4c414e52                sfploadmacro    L15012, 0, 1
533 ffb006ec:       42454420                ttzeroacc       18, 2, 20744
534 ffb006f0:       50204755                ttsetadczw      0, 16, 1, 0, 7, 21
535 ffb006f4:       544e4952                sfplutfp32      L5, 4
536 ffb006f8:       46554220                ttzerosrc       611592, 1, 0, 0
537 ffb006fc:       20524546                sfppopc 1
538 ffb00700:       5245564f                fnmadd.d        fa2, fa0, ft4, fa0, unknown
539 ffb00704:       574f4c46                sfplutfp32      L1, 1
540 ffb00708:       2a2a2a20                ttmovd2b        1, 5, 1, 0, 2696
541 ffb0070c:                       sfpnot  L8, L2

That sequence looks ok to me - sfplut requires a an SFPU insn (nop or other) before reading the value written by sfplut.  The above sequence meets that criteria afaict

After doing some experiments numerically. It seems SrcB that holds the scalar tile filled by the writer is not updated before the matmul and the matrix multiplication happens with that.
So the modified kernel basically does this
qk = Q*K
discarded = qk + scalar_tile (with first 32 elements set to nonzero)
OUT = qk *V
I set the matrices to diagonal matrices without changing their square size of 128X128
Q= diagonal (5)
K = diagonal(7)
V= diagonal(9)
My result is supposed to be a diagonal matrix of 316 (rounded from 315) , I get that but during errors I get rows like this
          [ 27.,  27.,  27.,  27.,  27.,  27.,  27.,  27.,  27.,  27.,  27.,
            27.,  27.,  27.,  27.,  27.,  27.,  27.,  27.,  27.,  27.,  27.,
            27.,  27.,  27.,  27.,  27.,  27.,  27.,  27.,  27.,  27.,   0.,
             0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,
             0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,
             0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0., 316.,   0.,
             0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,
             0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,
             0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,
             0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,
             0.,   0.,   0.,   0.,   0.,   0.,   0.,

From what I gather.
If by error in NOC/ memory address a tile was overwritten I would not get the triangular matrix.
If flushing of dest register failed I would not get 27 but rather a number greater than 35.
Only confusion is if this happens to the first block in the output, the diagonal 316s are not present for any other block if the 27s are present, then the diagonal 316s are also present.

To remove any doubt , in the reduce_c function that actually does an eltwise add of QK & Scalar_tile , I changed it to eltwise multiple, to zero out most of the elements and also eltwise sub, to negate all the elements. But the result remains as before. Thus SrcB retains its previous L1 address for a while it seems. The address is supposed to be changed in the matmul_blocks code by setting some registers using MMIO based on the current context in the llk_unpack_AB_matmul
        wait_for_next_context(2);

        semaphore_post(semaphore::UNPACK_SYNC);  // Trisc::SEMPOST for context acquire

        // Program unpacker 1 base address
        if (0 == unp_cfg_context) {
            cfg[THCON_SEC0_REG3_Base_address_ADDR32] = address_b;
            cfg[THCON_SEC1_REG3_Base_address_ADDR32] = address_a;
        } else {
            cfg[THCON_SEC0_REG3_Base_cntx1_address_ADDR32] = address_b;
            cfg[THCON_SEC1_REG3_Base_cntx1_address_ADDR32] = address_a;
        }

and in the MOP it is updated using RDCFG.
            } else {
                TTI_RDCFG(p_gpr_unpack::TMP0, THCON_SEC0_REG3_Base_address_ADDR32);
                TTI_ADDDMAREG(0, p_gpr_unpack::TMP0, p_gpr_unpack::TMP0, p_gpr_unpack::TILE_SIZE_A);
                TTI_REG2FLOP(1,0,0,0,THCON_SEC0_REG3_Base_address_ADDR32-THCON_CFGREG_BASE_ADDR32, p_gpr_unpack::TMP0);
            }

The llc-doc says there have been issues when RDFG and MMIO read. In this test case we are using MMIO & RDFG in the unpacker thread to change the SrcB address and using WRCFG in the packer thread to change the configuration.
inline void _llk_pack_reduce_mask_clear_() {
    // By default, all packers are set to use TILE_ROW_SET_MAPPING_0 and
    // mask is configured to pass through all the datums
    pck_edge_offset_u pack_edge_offset = {.val = 0};
    pack_edge_offset.f.mask = 0xffff;

    // Initialize TMP registers with values we need to write in CFG registers
    TTI_SETDMAREG(0, LOWER_HALFWORD(pack_edge_offset.val), 0, LO_16(p_gpr_pack::TMP0));
    TTI_SETDMAREG(0, UPPER_HALFWORD(pack_edge_offset.val), 0, HI_16(p_gpr_pack::TMP0));

    // Wait for packer to finish to avoid breaking its current configuration
    TTI_STALLWAIT(p_stall::STALL_CFG, p_stall::PACK);

    // Clear out packer configuration for reduce
    TTI_WRCFG(p_gpr_pack::TMP0,  p_cfg::WRCFG_32b, PCK_EDGE_OFFSET_SEC0_mask_ADDR32);
    TTI_WRCFG(p_gpr_pack::TMP0,  p_cfg::WRCFG_32b, PCK_EDGE_OFFSET_SEC1_mask_ADDR32);

    // All mappings point to PCK_EDGE_OFFSET_SEC0_mask_ADDR32
    TTI_WRCFG(p_gpr::ZERO,  p_cfg::WRCFG_32b, TILE_ROW_SET_MAPPING_0_row_set_mapping_0_ADDR32);
    TTI_WRCFG(p_gpr::ZERO,  p_cfg::WRCFG_32b, TILE_ROW_SET_MAPPING_1_row_set_mapping_0_ADDR32);

    TTI_NOP; TTI_NOP;
}

It seems likely they are causing the conflict. In any case I will be trying to debug a bit further but we plan to introduce a synchronization mechanism for these two.

Making the following change to reduce_revert_delta function, that is using RMWIB* functions instead of WRCFG ones, fixed the issue both for the reduced test case and the main branch with the original test.
@@ -277,20 +277,13 @@ inline void _llk_pack_reduce_mask_clear_() {
     pck_edge_offset_u pack_edge_offset = {.val = 0};
     pack_edge_offset.f.mask = 0xffff;

-    // Initialize TMP registers with values we need to write in CFG registers
-    TTI_SETDMAREG(0, LOWER_HALFWORD(pack_edge_offset.val), 0, LO_16(p_gpr_pack::TMP0));
-    TTI_SETDMAREG(0, UPPER_HALFWORD(pack_edge_offset.val), 0, HI_16(p_gpr_pack::TMP0));
-
     // Wait for packer to finish to avoid breaking its current configuration
     TTI_STALLWAIT(p_stall::STALL_CFG, p_stall::PACK);

-    // Clear out packer configuration for reduce
-    TTI_WRCFG(p_gpr_pack::TMP0,  p_cfg::WRCFG_32b, PCK_EDGE_OFFSET_SEC0_mask_ADDR32);
-    TTI_WRCFG(p_gpr_pack::TMP0,  p_cfg::WRCFG_32b, PCK_EDGE_OFFSET_SEC1_mask_ADDR32);
-
-    // All mappings point to PCK_EDGE_OFFSET_SEC0_mask_ADDR32
-    TTI_WRCFG(p_gpr::ZERO,  p_cfg::WRCFG_32b, TILE_ROW_SET_MAPPING_0_row_set_mapping_0_ADDR32);
-    TTI_WRCFG(p_gpr::ZERO,  p_cfg::WRCFG_32b, TILE_ROW_SET_MAPPING_1_row_set_mapping_0_ADDR32);
+    cfg_reg_rmw_tensix<PCK_EDGE_OFFSET_SEC0_mask_RMW>(pack_edge_offset.val);
+    cfg_reg_rmw_tensix<PCK_EDGE_OFFSET_SEC1_mask_RMW>(pack_edge_offset.val);
+    cfg_reg_rmw_tensix<TILE_ROW_SET_MAPPING_0_row_set_mapping_0_RMW>(0);
+    cfg_reg_rmw_tensix<TILE_ROW_SET_MAPPING_1_row_set_mapping_0_RMW>(0);

     TTI_NOP; TTI_NOP;
 }

Because the reduced problem did not require the exact instructions in the llk_pack_reduce_mask_clear function since the mask was never set, we tried to introduce RMW instructions to replace the WRCFG instructions in such a way that the timing and cycles consumed is same as before, even in that case the reduced test passes. Which further corroborates to the above conjecture.

If I'm following, you have a workaround! Does this mean that the underlying problem is understood? Are there other LLKs which use this faulty pattern?

If I'm following, you have a workaround! Does this mean that the underlying problem is understood? Are there other LLKs which use this faulty pattern?

Yes we have a workaround, but we need to do the simulation to verify that WRCFG & MMIO writes conflict like RDCFG and MMIO reads do (I think we have done as much as possible in pure software/coding to identify the bug) & Syed is also going to look into the RTL/Hardware.
I have not seen the use of this reduce_revert_delta function in the tt-metal repo anywhere other than this code.

We have pushed a workaround patch for this. https://github.com/tenstorrent/tt-metal/pull/12832
BUT PLEASE DO NOT CLOSE OR DELETE THE ISSUE OR ANY RELATED BRANCH
as we want to verify the conjecture in simulation and if a hardware bug is found we would document the issue.

I will be continuing further work in this issue https://github.com/tenstorrent/tt-metal/issues/12855

Managed to make a tiny c++ test case that manifests this issue using single tile operations. The ND behaviour is controlled by adding NOPs in one of the threads (packer) for the last version. This has been simulated using versim and the simulator was able to manifest the ND behaviour with the correct number of NOPs.  More details here :
https://github.com/tenstorrent/tt-metal/issues/12855#issuecomment-2423610089

Great, thank you for the update! Does this indicate that there is a HW bug that should be tracked, or were the LLKs using the HW in a way that had undefined behavior?

We are going to look at the versim today or tomorrow. I think it is a hardware bug since the software was changed quite a bit with lots of sync instructions and then the bug was still produced but with a lower frequency.

VCD Dumps for 35 nops (ND not observed) and 36 nops (ND observed)  introduced in the above mentioned test case.
Uploading SDPA_VCD.zip…

Was able to reproduce the same issue on blackhole.

@ttmtrajkovic  investigated the versim files and found the issue. In the unpacker we have the following code :
     // Program unpacker 1 base address
        if (0 == unp_cfg_context) {
            cfg[THCON_SEC0_REG3_Base_address_ADDR32] = address_b;
            cfg[THCON_SEC1_REG3_Base_address_ADDR32] = address_a;
        } else {
            cfg[THCON_SEC0_REG3_Base_cntx1_address_ADDR32] = address_b;
            cfg[THCON_SEC1_REG3_Base_cntx1_address_ADDR32] = address_a;
        }

        if (reuse_a) {
            #if SKIP_UNP == 1
                TTI_NOP;
            #else
                if (unpB_partial_face) {
                    TTI_UNPACR_NOP(SrcB, 0, 0, 0 /*Set Dvalid*/, 0, 0, 0, 0, p_unpacr_nop::UNP_ZEROSRC);
                    // Do face by face unpacking
                    TTI_UNPACR(SrcB, 0b00010001, 0, 0, 0, 1 /*Set OvrdThreadId*/, 0 /*Set Dvalid*/, p_unpacr::RAREFYB_DISABLE, 0, 0 /* Set ContextIdInc */, 0, 0, 1);
                    TTI_UNPACR(SrcB, 0b00010001, 0, 0, 0, 1 /*Set OvrdThreadId*/, 1 /*Set Dvalid*/, p_unpacr::RAREFYB_DISABLE, 0, 0 /* Set ContextIdInc */, 0, 0, 1);
                    TTI_SETADCZW(p_setadc::UNP_B, 0, 0, 0, 0, 0b0101); // Set ch0_z=0, ch1_z=0
                } else {
                    TTI_UNPACR(SrcB, 0, 0, 0, 0, 1 /*Set OvrdThreadId*/, 1 /*Set Dvalid*/, p_unpacr::RAREFYB_DISABLE, 0, 0 /* Set ContextIdInc */, 0, 0, 1);
                }
            #endif
        } else {

Note there is no sync between the addresses are written for the unpacker and reading by the unpackerB. This was probably done for performance reasons assuming the read will always be done after the MMIO writes are complete, which is most of the time true. But in our test case when the multiple WRCFG instructions are issued in the packer thread, during the arbitration they are given priority and the MMIO writes get delayed and the unpackers read data from previous addresses saved in those registers.
The fix could work in many ways,

We could put 2 NOPs after every WRCFG instructions. This would reduce the probability but not guarantee the correct answer because if in a very rare case both math thread and packer thread both issued WRCFG instructions then they would queue up and delay this MMIO write again. In that case we would need 2 NOPs after every WRCFG instruction. For safety this is probably better done through compiler.

We could not use MMIO instructions and use WRCFG instructions in the above snippet and use a stallwait afterwards.

We could also use sync_reg_write instruction to make sure the MMIO op is finished.

For the last two cases we should make sure if there are other such cases or not.

It is good to hear this is not a hardware bug.

PR to fix this issue. (The wrong code pattern is used in other files which may show up in other problems, we have a separate issue for that.)
https://github.com/tenstorrent/tt-metal/pull/14760


Breadcrumbs and navigation menu not working properly

Problem
I am using the sphinx_rtd_theme with autosummary extension for generating the docs automatically. But for now the menu navigation nor the breadcrumbs is not working properly. The menu is always closing if I click a menu item. Also some submenu items are not shown. Lets assume I have 3 main classes A, B, C with some methods A.m1, A.m2... If I click on A.m1 the breadcrumbs should show A >> A.m1. But this is not working. The breadcrumbs only shows A.m1. I dont know if thats a missconfiguration or a bug. It looks like there is a wrong or not existing linking/routing for the rst files. I want the menu and breadcrumbs to work like in this example: https://pvlib-python.readthedocs.io/en/stable/generated/pvlib.location.Location.html
Reproducible Project
https://vps2106233.servdiscount-customer.com/sphinx/
conf.py
html_theme = 'sphinx_rtd_theme'
master_doc = 'index'
html_static_path = ['_static']
source_suffix = '.rst'
pygments_style = 'sphinx'
autosummary_generate = True
napoleon_use_rtype = False  # group rtype on same line together with return
make_github_url = "https://lifv002.joanneum.at/stn/mpc_tagger_areal/blob/master"
html_css_files = ["custom.css"]
html_show_sphinx = False
html_logo = "_static/jr_logo.png"

Environment Info

Python Version: 3.8.5
Sphinx Version: 4.0.2
RTD Theme Version: 0.5.2

The issue was caused by a wrong syntax in the .rst file.
WRONG:
.. autosummary::
:toctree: autogen/

data.ForecastData
data.HistoryData
RIGHT:
.. autosummary::
:toctree: autogen/
data.ForecastData
data.HistoryData

Looks like the syntax error was the cause, can we close this issue?


Refactor mock get method for testing to accept return object

We keep using a mocked_get() function pretty much everywhere. A variant of this has already been refactored into the conftest.py file, so it probably makes sense to just have a single mock method but have it accept the return type as an argument. Something like so:
def my_mock_get(expectedReturn):
  async def inner_mock(some, other, args):
    return expectedReturn
  return inner_mock

It seems that you can do something like this with fixtures in pytest using indirect parameterizations: https://docs.pytest.org/en/latest/example/parametrize.html#apply-indirect-on-particular-arguments
Originally posted by @surchs in https://github.com/neurobagel/api/pull/264#discussion_r1462460857

:rocket: Issue was released in v0.2.0 :rocket:


Update small ubuntu, just rebuild

Summary

Regular update

Related issue :

Hi,
I can't get a copy of Small.Ubuntu.20.04-2023.06.03.ova
Could you please have a look?
Thanks!

I can't get a copy of Small.Ubuntu.20.04-2023.06.03.ova

wrong year in the version, should work now


Github-desktop broken since update to NixOS 23.05 due to dependency on openssl-1.1.1u

Describe the bug
Since updating my systems to NixOS 23.05 the package github-desktop is no longer usable. It depends on openssl-1.1.1u which is marked as insecure.
Steps To Reproduce
Steps to reproduce the behavior:

Run NixOS 23.05
Attempt to add github-desktop to your configuration

Expected behavior
The system / home-manager flake is supposed to build with github-desktop.
Additional context
I get the following error shown below. Nix then tells me to do a bunch of workarounds such as export NIXPKGS_ALLOW_INSECURE=1 or adding the package into the list of allowed packages. Which is not ideal for my flakes-based setup with multiple machines.
I am not sure why github-desktop depends on an outdated version of openssl in the first place, but maybe there is another way to get this solved permanently?
error: Package ‘openssl-1.1.1u’ in /nix/store/0yzh1r9mhsr4vp5w96y3i0jgz3m2qzv6-source/pkgs/development/libraries/openssl/default.nix:210 is marked as insecure, refusing to evaluate.

Known issues:
- OpenSSL 1.1 is reaching its end of life on 2023/09/11 and cannot be supported through the NixOS 23.05 release cycle. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/

Notify maintainers
@dan4ik605743

Alright, I did a little digging since nothing appears to be happening here. I found this issue on the Linux Github Desktop Github - yeah this one: https://github.com/shiftkey/desktop/issues/809
It appears we are not the only people which had openssl issues. Arch Linux did too. If I am not mistaken, the issue behind all this in the fact that the current github-desktop app is based on Electron 22, which in turn is based on nodejs 16.17.1. Nodejs got openssl 3 support only in version 17 and onward.
Workaround might be to pass some special flags to nodejs when building from source as indicated in the issue above.
Problem is, our nix derivation is based on the *.deb release, and hence not built from source directly.

As of right now this appears to be working again, I will close this issue

it's not fixed yet. 22:54 IST Aug 21

As of right now this appears to be working again, I will close this issue
its not yet solved.

@guruswarupa
Is it possible you are not getting this from nixpkgs unstable?
Try running this flake with nix develop and see if you get github desktop:
{
  description = "Nix flake for GitHub Desktop";
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/master";

  outputs = { self, nixpkgs }:
    let
      pkgs = import nixpkgs {
        system = "x86_64-linux";
      };
    in
    {
      devShells.x86_64-linux.default = pkgs.mkShell {
        name = "GitHub Desktop";
        nativeBuildInputs = with pkgs; [
          bashInteractive
        ];
        buildInputs = with pkgs; [
          github-desktop
        ];
      };
    };
}


Could not find bundler

Hello!
We're using chruby and ruby install. Installing to /opt/rubies.
I have two versions of ruby installed on this system:
jenkins@Jenkins:~$ chruby
    ruby-1.9.3-p547
 * ruby-2.2.1

However, when I run 'bundle install' from a directory, I get the following:
jenkins@Jenkins:~/jobs/myapp-test/workspace$ ruby -v
ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-linux]

jenkins@Jenkins:~/jobs/myapp-test/workspace$ env | egrep -i 'gem|ruby'
GEM_HOME=/var/lib/jenkins/.gem/ruby/2.2.1
PATH=/var/lib/jenkins/.gem/ruby/2.2.1/bin:/opt/rubies/ruby-2.2.1/lib/ruby/gems/2.2.0/bin:/opt/rubies/ruby-2.2.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
RUBY_ENGINE=ruby
GEM_ROOT=/opt/rubies/ruby-2.2.1/lib/ruby/gems/2.2.0
GEM_PATH=/var/lib/jenkins/.gem/ruby/2.2.1:/opt/rubies/ruby-2.2.1/lib/ruby/gems/2.2.0
RUBY_ROOT=/opt/rubies/ruby-2.2.1
RUBYOPT=
RUBY_VERSION=2.2.1

jenkins@Jenkins:~/jobs/myapp-test/workspace$ bundle install
/usr/lib/ruby/1.9.1/rubygems/dependency.rb:247:in `to_specs': Could not find bundler (>= 0) amongst [] (Gem::LoadError)
	from /usr/lib/ruby/1.9.1/rubygems/dependency.rb:256:in `to_spec'
	from /usr/lib/ruby/1.9.1/rubygems.rb:1231:in `gem'
	from /usr/local/bin/bundle:22:in `<main>'

I've made sure to install rubies and gems like so:
ruby-install -i /opt/rubies/ruby-#{ruby_version} ruby #{ruby_version}
cd /opt/rubies/ruby-#{ruby_version}/bin/ && sudo ./gem install #{gem} -v '#{version}'

This always worked for us in the past, but not sure why we're having this issue on this new box.
Ubuntu 14.04 Server.
The jenkins user does not have a .gemrc file, there isnt an /etc/gemrc file.
I do have chruby.sh linked in /etc/profile.d though.
Any ideas?

Forgot to add this - definitely where some of the weirdness is coming from Im sure!
Even when I run chruby to a new version, when I run the bug report it seems the older stuff is there, even though the output of 'env' seems to disagree
jenkins@Jenkins:~$ ./chruby_bug_report.sh

## System

    Linux Jenkins 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
    GNU bash, version 4.3.8(1)-release (x86_64-pc-linux-gnu) [/bin/bash]
    tmux 1.8 [/usr/bin/tmux]
    ruby 1.9.3p547 (2014-05-14) [x86_64-linux] [/opt/rubies/ruby-1.9.3-p547/bin/ruby]
    Bundler version 1.9.2 [/opt/rubies/ruby-1.9.3-p547/bin/bundle]
    chruby version 0.3.8 [/usr/local/bin/chruby-exec]

## Environment

    CHRUBY_VERSION=0.3.8
    SHELL=/bin/bash
    PATH=/var/lib/jenkins/.gem/ruby/1.9.3/bin:/opt/rubies/ruby-1.9.3-p547/lib/ruby/gems/1.9.1/bin:/opt/rubies/ruby-1.9.3-p547/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
    HOME=/var/lib/jenkins
    RUBIES=(/opt/rubies/ruby-1.9.3-p547 /opt/rubies/ruby-2.2.1)
    RUBY_ROOT=/opt/rubies/ruby-1.9.3-p547
    RUBY_VERSION=1.9.3
    RUBY_ENGINE=ruby
    RUBY_AUTO_VERSION=
    RUBYLIB=
    RUBYOPT=
    RUBYPATH=
    RUBYSHELL=
    GEM_ROOT=/opt/rubies/ruby-1.9.3-p547/lib/ruby/gems/1.9.1
    GEM_HOME=/var/lib/jenkins/.gem/ruby/1.9.3
    GEM_PATH=/var/lib/jenkins/.gem/ruby/1.9.3:/opt/rubies/ruby-1.9.3-p547/lib/ruby/gems/1.9.1

## Hooks

    trap -- '' SIGTSTP
    trap -- '' SIGTTIN
    trap -- '' SIGTTOU

## Aliases

jenkins@Jenkins:~$ env
XDG_SESSION_ID=24
GEM_HOME=/var/lib/jenkins/.gem/ruby/2.2.1
SHELL=/bin/bash
TERM=xterm
OLDPWD=/var/lib/jenkins/jobs
USER=jenkins
MAIL=/var/mail/jenkins
PATH=/var/lib/jenkins/.gem/ruby/2.2.1/bin:/opt/rubies/ruby-2.2.1/lib/ruby/gems/2.2.0/bin:/opt/rubies/ruby-2.2.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
PWD=/var/lib/jenkins
LANG=en_US.UTF-8
RUBY_ENGINE=ruby
SHLVL=1
HOME=/var/lib/jenkins
GEM_ROOT=/opt/rubies/ruby-2.2.1/lib/ruby/gems/2.2.0
LOGNAME=jenkins
GEM_PATH=/var/lib/jenkins/.gem/ruby/2.2.1:/opt/rubies/ruby-2.2.1/lib/ruby/gems/2.2.0
RUBY_ROOT=/opt/rubies/ruby-2.2.1
XDG_RUNTIME_DIR=/run/user/1001
RUBYOPT=
RUBY_VERSION=2.2.1
_=/usr/bin/env

Did you make sure bundler was installed when using ruby-2.2.1? I'm also curious how ruby-1.9.3 is being loaded for the debug script?

I faced this issue today and I think I know the problem.
gem install bundler under ruby 1.9.3 installs bundler into ~/.gem/ruby/1.9.1/bin. Where as chruby adds  ~/.gem/ruby/1.9.3/bin to the PATH environment variable.
Also under ruby 1.9.3 ruby -e 'puts Gem.user_dir' prints ~/.gem/ruby/1.9.1. I don't know how chruby does this, but I think Gem.user_dir must be checked before adding into the PATH.

@nikhildamle could you post the output of gem env?

@jlove4m keep in mind that the bug_report.sh script runs in a sub-shell. It could be activating a .ruby-version or a chruby 1.9 in .bashrc could be overriding the current ruby.

@postmodern Here is the output
RubyGems Environment:
  - RUBYGEMS VERSION: <IP_ADDRESS>
  - RUBY VERSION: 1.9.3 (2014-11-13 patchlevel 551) [x86_64-darwin14.4.0]
  - INSTALLATION DIRECTORY: /Users/nikhil/.gem/ruby/1.9.3
  - RUBY EXECUTABLE: /Users/nikhil/.rubies/ruby-1.9.3-p551/bin/ruby
  - EXECUTABLE DIRECTORY: /Users/nikhil/.gem/ruby/1.9.3/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-darwin-14
  - GEM PATHS:
     - /Users/nikhil/.gem/ruby/1.9.3
     - /Users/nikhil/.rubies/ruby-1.9.3-p551/lib/ruby/gems/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - "gem" => "--user-install"
  - REMOTE SOURCES:
     - http://rubygems.org/

@nikhildamle ok so chruby is correctly setting GEM_HOME to .gem/ruby/1.9.3. What is the output of which bundle and head -n 1 $(which bundle)?

@postmodern which bundle prints bundle not found and head -n 1 "$(which bundle)" prints head: bundle not found: No such file or directory
Before chruby I had used system ruby (ruby 2.0.0) that came with the OS and had gem: --user-install set in my ~/.gemrc to install gems without sudo. Today, with ruby 2.2.2 I noticed gem install warning EXECUTABLE DIRECTORY not in the PATH environment variable. Removing --user-install from ~/.gemrc and running gem install again did not produce any warning and resolved this issue with both ruby-1.9.3 and ruby-2.2.2
I think what happening is with --user-install, ruby gem ignores GEM_HOME set by chruby and instead install gems in value returned by Gem.user_dir (Gem.user_dir returns ~/.gem/ruby/1.9.1 for ruby-1.9.3 and ~/.gem/ruby/2.2.0 for ruby-2.2.2 in my computer). But chruby only adds $GEM_HOME/bin to the PATH.

I have been using a substituted line for GEM_HOME in chruby.sh,
export GEM_HOME="$($RUBY_ROOT/bin/ruby -e 'puts Gem.user_dir')"

@nikhildamle yep, chruby uses different gem dirs per-ruby. Since the gem dirs are located in ~/.gem/, --user-install is redundant. Simply remove --user-install and gem install bundler.

@postmodern - Yes. Have removed --user-install. No issues since. 👍

Going to close this since it appears resolved now.


2018's Board Final Firmware Reviewed

This pull request was made to bring 2018's board firmware branch to the master branch as this is the most advanced revision of the software yet. This will be a good starting point for the still needed PID adjustments, and other features implementation.

This code somehow managed to brick the Arduino leonardo, still working to figure out what caused it and how to bring the USB function back to life.


Translating Vietnamese

I want to build unitime in Vietnamese, I am using POEdit to make translation,  export as *.po and save to unitime/Documentation/Translators, after that I re-build, paste into the tomcat, shutdown and startup again tomcat and it still not working with my translate version.
Notes: I already update  in ./JavaSource/org/unitime/timetable/gwt/UniTime.gwt.xml
So, are there anything wrong in my step?
*Update, when I try again in many different ways, I got some changes when using:
http://localhost:8080/UniTime/login.do?locale=vi
a few words are translated into Vietnamese

This is also my .po file in Vietnamese

You can make the UniTime build with the Vietnamese translations using
ant -Dlocale=vi import-translations build

This will

download the Vietnamese translations from poeditor.com and put them at Documentation/Translations/UniTime4.8_vi.po
import the translations; note that this add vi locale in JavaSource/org/unitime/timetable/gwt/UniTime.gwt.xml, but also create JavaSource/org/unitime/localization/messages/ConstantsMessages_vi.properties and JavaSource/org/unitime/localization/messages/CourseMessages_vi.properties (and perhaps some others, depending on what messages have been already translated)
make a unitime build; the resultant war file is at Distributions/UniTime.war

Since you have downloaded the UniTime4.8_vi.po and updated UniTime.gwt.xml manually, my guess is that you have missed the creation of the *_vi.properties files (UniTime does not use the .po files directly, but the properties, like
ConstantsMessages_cs.properties. This can also be done by calling ant -Dlocale=vi -Ddownload=false import-translations. The properties file would look like this; example from JavaSource/org/unitime/localization/messages/CourseMessages_vi.properties:
# Default: Instructor Assignment Preferences
actionEditClassInstructorAssignmentPreferences=Tu\u1EF3 ch\u1ECDn gi\u1EA3ng vi\u00EAn cho bu\u1ED5i h\u1ECDc

# Default: Edit Assignment Preferences
actionEditInstructorAssignmentPreferences=Thay \u0111\u1ED5i tu\u1EF3 ch\u1ECDn bu\u1ED5i h\u1ECDc

# Default: Instructor Assignment Preferences
actionEditSubpartInstructorAssignmentPreferences=Tu\u1EF3 ch\u1ECDn gi\u1EA3ng vi\u00EAn cho bu\u1ED5i h\u1ECDc

# Default: Do you want to remove any instructor preferences \nthat may have been applied to this class?
confirmRemoveInstructorPreferencesFromClass=B\u1EA1n c\u00F3 mu\u1ED1n lo\u1EA1i b\u1ECF t\u1EA5t c\u1EA3 gi\u1EA3ng vi\u00EAn cho l\u1EDBp n\u00E0y?

Also, please note that the Examination Periods preferences from the screenshot are using the GWT-Const:examPeriodDateFormat property that contains a pattern (defaults to EEE MM/dd) for that the SimpleDateFormat class to use and provide localized date and time pattern strings.
But for instance, you should be able to see the translated All Classes description when adding a new distribution constraint (Courses > Input Data > Distribution Preferences, when Add Distribution Preference is clicked and the Structure: All Classes selected)


Restructure

See #84.

[x] Restructure every exercise directory
[x] Update every project.clj
[x] Update _test/check_exercises.clj
[x] Update */test/*_test.clj
[x] Update pertinent documentation
[x] :shipit:

@exercism/track-maintainers, Can someone else look this over?
cc: @kytrinyx

Should we mention lein auto test via lein-auto?

I mean, this is a big change, but I'm confident it's good to go. :shipit:

This looks excellent! :tada:


when executing bin/rly testnets request ...,   error : gasUsed: 1000: out of gas\n #65

/> bin/rly testnets request chain_1 faucet -u http://<IP_ADDRESS>:8000 --home data/relayer
{"error":"transaction failed to execute\nResponse:\n TxHash: DD779702E8CC32B8547C13C7CC229D2A7E254D24E348F4A4CFAE244D9596512D\n Code: 11\n Raw Log: out of gas in location: ReadFlat; gasWanted: 0, gasUsed: 1000: out of gas\n GasUsed: 1000\n Codespace: sdk"}
why and how to resolve above question?
/> bin/gaiad version --long
name: gaia
server_name: gaiad
version: stargate-3
commit: 5f28583b510a86fac671e4590d0863d56989735d
build_tags: netgo,ledger
go: go version go1.15.2 linux/amd64
/>bin/rly version
version: ""
commit: ""
cosmos-sdk: v0.34.4-0.20200921130040-27db2cf89772
go: go1.15.2 linux/amd64
get relayer from https://github.com/ovrclk/relayer/releases/tag/stargate-3

Have fixed this issue in upstream. Need to increase the gas adjustment in the chain config if you continue to run into the issue.


Unreal: Publishing and Loading for UAssets

Brief description
Implementation for the publishing and loading for UAssets in Unreal.
Description
This PR implements the publishing and loading of UAssets in Unreal. At this moment, only a single UAssets can be published. Hence, it has been included a validator to check that the UAssets doesn't have any dependency before being published.

So, I have this simple obj imported, I've created uasset (strangely, the mesh asset didn't moved to the instance folder, I had to do it manually). From that point everything seems fine, except publish can't find the instance of UAsset:

Note
Tested in Unreal 5.1


oneOf does not work with multipart/form-data

Currently, using oneOf within multipart/form-data does not display any of the schemas defined within. Removing the oneOf and keeping one schema will display its form fields in the generator.
Below is a minimum reproducible example
{
  "openapi": "3.1.0",
  "paths": {
    "/example": {
      "post": {
        "requestBody": {
          "required": true,
          "content": {
            "multipart/form-data": {
              "schema": {
                "oneOf": [
                  {
                    "type": "object",
                    "properties": {
                      "prop1": {
                        "type": "string"
                      }
                    }
                  },
                  {
                    "type": "object",
                    "properties": {
                      "prop2": {
                        "type": "number"
                      }
                    }
                  }
                ]
              }
            }
          }
        }
      }
    }
  }
}

Seems like the spec supports it. Here's the part I don't get, how do your api clients know which payload is going to be returned. It seems like potentially a bad idea, right?

Do you mean in terms of an actual service trying to implement the openapi contract? Or do you mean clients implementing your library to display the payload of the oneOf schema definition?
If its the former, and if the response is consistent, it's not an issue; i.e. returning a string ID regardless of what is uploaded. If the response changes depending on the upload, then I believe you cannot use the above method and instead you must define each entire schema individually to contain both the upload and corresponding response.
If its the latter, I have seen other openapi explorers display radio buttons which let you toggle which schema within the oneOf you view at any time. They seem to use the description (when provided) of each nested schema.

The latter isn't a problem, there are ways in the library to handle this for other oneOf. I was curious about the former, but "it's consistent with the original request" makes sense. Although in that case (and in the one you've shared) would it make sense to use a compound type instead of oneOf or is this much more complicated with many different fields being different?

or is this much more complicated with many different fields being different?

Yes this is my case. The upload form fields vary wildly but the response is always limited to the same success and failure responses.

This has been fixed in the latest version, you can see the linked PR: #133


[BUG] Polygon fill does not clip to path

Description
Filling a polygon from a SKPath fills the entire canvas, not just the interior of the path. This only happens when you fill the line using MoveTo/LineTo.
Maybe it is because of the InverseWinding and IsConcave...
Code

public void FillPath(SKCanvas g, SKPath gp)
        {

            SKPoint[] points =  new SKPoint[]{
            new SKPoint(728.4489f,48.174187f),
            new SKPoint(618.8237f,168.18684f),
            new SKPoint(573.079f,375.3296f),
            new SKPoint(662.4753f,478.39078f),
            new SKPoint(842.29297f,508.02264f),
            new SKPoint(940.2133f,237.2352f),
            new SKPoint(728.4489f,48.174187f)
            };
            gp = new SKPath();

            for (int i = 0; i < points.Length - 1; i++)
            {
                gp.MoveTo(points[i]);
                gp.LineTo(points[i + 1]);
            }

            gp.FillType = SKPathFillType.InverseWinding;

            using (var p = new SKPaint() { Color = SKColors.Green, Style = SKPaintStyle.Fill })
            {
                g.DrawPath(gp, p);
            }
        }

Expected Behavior
Expect only the interior of the SKPath to be filled.
Actual Behavior
Drawing with Fill

Drawing only the stroke (ie, commenting out g.DrawPath(gp, p);

Basic Information

Version with issue:  SkiaSharp 2.88.3
Last known good version:  Unknown
IDE:  VS 17.4.1
Platform Target Frameworks: So far I am only able to test on Windows using Maui/Net7

Thanks, I was using moveTo/Line to to also draw the boundary (i.e., g.TrawPoint(SKPointMode.Lines, gp.Points, paint)). Changing this to DrawPath instead fixed the boundary not drawing to each point in the path.


URLs of support.microsoft.com Content Changed Without Warning.

Describe the bug
Seemingly overnight, some URLs within the support.microsoft.com domain have been changed, leading to content not being displayed and confusion about how to reconfigure the playlists. The original working assets, as well as the old working URL, now point to a page that says:
"Need assistance? Use the search box to tell us what you're looking for or browse for content on the Office help and training site."
When you try to re-configure the playlist with the new asset, duplicates appear and it's guesswork on which one should be selected.
To Reproduce
Create a custom playlist with the OneNote 'Take Notes' asset.
Expected behavior
The URLs should re-direct to the newly hosted pages or the content should've been published on the original URL.
Learning Pathways version number
To be confirmed once sys admin is available.
Additional context

Hey @dcashpeterson, we are working with our community managers to understand the scale and scope of the issue as we speak. Comms were sent out to our clients yesterday so I'll let you know of any replies as soon as I hear. The challenge we have is that all clients have a different mix of assets so it's not as quick to identify as I'd like!

Hey @dcashpeterson, we're seeing issues with all of the assets shown in this screenshot. Only Take Notes shows an alternative, and the rest didn't when we last checked.

@AaronKGumbs I was able to get a hold of this one and it looks like there are two issues.

There are two Take Notes, one that works and one that doesn't.
The other links in the manifest file are broken.

I will work with the content team to get this resolved and update you when we have deployed the update.

Update on this. We are still waiting on a content update. @peterjkrebs do you have an update on when this can be fixed?

@dcashpeterson Any news yet on when the issue will be resolved?
We are currently in a Microsoft 365 implementation and are using the Learning Pathway. In this process, we also noticed the error with the OneNote Quick Start pages (take notes, share and stay organized, set up your mobile apps).

@frkl1103 I am working on getting an update from the content team.

@dcashpeterson  Any news on that?

@frkl1103 The issue with the broken OneNote items has been resolved and is live. There are still two Take Notes assets but we will fix that in the next content release.

@jhwang-ms one more thing to add to the next content update. Remove the duplicate Take Notes entry.

@frkl1103 The issue with the broken OneNote items has been resolved and is live. There are still two Take Notes assets but we will fix that in the next content release.

@dcashpeterson It seems that the issue with the broken OneNote items has been resolved only in the Englisch version. We are using the German version and the OneNote Quick Start pages (take notes, share and stay organized, set up your mobile apps) are still broken.

Just wanted to check if this issue has been resolved, we are also experiencing this issue where only the OneNote Quick start is working and the other ones are all broken.

@CSViviandee no this issue has not been resolved with the other Learning Pathways languages. It is on our radar to resolve. @jhwang-ms

@AaronKGumbs and @CSViviandee  This has been a long time coming but I have rolled out a fix for the OneNote content issues. You will need to clear the cache in Learning Pathways to see the changes. This should be rolled out to all languages.
Please let me know if there are any issues and reference this issue.


⚠ Thumbnails API Endpoint has degraded performance

In 3d4f92e, Thumbnails API Endpoint (https://thumbnails.roblox.com/v1/assets?assetIds=82738847&format=Png&isCircular=false&size=30x30) experienced degraded performance:

HTTP code: 200
Response time: 4405 ms

Resolved: Thumbnails API Endpoint performance has improved in 4d424fd after 16 hours, 52 minutes.


main.js file has console.log statement

main.js file has console.log statement on line 54 that should be removed from production version of software. I can submit PR with this change if you would like.

Thanks for this information, it was removed in 0.6.2 version.


Introduce a default-for attribute

latest attribute seems not robust enough since it does not manage any notion of semantic versioning.
For example,  I am going to add metadata for ch.qos.logback:logback-classic 1.4.1 with the latest flag set to true. Once Logback 1.2.12 will be out and used by somebody, native compilation will be broken due to the default to the latest if we just have metadata for 1.2.11.
As discussed with @melix, we could introduce a default-for attribute with a regexp value used to match the version of the dependency. latest would translate to "default-for": ".*", and we could document and use regexp for matching the same major + major version, which would be the most common use case.

Related NBT PR is https://github.com/graalvm/native-build-tools/pull/432.


Error: Cannot set property 'select' of undefined

Hi I created with the pal c the full-stack-nextjs project. I have to say this is really nice, didn't expect that, thx for this.
But I get the error:
ApolloError: Cannot set property 'select' of undefined
at new ApolloError (.../node_modules/@apollo/client/errors/errors.cjs.js:31:28)
                                 .../node_modules/@apollo/client/core/core.cjs.js:1438:47)

This is happening when I use getStaticProps like:
export async function getStaticProps() {
  const apolloClient = initializeApollo();

  await apolloClient.query({
    query: PAGE,
  });

  return {
    props: {
      initialApolloState: apolloClient.cache.extract(),
    },
    revalidate: 1,
  };
}

to solve this problem I made this change in src/Api/client:
function createIsomorphLink() {
  const { HttpLink } = require('@apollo/client/link/http')
  return new HttpLink({
    uri: 'http://localhost:3000/api/graphql',
    credentials: 'same-origin',
  })
}

But now I don't use anymore the SchemaLink from "@apollo/client/link/schema"
I guess I'm doing something wrong in the getStaticProps()

Ok I have to use like:
const prisma = new PrismaClient();

export async function getStaticProps() {
  const data = await prisma.page.findMany();

  return {
    props: {
      data,
    },
    revalidate: 1,
  };
}

But now I dont have the query in my client cache. Somebody know I can save the query in the cache?

Still have the Error.  Please help me
import * as React from 'react';
import { Card, CardBody } from '@paljs/ui/Card';
import { Button } from '@paljs/ui/Button';
import { useRouter } from 'next/router';
import { initializeApollo } from '../Api/client';
import { gql, useQuery } from '@apollo/client';

const POSTS = gql`
  query findManyPost {
    findManyPost {
      id
    }
  }
`;

const Index = () => {
  const { data } = useQuery(POSTS);
 // query is working on the client
  console.log(data);
  ...
};

//If I use getStaticProps I get the error
export async function getStaticProps() {
  const apolloClient = initializeApollo();

  await apolloClient.query({
    query: POSTS,
  });

  return {
    props: {
      initialApolloState: apolloClient.cache.extract(),
    },
  };
}

export default Index;

This issue not in our generator please ask your question at https://stackoverflow.com/


RCFile storage for Protobufs

[ this is NOT ready for merge yet. but usable and works well. I will send a different pull request for merge ]
This patch add support for RCFile support for storing and loading protobufs. The existing loaders deserialize the entire protobuf irrespective of which fields are required. Columnar storage like RCFile can help with avoiding loading unnecessary columns as well as better compression.
Mainly includes following four classes :

RCFileProtobufInputFormat
RCFileProtobufOutputFormat
RCFileProtobufPigLoader
RCFileProtobufPigStorage

Unknown fields are preserved while storing and are read while loading (if required).
results with a large protobuf with 70+ simple fields (compared with LzoProtobufBlockPigStorage, lzo compression level 3, 3.7M records, Pig local mode) :

space savings : 30% with gzip, 15% with lzo
load speed up : takes less than half the time: 125% speed up (both gzip and lzo)

current TODO:
- Add tests
- Thrift support

this is closed and replaced by pull #144
I made the mistake of merging master and this request contains too many unrelated commits.


Version 2.0.4 has bad behavior with version 27 of jest-environment-jsdom

This week, I upgraded jest-environment-jsdom from 26.6.2 to 27.0.3 and I'm now seeing some issues that I believe are related to this package. If I run multiple test files at once, everything is fine, but if I run a single test file, then there's a crash in this package:
  ● Test suite failed to run

    evalmachine.<anonymous>:1
    AggregateError
    ^

    ReferenceError: AggregateError is not defined

      at evalmachine.<anonymous>:1:1
      at setupWindow (node_modules/jsdom/lib/jsdom/browser/Window.js:111:55)
      at new Window (node_modules/jsdom/lib/jsdom/browser/Window.js:223:3)
      at exports.createWindow (node_modules/jsdom/lib/jsdom/browser/Window.js:95:10)
      at new JSDOM (node_modules/jsdom/lib/api.js:36:20)
      at new JSDOMEnvironmentGlobal (node_modules/jest-environment-jsdom-global/environment.js:12:5)

I think issue #46 is related.

I ended up debugging this with some of the jsdom folks and we narrowed down the problem to polyfills. I added an explanation here: https://github.com/jsdom/jsdom/issues/3205#issuecomment-861902957


iframes vs. CSS-in-JS

This is a long-standing issue with components which are dynamically injecting styles into the page at the time when they're rendered (a.k.a CSS-in-JS). When using the HTML/React Specimen in with either the frame or responsive option, dynamic style injection is a problem because styles are always inserted outside of the dynamically created iframe and style updates are not reflected in the Specimens.
To make this problem worse, most styling libraries use different injection techniques from each other and also depending on if they're running in development or production mode.
In development, styles are usually injected by adding new <style> tags to the head or by updating the textContent of an existing <style> tag.
In production, most of the existing libraries use CSSStyleSheet.insertRule()
Current situation
At the moment, <style> and <link> tags from the main document are cloned into the iframe at the time it's mounted or updated. This is a pretty blunt approach but works fine if all styles are already there. Unfortunately, sometimes styles are injected after the iframe has rendered.
Possible approaches
Dealing with the problem of style tags being appended or their content being modified (i.e. development mode) is quite straightforward: use a MutationObserver to watch for changes of the main document's head, and clone styles if necessary.
Dealing with insertRule is another beast because there's no way to observe style changes made with it (at least not that I'm aware of)! The only way to detect this would be to register a callback with the styling library – an approach taken by react-popout-component. But I don't think any popular library supports that yet.
The only approach that comes to my mind that doesn't feel like a hack is to not use dynamically created iframes but actual iframes (which would also remedy #340). This would mean rendering each Specimen on a separate route and embed it in a regular iframe. But extracting Specimens at runtime would be quite complex at the moment. Even if that's possible, pages containing lots of regular iframes tend to load quite slow as each iframe creates its own request(s) (see https://statistikstadtzuerich.github.io/sszvis/#/beginners for example). One possibility to avoid the extraction complexity issue is to require the user to create separate "pages" for responsive Specimens.
So at the moment, I don't see a solution that would Just Work™ and am looking for input on this issue. Any help in finding a good solution is greatly appreciated! 🙏
P.S.: Why use iframes at all? Because it's the only way getting styles like position: fixed and viewport units vw/vh working.

Hi @herrstucki  Can we split this fix into two fixes? The first fix for running in dev mode and with versions that do not use the insertRule. And the second fix for when insertRule is used.

@herrstucki Could you please have a look and share your opinion on this PR. I would like to help to solve this issue.


beginner issue: Followed the steps in the “README.md“, but got different results and failed to connect to the context website

beginner issue
Hi,
I'm a begginner of the openworm，could i ask a fool question about the PyOpenWorm?

After installing the PyOpenWorm in ubuntu system, it shows install successfully. Then I followed the steps in the “README.md“, but got different results. The result of "aval.type.one()" is None. The result of code ”aval.connection.count('pre')“ is 0.
Failed to connect to the website “http://openworm.org/entities/bio#worm0-data”.

I don't know if there is a causal relationship between the two questions. If there's no causal relationship，I don't no why the result is wrong and how to fix it.
Please help me ,thank you!!
The  following is written in the document:
# Make the context
>>> from PyOpenWorm.context import Context
>>> ctx = Context(ident='http://openworm.org/entities/bio#worm0-data')

# Grabs the representation of the neuronal network
>>> from PyOpenWorm.worm import Worm
>>> net = ctx.stored(Worm)().neuron_network()

# Grab a specific neuron
>>> from PyOpenWorm.neuron import Neuron
>>> aval = ctx.stored(Neuron)(name='AVAL')

>>> aval.type.one()
'interneuron'

#show how many connections go out of AVAL
>>> aval.connection.count('pre')
86

The following is the result of mine：

>>> from PyOpenWorm.context import Context
>>> ctx = Context(ident='http://openworm.org/entities/bio#worm0-data')

>>> from PyOpenWorm.worm import Worm
>>> net = ctx.stored(Worm)().neuron_network()

>>> from PyOpenWorm.neuron import Neuron
>>> aval = ctx.stored(Neuron)(name='AVAL')

>>> aval.type.one()

>>> aval.connection.count('pre')
0

When I first time execute this command on the command line，There are some errors.
pow clone git@github.com:openworm/OpenWormData.git
Now I've fixed these errors.Then retry code I've posted in this issue.I got the same result  with README.md.
Thank you for your help!

Good news! Thanks again.


Illegal argument 'column' with latest version 1.25.1

After updating to version 1.25.1, I can't use preview anymore. This is the error that comes up:
Running the contributed command:'vscode.previewHtml' failed. Illegal argument 'column' - (optional) Column in which to preview.
It does work under version 1.24.1 so the change really happened in this new one.
OS: Arch Linux

It seems that this is issue related to the processing tab button, as manually issuing command
"LaTeX: Open Preview" over command palette works normally. Since this extension last updated years ago, I recommend setting command to a keyboard short cut and using it instead.

This might be related to a bigger problem though, which is that the previewHtml command is being deprecated. I'm trying to figure out how the webviews api could be swapped in, but I'm not entirely sure.


Gitter

It would be nice if there is an gitter chat for easy bug reporting and asking for help. Maybe you should make one. ;)

Well, closing this.


CB-10440: Fix target for cname records to allow external references

The FreeIPA management service API for adding cname DNS records did
not support external FQDNs for the target. This was fixed.
This was tested by looking up the DNS record in a local deployment of
cloudbreak.
See detailed description in the commit message.

@lacikaaa can you please also confirm that you agree with this change as it does change the behavior of the API?
We have not released since the original cname API was added so we don't really need to worry about backward compatibility outside of mow-dev and right now the only consumer is @hreeve-cloudera for registering the load balancers. We need external domain names for the load balancers.


Fixed #17002 -- M2M traversal through models using concrete inheritance

https://code.djangoproject.com/ticket/17002

Buildbot, add to whitelist.

To merge this as multiple commits (if you think that adds value), it was be nice to have the review fixes incorporated into the first three commits rather than as a separate commit. If you envisioned the commits to be squashed when merging, let me know. I don't have strong feeling either way.

I was developing under the assumption it would be squashed when merging. If you don't feel strongly it should be multiple commits, then I think it should be squashed.

merged in 98359109eb0ed68a5821476bcd797455723aaaba, thanks!

I noticed some check errors in the models:
m2m_through_regress.Event.people: (fields.E340) The field's intermediary table 'm2m_through_regress_individualcompetitor' clashes with the table name of 'm2m_through_regress.ProxiedIndividualCompetitor'.
m2m_through_regress.Event.special_people: (fields.E340) The field's intermediary table 'm2m_through_regress_individualcompetitor' clashes with the table name of 'm2m_through_regress.IndividualCompetitor'.
How should we resolve them?

Having a M2M which uses a proxy of an existing through models doesn't seem all that useful to me, but assuming we want it to work if anyone tries it looks like https://github.com/django/django/blob/98359109eb0ed68a5821476bcd797455723aaaba/django/db/models/fields/related.py#L1450 could be changed to if m2m_db_table in registered_tables and registered_tables[m2m_db_Table]._meta.concrete_model != self.remote_field.through._meta.concrete_model:.
Unfortunately I don't have enough time to spare at the moment to try it myself.

Thanks, I created https://github.com/django/django/pull/7753 with that suggestion.


PDF Font Recoginition

req = requests.get(pdf_url)
content_type = req.headers['Content-Type']
modified_date = req.headers['Last-Modified']
content_buffer = BytesIO(req.content)

if content_type == 'application/pdf':
    resource_manager = PDFResourceManager()
    fake_file_handle = StringIO()
    converter = TextConverter(resource_manager, fake_file_handle, codec='utf-8',
                              laparams=LAParams(boxes_flow=-1.0, all_texts=True))
    page_interpreter = PDFPageInterpreter(resource_manager, converter)
    for page in PDFPage.get_pages(content_buffer, caching=False):
        page_interpreter.process_page(page)
    text = fake_file_handle.getvalue()

CurrentBriefAgenda.pdf
When trying to convert this PDF, the output gives unrecognized font characters:
(cid:38)(cid:44)(cid:55)(cid:60)(cid:3)(cid:38)(cid:50)(cid:56)(cid:49)(cid:38)(cid:44)(cid:47)(cid:3)(cid:36)(cid:42)(cid:40)(cid:49)(cid:39)(cid:36)
(cid:54)(cid:51)(cid:40)(cid:38)(cid:44)(cid:36)(cid:47)(cid:3)(cid:48)(cid:40)(cid:40)(cid:55)(cid:44)(cid:49)(cid:42)(cid:3)(cid:3)
(cid:37)(cid:60)(cid:3)(cid:40)(cid:47)(cid:40)(cid:38)(cid:5

Hi @vitalibertas! Which characters do you expect instead? Is all of the output wrong, or just a part?
Having these (cid:*) in the output often happens when the unicode mapping for those characters are missing.

That whole first page of the attachment is all CID and unrecognized. I would expect the text of that page to show. I’m getting much better results with just OCR’ing the page images with tesseract, wand, and pyocr.

The unicode mapping appears to be missing. E.g. if you try to copy a line to a text editor, you notice that the pasted text is very different. This is a symptom of the same problem. With this pdf, pdfminer.six cannot do much more than outputting unrecognized characters.


Selection view content should be copy-pasteable

As much as possible of the content in the selection view should be copy-pasteable. That way any interesting data or blueprint options can easily be extracted and re-used elsewhere when debugging or exploring recordings in Rerun.
Example use cases:

Live logging the pose output of a SLAM algorithm, finding five poses that you think make sense for the scene and copying the parameter values to use in another script (that might generate simulated sensor data).
Once #4649 has landed, copy paste the recording id and quickly log some complementary data from a throw away script
Open a folder with images with the viewer -> find a strange looking image -> copy it's path and pass it to another script

Adding on to this, the TextLog fields should also be copy pasteable


Candidate window hides pre edit texts if it is near by Dock

What steps will reproduce the problem?

1. Place text field just above Dock (Dock should be placed at the bottom of the
screen.)
2. Convert Japanese on that text field.
3. The candidate window will hide pre edit texts (See the attachment.)

What is the expected output? What do you see instead?

The candidate window should not hide pre edit texts, should be placed on the
top of the text field in this case.

What version of the product are you using? On what operating system?

$ uname -rsv
Darwin 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011;
root:xnu-1504.9.37~1/RELEASE_I386

$ xcodebuild -version
Xcode 4.0.2
Build version 4A2002a

$ svn info|grep Revision
Revision: 55

Please provide any additional information below.

This issue might be caused by my previous patch to address the other issue.
http://code.google.com/p/mozc/issues/detail?id=74
Due to run the renderer as Cocoa app, it might be affected from Dock.

I've attached a patch to fix this issue, I guess you can't use or see this
patch though (How can I file a patch you can use, should I display the license
of the patch?)
Basically we can fix this issue by using [NSScreen visibleFrame] instead of
CGDisplayBounds() in GetNearestDisplayRect(); then convert the result NSRect
which is using left-bottom origin to the rect for top-left origin (the origin
is always based on the main display.)
To lookup and select the current NSScreen, use [NSScreen screens], get
deviceDescription then compare the value for @"NSScreenNumber" and displayID.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 5 May 2011 at 11:01
Attachments:

candidate_window_hides_preedit_texts.png
CandidateController.mm.patch

Original comment by<EMAIL_ADDRESS>on 1 Apr 2012 at 2:21

Added labels: OpSys-OSX


[Syntax Error] Unable to delete server due to DB

[2017-06-12 14:24:25] production.ERROR: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'IF EXISTS s105_O0dgpMm4Ud@%' at line 1 in /var/www/pterodactyl/html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:77

You need to update to MariaDB 10.1 as noted in the documentation.


<EMAIL_ADDRESS>Decompress Error

` scoop update qView
qView: 4.0 -> 5.0
Updating 1 outdated app:
Updating 'qView' (4.0 -> 5.0) [64bit]
Downloading new version
Loading qView-5.0-win64.zip from cache.
Checking hash of qView-5.0-win64.zip ... ok.
Uninstalling 'qView' (4.0)
WARN  Shim for 'qView' is missing. Skipping.
Removing shortcut ~\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Scoop Apps\qView.lnk
Installing 'qView' (5.0) [64bit] [extras]
WARN  By installing you accept following license: GPL-3.0-only (https://spdx.org/licenses/GPL-3.0-only.html)
Loading qView-5.0-win64.zip from cache.
Extracting qView-5.0-win64.zip ... ERROR Could not find 'qView in C:\Scoop\apps\qView\5.0'! (error 16)
Please try again or create a new issue by using the following link and paste your console output:
https://github.com/ScoopInstaller/Extras/issues/new?title=qView%405.0%3A+Decompress+Error&body=Could+not+find+'qView+in+C%3A\Scoop\apps\qView\5.0'!+(error+16)
ERROR This application failed to update: qView`

I also have an issue with this package, I'll try to see if I can fix it though
Installing 'qview' (5.0) [64bit]
Loading qView-5.0-win64.zip from cache
Checking hash of qView-5.0-win64.zip ... ok.
Extracting qView-5.0-win64.zip ... Exception: ~\scoop\apps\scoop\current\lib\core.ps1:516
Line |
 516 |          throw "Could not find '$(fname $from)'! (error $($proc.ExitCo …
     |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Could not find 'qView'! (error 16)

yep #7744 fixed it 👍


Errors when using current go.mod (and dependencies)

When simply importing module
import slog "github.com/go-eden/slf4go"
and using the following
slog.SetLevel(slog.InfoLevel)
slog.Debug("Don't see this")
slog.Info("DO see this")
Here are the errors
github.com/go-eden/etime
C:\Go_Projs\pkg\mod\github.com\go-eden\etime@v1.0.1\etime_now.go:19:11: cannot use tv.Sec (type int32) as type int64 in return argument
C:\Go_Projs\pkg\mod\github.com\go-eden\etime@v1.0.1\etime_now.go:33:20: invalid operation: tv.Sec * 1000 + int64(tv.Usec) / 1000 (mismatched types int32 and int64)
C:\Go_Projs\pkg\mod\github.com\go-eden\etime@v1.0.1\etime_now.go:47:20: invalid operation: tv.Sec * 1e+06 + int64(tv.Usec) (mismatched types int32 and int64)
github.com/huandu/go-tls
C:\Go_Projs\pkg\mod\github.com\huandu\go-tls@v0.0.0-20190320055402-ef90f27f86a2\syscall_unix.go:17:17: undefined: syscall.PROT_NONE
C:\Go_Projs\pkg\mod\github.com\huandu\go-tls@v0.0.0-20190320055402-ef90f27f86a2\syscall_unix.go:18:17: undefined: syscall.PROT_READ
C:\Go_Projs\pkg\mod\github.com\huandu\go-tls@v0.0.0-20190320055402-ef90f27f86a2\syscall_unix.go:19:17: undefined: syscall.PROT_WRITE
C:\Go_Projs\pkg\mod\github.com\huandu\go-tls@v0.0.0-20190320055402-ef90f27f86a2\syscall_unix.go:20:17: undefined: syscall.PROT_EXEC
C:\Go_Projs\pkg\mod\github.com\huandu\go-tls@v0.0.0-20190320055402-ef90f27f86a2\syscall_unix.go:30:32: not enough arguments in call to syscall.Syscall
C:\Go_Projs\pkg\mod\github.com\huandu\go-tls@v0.0.0-20190320055402-ef90f27f86a2\syscall_unix.go:30:33: undefined: syscall.SYS_MPROTECT

Got it, I will fix it before tomorrow.

@ms-clovis I have fix this issue in version v1.0.4.
slf4go don't use github.com/go-eden/etime and github.com/huandu/go-tls anymore, now it only requires github.com/go-eden/common, which is maintained by myself.
You could run go get -u -t ./... to update versions, after that the go.mod should like:
require (
    ......
    github.com/go-eden/slf4go v1.0.4
)

Thank you for your prompt attention. I am still getting the following (as part of common)
github.com/go-eden/common/etime
C:\Go_Projs\pkg\mod\github.com\go-eden\common@v0.1.3\etime\etime_now.go:23:20: invalid operation: tv.Sec * 1000 + int64(tv.Usec) / 1000 (mismatched types int32 and int64)
C:\Go_Projs\pkg\mod\github.com\go-eden\common@v0.1.3\etime\etime_now.go:32:20: invalid operation: tv.Sec * 1e+06 + int64(tv.Usec) (mismatched types int32 and int64)

These are the changes necessary in etime_now.go:
func NowMillisecond() int64 {
var tv syscall.Timeval
if err := syscall.Gettimeofday(&tv); err != nil {
return time.Now().UnixNano() / 1e6
}
return int64(tv.Sec*1e3) + int64(tv.Usec)/1e3
}
// NowMicrosecond obtains the current microsecond, use syscall for better performance
func NowMicrosecond() int64 {
var tv syscall.Timeval
if err := syscall.Gettimeofday(&tv); err != nil {
return time.Now().UnixNano() / 1e3
}
return int64(tv.Sec*1e6) + int64(tv.Usec)
}

OK... now I find the reason.
In linux and osx, the datatype of syscall.Timeval.Sec is int64, but in windows, it is int32, this is really unexpected...
I have commit it into the new release v1.0.5, you could try it.
Thank you for all.

Thank you for your time


Support Delta Lake in GCP Big data Ecosystem

Is there any plans to integrate Delta Lake in GCP Big Data Ecosystem?
Delta Lake is very famous for ACID Transactions, Time Travel, Good Metadata, Support Streaming ingest, Audit History
Requirements for storage system: https://github.com/delta-io/delta#requirements-for-underlying-storage-systems and https://docs.delta.io/latest/delta-storage.html#configuration-for-hdfs
Since Databricks is not on GCP yet and delta developers don't have GCS development experience and they don't know exact semantics that the GCP FileSystem implementation offers, there are no developments in delta's integration with GCP...

Right now, you can utilize the GCS connector to use Delta Lake on GCS. You just need to point the Delta Lake table location to use gs://.

separate LogStore to implement things like listFrom with GCS native ways

That will be helpful if you have resources do share them...

Delta Lake table location to use gs://
Yup, df.write.format("delta").save("gs://[BUCKET-NAME]/tmp/delta-table") works..

You can find out how to use Delta Lake with Dataproc in this blog post.


upgrade HTTP and Julia compat to latest versions

Ping. I'm wondering if it's worth it for me to integrate this package into my project. It looks very good and useful, but this kind of issue being open so long and no active development does make this package look abandoned.

This PR fixes #5 I believe.


Rlocus visual display of clicked point

Added a visual emphasis on the clicked point in the Root locus plot while displaying the real and imagionary coordinates of the clicked point and the gain and the damping in the plot title.

Coverage decreased (-0.1%) to 77.771% when pulling c65c100d5cc080e63b1b17305cb3a3532c1a61fa on icam0:rlocus_zoom into 601b58152080d89575cc677474ec7714e1a34ee2 on python-control:master.

Note: this PR has been included in PR #209.  If that PR is merged, can delete this one.


Why does order of the bindings matter?

For this template:

This binding produces the expected iterated list of news:
news: ['.news', {
  img: '.image',
  title: 'h3',
  excerpt: 'p'
}]

But when changing the order of the bindings to this:
news: ['.news', {
  title: 'h3',
  excerpt: 'p',
  img: '.image'
}]

I get this:

It seems weird that the binding would be so tightly coupled to the DOM structure.

This is most likely a bug, but I can explain why. Iterating over keys of JS objects is ordered by when the key was assigned, from first to last. When this order doesn't match the order in the DOM, the "marker" nodes get placed in the wrong places.
An obvious and easy workaround would be to order the keys by it's order in the DOM (which is what I'm doing currently), but you're right, this shouldn't be necessary. I will get around to fixing this.

Thanks for your fast response.
Simulacra is great btw. I'm eagerly waiting for the new version of Riot.

This has been fixed in https://github.com/daliwali/simulacra/commit/8ea82dcade60013ebbf7574e90bb30a409dfdc68
There is this example here: https://github.com/daliwali/simulacra/blob/master/test/demo.html


Missing License

Hi,
This looks great. Do you mind adding a license to it? Preferably the same license Kubernetes uses.
Thanks.

Thanks for the heads up, I've licensed this under the Apache 2.0 license (the same as Kubernetes). Enjoy!


not working on Windows Server 2019

Defect
Make sure that these boxes are checked before submitting your issue -- thank you!

[x] Included the relevant configuration snippet
[x] Included the relevant process-compose log (log location: process-compose info)
[x] Included a [Minimal, Complete, and Verifiable example] (https://stackoverflow.com/help/mcve)

Version of process-compose: v0.60.0
OS environment: Windows Server 2019 Datacenter
Steps or code to reproduce the issue: process-compose.exe version
Expected result:
Process Compose
Version:        v0.60.0
Commit:         79d0cbd
Date (UTC):     2023-07-21T21:40:41Z
License:        Apache-2.0

Written by Eugene Berger

Actual result:
panic: open C:\Users\ADMINI~1\AppData\Local\Temp\2\process-compose-WIN-2B62Q54U8RC\Administrator.log: The system cannot find the path specified.

goroutine 1 [running]:
github.com/f1bonacc1/process-compose/src/cmd.Execute()
        /home/eugene/projects/go/process-compose/src/cmd/root.go:54 +0x111
main.main()
        /home/eugene/projects/go/process-compose/src/main.go:9 +0x17

Full command
C:\Users\Administrator\Downloads>process-compose.exe version
panic: open C:\Users\ADMINI~1\AppData\Local\Temp\2\process-compose-WIN-2B62Q54U8RC\Administrator.log: The system cannot find the path specified.

goroutine 1 [running]:
github.com/f1bonacc1/process-compose/src/cmd.Execute()
        /home/eugene/projects/go/process-compose/src/cmd/root.go:54 +0x111
main.main()
        /home/eugene/projects/go/process-compose/src/main.go:9 +0x17

When I manually create the C:\Users\ADMINI~1\AppData\Local\Temp\2\process-compose-WIN-2B62Q54U8RC directory, it works.
I think there's a problem creating the directory!

BTW, thank you for this beautiful app. It is exactly what I looking for! 😆

Hi @outstanding1301,
Thank you for letting me know!
This should be an easy fix and will be delivered in the next version.
Glad you like the app! I'm glad to see that all the efforts to keep the cross-platform compatibility weren't wasted :)

Fixed in v0.65.1


Fails to download artifacts due to cannot find artifacttool

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az artifacts universal download Extension Name: azure-devops. Version: 0.12.0.
Errors:
[Errno 2] No such file or directory: '/home/azureuser/.azure/azuredevops/cli/tools/artifacttool/ArtifactTool_linux-x64_0.2.104/artifacttool': '/home/azureuser/.azure/azuredevops/cli/tools/artifacttool/ArtifactTool_linux-x64_0.2.104/artifacttool'
Traceback (most recent call last):
python3.6/site-packages/knack/cli.py, ln 206, in invoke
    cmd_result = self.invocation.execute(args)
cli/core/commands/__init__.py, ln 603, in execute
    raise ex
...
FileNotFoundError: [Errno 2] No such file or directory: '/home/azureuser/.azure/azuredevops/cli/tools/artifacttool/ArtifactTool_linux-x64_0.2.104/artifacttool': '/home/azureuser/.azure/azuredevops/cli/tools/artifacttool/ArtifactTool_linux-x64_0.2.104/artifacttool'

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az artifacts universal download --organization {} --feed {} --name {} --version {} --path {}

Expected Behavior
Environment Summary
Linux-4.15.0-1055-azure-x86_64-with-debian-stretch-sid
Python 3.6.5
Shell: bash

azure-cli 2.0.72

Extensions:
azure-devops 0.12.0

Additional Context

It's been a while since we've heard anything here, going to close this one. Would love to hear if any of the above helped, or if you're still having issues. Cheers!

I'm hitting the same issue in an Azure DevOps pipeline that I'm upgrading to use the azure cli to download artifacts.  The issue occurs randomly.  About 2 out of 5 runs fail.  I ran with --debug but the output is very long so here are some interesting snippets...
2022-11-16T20:25:47.9230024Z         az pipelines runs artifact download --artifact-name libftd2xx --path /home/cloudtest/AzureSphereCache/Artifacts/556/libftd2xx --run-id 556 --debug
...
2022-11-16T20:25:47.9294244Z         DEBUG: azext_devops.devops_sdk.client: GET<EMAIL_ADDRESS>...
2022-11-16T20:25:47.9303175Z         DEBUG: cli.azext_devops.dev.common.artifacttool_updater: Checking for ArtifactTool updates
...
2022-11-16T20:25:47.9303666Z         DEBUG: cli.azext_devops.dev.common.services: PAT is present which can be used against this instance
...
2022-11-16T20:25:48.1093643Z         DEBUG: cli.azext_devops.dev.common.artifacttool_updater: Downloading ArtifactTool from https://0t3vsblobprodcus362.vsblob.vsassets.io/artifacttool/artifacttool-linux-x64-Release_0.2.254.zip?sv=2019-07-07&sr=b&sig=z4QhaYspaJTij0bQnndrabZEUpggpNAi7n0HCqXKz2c%3D&spr=https&se=2022-11-16T21%3A25%3A35Z&sp=r&P1=1668633635&P2=11&P3=2&P4=ac0olmgIITJBw4FGv0kLeK27MVi8XrBPuKMGu0VBCXM%3D
...
2022-11-16T20:25:48.1098164Z         DEBUG: cli.azext_devops.dev.common.artifacttool_updater: Extracting ArtifactTool to /home/cloudtest/.azure/azuredevops/cli/tools/artifacttool/eaa84eac-209d-4c51-90e1-944de7dbb961
...
2022-11-16T20:25:48.1099417Z         DEBUG: cli.azext_devops.dev.common.artifacttool_updater: Moving downloaded ArtifactTool from /home/cloudtest/.azure/azuredevops/cli/tools/artifacttool/322e1528-6472-4281-9199-4cd92101f493 to /home/cloudtest/.azure/azuredevops/cli/tools/artifacttool/ArtifactTool_linux-x64_0.2.254
...
2022-11-16T20:25:48.1136190Z         DEBUG: cli.azure.cli.core.util: azure.cli.core.util.handle_exception is called with an exception:
2022-11-16T20:25:48.1136654Z         DEBUG: cli.azure.cli.core.util: Traceback (most recent call last):
2022-11-16T20:25:48.1137215Z           File "/opt/az/lib/python3.10/site-packages/knack/cli.py", line 233, in invoke
2022-11-16T20:25:48.1137602Z             cmd_result = self.invocation.execute(args)
2022-11-16T20:25:48.1138195Z           File "/opt/az/lib/python3.10/site-packages/azure/cli/core/commands/init.py", line 663, in execute
2022-11-16T20:25:48.1138561Z             raise ex
2022-11-16T20:25:48.1139106Z           File "/opt/az/lib/python3.10/site-packages/azure/cli/core/commands/init.py", line 726, in _run_jobs_serially
2022-11-16T20:25:48.1139570Z             results.append(self._run_job(expanded_arg, cmd_copy))
2022-11-16T20:25:48.1140184Z           File "/opt/az/lib/python3.10/site-packages/azure/cli/core/commands/init.py", line 718, in _run_job
2022-11-16T20:25:48.1140596Z             return cmd_copy.exception_handler(ex)
2022-11-16T20:25:48.1141258Z           File "/opt/az/azcliextensions/azure-devops/azext_devops/dev/common/exception_handler.py", line 31, in azure_devops_exception_handler
2022-11-16T20:25:48.1141706Z             reraise(*sys.exc_info())
2022-11-16T20:25:48.1142192Z           File "/opt/az/lib/python3.10/site-packages/six.py", line 703, in reraise
2022-11-16T20:25:48.1142519Z             raise value
2022-11-16T20:25:48.1143060Z           File "/opt/az/lib/python3.10/site-packages/azure/cli/core/commands/init.py", line 697, in _run_job
2022-11-16T20:25:48.1143455Z             result = cmd_copy(params)
2022-11-16T20:25:48.1144008Z           File "/opt/az/lib/python3.10/site-packages/azure/cli/core/commands/init.py", line 333, in call
2022-11-16T20:25:48.1144421Z             return self.handler(*args, **kwargs)
2022-11-16T20:25:48.1145019Z           File "/opt/az/lib/python3.10/site-packages/azure/cli/core/commands/command_operation.py", line 121, in handler
2022-11-16T20:25:48.1145491Z             return op(**command_args)
2022-11-16T20:25:48.1146111Z           File "/opt/az/azcliextensions/azure-devops/azext_devops/dev/pipelines/runs_artifacts.py", line 27, in run_artifact_download
2022-11-16T20:25:48.1146585Z             return artifact_tool.download_pipeline_artifact(
2022-11-16T20:25:48.1147229Z           File "/opt/az/azcliextensions/azure-devops/azext_devops/dev/common/artifacttool.py", line 25, in download_pipeline_artifact
2022-11-16T20:25:48.1147726Z             return self.run_artifacttool(organization, args, "Downloading")
2022-11-16T20:25:48.1148377Z           File "/opt/az/azcliextensions/azure-devops/azext_devops/dev/common/artifacttool.py", line 67, in run_artifacttool
2022-11-16T20:25:48.1148897Z             proc = self._tool_invoker.run(command_args, new_env, initial_progress_message, _process_stderr)
2022-11-16T20:25:48.1149573Z           File "/opt/az/azcliextensions/azure-devops/azext_devops/dev/common/external_tool.py", line 74, in run
2022-11-16T20:25:48.1150052Z             self.start(command_args, env)
2022-11-16T20:25:48.1150632Z           File "/opt/az/azcliextensions/azure-devops/azext_devops/dev/common/external_tool.py", line 33, in start
2022-11-16T20:25:48.1151026Z             self._proc = subprocess.Popen(
2022-11-16T20:25:48.1151375Z           File "/opt/az/lib/python3.10/subprocess.py", line 969, in init
2022-11-16T20:25:48.1151773Z             self._execute_child(args, executable, preexec_fn, close_fds,
2022-11-16T20:25:48.1152167Z           File "/opt/az/lib/python3.10/subprocess.py", line 1845, in _execute_child
2022-11-16T20:25:48.1152576Z             raise child_exception_type(errno_num, err_msg, err_filename)
2022-11-16T20:25:48.1153333Z         FileNotFoundError: [Errno 2] No such file or directory: '/home/cloudtest/.azure/azuredevops/cli/tools/artifacttool/ArtifactTool_linux-x64_0.2.254/artifacttool'
From the logs it appears that artifacttool is being downloaded successfully but then is missing when it tries to actually execute it.

I also have this problem. I have az CLI configured to automatically download extensions
az config set extension.use_dynamic_install=yes_without_prompt
When running "az artifacts universal download ..." I get the same error as mentioned above:
FileNotFoundError: [Errno 2] No such file or directory: '/home/AzDevOps/.azure/azuredevops/cli/tools/artifacttool/ArtifactTool_linux-x64_0.2.254/artifacttool'
I noticed that there is no 'artifacttool' in the path
~/.azure/azuredevops/cli/tools/artifacttool/ArtifactTool_linux-x64_0.2.254
However, there is an artifacttool executable in
~/.azure/azuredevops/cli/tools/artifacttool/954aecc3-1f91-4b3a-b3b6-e78c5709d9fd
The command "az extension list" returns the following
[   {     "experimental": false,     "extensionType": "whl",     "name": "azure-devops",     "path": "/home/AzDevOps/.azure/cliextensions/azure-devops",     "preview": false,     "version": "0.25.0"   } ]
Seems like the artifacttool has been installed in another directory which is not part of the search path of the az CLI