Can't ssh into remote folder in 1.79.0

Type: Bug
In Short:
Inability to Open Remote Folder as Workspace in VS Code 1.79.0
Description:
When using WireGuard to tunnel traffic to a company server with IP address <IP_ADDRESS> and SSH-ing into it via a non-standard SSH port (e.g., 11100), there is an issue with opening a remote folder as a workspace in VS Code version 1.79.0.
Steps to Reproduce:
Set up WireGuard to tunnel traffic to a server with IP address <IP_ADDRESS>.
SSH into the server using a non-standard SSH port (e.g., 11100).
Open the remote server in VS Code 1.79.0.
Attempt to open a remote folder as a workspace.
Actual Results:
The remote server is accessible, but it is not possible to open a remote folder as a workspace.
Expected Results:
The remote server and its folders should be accessible and openable as a workspace seamlessly, as it was in VS Code version 1.78.2 and earlier.
Additional Information:
Reverting to VS Code version 1.78.2 resolves the issue, but this version requires the Python extension to be reloaded which fails.
The issue is reproducible on another Windows 11 computer.
The issue persists even when using the standard SSH port (22).
The issue is not exclusive to WireGuard-tunneled connections and is also observed when SSH-ing into a non-tunneled machine using port 22.
VS Code version: Code 1.79.0 (b380da4ef1ee00e224a15c1d4d9793e27c2b6302, 2023-06-07T14:26:35.552Z)
OS version: Windows_NT x64 10.0.22631
Modes:
Connection to 'SSH: jiayin_get_data' could not be established  Connecting with SSH timed out

System Info

Item
Value

CPUs
13th Gen Intel(R) Core(TM) i9-13900H (20 x 2995)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
63.64GB (51.07GB free)

Process Argv
--crash-reporter-id 46ddd735-fd2e-4f06-8448-eff117d0696a --crash-reporter-id 46ddd735-fd2e-4f06-8448-eff117d0696a

Screen Reader
no

VM
0%

Connection to 'SSH: jiayin_get_data' could not be established  Connecting with SSH timed out
Extensions: none
A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30410667
cppdebug:30492333
vsclangdf:30486550
c4g48928:30535728
dsvsc012:30540252
pynewext54:30695312
azure-dev_surveyone:30548225
282f8724:30602487
pyind779:30671433
89544117:30613380
pythonsymbol12:30671437
showlangstatbar:30737416
vsctsb:30748421
pythonms35:30701012
03d35959:30757346
pythonfmttext:30731395
pythoncmv:30756943
fixhidewlkth:30730051
hidesbindicator:30760978
pythongtdpathcf:30739705
dh2dc718:30763024
pythonnosm12tcf:30765602

Well, I double checked the ssh command which timed out.
The ssh command is C:\Windows\System32\OpenSSH\ssh.exe -T -D 60492 -F C:\Users\11633\Nextcloud\Mine\.ssh\config jiayin_get_data bash and the port is changing every time I try this, let's just assume it's 60492
When I open the remote server, the 60492 is listening.
PS C:\Users\11633> netstat -aon | findstr :60492
  TCP    <IP_ADDRESS>:60492        <IP_ADDRESS>:0              LISTENING       3396
  TCP    <IP_ADDRESS>:60492        <IP_ADDRESS>:0              LISTENING       4248
  TCP    [::1]:60492            [::]:0                 LISTENING       3396
  TCP    [::1]:60492            [::]:0                 LISTENING       4248

When I open any folder as workspace in the remote server, the port will change, say it's 50699 this time.
But it can never be opened and will show me Connection to 'SSH: jiayin_get_data' could not be established Connecting with SSH timed out
And PS C:\Users\11633> netstat -aon | findstr :50699 No program is listening on this port.
But when I try this command C:\Windows\System32\OpenSSH\ssh.exe -T -D 50699 -F C:\Users\11633\Nextcloud\Mine\.ssh\config jiayin_get_data bash in C:\Windows\System32\cmd.exe as is suggested in
[16:00:20.787] Running script with connection command: "C:\Windows\System32\OpenSSH\ssh.exe" -T -D 50699 -F "C:\Users\11633\Nextcloud\Mine\.ssh\config" "jiayin_get_data" bash
[16:00:20.789] Terminal shell path: C:\Windows\System32\cmd.exe
[16:00:37.807] Resolver error: Error: Connecting with SSH timed out
	at f.Timeout (c:\Users\11633\.vscode\extensions\ms-vscode-remote.remote-ssh-0.103.2023060715\out\extension.js:1:585545)
	at Timeout._onTimeout (c:\Users\11633\.vscode\extensions\ms-vscode-remote.remote-ssh-0.103.2023060715\out\extension.js:1:682706)
	at listOnTimeout (node:internal/timers:559:17)
	at process.processTimers (node:internal/timers:502:7)

The port 50699 is being listened.
PS C:\Users\11633> netstat -aon | findstr :50699
  TCP    <IP_ADDRESS>:50699        <IP_ADDRESS>:0              LISTENING       20592
  TCP    [::1]:50699            [::]:0                 LISTENING       20592

I'm sure there is something wrong in the remote ssh plugin.

Do you use the secondary sidebar? Open the remote, close the secondary sidebar (View -> Appearance -> Secondary Sidebar (CTRL+ALT+B))
I also had problems with the SSH remote with the latest version (again).
And I remembered the last time it happened it was some kind of bug with the secondary sidebar being opened.
I guess its a regression

Do you use the secondary sidebar? Open the remote, close the secondary sidebar (View -> Appearance -> Secondary Sidebar (CTRL+ALT+B))
I also had problems with the SSH remote with the latest version (again).
And I remembered the last time it happened it was some kind of bug with the secondary sidebar being opened.
I guess its a regression

Exactly! I'm currently using Explorer (CRTL+SHIFT+E) in the right secondary sidebar. And the left side is the many many plugins.
After I closed the Explorer (CRTL+SHIFT+E) in the right secondary sidebar, the problem disappeared. I can open folder in the remote as workspace.
Then I call Explorer to appear, all works well.
Thank you webtroter

Discussing this in https://github.com/microsoft/vscode-remote-release/issues/8586- need help investigating if you can share more details


Update sbt-scalafmt to 2.0.7

Updates org.scalameta:sbt-scalafmt from 2.0.6 to 2.0.7.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "sbt-scalafmt" } ]

labels: semver-patch

Codecov Report

Merging #1294 into master will increase coverage by 0.19%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1294      +/-   ##
==========================================
+ Coverage   85.91%   86.11%   +0.19%
==========================================
  Files          74       74
  Lines        2535     2535
  Branches      108      108
==========================================
+ Hits         2178     2183       +5
+ Misses        357      352       -5

Impacted Files
Coverage Δ

...re/shared/src/main/scala/io/circe/KeyDecoder.scala
94.59% <0%> (-2.71%)
:arrow_down:

...rc/main/scala/io/circe/numbers/BiggerDecimal.scala
85.96% <0%> (+0.58%)
:arrow_up:

...re/shared/src/main/scala/io/circe/JsonNumber.scala
93.97% <0%> (+1.2%)
:arrow_up:

...les/core/shared/src/main/scala/io/circe/Json.scala
78.78% <0%> (+1.21%)
:arrow_up:

...rc/main/scala/io/circe/shapes/SizedInstances.scala
92.85% <0%> (+14.28%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c76326b...a76dcfc. Read the comment docs.


In the squiggle compile cli, sometimes multiple compiles are needed.

In the squiggle compile cli, sometimes multiple compiles are needed. This is because sometimes A imports B, which imports C. In the first compile, A imports (B with C_old), and B imports the new C. In the second compile, A imports (B with the new C), and B imports C anew.
The solution to this could be to either:

Just keep this in mind, and suggest not to have too many recursive compiles
Keep track of the maximum number of layers of recursion, and recompile as many times as needed to overcome those. Maybe have a flag for this.

@berekuk I remember you saying that you tackled multiple-level dependencies. Maybe something broke? It's also possible there was some miscommunication here; this seems like it would be a fairly tricky feature to me.

We should eventually really be able to handle multiple levels of dependencies, as long as there aren't loops.

I did handle multiple-level dependencies, but they work correctly only if you import .squiggleU files, not generated .squiggle files.
If you import intermediate files, execution order is not guaranteed, since the current implementation doesn't try to build and merge the dependency trees for each .squiggleU file. It just makes a single recursive pass for each entrypoint.
(Btw, this is O(N^2) in complexity, but shouldn't matter much)
Also, I just realized that the watch mode is pretty broken. If there's an A -> B dependency and you change B, A doesn't recompile.

Both of these are not hard to fix (and pretty fun; finally, a practical task where my graph algorithm skills would be useful!), but I'm not sure if we should put much effort into improving CLI, since squiggleU system is still temporary?

got it, thanks!
do you have a recommendation on whether it's better to import the .squiggleU or .squiggle files in general? in terms of performance in particular

Always .squiggleU, for now. I don't expect you to have enough code to hit the performance issues ever.

Example simple algorithm to keep track of this: Compile, then hash all the files. Compile again, hash again. Repeat until the hashes coincide.

I'll close this. I remember at at time someone said to me that there were still issues even when importing .squiggleU, but I've never seen an example and don't see how that could be possible.
Also, we're going to get real imports soon.


Path cannot be moved with the gesture when using fillType property

Description
path.offset donnt work when using fillType property. Is there any other solution?
Version
0.1.190
Steps to reproduce
my version is:
    "react": "18.0.0",
    "react-native": "0.67.5",
    "@shopify/react-native-skia": "0.1.190",

Snack, code example, screenshot, or link to a repository

import React, { useRef } from 'react';
import {
  Canvas,
  useTouchHandler,
  Path,
  Skia,
} from '@shopify/react-native-skia';

const star = () => {
  const R = 115.2;
  const C = 128.0;
  const path = Skia.Path.Make();
  path.moveTo(C + R, C);
  for (let i = 1; i < 8; ++i) {
    const a = 2.6927937 * i;
    path.lineTo(C + R * Math.cos(a), C + R * Math.sin(a));
  }
  return path;
};

const path = star();
const Demo = () => {
  const position = useRef({ x: 0, y: 0 }).current;

  const touchHandler = useTouchHandler({
    onStart: ({ x, y }) => {
      position.x = x;
      position.y = y;
    },
    onActive: ({ x, y }) => {
      const offsetX = x - position.x;
      const offsetY = y - position.y;
      path.offset(offsetX, offsetY);
      position.x = x;
      position.y = y;
    },
  });

  return (
    <Canvas style={{ flex: 1 }} onTouch={touchHandler}>
      <Path path={path} color="lightblue" fillType="evenOdd" />
    </Canvas>
  );
};

export default Demo;

The issue is that the path identity remained unchanged so Skia doesn't know the path has changed. I'm closing this issue as it doesn't appear to be a bug there. This documentation may help: https://shopify.github.io/react-native-skia/docs/animations/reanimated
Please reopen it if you feel like there is a bug there.

I had similar issue. My path wasn't animated with fillType="evenOdd". When removed it, all worked well. I'm on latest version (1.0.4).
I tested this also with code example from https://shopify.github.io/react-native-skia/docs/animations/hooks#usepathvalue


GH-264: consistent IDE configuration via .editorconfig

Thanks a lot for your PR!
Right now, I'm not aware of any contributors that would be using the editorconfig. I would like to prevent adding a configuration file to the repository that needs to be maintained without a clear need at the moment.
In consequence, I will close this PR - but if there is a a concrete demand from multiple users, I will gladly revisit this PR.


Compilation error in linalg-tensors matmul test

Manifested in one build run on Windows only - may be an indicator of non-determinism.
2021-01-07T00:04:00.7571560Z [3108/3308] Generating check_llvm-ir_llvm_matmul.mlir_module.module
2021-01-07T00:04:00.7572709Z FAILED: iree/test/e2e/linalg_tensor_ops/check_llvm-ir_llvm_matmul.mlir_module.module
2021-01-07T00:04:00.7576590Z cmd.exe /C "cd /D D:\a\iree\iree\iree-build\iree\test\e2e\linalg_tensor_ops && D:\a\iree\iree\iree-build\iree\tools\iree-translate.exe -iree-mlir-to-vm-bytecode-module --iree-hal-target-backends=dylib-llvm-aot -iree-flow-dispatch-linalg-on-tensors -iree-flow-dispatch-linalg-on-tensors-tile-sizes=1,1 -iree-codegen-llvm-experimental-linalg-on-tensors D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir -o check_llvm-ir_llvm_matmul.mlir_module.module"
2021-01-07T00:04:00.7581181Z D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
2021-01-07T00:04:00.7582575Z   %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
2021-01-07T00:04:00.7583142Z        ^
2021-01-07T00:04:00.7584389Z D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %2 = flow.dispatch.input.load %arg0, offsets = [%arg4, %c0], sizes = [%1, %c3], strides = [%c1, %c1] : !flow.dispatch.input<2x3xf32> -> tensor<?x3xf32>
2021-01-07T00:04:00.7586492Z D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
2021-01-07T00:04:00.7587868Z   %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
2021-01-07T00:04:00.7588433Z        ^
2021-01-07T00:04:00.7589721Z D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %8 = flow.dispatch.input.load %arg1, offsets = [%c0, %arg5], sizes = [%c3, %7], strides = [%c1, %c1] : !flow.dispatch.input<3x4xf32> -> tensor<3x?xf32>
2021-01-07T00:04:00.7591789Z D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
2021-01-07T00:04:00.7593696Z   %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
2021-01-07T00:04:00.7594273Z        ^
2021-01-07T00:04:00.7595533Z D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %13 = flow.dispatch.input.load %arg2, offsets = [%arg4, %arg5], sizes = [%1, %7], strides = [%c1, %c1] : !flow.dispatch.input<2x4xf32> -> tensor<?x?xf32>
2021-01-07T00:04:00.7597580Z D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'linalg.matmul'?): falling back to runtime resolution
2021-01-07T00:04:00.7598817Z   %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
2021-01-07T00:04:00.7599372Z        ^
2021-01-07T00:04:00.7600553Z D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %19 = linalg.matmul {__internal_linalg_transform__ = "workgroup"} ins(%6, %12 : tensor<?x3xf32>, tensor<3x?xf32>) outs(%18 : tensor<?x?xf32>) -> tensor<?x?xf32>
2021-01-07T00:04:00.7602064Z PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
2021-01-07T00:04:00.7602867Z Stack dump:
2021-01-07T00:04:00.7606318Z 0.	Program arguments: D:\\a\\iree\\iree\\iree-build\\iree\\tools\\iree-translate.exe -iree-mlir-to-vm-bytecode-module --iree-hal-target-backends=dylib-llvm-aot -iree-flow-dispatch-linalg-on-tensors -iree-flow-dispatch-linalg-on-tensors-tile-sizes=1,1 -iree-codegen-llvm-experimental-linalg-on-tensors D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir -o check_llvm-ir_llvm_matmul.mlir_module.module
2021-01-07T00:04:00.7609873Z 1.	2.	In-Flight Diagnostics:
2021-01-07T00:04:00.7611020Z     loc("D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir":8:8): error: expected dispatch function to have a single call operation
2021-01-07T00:04:00.7612411Z     loc("D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir":8:8): error: expected dispatch function to have a single call operation
2021-01-07T00:04:00.7614153Z     loc("D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir":8:8): remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
2021-01-07T00:04:00.7616289Z     loc("D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir":8:8): remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
2021-01-07T00:04:00.7618322Z     loc("D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir":8:8): remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
2021-01-07T00:04:00.7620279Z     loc("D:/a/iree/iree/main_checkout/iree/test/e2e/linalg_tensor_ops/matmul.mlir":8:8): remark: unable to materialize shape calculation (unsupported op 'linalg.matmul'?): falling back to runtime resolution

I think this is due to the recent PR for linalg on tensors. Will take a look (have to spin up my windows build again) in a bit.

I think this is due to the recent PR for linalg on tensors. Will take a look (have to spin up my windows build again) in a bit.

It passed on the next run, so probably more of just non determinism vs
platform
On Wed, Jan 6, 2021, 4:23 PM MaheshRavishankar<EMAIL_ADDRESS>wrote:

I think this is due to the recent PR for linalg on tensors. Will take a
look (have to spin up my windows build again) in a bit.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/google/iree/issues/4409#issuecomment-755793354, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AADYVABFB7UCPUQFBWJJFV3SYT5ITANCNFSM4VYHSK6Q
.

It passed on the next run, so probably more of just non determinism vs
platform
On Wed, Jan 6, 2021, 4:23 PM MaheshRavishankar<EMAIL_ADDRESS>wrote:

I think this is due to the recent PR for linalg on tensors. Will take a
look (have to spin up my windows build again) in a bit.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/google/iree/issues/4409#issuecomment-755793354, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AADYVABFB7UCPUQFBWJJFV3SYT5ITANCNFSM4VYHSK6Q
.

First place I look with things like this is use of unordered maps - the msft STL differs from libc++ and often exposes issues related to them.

First place I look with things like this is use of unordered maps - the msft STL differs from libc++ and often exposes issues related to them.

There is probably a DenseMap iteration somewhere.

There is probably a DenseMap iteration somewhere.

FWIW, I'm also seeing this on my Windows machine.

FWIW, I'm also seeing this on my Windows machine.

Sorry, i didnt get a chance to look at this. Ill try to repro it on my windows machine

Sorry, i didnt get a chance to look at this. Ill try to repro it on my windows machine

I've seen this expected dispatch function to have a single call operation message in the the WorkGroupFn thing, I'll send a simple tentative fix. Could someone give it a quick shot on Windows?
I don't have a repro myself, which I find quite weird ..

I've seen this expected dispatch function to have a single call operation message in the the WorkGroupFn thing, I'll send a simple tentative fix. Could someone give it a quick shot on Windows?
I don't have a repro myself, which I find quite weird ..

FYI - I just got this one time on a Linux/GCC build and then it worked the next. So definitely a non-determinism.

FYI - I just got this one time on a Linux/GCC build and then it worked the next. So definitely a non-determinism.

Was closed automatically by the PR landing, would be good to test a few times on Windows.

Was closed automatically by the PR landing, would be good to test a few times on Windows.

I just saw a similar error at tip of tree on Windows: https://gist.github.com/ScottTodd/7e36b293626af4af9d10df993512c4bf .

I just saw a similar error at tip of tree on Windows: https://gist.github.com/ScottTodd/7e36b293626af4af9d10df993512c4bf .

I wasnt able to repro on my windows. Will spin a new one again.

I wasnt able to repro on my windows. Will spin a new one again.

Building in debug mode I see the following assertion hit :
Assertion failed: llvmFuncOp.getNumArguments() > 0, file C:\Users\ravishankarm\Development\iree\iree\compiler\Conversion\LinalgToLLVM\ConvertToLLVM2.cpp, line 180

@nicolasvasilache this is new code, and I dont have full context on the ABI. Can you take a look?

Unable to repro locally with 1e5 runs..
@MaheshRavishankar this is fishy: as if there was a race condition in conversion pattern application.
Can you run with -debug-only=dialect-conversion -print-ir-after-all and paste what you see on failure ?
Once the enclosing llvmFunc exists (i.e. the MLIR func has been converted), it must have arguments otherwise there is nowhere to get the pointers to the buffers.

Unable to repro locally with 1e5 runs..
@MaheshRavishankar this is fishy: as if there was a race condition in conversion pattern application.
Can you run with -debug-only=dialect-conversion -print-ir-after-all and paste what you see on failure ?
Once the enclosing llvmFunc exists (i.e. the MLIR func has been converted), it must have arguments otherwise there is nowhere to get the pointers to the buffers.

Here is the output of dump https://gist.github.com/MaheshRavishankar/bfc1ce7d42c58843516896683e1ab26f

Here is the output of dump https://gist.github.com/MaheshRavishankar/bfc1ce7d42c58843516896683e1ab26f

FYI, on my windows machine (with Debug build) this is not intermittent. The assert triggers always. I am using MSVC 2019.

FYI, on my windows machine (with Debug build) this is not intermittent. The assert triggers always. I am using MSVC 2019.

Its a problem of competing patterns. The ConvertToLLVM2 pass adds a pattern from func -> llvm.func and so does populateStdToLLVMPatterns. THe latter is triggered and causes the issue.

Its a problem of competing patterns. The ConvertToLLVM2 pass adds a pattern from func -> llvm.func and so does populateStdToLLVMPatterns. THe latter is triggered and causes the issue.

Ahh good catch - that would explain the differences between compilers. I did notice there's an LLVM_REVERSE_ITERATION:BOOL flag that causes all unordered containers to be iterated in reverse order and that may be useful to have on a CI to catch issues like this vs. how we are doing it now by just compiling with different compilers that iterate differently :P

Ahh good catch - that would explain the differences between compilers. I did notice there's an LLVM_REVERSE_ITERATION:BOOL flag that causes all unordered containers to be iterated in reverse order and that may be useful to have on a CI to catch issues like this vs. how we are doing it now by just compiling with different compilers that iterate differently :P

This could be tracked separately, but I'm still seeing warnings (not errors/failures) that spam the build log each time I build all:
[237/246] Generating check_llvm-ir_llvm_matmul.mlir_module.module
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
  %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
       ^
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %6 = flow.dispatch.input.load %arg0, offsets = [%arg4, %c0], sizes = [%5, %c3], strides = [%c1, %c1] : !flow.dispatch.input<2x3xf32> -> tensor<?x3xf32>
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
  %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
       ^
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %12 = flow.dispatch.input.load %arg1, offsets = [%c0, %arg5], sizes = [%c3, %11], strides = [%c1, %c1] : !flow.dispatch.input<3x4xf32> -> tensor<3x?xf32>
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
  %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
       ^
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %17 = flow.dispatch.input.load %arg2, offsets = [%arg4, %arg5], sizes = [%5, %11], strides = [%c1, %c1] : !flow.dispatch.input<2x4xf32> -> tensor<?x?xf32>
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'linalg.matmul'?): falling back to runtime resolution
  %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
       ^
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %23 = linalg.matmul {__internal_linalg_transform__ = "workgroup"} ins(%10, %16 : tensor<?x3xf32>, tensor<3x?xf32>) outs(%22 : tensor<?x?xf32>) -> tensor<?x?xf32>
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
  %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
       ^
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %9 = flow.dispatch.input.load %0, offsets = [%arg0, %c0], sizes = [%8, %c3], strides = [%c1, %c1] : !flow.dispatch.input<2x3xf32> -> tensor<?x3xf32>
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
  %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
       ^
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %18 = flow.dispatch.input.load %1, offsets = [%c0, %arg1], sizes = [%c3, %17], strides = [%c1, %c1] : !flow.dispatch.input<3x4xf32> -> tensor<3x?xf32>
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
  %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
       ^
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %26 = flow.dispatch.input.load %2, offsets = [%arg0, %arg1], sizes = [%8, %17], strides = [%c1, %c1] : !flow.dispatch.input<2x4xf32> -> tensor<?x?xf32>
[246/246] Generating check_vmla_vmla_bert_encoder_unrolled_fake_weights.mlir_module.module

these are also visible on Linux and in our presubmit logs: https://source.cloud.google.com/results/invocations/03718313-dccb-4f52-b604-4a1cf455248e/targets/iree%2Fgcp_ubuntu%2Fcmake%2Flinux%2Fx86-swiftshader%2Fpresubmit/log

This could be tracked separately, but I'm still seeing warnings (not errors/failures) that spam the build log each time I build all:
[237/246] Generating check_llvm-ir_llvm_matmul.mlir_module.module
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
  %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
       ^
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %6 = flow.dispatch.input.load %arg0, offsets = [%arg4, %c0], sizes = [%5, %c3], strides = [%c1, %c1] : !flow.dispatch.input<2x3xf32> -> tensor<?x3xf32>
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
  %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
       ^
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %12 = flow.dispatch.input.load %arg1, offsets = [%c0, %arg5], sizes = [%c3, %11], strides = [%c1, %c1] : !flow.dispatch.input<3x4xf32> -> tensor<3x?xf32>
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
  %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
       ^
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %17 = flow.dispatch.input.load %arg2, offsets = [%arg4, %arg5], sizes = [%5, %11], strides = [%c1, %c1] : !flow.dispatch.input<2x4xf32> -> tensor<?x?xf32>
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'linalg.matmul'?): falling back to runtime resolution
  %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
       ^
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %23 = linalg.matmul {__internal_linalg_transform__ = "workgroup"} ins(%10, %16 : tensor<?x3xf32>, tensor<3x?xf32>) outs(%22 : tensor<?x?xf32>) -> tensor<?x?xf32>
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
  %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
       ^
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %9 = flow.dispatch.input.load %0, offsets = [%arg0, %c0], sizes = [%8, %c3], strides = [%c1, %c1] : !flow.dispatch.input<2x3xf32> -> tensor<?x3xf32>
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
  %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
       ^
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %18 = flow.dispatch.input.load %1, offsets = [%c0, %arg1], sizes = [%c3, %17], strides = [%c1, %c1] : !flow.dispatch.input<3x4xf32> -> tensor<3x?xf32>
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: remark: unable to materialize shape calculation (unsupported op 'flow.dispatch.input.load'?): falling back to runtime resolution
  %D = linalg.matmul ins(%A, %B: tensor<2x3xf32>, tensor<3x4xf32>)
       ^
D:/dev/projects/iree/iree/test/e2e/linalg_tensor_ops/matmul.mlir:8:8: note: see current operation: %26 = flow.dispatch.input.load %2, offsets = [%arg0, %arg1], sizes = [%8, %17], strides = [%c1, %c1] : !flow.dispatch.input<2x4xf32> -> tensor<?x?xf32>
[246/246] Generating check_vmla_vmla_bert_encoder_unrolled_fake_weights.mlir_module.module

these are also visible on Linux and in our presubmit logs: https://source.cloud.google.com/results/invocations/03718313-dccb-4f52-b604-4a1cf455248e/targets/iree%2Fgcp_ubuntu%2Fcmake%2Flinux%2Fx86-swiftshader%2Fpresubmit/log

Yeah thats a separate issue. It has to do with the shape dialect. It might be a few days before I get around to this. It could be as simple as just removing the remark, but it would probably be better if someone with more knowhow about shape dialect (@silvasean ?) take a look.

Yeah thats a separate issue. It has to do with the shape dialect. It might be a few days before I get around to this. It could be as simple as just removing the remark, but it would probably be better if someone with more knowhow about shape dialect (@silvasean ?) take a look.

This is basically what gets printed if we don't have a shape transfer function registered when we materialize shape calculations. My suggestion is to not use the tie shape pass / materialize shape calculations within flow.dispatch.workgroups, and instead just insert raw dim ops and let them canonicalize to a fixed point.

This is basically what gets printed if we don't have a shape transfer function registered when we materialize shape calculations. My suggestion is to not use the tie shape pass / materialize shape calculations within flow.dispatch.workgroups, and instead just insert raw dim ops and let them canonicalize to a fixed point.

Can you take a pass at cleaning shape related things that are obvious to
you?
Thanks in advance!
On Tue, Jan 26, 2021 at 6:04 PM Sean Silva<EMAIL_ADDRESS>wrote:

This is basically what gets printed if we don't have a shape transfer
function registered when we materialize shape calculations. My suggestion
is to not use the tie shape pass / materialize shape calculations within
flow.dispatch.workgroups, and instead just insert raw dim ops and let them
canonicalize to a fixed point.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/iree/issues/4409#issuecomment-767885382, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACNNU5AA2OJN4HEP6BNFQ7DS35C7DANCNFSM4VYHSK6Q
.

--
N

Can you take a pass at cleaning shape related things that are obvious to
you?
Thanks in advance!
On Tue, Jan 26, 2021 at 6:04 PM Sean Silva<EMAIL_ADDRESS>wrote:

This is basically what gets printed if we don't have a shape transfer
function registered when we materialize shape calculations. My suggestion
is to not use the tie shape pass / materialize shape calculations within
flow.dispatch.workgroups, and instead just insert raw dim ops and let them
canonicalize to a fixed point.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/iree/issues/4409#issuecomment-767885382, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACNNU5AA2OJN4HEP6BNFQ7DS35C7DANCNFSM4VYHSK6Q
.

--
N

Sure. I'm deep in an npcomp change. Will try to get to this in the next week.

Sure. I'm deep in an npcomp change. Will try to get to this in the next week.

This PR should remove most of the tie_shape nonsense: https://github.com/google/iree/pull/4664
(there is still flow.dispatch.tie_shape and the shapex.tie_shape on the flow.dispatch.workgroups op itself, but those are much more constrained in how they affect the code)

This PR should remove most of the tie_shape nonsense: https://github.com/google/iree/pull/4664
(there is still flow.dispatch.tie_shape and the shapex.tie_shape on the flow.dispatch.workgroups op itself, but those are much more constrained in how they affect the code)


Get data of each elements of canvas

Hello,
Is it possible to get data of each elements of the canvas or create an image of each elements independently ?
Thank you

There's no designed api for this too.
One possible way: Create a SnapshotTarget by yourself, and call the renderSelf(on:) method of the elements witch you want, then you can take a snapshot for the texture of this SnapshotTarget


Moved context into its own module.

What was wrong?
Context was cluttering the analyzer's lib.rs file.
How was it fixed?
Moved Context into its own module.
To-Do

[ ] OPTIONAL: Update Spec if applicable

[x] Add entry to the release notes (may forgo for trivial changes)

[ ] Clean up commit history

Codecov Report

Merging #381 (49243a0) into master (597bfcc) will not change coverage.
The diff coverage is 90.51%.

:exclamation: Current head 49243a0 differs from pull request most recent head 156f733. Consider uploading reports for the commit 156f733 to get more accurate results

@@           Coverage Diff           @@
##           master     #381   +/-   ##
=======================================
  Coverage   86.30%   86.30%
=======================================
  Files          66       67    +1
  Lines        4032     4032
=======================================
  Hits         3480     3480
  Misses        552      552

Impacted Files
Coverage Δ

analyzer/src/lib.rs
14.81% <ø> (-63.24%)
:arrow_down:

analyzer/src/namespace/types.rs
89.75% <ø> (ø)

analyzer/src/traversal/assignments.rs
96.55% <ø> (ø)

analyzer/src/traversal/contracts.rs
100.00% <ø> (ø)

analyzer/src/traversal/expressions.rs
91.73% <ø> (ø)

analyzer/src/traversal/functions.rs
97.39% <ø> (ø)

analyzer/src/traversal/types.rs
100.00% <ø> (ø)

analyzer/src/traversal/utils.rs
81.81% <ø> (ø)

compiler/src/abi/builder.rs
95.34% <ø> (ø)

compiler/src/abi/elements.rs
84.61% <ø> (ø)

... and 16 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 597bfcc...156f733. Read the comment docs.


Fixed a minor typo

Overview
TL;DR
Fixed a minor typo.
Thank you

Thank you for this fix, @Ashikpaul! ✨


feat: add codeql workflow

Related Issues or bug
This PR resolves issue: #316
Files added/modified

.github/workflows/codeql.yml

Please review this PR.
Thanks

Hello @harmeetsingh11!
Thank you for submitting this pull request Your pull request will be reviewed by maintainers shortly. Meanwhile make sure you have referenced the respected issue in this pr Your pr will not be merged if it does not have reference to respected issue
please read our Contributing Guidelines https://github.com/UBA-GCOEN/StichHub/blob/main/CONTRIBUTING.md And Code of Conduct https://github.com/UBA-GCOEN/StichHub/blob/main/CODE_OF_CONDUCT.md


Remove two pImpl abstraction layers in rename

IMO the code is a lot easier to read if we don’t hide the implementation in an Implementation class. AFAICT the abstraction layer wasn’t giving us anything.

@swift-ci Please smoke test

@swift-ci Please test Windows


[WIP] Run tests on rhel-8.4 ga runner

Opening this just to keep track of it. This needs 8.4 runners in osbuild-composer repository first to get the rpms from it and also new manifests with released content.

This will be done along with https://github.com/osbuild/osbuild/pull/810


Issue in parsing mtggoldfish

While parsing some mtggoldfish decks with next code:
cards = mtg_parser.mtggoldfish.parse_deck(url)
for card in cards:
print(card)
Occurs:
Traceback (most recent call last):
File "/Users/macbookair/Public/cedh_data_miner/databaseProcessing/a.py", line 8, in
for card in cards:
^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/mtg_parser/mtggoldfish.py", line 40, in _parse_deck
last_category = row.th.string.strip().splitlines()[0].lower()
^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'strip'
This happens only if deck has a modified land, so heading above lands section is not "Lands (34)" but "Lands (34) +1 MDFC"
You can try it with these URLs:
https://www.mtggoldfish.com/deck/5887226#paper
https://www.mtggoldfish.com/deck/5864817#paper
https://www.mtggoldfish.com/deck/5633606#paper

Fixed is released in version 0.0.1a36 (https://github.com/lheyberger/mtg-parser/releases/tag/v0.0.1a36)

I want to create a convenient tool for analyzing statistics from cedh tournaments. I get a database of events from the website edhtop16.com. Then, with the help of your project, I download the participants' decklists. Using the resulting database, I can analyze the win rate trends of individual cards, combinations, or commanders. So, for example, I have already found very strong but not popular white cedh staple - Touch the Spirit Realm. I know which staples are overrated or underrated, which wincons are stronger, and I can also analyze some non-obvious principles of deck building, such as, for example, what number of counterspells is most effective to have in deck (10-12). Everything is great, but progress is not very fast, because I'm not even a junior programmer :)


avoid using cache when the image on the host have changed

currently when I use locally built images, if I rebuild and restart a deployment that uses those images (and imagePullPolicy set to Always) I expect the newly built image to be used but the registry uses it's local cache and does not pull the new image from the host. I ma not sure if it's possible or how to do so but if the registry can comapre the sha256 of the cahched image with the one on the host, it can decide if the cache should be used or not. If checking the sha256 value is the same effort as pulling the image from the host, then I suggest to have an option to disable the registry local cache and allways pull from the host.

Hey @benamizilber! I made an attempt to solve this in 26ed25c and pushed it to ligfx/k3d-registry-dockerd:latest. Can you try that out and let me know if it works for you?

Released in v0.2, accessible on Docker Hub as ligfx/k3d-registry-dockerd:v0.2


update image on gratuitous example

Update image since previous one was deleted
Test plan (required)*
UIExplorer

Could we just use a local image instead? Will avoid this issue and work better offline.

@janicduplessis definitely you are right. Fixed.

@facebook-github-bot shipit


Maybe should add Alternate Function Input Mode

I found Alternate Function Input Mode from stm32f1xx_hal_gpio.h
#define  GPIO_MODE_INPUT                        0x00000000u   /*!< Input Floating Mode                   */
/* codes */
#define  GPIO_MODE_AF_INPUT                     GPIO_MODE_INPUT          /*!< Alternate Function Input Mode         */

Although Alternate Function Input Mode same Input Floating Mode , but I think should add this mode that would be helping user to aviod ambiguity and as same as possible with  stm32f1xx_hal Clang version.

Does this solve a use case that isn't solved by the combination of Input and AlternateFunction pin modes already present?

@TheZoq2 In fact, used Input Floating Mode same to used Alternate Input

I don't like this idea, because from my understanding, there simply is no difference. I would prefer to keep the type-stated I/O pins as close as possible to the actual hardware state transitions.
The reference manual states in 9.1:

Subject to the specific hardware characteristics of each I/O port listed in the datasheet, each port bit of the General Purpose IO (GPIO) Ports, can be individually configured by software in several modes:

Input floating
Input pull-up
Input-pull-down
Analog
Output open-drain
Output push-pull
Alternate function push-pull
Alternate function open-drain

It does not mention a "Alternate input" mode, and figure 13 suggests that the after-schmitt-trigger-input-signal is just both routed to the input of an alternate function peripheral and to the input register file at the same time.

That's a very good point, I'll close this issue for now, feel free to re-open if there are other considerations


Storage util final

Made StorageUtil class as final, as java does not support static at top level. And fix the issue with cassandra-rackdc.properties at .gitignore.

Can one of the admins verify this patch?

@mesosphere-ci retest this please

@triclambert Can you please re-run the build or pass along the test failure info?

@mesosphere-ci retest this please

please re-run the build.

@mesosphere-ci retest this please

@mesosphere-ci retest this please.

@vargup Thanks for the PR!


MikesTweaks additional inventory slots not working when LethalThings is enabled

Hey there!
Been playing modded LC while having those two mods enabled.
But recently after waiting for mods to update, when me and friends came back, additional slots from MikesTweaks were not working.
The difficult part is... as long as LethalThings is disabled, the additional inventory slots from MTweaks are working fine.
As soon as LethalThings mod is enabled, the only part from MikesTweaks that is not working is the additional slots.
If it's not LethalThings mod fault, please let me know and I will head over to MikesTweaks github!
TL;DR: Then MTweaks and LThings are both on, MT's additional slots are not working.
But if anything I can easily reproduce the issue by installing MikesTweaks and LethalThings.
Then when you run the modded client with just MikesTweaks enabled the default 2 additional slots are present, but when both are enabled the slots return to vanilla 4.

Sounds like a mtweaks problem and not a lethal things problem, i rewrote the utility belt code recently for better support with mods like Reserved Item Slots which may be related. I recommend creating an issue there and mentioning this issue.

Actually, for some reason the update literally less than 2 hours ago for... Lategame Upgrades fixed the issue.
I have NO clue why or what caused the issue in the first place.
If comes up again will head over to MTweaks Github then, thanks a lot!


[Bug]: linker file is not an xml according to standard because of version attribute

What happened?
I created a PowerShell script that uses the xml generated in the dvdt.linker.xml file to automate some actions.
When I try to load the file as an xml I get an error. The issue is that the file has the version set like version="1", but the standard says that the version must be version="1.0".
I can edit the file and make the script work, but when a new link is created, the file is regenerated, and I have to change it again.
Can the xml be updated to have the version like the standard?
Thanks
What version of the tool are you using?
v2.2.0
What version of Visual Studio Code are you running?
1.92.1
Any relevant session id from VSCode?
No
Relevant log output
No response

I am using fast xml parser to parse the file into xml. I'll have to check with that package if there is a config missing or if it's an issue with the package.

I don't know if it is relevant, but the linker file in the templates section has the correct value set for the version. I don't know if this file was generated with the same package, but just pointing it in case it helps.
The file is the one in resources/templates/dvdt.linker.xml.

Can this be reopened? It is still not solved.

This should be resolved now


Rotation animation shouldn't apply to the shadow on pre-Lollipop

You can see an example of that here at 1m40: https://youtu.be/xzNN693IY8I?t=1m40s
When the FAB rotates, the shadow looks odd.
And the code is here: https://github.com/geecko86/QuickLyric/blob/master/QuickLyric/src/main/java/com/geecko/QuickLyric/view/RefreshIcon.java
Basically, any animation that's started this way:
 New FloatingActionButton().startAnimation(rotateAnimation);

Applies to the shadow as well. It doesn't do that on Lollipop.

This will be because the shadow is performed by Android on Lollipop using elevation, but with an image file on the FAB for pre-Lollipop.
This could be fixed, by having a way to rotate the icon rather than the whole FAB.

From what I've seen, animations apply to view and the icon is not a view: it's the drawable used as background for the FAB. In my opinion a good fix would be to separate the shadow and the FAB as 2 separate views and to automatically transfer all animations to the FAB. I could take care of that but I'd rather have the author's opinion.

How about disabling the shadow for the FAB itself (fab:fab_shadow="false") and wrapping the FAB with a view group that provides a shadow for it. For example I have found this library that might be used: https://github.com/dmytrodanylyk/shadow-layout.
I'm not sure if it's a good idea to separate the FloatingActionButton class to two views.

I ended up doing something like that, yes. The problem is that if we need to implement a shadow manually, then we also need to hide and show it manually. It feels more like a hack.
This is cicumvents the problem but it doesn't solve it.


feat(core, theme-classic): allow overriding htmlLang

Motivation

I'm in the middle of building a website for Interslavic language which is available in multiple locales and scripts. The problem is that Interslavic language has quite a long BCP-47 language tag: art-x-interslv.[^1]

Besides, since it supports equally the Latin and Cyrillic scripts, you ought[^2] to specify the script as well: art-Latn-x-interslv and art-Cyrl-x-interslv respectively. Also, the language has a for-internal-use script with extra etymological letters[^3], the so-called Etymological (or Scientific) alphabet, which we agreed to have under art-Latn-x-interslv-etymolog.
[^1]: See ConLang Code Registry: https://www.kreativekorp.com/clcr/
[^2]: See page 12: https://tools.ietf.org/search/bcp47
[^3]: http://steen.free.fr/interslavic/orthography.html#etymological_alphabet

Docusaurus is too coupled at the moment to the language code – you have to maintain directory and URL structure accordingly to the code. I'd like to shorten my directory names and URLs to .../sla-Latn/... and .../sla-Cyrl/..., for example, but I'd still want to render the adopted BCP 47 language tag in the document markup.
Without this feature, even the home page would have a URL like https://interslavic.fun/art-Latn-x-interslv-etymolog, which looks clumsy.

Have you read the Contributing Guidelines on pull requests?
Yes, although some parts I skimmed. 🙏
Test Plan
In your docusaurus.config.js, try overriding your i18n section, e.g.:
   i18n: {
     defaultLocale: 'en',
+    localeConfig: {
+      en: { htmlLang: 'en-GB' }
+    }

After reloading the website, check that you see <html lang="en-GB"> in the rendered HTML markup.
Related PRs

feat(v2): add support for RTL direction: https://github.com/facebook/docusaurus/pull/4140
fix(v2): fix/enhance minor i18n issues reported: https://github.com/facebook/docusaurus/pull/4092

Thanks, LGTM 👍
nice site, please add it to our showcase ;)

Oops, forgot about docs🤦♂

😅 missed that too

@slorber , @Josh-Cena , so what action is required? Please elaborate and I'll try to supplement what's missing.

No worries @noomorph I'll write some docs. I have long planned to renew the i18n docs, going to document this change as well.

It wouldn't harm to add it here quickly @noomorph : https://docusaurus.io/docs/api/docusaurus-config#i18n
This way we are sure to not forget when updating the i18n doc ;)


fix(chats): show the scroll button early while still tracking the scroll position using intersectionobserver

What this PR does 📖

reverts #1530 but then adds back the onscroll handler. This time the onscroll handler sets a flag which is used in conjunction with the UseSharedState<ScrollBtn>. This way the scroll button can appear early for very large pictures while preserving the ChatBehavior functionality.

Which issue(s) this PR fixes 🔨

Resolve #1566

Special notes for reviewers 🗒
Additional comments 🎤

replaced by another pr


don't allow expressions outside of functions (besides REPL)

Right now if the brightscript runtime executes a file, it will execute every expression it finds outside of a function.  This doesn't match the brightscript implementation where expressions must be inside functions.
...
print "running something"

sub Main()
    print "in showChannelSGScreen"
    ...

which raises a syntax error the following error:
Syntax Error. (compile error &h02) in pkg:/source/Main.brs(10)

Should we match the device implementation and look for a main function, or should we enable a flag to toggle it so we can still run expressions in the REPL?

This is a tough one – node handles it ostensibly by assigning the result of the expression to $_ and printing $_.  That won't work in BrightScript because – unlike JavaScript – BrightScript Doesn't support right-associative assignments (e.g. let foo = bar = baz = qux;).
This might require a separate parser entirely, or maybe a separate mode for the parser?  Not too sure yet.


concept issue: defining functions for field properties

Great stuff!
However there seems to be an issue with the concept of defining functions for fields properties and validators as standard JSON does not allow / support to generate JSON containing javascript functions like the following:
{
  type: "select",
  label: "Type",
  model: "type",
  values: [
    { id: "personal", name: "Personal" },
    { id: "business", name: "Business" }
   ]
},{
  type: "text",
  label: "Company name",
  model: "company.name",
  visible: function(model) {
    return model && model.type == "business";
  }
}

The workaround from #149 does not work in version 3.
Is there any know way to solve this??

What I did was create a schema parser, which was able to map strings to methods.
For example “bind:someMethod”, would change the value from the string “bind:someMethod” and switch it over to a reference to that function.  I’ve posted an example of this a couple of times in other issues, a quick search should turn them up... unfortunately I don’t have the time to find them at the moment.

I also handled this in a similar fashion. Although a bit more work but very flexible.
I have a parser that finds any key with the _calc extension and converts the value to an evaluated function and added as a getter. This way it works with all keys anywhere in the schema.
eg
visible_calc = "model.sAllowed"
// or
values_calc = "model.myArrayOfValues"

My technique replaces the raw key with the getter function

To clarify, I look for “bind:” prefix in the schema value and then lookup and attach to that, whether it be a property or a function.

ok, understand the concept but am struggling with the details (due to my lack of deeper knowledge...).
Tried to adopt the code I found in #601 but can't make it work.
I want to control the visibility of a field based on the selected value of another field.
I understand, the approach would be
{
"visible" : "bind:myToggleFunction"
}

and than parse the bind:myToggleFunction using
`_.set(object, key, bindValue(param));``
Where / how would I define myToggleFunction to make it work?
Could you provide a working example (could be best practice as part of the documentation)?
For a future version a totally different approach to control form properties could be similar to https://github.com/ncform/ncform#dx-expression

anyone?

Sorry for delay, must have missed this.
VFG schemes are dynamic, if you update the schema VFG will update as well.
You can listen for VFG change events, watchers on the model, etc, and then update the schema visibility property.
My approach with “bind” allows for the schema to be defined remotely and use code I exposed to the component controlling VFG... you can define “myToggleFunction” anywhere the schema parser that wires up the actual binding has access to.
In my case, I did something similar to VFG validation class and attach a number of utility functions there... then my schema parser just looks for matches there.

ok, not really understanding what am doing the following works for me to toggle the visibility of a field depending on the value of another field w/o using the function syntax (which would force me to generate invalid json)
in app.js
var self = this;

axios
            .get(requestUrl)
            .then(function (response) {
                self.schema = response.data.data.schema;
                // https://github.com/vue-generators/vue-form-generator/issues/601

                // bind a field property to code
                let functionValue = (code, self) => {
                    return () => {
                        let fn = new Function('self', code)
                        return fn(self);
                    };
                };
                // bind a field property to `path` (can be a function)
                let bindValue = (path) => {
                    return () => {
                        return _.get(self, path);
                    };
                };
                // returns true if `path` exists, else false
                let hasValue = (path) => {
                    return () => {
                        return _.has(self, path);
                    };
                }

                let recurse = (obj) => {
                    _.forIn(obj, (value, key, object) => {
                        if (_.isString(value) && value.includes(':')) {
                            let parts = value.split(':', 2);
                            let op = parts[0];
                            let param = null;
                            if (parts.length > 1) {
                                param = parts[1];
                            }
                            switch (op) {
                                case 'function':
                                    _.set(object, key, functionValue(param, self));
                                    break;
                                case 'bind':
                                    _.set(object, key, bindValue(param));
                                    break;
                                case 'has':
                                    _.set(object, key, hasValue(param));
                                    break;
                                case 'ValidateJs':
                                    // ValidateJs is a custom validator object
                                    _.set(object, key, ValidateJs[param]);
                                    break;
                            }
                        }
                        // go deep
                        if (_.isArray(value) || _.isObject(value)) {
                            _.set(object, key, recurse(value));
                        }
                    });
                    return obj;
                };

                self.schema = recurse(self.schema);
            })

and in my schema generated through laravel:
 'visible' => 'function: return self.model.myValue == 3',

would be great to get your view on this!
thanks again

I’m not a big fan of evaluating a function like that... what I did was created the functions in my code, and just passed Paramus to them from the Json schema.
A quick look ... seems your code should work though.  I haven’t touched VFG in a few months though, so don’t have a project handy to test on at the moment (switched jobs back in March).


Login - no user found with that username

Describe the bug

Expected behavior

To Reproduce

My Platform

Additional context

Hi @davaya, please fill the template?

It should have not been created - don't see a way to delete.  Closing now.


fix cursor mismatch issue in 21:9 ultrawide monitor fullscreen mode.

VRGUI.width and VRGUI.height now stores game resolution instead of window resolution in fullscreen mode


[SPARK-3957]: show broadcast variable resource usage info in UI

show the broadcast variables resource usage in UI

Test build #25600 has started for   PR 2851 at commit bf7095c.

This patch merges cleanly.

Test build #25600 has finished for   PR 2851 at commit bf7095c.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class SparkListenerBlockUpdate(blockManagerId: BlockManagerId, blockId: BlockId,
class DefaultSparkListenerEventFilter
class BroadcastInfo(

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

ping

Test build #25817 has started for   PR 2851 at commit 1f53135.

This patch merges cleanly.

Test build #25817 has finished for   PR 2851 at commit 1f53135.

This patch fails to build.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class SparkListenerBlockUpdate(blockManagerId: BlockManagerId, blockId: BlockId,
class DefaultSparkListenerEventFilter
class BroadcastInfo(

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

Test build #25837 has started for   PR 2851 at commit 6b25507.

This patch merges cleanly.

Test build #25837 has finished for   PR 2851 at commit 6b25507.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class SparkListenerBlockUpdate(blockManagerId: BlockManagerId, blockId: BlockId,
class DefaultSparkListenerEventFilter
class BroadcastInfo(

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

Hey @CodingCat this seems like a very complicated change for showing broadcast variables. In particular I do not understand why we need to introduce a new listener event for this. Can you summarize how the broadcast blocks info is sent to the driver before and after this PR?

Test build #27377 has started for   PR 2851 at commit 3a0aa25.

This patch merges cleanly.

Hey, @andrewor14
Sorry for the late response, I just cleaned a congested task queue in my schedule...I will address your comments within today

Test build #27377 has finished for   PR 2851 at commit 3a0aa25.

This patch fails to build.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class SparkListenerBlockUpdate(blockManagerId: BlockManagerId, blockId: BlockId,
class DefaultSparkListenerEventFilter
class BroadcastInfo(

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

Test build #27380 has started for   PR 2851 at commit b65d49e.

This patch merges cleanly.

Test build #27380 has finished for   PR 2851 at commit b65d49e.

This patch fails to build.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class SparkListenerBlockUpdate(blockManagerId: BlockManagerId, blockId: BlockId,
class DefaultSparkListenerEventFilter
class BroadcastInfo(

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

Test build #27387 has started for   PR 2851 at commit bf03271.

This patch merges cleanly.

Test build #27387 has finished for   PR 2851 at commit bf03271.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class SparkListenerBlockUpdate(blockManagerId: BlockManagerId, blockId: BlockId,
class DefaultSparkListenerEventFilter
class BroadcastInfo(

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

Test build #27404 has started for   PR 2851 at commit 5c60a34.

This patch merges cleanly.

Test build #27405 has started for   PR 2851 at commit 08ad98d.

This patch merges cleanly.

Hi, @andrewor14, thanks for the review.
To answer your question:

how the broadcast blocks info is sent to the driver before and after this PR?

before this PR, the broadcast blocks was not sent to the driver from executors,
in this PR, I am exactly using the strategy mentione by @shivaram, i.e. setting tellMaster=true

Would all the new logic just go away if we simply set tellMaster = true for all broadcast blocks,

No...the complexity comes from 1) updating the page, and 2) as mentioned by @rxin , we need to avoid introduce more complexity to BlockManagers (at the beginning I simply piggyback the broadcast info in the BlockManager heartbeat)
to address 2), I use the listenerBus to notify the StorageStatusListener and StorageListener that some of the blocks are updated, they need to apply the operation respectively (StorageStatusListener => update executorIdToStorageStatus, StorageListener => update internal data structure)

Test build #27404 has finished for   PR 2851 at commit 5c60a34.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class SparkListenerBlockUpdate(blockManagerId: BlockManagerId, blockId: BlockId,
class DefaultSparkListenerEventFilter
class BroadcastInfo(

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

Test build #27405 has finished for   PR 2851 at commit 08ad98d.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class SparkListenerBlockUpdate(blockManagerId: BlockManagerId, blockId: BlockId,
class DefaultSparkListenerEventFilter
class BroadcastInfo(

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

Hi, @squito , thanks for the review, I will handle it in the weekend

Hi @CodingCat ,
thanks for working on this, sorry the review has been dragging out.  This will be a nice addition, but I have some concerns similar to the other reviewers -- but lemme explain in a little more detail.  I don't necessarily see anything wrong with your approach for getting the Broadcast block info by itself, but it seems like it ought to share a similar code path to tracking the RDDBlocks.  RDDBlocks get updated in the SparkListenerTaskEnd event, through event.taskMetrics.updatedBlocks.  this makes its way to the current StorageTab in StorageListener, which then filters down to the RDDBlocks via BlockId.asRDDId.
So, this makes me wonder about two possible alternatives for unifying the code paths:

Can you get the Broadcast block ids into the same SparkListenerTaskEnd event, which would eliminate the need to create a new event?  (In fact, maybe those block ids are already there?  I am still looking into the code for how those events get created ...)

If we can't get Broadcast block ids into the same SparkListenerTaskEnd, does it make sense to change the RDD block tracking logic to do the same thing?  Yes this will be a bigger change, but it seems strange to have these two blocks tracked by such different mechanisms so it will lead to simpler code overall.  (But really that pushes me to option #1)

hmm, ok now I see that it is hard to get the BroadcastBlockIds into the task end metrics, since when broadcast blocks get created, its a side effect of task-deserialization, so the broadcast var doesn't really know which task its being created for.  The only other option I can think of is to create a ThreadLocal with the current task id, before deserializing the task here.  Then when the broadcast var is actually put in the block manager, (eg.  for TorrentBroadcast) and finally when the task is finished you'd update the metrics.
Honestly I am somewhat torn between (a) leaving it as you have it, (b) what I've outlined in this comment, and (c) having RDD block info also tracked by your new mechansim (option 2 above)

working on this now

well I was leaning towards using a ThreadLocal to get the broadcast blocks into the task end event ... but I forgot that broadcast blocks are also created by the driver (eg. here or here). It doesn't make any sense to stick those into a task end event.  I suppose they could go into a task start event, but that is still a little weird, maybe we really do need a new event.
@rxin @andrewor14 thoughts?

Test build #27569 has started for   PR 2851 at commit 57d3f46.

This patch merges cleanly.

Test build #27569 has finished for   PR 2851 at commit 57d3f46.

This patch fails RAT tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class SparkListenerBlockUpdate(blockManagerId: BlockManagerId, blockId: BlockId,
class DefaultSparkListenerEventFilter
class BroadcastInfo(

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

Test build #27570 has started for   PR 2851 at commit b05196a.

This patch merges cleanly.

Test build #27571 has started for   PR 2851 at commit 34aed25.

This patch merges cleanly.

Test build #27570 has finished for   PR 2851 at commit b05196a.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class SparkListenerBlockUpdate(blockManagerId: BlockManagerId, blockId: BlockId,
class DefaultSparkListenerEventFilter
class BroadcastInfo(

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

Test build #27588 has started for   PR 2851 at commit 04726c4.

This patch merges cleanly.

Hi, @squito, thank you very much for your patient review
Here is the summary on what I have done on addressing your comments

regarding the duplication in RDDPage and BroadcastPage
Now, both of them inherit from InMemoryObjectPage, which defines the common parts of these two classes, e.g. Worker Header, etc.

Serialization and Deserialization of SparkListenerBlockUpdate event
I implemented the serialization and deserialization methods (https://github.com/apache/spark/pull/2851/files#diff-4f6ba18259eb4c31ac930e18f1ba6f88R99) and (https://github.com/apache/spark/pull/2851/files#diff-4f6ba18259eb4c31ac930e18f1ba6f88R480)
To prevent the large volume of events being logged, there is an event filter existing in SparkListenerBus (https://github.com/apache/spark/pull/2851/files#diff-01185688f339238fc6689baa6106df63R27). Now this filter ensure that only the broadcast block update event is logged (https://github.com/apache/spark/pull/2851/files#diff-fbe8f967070627c8dc155237e77c7314R130) (actually this was implemented long time ago)

get rid of the mutable variable in BlockManagerMasterActor
Done (https://github.com/apache/spark/pull/2851/files#diff-6da9360efd5e37dcd0edcc651db1e9cbR508)

shorten the compare() in BroadcastInfo (https://github.com/apache/spark/pull/2851/files#diff-6da9360efd5e37dcd0edcc651db1e9cbR508)
Unfortunately, I probably cannot do that, since compare() returns Int, but broadcastId is Long

tighten the methods in StorageUtils
Done (https://github.com/apache/spark/pull/2851/files#diff-6da9360efd5e37dcd0edcc651db1e9cbR508)

Potential problems in the current patch

to de-duplicate the code in StorageUtils, I save RDD ID with Int type in a Long Field (https://github.com/apache/spark/pull/2851/files#diff-21027f5c826cd378daaae5f7c3eea2b5R41), otherwise it's hard to get a BlockMap according to the blockId (https://github.com/apache/spark/pull/2851/files#diff-21027f5c826cd378daaae5f7c3eea2b5R126) (you will see a lot of type imcompatibility from the compiler)

InMemoryObjectPage.scala (https://github.com/apache/spark/pull/2851/files#diff-dc63d4ab5b2ed5a2135c054be78820eeR97), I'm not sure if the semantics of (memory usage of a worker) is correct...it should be the memory used by the current InMemoryObject or the total memory usage?

Test build #27571 timed out     for PR 2851 at commit 34aed25     after a configured wait of 120m.

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

Test build #27595 has started for   PR 2851 at commit 0d854b8.

This patch merges cleanly.

Test build #27588 timed out     for PR 2851 at commit 04726c4     after a configured wait of 120m.

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

weird...I can pass the test cases in my laptop without any problem....

oh...the failed one is the previous submission.....

Test build #27595 has finished for   PR 2851 at commit 0d854b8.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class SparkListenerBlockUpdate(blockManagerId: BlockManagerId, blockId: BlockId,
class DefaultSparkListenerEventFilter
class BroadcastInfo(

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

Hi @CodingCat
thanks for making all the updates.  Sorry I hadn't realized the subtlety w/ Int vs Long on the RDDBlockId and BroadcastBlockId.  Still, I think its still a good change for simplifying the code, glad you figured a way to make it work.   And on issue (2), the memory usage of a worker, I think what you have is correct, its supposed to be memory usage of the particular object on the worker.  This is on a UI page in the context of a particular object -- there is a separate page to summarize the memory usage of the executor overall.  (though I agree the UI is a little confusing ...)
I'll make a few more minor comments on the code, but mostly I just want to get another opinion on the right events to pass the block added events around, as I have mentioned above.

can you also post a screenshot of the detailed page for a broadcast var?  Ideally involving a broadcast var that gets turned into multiple blocks by TorrentBroadcast, I think just needs to be over 4MB by default.

Test build #27638 has started for   PR 2851 at commit 564f7d2.

This patch merges cleanly.

Test build #27638 has finished for   PR 2851 at commit 564f7d2.

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

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

Hi, @squito , thanks for the further comments
I have addressed them and also replied under some of them
The snapshots was uploaded,
I will not be here tomorrow but will be back after that....

Test build #28529 has started for   PR 2851 at commit 2ea8ee3.

This patch merges cleanly.

Test build #28529 has finished for   PR 2851 at commit 2ea8ee3.

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

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

Test build #28534 has started for   PR 2851 at commit 223cdfb.

This patch merges cleanly.

Test build #28534 has finished for   PR 2851 at commit 223cdfb.

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

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

Hi, @squito , would you mind taking further review when you have time?

Hi @CodingCat , I took another look through everything.  My comments are all very minor.  But I think I'd still like to get some more thoughts from others on how the broadcast block info is passed along.  As I mentioned earlier, it is also possible to get it into TaskEnd events, like the RDD blocks.  I'm torn, so I'd like to hear what others think.  Sorry it is taking so long to get feedback ...

Test build #28577 has started for   PR 2851 at commit 26977c9.

This patch merges cleanly.

Test build #28577 has finished for   PR 2851 at commit 26977c9.

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

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

Test build #28585 has started for   PR 2851 at commit 49ee118.

This patch merges cleanly.

Test build #28585 has finished for   PR 2851 at commit 49ee118.

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

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

Test build #28601 has started for   PR 2851 at commit 9b1bccf.

This patch merges cleanly.

Test build #28601 has finished for   PR 2851 at commit 9b1bccf.

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

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

Hi, @squito , thanks for the comments, I made some revision on the patch

thanks for the updates!  just one small style comment.
FWIW, after thinking about it more, I am in favor of your approach of sending the block updates, just want to get some confirmation.
lgtm (with the minor style update)

Test build #28626 has started for   PR 2851 at commit 1aec3a8.

This patch merges cleanly.

Test build #28626 has finished for   PR 2851 at commit 1aec3a8.

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

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

thanks @squito
I updated that again

Hey @CodingCat, it looks like this PR is significantly out of date. Do you mind closing it for now? You can always re-open / re-submit once we're ready to work on this feature again. Thanks!

sure, I will close this temporarily


When turning over months, several dates are highlighted.

When a date is selected which when turning over month present in the current and next, it will be highlighted in both.
Steps to reproduce the behavior:

Select date in the end of month.
Turn over next month.
It can be seen that several dates are highlighted.
The same thing when select date in start of month and turning over on the previous month.

It doesn't look like a bug. As I understood 30 June on gif it's selected date and it's equal the date in input, but 30 Jule it's a date which displays selected date after increasing by the month. You can see it by the color of the days. 30 June(current date) is darker than 30 July(current date + month). Light highlight may be seen if you try to manipulate by keyboard arrows.  If it inappropriate behavior you can try rewrite styles for it(class react-datepicker__day--keyboard-selected responsible for this)

When a date is selected which when turning over month present in the current and next, it will be highlighted in both.

It doesn't look like a bug. As I understood 30 June on gif it's selected date and it's equal the date in input, but 30 Jule it's a date which displays selected date after increasing by the month. You can see it by the color of the days. 30 June(current date) is darker than 30 July(current date + month). Light highlight may be seen if you try to manipulate by keyboard arrows. If it inappropriate behavior you can try rewrite styles for it(class react-datepicker__day--keyboard-selected responsible for this)

Okay, sorry.
I did not notice that they are of different colors, did not expect such behavior, I will rewrite the class you wrote about.


[CT-3376] [Bug] dbt snapshot throws "SSL connection has been closed unexpectedly"

Is this a new bug in dbt-core?

[X] I believe this is a new bug in dbt-core
[X] I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior
Encountered problem similar to https://github.com/dbt-labs/dbt-core/issues/4853#issue-1165307353, except that snapshot did not succeed in spite of the error as it did in that report.
In each of 7 attempts, I get and ERROR with "SSL connection has been closed unexpectedly" after anywhere from 45-121 seconds.
Assuming this was some kind of connectivity issue, I tried, with no luck:

increase max compute from 0.25 CPU to 1.0 in case resource limitation was causing the issue
setting dbt profile option connect_timeout to 300
setting dbt prfile option sslmode to 'require'

I also filed a ticket with the DB server host, hoping something in the logs on their end could help shed light on the issue.
Ultimately I realised that the dbt error and all subsequent reasoning based on it meaning something was inaccurate.
I had specified the "unique_key" column in the config with single quotes instead of double. Fixing this allowed snapshot to run successfully.
Expected Behavior
When this mistake is made in postgres, a fairly obvious exception is thrown. The dev says "doh", fixes it quickly, and moves on.
I would have expected dbt to pass through an error like this rather than lead one to believe the connection has problems.
Steps To Reproduce
Use single quotes for the unique_key column in a snapshot file.
Relevant log output
21:10:48.267844 [debug] [Thread-2 (]: Postgres adapter: Postgres error: SSL connection has been closed unexpectedly

21:10:48.268563 [debug] [Thread-2 (]: On snapshot.dbt_ppi.snapshot_ppi: ROLLBACK
21:10:48.269575 [debug] [Thread-2 (]: Failed to rollback 'snapshot.dbt_ppi.snapshot_ppi'
21:10:48.270517 [debug] [Thread-2 (]: Timing info for snapshot.dbt_ppi.snapshot_ppi (execute): 21:09:49.896703 => 21:10:48.270209
21:10:48.271107 [debug] [Thread-2 (]: On snapshot.dbt_ppi.snapshot_ppi: Close
21:10:48.273701 [debug] [Thread-2 (]: Database Error in snapshot snapshot_ppi (snapshots/snapshot_ppi.sql)
  SSL connection has been closed unexpectedly
21:10:48.274393 [debug] [Thread-2 (]: Sending event: {'category': 'dbt', 'action': 'run_model', 'label': '28fab020-c092-4c56-a996-9bd94d391f09', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7f535ba24400>]}
21:10:48.275530 [error] [Thread-2 (]: 1 of 1 ERROR snapshotting snapshots.snapshot_ppi ............................... [ERROR in 58.39s]
21:10:48.276046 [debug] [Thread-2 (]: Finished running node snapshot.dbt_ppi.snapshot_ppi
21:10:48.277728 [debug] [MainThread]: Using postgres connection "master"
21:10:48.278359 [debug] [MainThread]: On master: BEGIN
21:10:48.278843 [debug] [MainThread]: Opening a new connection, currently in state closed
21:10:53.515085 [debug] [MainThread]: SQL status: BEGIN in 5.0 seconds
21:10:53.515698 [debug] [MainThread]: On master: COMMIT
21:10:53.516138 [debug] [MainThread]: Using postgres connection "master"
21:10:53.516569 [debug] [MainThread]: On master: COMMIT
21:10:53.664440 [debug] [MainThread]: SQL status: COMMIT in 0.0 seconds
21:10:53.664985 [debug] [MainThread]: On master: Close
21:10:53.665925 [debug] [MainThread]: Connection 'master' was properly closed.
21:10:53.666336 [debug] [MainThread]: Connection 'snapshot.dbt_ppi.snapshot_ppi' was properly closed.
21:10:53.666805 [info ] [MainThread]:
21:10:53.667412 [info ] [MainThread]: Finished running 1 snapshot in 0 hours 1 minutes and 24.31 seconds (84.31s).
21:10:53.668224 [debug] [MainThread]: Command end result
21:10:53.746113 [info ] [MainThread]:
21:10:53.746581 [info ] [MainThread]: Completed with 1 error and 0 warnings:
21:10:53.746870 [info ] [MainThread]:
21:10:53.747172 [error] [MainThread]: Database Error in snapshot snapshot_ppi (snapshots/snapshot_ppi.sql)
21:10:53.747459 [error] [MainThread]:   SSL connection has been closed unexpectedly
21:10:53.747733 [info ] [MainThread]:
21:10:53.748040 [info ] [MainThread]: Done. PASS=0 WARN=0 ERROR=1 SKIP=0 TOTAL=1
21:10:53.748546 [debug] [MainThread]: Command `dbt snapshot` failed at 21:10:53.748466 after 85.55 seconds
21:10:53.748832 [debug] [MainThread]: Sending event: {'category': 'dbt', 'action': 'invocation', 'label': 'end', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7f53a3d12da0>, <snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7f535ba13f70>, <snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7f5360a78490>]}
21:10:53.749111 [debug] [MainThread]: Flushing usage events
21:14:59.000519 [debug] [MainThread]: Sending event: {'category': 'dbt', 'action': 'invocation', 'label': 'start', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7f33b5c71c00>, <snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7f33b48c3940>, <snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7f33b48c38b0>]}

Environment
- OS: Xubuntu 20.04
- Python: 3.10.13
- dbt: 1.5.4

Which database adapter are you using with dbt?
postgres
Additional Context
No response

It turns out the solution assumed above was not relevant. It is failing again today with the same error message with no further change to any code:
17:00:52.458833 [debug] [Thread-2 (]: Postgres adapter: Postgres error: SSL connection has been closed unexpectedly
17:00:52.459582 [debug] [Thread-2 (]: On snapshot.dbt_ppi.snapshot_ppi: ROLLBACK
17:00:52.460648 [debug] [Thread-2 (]: Failed to rollback 'snapshot.dbt_ppi.snapshot_ppi'
17:00:52.461531 [debug] [Thread-2 (]: Timing info for snapshot.dbt_ppi.snapshot_ppi (execute): 16:58:45.013617 => 17:00:52.461219
17:00:52.462079 [debug] [Thread-2 (]: On snapshot.dbt_ppi.snapshot_ppi: Close
17:00:52.464693 [debug] [Thread-2 (]: Database Error in snapshot snapshot_ppi (snapshots/snapshot_ppi.sql)
SSL connection has been closed unexpectedly
17:00:52.465309 [debug] [Thread-2 (]: Sending event: {'category': 'dbt', 'action': 'run_model', 'label': '55ee3e4c-9ead-4255-b045-db56de13cd6f', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7f311d14e8f0>]}
17:00:52.466386 [error] [Thread-2 (]: 1 of 1 ERROR snapshotting snapshots.snapshot_ppi ............................... [ERROR in 127.47s]
17:00:52.467235 [debug] [Thread-2 (]: Finished running node snapshot.dbt_ppi.snapshot_ppi
17:00:52.469002 [debug] [MainThread]: Using postgres connection "master"
17:00:52.469567 [debug] [MainThread]: On master: BEGIN
17:00:52.469982 [debug] [MainThread]: Opening a new connection, currently in state closed
17:01:01.046252 [debug] [MainThread]: SQL status: BEGIN in 9.0 seconds
17:01:01.047071 [debug] [MainThread]: On master: COMMIT
17:01:01.047387 [debug] [MainThread]: Using postgres connection "master"
17:01:01.047697 [debug] [MainThread]: On master: COMMIT
17:01:01.194217 [debug] [MainThread]: SQL status: COMMIT in 0.0 seconds
17:01:01.194864 [debug] [MainThread]: On master: Close
17:01:01.195894 [debug] [MainThread]: Connection 'master' was properly closed.
17:01:01.196327 [debug] [MainThread]: Connection 'snapshot.dbt_ppi.snapshot_ppi' was properly closed.
17:01:01.196787 [info ] [MainThread]:
17:01:01.197493 [info ] [MainThread]: Finished running 1 snapshot in 0 hours 2 minutes and 35.49 seconds (155.49s).
17:01:01.198421 [debug] [MainThread]: Command end result
17:01:01.215562 [info ] [MainThread]:
17:01:01.216033 [info ] [MainThread]: Completed with 1 error and 0 warnings:
17:01:01.216329 [info ] [MainThread]:
17:01:01.216628 [error] [MainThread]: Database Error in snapshot snapshot_ppi (snapshots/snapshot_ppi.sql)
17:01:01.216914 [error] [MainThread]:   SSL connection has been closed unexpectedly
17:01:01.217231 [info ] [MainThread]:
17:01:01.217549 [info ] [MainThread]: Done. PASS=0 WARN=0 ERROR=1 SKIP=0 TOTAL=1
17:01:01.218066 [debug] [MainThread]: Command dbt snapshot failed at 17:01:01.217981 after 156.55 seconds
17:01:01.218356 [debug] [MainThread]: Sending event: {'category': 'dbt', 'action': 'invocation', 'label': 'end', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7f316144cfd0>, <snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7f311cff42b0>, <snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7f311cff40a0>]}
17:01:01.218637 [debug] [MainThread]: Flushing usage events

Thanks for reporting this @rm-minus-r-star !
It sounds like this does not reproduce the issue for you after all?

Use single quotes for the unique_key column in a snapshot file.

If not, do you know how to reliably reproduce this issue? We'll need to be able to reproduce it in order to try fixing it.

apologies @dbeatty10, that's now correct. I've tried going back and running dbt snapshot with both single and double quotes, and I get the same failure mode no matter what now. I've re-opened the case with my host provider, on the hope that their logs will enlighten.
The only other thing I can offer is that snapshot worked flawlessly when each run was inserting entirely new data. This is the first occasion where I'm ingesting refreshed data -- one month's worth of new data, with revision on (I told) 4-7% of data already in DB. In the config, I've specified as composite column (defined in the SELECT statement) as the unique key, strategy is 'check', and then listed all columns that are not a component of the unique key in the check_cols. As mentioned, it apparently fluked that once (leading me to believe it was a quoting issue), but has failed perhaps 10 times now on a second tranche of refreshed/revised data.

Okay, let us know what you hear back from your provider. In the meantime, I'm going to update the description to add the following:

I've tried going back and running dbt snapshot with both single and double quotes, and I get the same failure mode no matter what now. I've re-opened the case with my host provider, on the hope that their logs will enlighten.


[formrecognizer] support for new fields returned by the service

[ ] form_type_confidence on RecognizedForm
[ ] model_id on RecognizedForm
[ ] form_type on RecognizedForm should use service value
[ ] add tests

folded into this issue https://github.com/azure/azure-sdk-for-python/issues/13458


Some language tweaks from our spreadsheet

Thank you! As we discussed, there were some bugs that created confusion on changes. New changes to be implemented in other PRs.


AMLR07 - glider restarting by itself

AMLR07 has been restarting by itself during simulations. We need to figure out why it is restarting. Probably a short or loose wire.
Glider support's response as of 9/4/24
The best guess I can give right now is there is some physical connection issue.  The evidence suggests that there is some momentary connection issue related to power.
I have seen this before in one of our in-house gliders and was able to narrow it down to the MCBH connector (green plug).  I could cause the "restart" by wiggling the green plug.  This also is supported by the first instance of it restarting was when it was brought outside for the FCP (possibly jostled) and the second time was after 3 hours of simulation (possible vibration of the pump and pitch motor running overtime).
So my best recommendation would be to closely inspect all connections.  Specifically the following:

White connectors between the main tray and science aft.  Check pins on both the male/female sides.
2nd connection starboard side on the aft of the main tray.  This is labeled lithium and connects the green plug to the board.
Wiggle the green plug itself when it is seated and the glider is powered on.
Check all connections at the BMS.
Check for any loose ground wires.

I wish I had a better solution at this point but this is a gremlin.

@flaimC  can you update this with what you have done with this glider please, so we have a record of it? Thank you

The issue with AMLR07 restarting of its own accord appears to have been inadvertently resolved.
Here are the steps of how the issue was resolved:

AMLR07 began restarting itself during a functional checkout prior to being deployed.
We disassembled AMLR07 and checked for bent/broken pins and that all plugs on the flight computer board were seated. We did not find anything.
We also tried several shorting plugs to ensure that the restarting issue was not due to a bad green plug. This did not resolve the issue.
I went through with a multimeter and checked for continuity on all of the power wires (red and black). I also checked for continuity from the main board to the molex connectors for the larger plugs. I did not find any connections that were not continuous or continuous connections that did not make sense. I found one wire that I could not find the corresponding end of, but I suspect it is the female side of the shorting plug. I again checked that all connections on the main board were properly seated and plugged in.
I then simulated AMLR07 outside and did not find it to restart.
Additionally, we simulated AMLR07 in the ballast tank with a narrow shadowgraph for 4 days with no restarts.

I think I inadvertently fixed a loose connection while probing plugs and wires with the multimeter and this fixed the restarting issue.
My conclusion is that the restarting was due to a loose power wire connection going to the flight computer, causing the glider to randomly restart. To further conclude that AMLR07 is deployment-ready, I would like to deploy it off of San Diego for a short mission to see if it resets. This deployment can also be a shadowgraph test.


Offload to main.py

Hello @weibullguy! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file src/ramstk/__main__.py:

Line 121:5: E265 block comment should start with '# '
Line 127:5: E265 block comment should start with '# '
Line 127:80: E501 line too long (81 > 79 characters)
Line 129:5: E265 block comment should start with '# '
Line 134:5: E265 block comment should start with '# '

In the file src/ramstk/db/common.py:

Line 997:80: E501 line too long (83 > 79 characters)
Line 1028:80: E501 line too long (83 > 79 characters)
Line 1055:80: E501 line too long (82 > 79 characters)
Line 1056:80: E501 line too long (88 > 79 characters)
Line 1080:80: E501 line too long (83 > 79 characters)
Line 1122:80: E501 line too long (83 > 79 characters)
Line 1168:80: E501 line too long (83 > 79 characters)
Line 1204:80: E501 line too long (83 > 79 characters)
Line 1235:80: E501 line too long (83 > 79 characters)
Line 1265:80: E501 line too long (83 > 79 characters)
Line 1288:80: E501 line too long (83 > 79 characters)
Line 1323:80: E501 line too long (83 > 79 characters)


Vosk library causes crash on release build

Versions:

vosk_flutter Version:  ^0.3.48
Flutter 3.11.0-12.0.pre.25
Framework • revision 23fe4fca59
Engine • revision fc6df9512a
Tools • Dart 3.1.0 (build 3.1.0-136.0.dev) • DevTools 2.23.1

Build Platform: Android, Android Version 10
On local build there is no problem. I can download Speak recognition model and use as expected with no issue like.
Code is like following:
_modelLoader
        .loadModelsList()
        .then((modelsList) =>
        modelsList.firstWhere((model) => model.name == modelName))
        .then((modelDescription) =>
        _modelLoader.loadFromNetwork(modelDescription.url)) // load model
        .then(
            (modelPath) =>
            _vosk.createModel(modelPath)) // create model object
           ...

When I get release build and install APK to same android device, execution of same code cause following crash. After crash once when I open app about second later app crash with same error.
Fatal Exception: java.lang.UnsatisfiedLinkError: Can't obtain peer field ID for class com.sun.jna.Pointer
       at com.sun.jna.Native.initIDs(SourceFile)
       at com.sun.jna.Native.<clinit>(:333)
       at com.sun.jna.Native.H()
       at org.vosk.LibVosk.<clinit>(:4)
       at org.vosk.LibVosk.vosk_model_new(SourceFile)
       at org.vosk.Model.<init>()
       at l9.i.h(:2)
       at l9.i.b()
       at l9.f.call(:2)
       at l9.e.g()
       at l9.e.b()
       at l9.b.run(:8)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
       at java.lang.Thread.run(Thread.java:919)

Android Manifest Permissions:
...
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
...

Waiting for response.

Hi, @EnsarErayAkkaya! Please take a look at https://github.com/alphacep/vosk-flutter#android