yanix v0.12.0 (/tmp/wasmtime/crates/wasi-common/yanix) fails to compile on armv7-unknown-linux-gnueabihf

git clone the repo, cd wasmtime/crates/wasi-common/yanix and execute cargo build fails with this beauty:
crates/wasi-common/yanix $ cargo build
    Updating crates.io index
  Downloaded cfg-if v0.1.10
  Downloaded thiserror v1.0.11
  Downloaded libc v0.2.67
  Downloaded log v0.4.8
  Downloaded bitflags v1.2.1
  Downloaded thiserror-impl v1.0.11
  Downloaded proc-macro2 v1.0.8
  Downloaded quote v1.0.2
  Downloaded unicode-xid v0.2.0
  Downloaded syn v1.0.15
   Compiling proc-macro2 v1.0.8
   Compiling unicode-xid v0.2.0
   Compiling syn v1.0.15
   Compiling bitflags v1.2.1
   Compiling libc v0.2.67
   Compiling log v0.4.8
   Compiling cfg-if v0.1.10
   Compiling quote v1.0.2
   Compiling thiserror-impl v1.0.11
   Compiling thiserror v1.0.11
   Compiling yanix v0.12.0 (/home/tim/wasmtime/crates/wasi-common/yanix)
error[E0308]: try expression alternatives have incompatible types
   --> crates/wasi-common/yanix/src/file.rs:247:23
    |
247 |     let offset: i64 = Errno::from_result(libc::lseek(fd, 0, libc::SEEK_CUR))?;
    |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |                       |
    |                       expected `i64`, found `i32`
    |                       help: you can convert an `i32` to `i64`: `Errno::from_result(libc::lseek(fd, 0, libc::SEEK_CUR))?.into()`

error[E0277]: the trait bound `i32: std::convert::From<i64>` is not satisfied
  --> crates/wasi-common/yanix/src/sys/linux/mod.rs:10:17
   |
10 |         Ok(Self(loc))
   |                 ^^^ the trait `std::convert::From<i64>` is not implemented for `i32`
   |
   = help: the following implementations were found:
             <i32 as std::convert::From<bool>>
             <i32 as std::convert::From<i16>>
             <i32 as std::convert::From<i8>>
             <i32 as std::convert::From<std::num::NonZeroI32>>
           and 2 others
   = note: required because of the requirements on the impl of `std::convert::Into<i32>` for `i64`

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0277, E0308.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `yanix`.

aarch64 seems fine.
rustc is v1.41.1 with llvm-9

same compile with verbose switch:
cargo build --verbose
       Fresh unicode-xid v0.2.0
       Fresh cfg-if v0.1.10
       Fresh proc-macro2 v1.0.8
       Fresh quote v1.0.2
       Fresh libc v0.2.67
       Fresh log v0.4.8
       Fresh bitflags v1.2.1
       Fresh syn v1.0.15
       Fresh thiserror-impl v1.0.11
       Fresh thiserror v1.0.11
   Compiling yanix v0.12.0 (/home/tim/wasmtime/crates/wasi-common/yanix)
     Running `rustc --edition=2018 --crate-name yanix crates/wasi-common/yanix/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 -C metadata=0f2083b39d9868a9 -C extra-filename=-0f2083b39d9868a9 --out-dir /home/tim/wasmtime/target/debug/deps -C incremental=/home/tim/wasmtime/target/debug/incremental -L dependency=/home/tim/wasmtime/target/debug/deps --extern bitflags=/home/tim/wasmtime/target/debug/deps/libbitflags-2f0d650362f6563c.rmeta --extern cfg_if=/home/tim/wasmtime/target/debug/deps/libcfg_if-73270e7e135e30d3.rmeta --extern libc=/home/tim/wasmtime/target/debug/deps/liblibc-e4e1be7f8b2f2e45.rmeta --extern log=/home/tim/wasmtime/target/debug/deps/liblog-e99f890746485ea4.rmeta --extern thiserror=/home/tim/wasmtime/target/debug/deps/libthiserror-2371134c478ad8d8.rmeta`
error[E0308]: try expression alternatives have incompatible types
   --> crates/wasi-common/yanix/src/file.rs:247:23
    |
247 |     let offset: i64 = Errno::from_result(libc::lseek(fd, 0, libc::SEEK_CUR))?;
    |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |                       |
    |                       expected `i64`, found `i32`
    |                       help: you can convert an `i32` to `i64`: `Errno::from_result(libc::lseek(fd, 0, libc::SEEK_CUR))?.into()`

error[E0277]: the trait bound `i32: std::convert::From<i64>` is not satisfied
  --> crates/wasi-common/yanix/src/sys/linux/mod.rs:10:17
   |
10 |         Ok(Self(loc))
   |                 ^^^ the trait `std::convert::From<i64>` is not implemented for `i32`
   |
   = help: the following implementations were found:
             <i32 as std::convert::From<bool>>
             <i32 as std::convert::From<i16>>
             <i32 as std::convert::From<i8>>
             <i32 as std::convert::From<std::num::NonZeroI32>>
           and 2 others
   = note: required because of the requirements on the impl of `std::convert::Into<i32>` for `i64`

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0277, E0308.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `yanix`.

Caused by:
  process didn't exit successfully: `rustc --edition=2018 --crate-name yanix crates/wasi-common/yanix/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 -C metadata=0f2083b39d9868a9 -C extra-filename=-0f2083b39d9868a9 --out-dir /home/tim/wasmtime/target/debug/deps -C incremental=/home/tim/wasmtime/target/debug/incremental -L dependency=/home/tim/wasmtime/target/debug/deps --extern bitflags=/home/tim/wasmtime/target/debug/deps/libbitflags-2f0d650362f6563c.rmeta --extern cfg_if=/home/tim/wasmtime/target/debug/deps/libcfg_if-73270e7e135e30d3.rmeta --extern libc=/home/tim/wasmtime/target/debug/deps/liblibc-e4e1be7f8b2f2e45.rmeta --extern log=/home/tim/wasmtime/target/debug/deps/liblog-e99f890746485ea4.rmeta --extern thiserror=/home/tim/wasmtime/target/debug/deps/libthiserror-2371134c478ad8d8.rmeta` (exit code: 1)

proposed fix for the E0308 error:
From 4823bf2d2e50275787c44695a9fcb24140897ced Mon Sep 17 00:00:00 2001
From: stefson<EMAIL_ADDRESS>Date: Wed, 4 Mar 2020 09:42:12 +0100
Subject: [PATCH] wasi-common/yanix: fix armv7 compile

---
 crates/wasi-common/yanix/src/file.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crates/wasi-common/yanix/src/file.rs b/crates/wasi-common/yanix/src/file.rs
index 1124dcd95..cd6d5999a 100644
--- a/crates/wasi-common/yanix/src/file.rs
+++ b/crates/wasi-common/yanix/src/file.rs
@@ -244,6 +244,6 @@ pub unsafe fn fionread(fd: RawFd) -> Result<u32> {
 /// This function is unsafe because it operates on a raw file descriptor.
 /// It's provided, because std::io::Seek requires a mutable borrow.
 pub unsafe fn tell(fd: RawFd) -> Result<u64> {
-    let offset: i64 = Errno::from_result(libc::lseek(fd, 0, libc::SEEK_CUR))?;
+    let offset: i64 = Errno::from_result(libc::lseek(fd, 0, libc::SEEK_CUR))?.into();
     Ok(offset.try_into()?)
 }

okay, that very error already is underway to get fixed in https://github.com/bytecodealliance/wasmtime/pull/1226

Hey @stefson, thanks for the report. Could you do me a favour actually, and rebase onto #1226 and see if it indeed fixes the error (unless you've already done it of course)?

ok, so I git cloned your fork and did git checkout yanix-error-cleanup, followed by cd crates/wasi-common/yanix and cargo build. It turns out that with the commits you added plus my patch from above, there's a new error now:
cargo build --target armv7-unknown-linux-gnueabihf
   Compiling yanix v0.12.0 (/tmp/wasmtime/crates/wasi-common/yanix)
error[E0433]: failed to resolve: use of undeclared type or module `Errno`
   --> crates/wasi-common/yanix/src/file.rs:247:23
    |
247 |     let offset: i64 = Errno::from_result(libc::lseek(fd, 0, libc::SEEK_CUR))?.into();
    |                       ^^^^^ use of undeclared type or module `Errno`

error[E0277]: the trait bound `i32: std::convert::From<i64>` is not satisfied
  --> crates/wasi-common/yanix/src/sys/linux/mod.rs:10:17
   |
10 |         Ok(Self(loc))
   |                 ^^^ the trait `std::convert::From<i64>` is not implemented for `i32`
   |
   = help: the following implementations were found:
             <i32 as std::convert::From<bool>>
             <i32 as std::convert::From<i16>>
             <i32 as std::convert::From<i8>>
             <i32 as std::convert::From<std::num::NonZeroI32>>
           and 2 others
   = note: required because of the requirements on the impl of `std::convert::Into<i32>` for `i64`

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0277, E0433.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `yanix`.

and I think that's due to you changing from Errno to Error in that line, right?

Yep, looks like it! So the general gist now is to re-use std::io::Error to spawn and wrap raw OS errno values instead of maintaining yet another mapping between errno values and some enum type. Anyhow, thanks for looking into it! After we land #1226, I'll be happy to help you out in weeding out any errors that might have left over.

ok, sweet, so here's the rebased patch for your branch, please simply add it if it's to your liking:
--- a/crates/wasi-common/yanix/src/file.rs
+++ b/crates/wasi-common/yanix/src/file.rs
@@ -244,6 +244,6 @@ pub unsafe fn fionread(fd: RawFd) -> Result<u32> {
 /// This function is unsafe because it operates on a raw file descriptor.
 /// It's provided, because std::io::Seek requires a mutable borrow.
 pub unsafe fn tell(fd: RawFd) -> Result<u64> {
-    let offset: i64 = Error::from_result(libc::lseek(fd, 0, libc::SEEK_CUR))?;
+    let offset: i64 = Error::from_result(libc::lseek(fd, 0, libc::SEEK_CUR))?.into();
     Ok(offset.try_into()?)
 }

and thank you for the offer, I'm totally new to rust and might need a bit of help with the other error. The first one was simple, since the compiler error message told me exactly what to do.

No probs, perfect opportunity to learn some Rust then!
Actually, I'd prefer if you submitted a separate PR either with #1226 as base, or waited until that one lands (which should be sometime today/tomorrow). This way we'd have contexts separated which should aid the readability of what's going on in wasmtime :-)

with the rebased source tree, and when #1231 is applied, the second error remains:
error[E0277]: the trait bound `i32: std::convert::From<i64>` is not satisfied
  --> crates/wasi-common/yanix/src/sys/linux/mod.rs:10:17
   |
10 |         Ok(Self(loc))
   |                 ^^^ the trait `std::convert::From<i64>` is not implemented for `i32`
   |
   = help: the following implementations were found:
             <i32 as std::convert::From<bool>>
             <i32 as std::convert::From<i16>>
             <i32 as std::convert::From<i8>>
             <i32 as std::convert::From<std::num::NonZeroI32>>
           and 2 others
   = note: required because of the requirements on the impl of `std::convert::Into<i32>` for `i64`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.

I tried to switch to from_raw(loc: i32) in that line, since i64 seems to be wrong, but that doesn't seem to solve anything :/

still struggeling, five new regressions since https://github.com/bytecodealliance/wasmtime/commit/061390ee1b1085a2191019d2219da730ec62485f
/tmp/wasmtime/crates/wasi-common/yanix $ cargo build --target armv7-unknown-linux-gnueabihf
   Compiling libc v0.2.67
   Compiling cfg-if v0.1.10
   Compiling bitflags v1.2.1
   Compiling log v0.4.8
   Compiling filetime v0.2.8
   Compiling yanix v0.12.0 (/tmp/wasmtime/crates/wasi-common/yanix)
error[E0308]: mismatched types
  --> crates/wasi-common/yanix/src/filetime.rs:18:29
   |
18 |                     tv_sec: ft.seconds(),
   |                             ^^^^^^^^^^^^ expected `i32`, found `i64`

error[E0308]: mismatched types
  --> crates/wasi-common/yanix/src/filetime.rs:19:30
   |
19 |                     tv_nsec: i64::from(ft.nanoseconds()),
   |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `i32`, found `i64`

error[E0308]: mismatched types
  --> crates/wasi-common/yanix/src/filetime.rs:72:22
   |
72 |             tv_nsec: UTIME_NOW,
   |                      ^^^^^^^^^ expected `i32`, found `i64`

error[E0308]: mismatched types
  --> crates/wasi-common/yanix/src/filetime.rs:76:22
   |
76 |             tv_nsec: UTIME_OMIT,
   |                      ^^^^^^^^^^ expected `i32`, found `i64`

error[E0277]: the trait bound `i32: std::convert::From<i64>` is not satisfied
  --> crates/wasi-common/yanix/src/sys/linux/mod.rs:13:17
   |
13 |         Ok(Self(loc))
   |                 ^^^ the trait `std::convert::From<i64>` is not implemented for `i32`
   |
   = help: the following implementations were found:
             <i32 as std::convert::From<bool>>
             <i32 as std::convert::From<i16>>
             <i32 as std::convert::From<i8>>
             <i32 as std::convert::From<std::num::NonZeroI32>>
           and 2 others
   = note: required because of the requirements on the impl of `std::convert::Into<i32>` for `i64`

error[E0308]: mismatched types
  --> crates/wasi-common/yanix/src/sys/linux/utimesat.rs:39:17
   |
39 |         tv_sec: ft.seconds(),
   |                 ^^^^^^^^^^^^ expected `i32`, found `i64`

error: aborting due to 6 previous errors

Some errors have detailed explanations: E0277, E0308.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `yanix`.

To learn more, run the command again with --verbose.

@kubkon if you happen to commit further changes to yanix, can you please do a testrun with cargo build --target armv7-unknown-linux-gnueabihf before you push the changes, to prevent further breakage?

@stefson OK, it's good that these have surfaced now. It looks like we might have to make certain targeted adjustments for armv7-unknown-linux-gnueabihf. Is this a 32bit architecture?

yes, it is 32bit, with hardfloat.
64bit is aarch64-unknown-linux-gnu (passes fine)

Should now be fixed with #1269 :-)

That's right, the yanix crate does now compile just fine. Thank you for helping with this! :+1:


Windows 10 - After installation, it does not prompt for Desktop App Server installation

Description
Versions older than 3.5.1-1 do not offer to install the JupyterLabDesktopAppServer, so the app is unable to start. This behavior is observed on Win10.
Reproduce

Remove older JupyterLab, as well as JupyterLabDesktopAppServer;
Download any version after 3.5.1-1 and use the provided installer to install it;
Start JupyterLab. An error is displayed and the app is not starting or working. It does not offer to install the JupyterLabDesktopAppServer.

Expected behavior
The app crashes at first start, without offering to install the JupyterLabDesktopAppServer.
Context
OS: Windows 10
JupyterLab Version: any above 3.5.1-1
Installer: exe

Per https://github.com/jupyterlab/jupyterlab-desktop/issues/677#issuecomment-1626877029, @mbektas reports that the Desktop app server installer is being removed with version 4.0.2-1.


UI of a Payment Tracker app

Description
UI of a payments tracker app having onboarding screen, home screen, smooth navigation and cool charts to graphically project usage data.
Screenshots

Additional information
As GSSOC '22 contributor, I myself want to work on this issue. Hoping to get assigned!

Have you coded this or yet to be coded?

Completed couple of days back, was waiting to get assigned :)

@naveeramesh check!


No x86_64-w64-mingw32-windres.exe

In /mingw64/bin there is no x86_64-w64-mingw32-windres.exe but there is a windres.exe. When I manually copy windres.exe to x86_64-w64-mingw32-windres.exe everything works for now.
Is there a special reason why this is not done automatically during installation (just like gcc.exe, g++.exe, etc, etc)?

Prefixed executables usually creating for cross tools

Yes, cross compiling is exactly my use case!
All the gcc exe's on MSYS2 (22 in total in my /mingw64/bin/) are available with and without the architecture prefix, apart from windres.exe. That is weird and inconsistent.
I use MSYS2-64 to build both a 32-bit as well as a 64 bit version of my project like https://github.com/ffes/indentbyfold and https://github.com/ffes/nppsnippets. I use the prefix to be sure I always use the right architecture, no matter which platform I compile on, be it MSYS, Cygwin and even Linux (for CI integration).
So I want explicitly said which architecture to use and that is not possible with MSYS2 because there is no x86_64-w64-mingw32-windres.exe.

Indeed the problem still persists. Since obviously there doesn't seem to be any interest whatsoever in fixing this issue my suggestion for a workaround is to manually create a copy of the respective files and name them i686-w64-mingw32-windres and x86_64-w64-mingw32-windres respectively.

Absolutely still an issue. The Linux systems don't have windres but do have it prefixed, while the Windows systems on MSYS2 don't have the prefixed one but do have windres...

The issue should be reopened. Note that the error does not only affect windres but also some other programs that should be prefixed. The error appears on i686-w64-mingw32 and x86_64-w64-mingw32. The following is my work-around for the bug, where the $MSYSTEM_PREFIX variable is set by MSYS2 and correspond the environment prefix, and $HOST is the user-defined compilation triplet. If symlinks have been enabled, the work-around is costless, otherwise it costs a copy.
if [ ! -e "${MSYSTEM_PREFIX}/bin/${HOST}-windres.exe" ]; then
    ln -s "${MSYSTEM_PREFIX}"/bin/windres.exe "${MSYSTEM_PREFIX}/bin/${HOST}-windres.exe"
fi
if [ ! -e "${MSYSTEM_PREFIX}/bin/${HOST}-as.exe" ]; then
    ln -s "${MSYSTEM_PREFIX}"/bin/as.exe "${MSYSTEM_PREFIX}/bin/${HOST}-as.exe"
fi

@MisterDA prefixed binaries are used only for crosscompiling. We builds native, so this is not the issue

What if I want to use MSYS2 to cross-compile?
For instance, on Windows, the OCaml compiler needs a Cygwin/MSYS2 environment to be build, even though the environment is not required at runtime.

Msys2 environment allow to build mingw applications natively. If you want cross-compile then use Msys-mingw crosscompilers

In my opinion we should have prefixed windres as well. It solves compatibility issues regarding switching between Windows and Linux environments. It also is more consistent with naming of other tools - we have prefixed MinGW gcc, even though it can build binaries for our native platform.


remove space in front of ' latest model'

causes the next tutorial to not find the model name

@joshknutson : Thanks for your contribution! The author, @HeidiSteen, has been notified to review your proposed change.

#sign-off  Looks good, thank you for the contribution!


Kubernetes: AWS Ingress Controller readiness gates show up as errors on all pods.

Expected Behavior
We currently use the AWS Load Balancer Controller to manage pod mappings to the AWS Application Load Balancer. As part of this setup, the AWS LB Controller manages a custom condition on our pods, which looks like:
status:
  conditions:
    - lastProbeTime: null
      lastTransitionTime: null
      message: Target registration is in progress
      reason: Elb.RegistrationInProgress
      status: 'True'
      type: target-health.elbv2.k8s.aws/k8s-ssoproxy-ssoproxy-ff3a93a63d

This condition causes the Kubernetes plugin to report an error with the pods - though no actual error exists - this is expected behavior.

The K8S plugin should not report custom conditions as errors by default.
Current Behavior
The K8S plugin reports some custom conditions as errors by default.

I think this error mapper https://github.com/backstage/backstage/blob/master/plugins/kubernetes/src/error-detection/pods.ts#L23 needs a more robust implementation, it's very basic ATM.

I am having a similar issue.  Using LB controller 2.3
It seems that containers become unregistered, maybe because of a restart or a host gets terminated and the pod gets moved to the new host.
Result of the following command:
kubectl get pod podname -o yaml -n namespace | grep -B7 'type: target-health'
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: null
    message: Target registration is in progress
    reason: Elb.RegistrationInProgress
    status: "True"
    type: target-health.elbv2.k8s.aws/k8s-podname-f9dc5ec48e

The pod eventually registers but this status stays the same.
In another case, I manually added the container IP to the target group to bring the app back up. (this is a production system)
I have 200 applications on the system and I see this happening every 4 to 6 hours for different apps. If left alone most of them fix themselves after 5 or 10 minutes.
Even hours later it still says registration in progress.
My environment:
EKS - kubernetes version 1.19
Rancher - version 2.6.1
Namespace has label:
labels:
elbv2.k8s.aws/pod-readiness-gate-inject: enabled
AWS LB controller 2.3

I am running into this right now as well. Looks like no progress has been made.


Osx tray

@HEskandari replacement PR

i got it building on CI, but 3 failing tests on mac. https://ci.appveyor.com/project/SimonCropp/diffengine/builds/35930418/job/q3vhl95r7uhbirhe/tests i will try to debug them tomorrow

@HEskandari actually we seem to have some build errors
/Users/appveyor/projects/diffengine/src/DiffEngineTray.Mac/DiffEngineTray.Mac.csproj(123,5): error MSB4019:
The imported project "/usr/local/share/dotnet/sdk/5.0.100-preview.5.20279.10/Xamarin/Mac/Xamarin.Mac.CSharp.targets"
was not found. Confirm that the expression in the Import declaration
"/usr/local/share/dotnet/sdk/5.0.100-preview.5.20279.10//Xamarin/Mac/Xamarin.Mac.CSharp.targets" is correct, and that the file exists on disk.

any ideas on how to get xamarin working on appveyor

@SimonCropp hmmm why is it using .NET 5 SDK?

According to this, that is the latest version of the .NET installed on their macos agents. I think we may need to lock it down to 3.1 (e.g. .NET Core SDK 3.1.300) with a global.json file?

any plans to release the osx one, or will the tool remain windows only?

@kaylumah i would really like to. unfortunately at the moment i dont have a mac to develop on. so as u can imagine that makes building an maintaining this difficult. i plan to make my next dev machine a max, but that wont happen for a few months
in the short term, if u r using rider you can use https://plugins.jetbrains.com/plugin/17240-verify-support

Oh yeah, I can imagine.
Loving your library more and more, so if there is anything I can do to help please let me know

The cross-platform library I was using for the tray app had some issues that had to be fixed first. I'll give this another go in a couple of weeks and see if it can be done now.

For reference, here's the repo I'm working off of. Got some success with the latest of the UI toolkit on the mac. Needs more testing, add packaging for mac and windows and add some configurations to allow supporting .NET and Golang solutions.

@HEskandari thats awesome

@SimonCropp @kaylumah I have an alpha release out available here. Needs some minor work but the bulk of it is working on my mac (Ventura). Let me know if you have an issue. Note that I don't have a cert to sign the app so you may need allow it to run.

@HEskandari could it be deployed as a dotnet tool ?

The output of the app is two things:

A binary file that you can run on mac (via terminal) which will launch the tray app.
A wrapper around the binary file to turn it into a ".app" Application (which is some added meta-data, icons, etc.)

If you want to install it as an Application in MacOs, you want the .app format, but theoretically, the binary is a mac-native binary so can be invoked by anything. You probably know that you can extract the binary by opening the '.app' file as a folder (via terminal or right-click -> "Show Package Content" and then copying the binary from the MacOS folder).

@HEskandari do u want your diff tray to be part of the main verify project? ie part of the DNF

@SimonCropp ultimately yes, I think. There are a few things I haven't coded yet (like having more than 20 diff files). I need to figure out packaging and do a bit more testing. You may want to keep the DiffEngine tray app for some time for this to become more mature.


Enable always sorting when using pager

because queries are not currently deterministic

@t8y8 Not sure what you mean?  It shouldn't miss the case where someone passes in the RequestsOptions because the check for sort = empty set is checked regardless of whether they pass in the requests options or not

We talked about this offline. The client library does not feel like the correct place to fix this. Let's talk more but I think we might want to revert this.

This is a temporary fix until the server is fixed so that the Pager is usable by default.  Once we release the fix, we can remove this.

The change itself looks fine but if we put in a default sort order for all queries it might not always be on name for every noun. Then Pager would have a weird behavior

I don't follow what you mean here.  Once the default sort is in, we'll delete this change.  Would you rather not have this temporary workaround in the meantime?

Nope. That sounds good although it might be a slight change in behavior for people

Sorry ... I didn't see your comment after my first comment and before my second comment. :)


nested proxyjump possibly broken

Consider an SSH config like:
Host first
  HostName xx.xx.xx.xx
  identityfile C:\path\to\first\idkey
  User ubuntu
Host second
  HostName compute-permanent-node-xxx
  User ubuntu
  identityfile C:\path\to\second\idkey
  ProxyJump first
Host te
  HostName localhost
  Port 11111
  User root
  identityfile C:\path\to\te\idkey
  ProxyJump second

In my testing,

ssh first, ssh second, ssh te all work on cmd.exe
in code editor's SSH, I can connect to first and second, but not te, which gives this:

[Info  - 11:01:10.769] Resolving ssh remote authority 'ssh-remote+te' (attemp #1)
[Error  - 11:01:10.797] Couldn't get identities from OpenSSH agent
Error: Failed to connect to agent
	at Socket.r (c:\Users\a\AppData\Local\Programs\cursor\resources\app\extensions\open-remote-ssh\dist\main.js:1:115762)
	at Socket.emit (node:events:513:28)
	at Socket.emit (node:domain:489:12)
	at emitErrorNT (node:internal/streams/destroy:157:8)
	at emitErrorCloseNT (node:internal/streams/destroy:122:3)
	at process.processTicksAndRejections (node:internal/process/task_queues:83:21)
[Trace  - 11:01:10.797] Identity keys:
C:\path\to\te\idkey ecdsa-sha2-nistp256
[Error  - 11:01:10.800] Couldn't get identities from OpenSSH agent
Error: Failed to connect to agent
	at Socket.r (c:\Users\a\AppData\Local\Programs\cursor\resources\app\extensions\open-remote-ssh\dist\main.js:1:115762)
	at Socket.emit (node:events:513:28)
	at Socket.emit (node:domain:489:12)
	at emitErrorNT (node:internal/streams/destroy:157:8)
	at emitErrorCloseNT (node:internal/streams/destroy:122:3)
	at process.processTicksAndRejections (node:internal/process/task_queues:83:21)
[Trace  - 11:01:10.800] Identity keys:
C:\path\to\te\idkey ecdsa-sha2-nistp256
[Error  - 11:01:11.823] Error resolving authority
Error: getaddrinfo ENOTFOUND compute-permanent-node-761
	at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:109:26)

NB: not sure if this is the correct place to ask about this -- I'm using cursor, and saw extensions\open-remote-ssh in the logs, so I assume this is the extension being used, but I may be wrong (or it may be an outdated version of the extension)

i too am facing the same issue with this extension on cursor.sh IDE

I can confirm that nested ProxyJump has issues. In my case I need to go through two jump hosts to get to the proper node and then connect to a ssh inside container that uses a non-standard port.
ssh configuration:
Host rust
  HostName <IP_ADDRESS>
  Port 2200
  ProxyJump my.example.org:22,[2a03:daed:beef:abcd::3]:22

result when using vscodium:
[Info  - 07:50:56.130] Resolving ssh remote authority 'ssh-remote+rust' (attemp #1)
[Trace  - 07:50:56.143] Identity keys:
/home/msivak/.ssh/id_rsa ssh-rsa SHA256:JvoNAe7z4/8vqDttsSCVfV12IQPqpsiUsXd3qr9X+s4=
<EMAIL_ADDRESS>ssh-rsa SHA256:245v618kjDGWVxuqhEwMhbaW9Zxfndo2fxS+qgv87Os=
[Trace  - 07:50:56.145] Identity keys:
/home/msivak/.ssh/id_rsa ssh-rsa SHA256:JvoNAe7z4/8vqDttsSCVfV12IQPqpsiUsXd3qr9X+s4=
<EMAIL_ADDRESS>ssh-rsa SHA256:245v618kjDGWVxuqhEwMhbaW9Zxfndo2fxS+qgv87Os=
[Info  - 07:50:56.266] Trying no-auth authentication
[Info  - 07:50:56.322] Trying publickey authentication: /home/msivak/.ssh/id_rsa ssh-rsa SHA256:JvoNAe7z4/8vqDttsSCVfV12IQPqpsiUsXd3qr9X+s4=
[Error  - 07:50:57.269] Error resolving authority
Error: (SSH) Channel open failure: Name or service not known
	at s (/home/msivak/.var/app/com.vscodium.codium/data/codium/extensions/jeanp413.open-remote-ssh-0.0.45-universal/out/extension.js:1:392464)
	at CHANNEL_OPEN_FAILURE (/home/msivak/.var/app/com.vscodium.codium/data/codium/extensions/jeanp413.open-remote-ssh-0.0.45-universal/out/extension.js:1:152221)
	at 92 (/home/msivak/.var/app/com.vscodium.codium/data/codium/extensions/jeanp413.open-remote-ssh-0.0.45-universal/out/extension.js:1:317008)
	at e.exports.M (/home/msivak/.var/app/com.vscodium.codium/data/codium/extensions/jeanp413.open-remote-ssh-0.0.45-universal/out/extension.js:1:178401)
	at H.decrypt (/home/msivak/.var/app/com.vscodium.codium/data/codium/extensions/jeanp413.open-remote-ssh-0.0.45-universal/out/extension.js:1:274737)
	at e.exports.F [as _parse] (/home/msivak/.var/app/com.vscodium.codium/data/codium/extensions/jeanp413.open-remote-ssh-0.0.45-universal/out/extension.js:1:177925)
	at e.exports.parse (/home/msivak/.var/app/com.vscodium.codium/data/codium/extensions/jeanp413.open-remote-ssh-0.0.45-universal/out/extension.js:1:182312)
	at Socket.<anonymous> (/home/msivak/.var/app/com.vscodium.codium/data/codium/extensions/jeanp413.open-remote-ssh-0.0.45-universal/out/extension.js:1:154578)
	at Socket.emit (node:events:517:28)
	at Socket.emit (node:domain:489:12)
	at addChunk (node:internal/streams/readable:335:12)
	at readableAddChunk (node:internal/streams/readable:308:9)
	at Readable.push (node:internal/streams/readable:245:10)
	at TCP.onStreamRead (node:internal/stream_base_commons:190:23)

result when using ssh:
$ ssh rust
Last login: Tue Jun  4 08:52:52 2024 from <IP_ADDRESS>
⬢[msivak@toolbox ~]$


Example URLs not working

On readme.md you have:
See the example postgis and example sqlite.
However neither of these 2 links are accessible (Im getting 404s)
https://github.com/caioariede/django-location-field/blob/master/example_sqlite
https://github.com/caioariede/django-location-field/blob/master/example_postgis
Thanks

Thanks for pointing it out.
Those examples were removed since all required configurations are in the README itself.


[Question] Does aks-engine support something akin to AKS's --nat-gateway-managed-outbound-ip-count?

Hi!
When provisioning an AKS Cluster, one can specify the --nat-gateway-managed-outbound-ip-count which will provision the cluster with multiple outbound public IP addresses by replacing the Load Balancer with a NAT Gateway. link link

Is this also possible with the aks-engine? I can't seem to find anything similar in the networking parts of the aks-engine docs.
Is there a schema somewhere for the api-model.json?

@razvangoga thanks for reaching out. Managed NAT gateway is a standard SKU load balancer feature.
--nat-gateway-managed-outbound-ip-count
NAT gateway managed outbound IP count.
Desired number of managed outbound IPs for NAT gateway outbound connection. Please specify a value in the range of [1, 16]. Valid for Standard SKU load balancer cluster with managedNATGateway outbound type only.
Azure Stack Hub only supports basic SKU load balancer. As a result, this is not possible with aks-engine. Please see Hub networking documentation for more information.


Add PermissionService for more fine grained access control

Description
Add simple Service and Repository for Permissions.
Jira Issue:
Type of change

[ ] Bug fix
[x] New feature
[ ] Other

Instructions for testing
Please describe tests how this change or new feature can be tested.
Checklist:

[x] I have written new tests (if applicable)
[x] I have ran the tests myself (if applicable)
[ ] I have made necessary changes to the documentation, link to confluence
or other location:

Other relevant info
Please describe here if there is e.g. some requirements for this change or
other info that the tester/user needs to know.

Replaced by https://github.com/City-of-Helsinki/haitaton-backend/pull/164, follow branch naming standard of HAI-*


Star or "favorite" an indicator

If you need to highlight a particular indicator for quick identification, a way to highlight the row in the tables/indicators page. Use .glyphicon-star .glyphicon-star-empty to indicate this.

Added in last update.


Deserialization Options is wrong

Based on our Readme, if we want to use decode JSON, we can pass deserialization options following this way:
#To have Atom keys
config :tentacat, :deserialization_options, [labels: :atoms]

But seems like this one is outdated or just a typo with the current version of exjsx (4.0.0)
https://github.com/talentdeficit/exjsx#decodejson-opts
We have to pass a tuple, not a keyword list. cc @edgurgel please take a look at it if you have time, I will create a PR to fix this one.

hmm, seems like I edited something and make it worked in the wrong way since now everything is normal with me. Thanks @edgurgel , I will close this issue


Fix integration test failures

Description
Fixes test failures of regular integration test
Checklist

[ ] PR is rebased to/aimed at branch develop
[ ] PR follows Contributing Guide
[ ] Added tests (if necessary)
[ ] Extended README/Documentation (if necessary)
[ ] Adjusted versions of image and Helm chart in Chart.yaml (if necessary)

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (6bd96ea) 96.58% compared to head (d27e809) 96.58%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #1331   +/-   ##
========================================
  Coverage    96.58%   96.58%
========================================
  Files           23       23
  Lines         1319     1319
========================================
  Hits          1274     1274
  Misses          45       45

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Backport add-onbeforeunload-support

Backports the onbeforeunload support to 0.5.x

CLA is valid!

:+1:

:shipit:


Adding newest OpenMP documentation

What does this PR do?
Add Resource(s)
For resources
Description
This PR adds the newest OpenMP specification (5.0)
Why is this valuable (or not)
It's valuable because every new release, new commands could be added and some old ones could be deprecated. So it's important to use the newest version
How do we know it's really free?
I'ts avaliable on the own creator web site
For book lists, is it a book?
It's a documentation
Checklist:

[X] Not a duplicate
[X] Included author(s) if appropriate
[X] Lists are in alphabetical order
[X] Needed indications added (PDF, access notes, under construction)

makes sense. Thanks!


Extensionless redirects

.html to extensionless: /foo.html -> /foo
https://no-html--express-website--adobe.hlx.live/express/create.html should redirect to
https://no-html--express-website--adobe.hlx.live/express/create

Doesn't unfortunately, because .html requests don't go to the pipeline, so the 404.html template is never used.


T1

pending:T1
account1:4hdCZJE4oPMaZCsvMpU1S66dKQRu8Nx2WyF5J1D1GbboqSzS7i
account2:3fDcjjRuaDfJiNziaJzuWKvU4VE6c9d3Y9CFqgnYinhuLVaHtC
DeviceDetails:verified
Screenshot:missing
We cannot fully verify this submission. Please provide us with screenshots with all transactions.
@asergs-9

pending:T1
account1:4hdCZJE4oPMaZCsvMpU1S66dKQRu8Nx2WyF5J1D1GbboqSzS7i
account2:3fDcjjRuaDfJiNziaJzuWKvU4VE6c9d3Y9CFqgnYinhuLVaHtC
DeviceDetails:verified
Screenshot:missing
We cannot fully verify this submission. Please provide us with screenshots with all transactions.
@asergs-9

Submission is written in task T1:
submit account addresses for A and B
submit device make and model and OS version.
Nothing is said about screenshots.
вт, 12 янв. 2021 г. в 14:43, Suhas Hegde<EMAIL_ADDRESS>
pending:T1
account1:4hdCZJE4oPMaZCsvMpU1S66dKQRu8Nx2WyF5J1D1GbboqSzS7i
account2:3fDcjjRuaDfJiNziaJzuWKvU4VE6c9d3Y9CFqgnYinhuLVaHtC
DeviceDetails:verified
Screenshot:missing
We cannot fully verify this submission. Please provide us with screenshots
with all transactions.
@asergs-9 https://github.com/asergs-9
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Concordium/Testnet3-Challenges/pull/1360#issuecomment-758602158,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARNSSDFS3HYEVHHICOML47DSZQYXLANCNFSM4TJQCKQA
.

Submission is written in task T1:
submit account addresses for A and B
submit device make and model and OS version.
Nothing is said about screenshots.
вт, 12 янв. 2021 г. в 14:43, Suhas Hegde<EMAIL_ADDRESS>
pending:T1
account1:4hdCZJE4oPMaZCsvMpU1S66dKQRu8Nx2WyF5J1D1GbboqSzS7i
account2:3fDcjjRuaDfJiNziaJzuWKvU4VE6c9d3Y9CFqgnYinhuLVaHtC
DeviceDetails:verified
Screenshot:missing
We cannot fully verify this submission. Please provide us with screenshots
with all transactions.
@asergs-9 https://github.com/asergs-9
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Concordium/Testnet3-Challenges/pull/1360#issuecomment-758602158,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARNSSDFS3HYEVHHICOML47DSZQYXLANCNFSM4TJQCKQA
.

the task did not have a clause on providing screenshots.

the task did not have a clause on providing screenshots.

confirmed:T1
account1:4hdCZJE4oPMaZCsvMpU1S66dKQRu8Nx2WyF5J1D1GbboqSzS7i
account2:3fDcjjRuaDfJiNziaJzuWKvU4VE6c9d3Y9CFqgnYinhuLVaHtC
DeviceDetails:verified

confirmed:T1
account1:4hdCZJE4oPMaZCsvMpU1S66dKQRu8Nx2WyF5J1D1GbboqSzS7i
account2:3fDcjjRuaDfJiNziaJzuWKvU4VE6c9d3Y9CFqgnYinhuLVaHtC
DeviceDetails:verified


PHP version display consistently

The data config file has versions stored as just the PATCH version (39 for 6.1.39). Only the default key is the full version string.
This makes the display of data confusing. Instead of showing full version strings you have tables of what looks like random numbers. Sometimes question marks. Sometimes RC version strings.
So the fix is to either have the config file use full version strings (easiest, sort might need fixing) or have a jekyll plugin to display the correct version string given the patch version (RC4 -> RC4, 13 -> 5.1.13, ?? -> unknown etc.)

You're discribging intent as an accident. The table has a category saying 5.4 then it says 6. That's 5.4.6.

I'm describing intent as a bad user experience. I get why you did it.

The whole site is a bad user experience, I’m just trying not to make it a crowded bad user experience.
Part of a redesign could take care of this. Also killing 5.2 out of here is probably a good idea too.


Revert "Roll engine to 1bc0e1bb9a8db882a21086096cc2b1e0854312b7"

Reverts flutter/flutter#16643, platform messages no longer distinguish a null reply from an empty one.
Maybe due to https://github.com/flutter/engine/blob/master/shell/platform/android/platform_message_response_android.cc#L59

RSLGTM


Appending full message objects in consumer

This is related to https://github.com/joekiller/logstash-kafka/issues/38
Change is not backwards compatible. Should i add any info to changelog?

@jpodeszwik Thank you for your contribution!


A pull request for gnmic prompt mode

I hope that you accept my changes for gnmic prompt mode. The gnmic prompt mode is an interactive CLI to support the tab completion of the data path and enumeration values for user convenience. To use the tab completion of the gnmic prompt mode, the schema data of the user YANG data model should be generated before the prompt mode is loaded as the following examples.
The first example shows how to generate the schema data using the gnmic path subcommand. The schema data will be generated to $HOME/.gnmic.schema file if you execute the path command with --generate-schema option. once it generated, it will be loaded every prompt mode starting. The second example shows how to load the schema data directly from the YANG modules without gnmic path subcommand.
./gnmic path --dir ../gnmi/model/yang/ --file ../gnmi/model/yang/openconfig-interfaces.yang --file<EMAIL_ADDRESS>--exclude ietf-interfaces --generate-schema
./gnmic --address <IP_ADDRESS>:57400 --tls-ca ../gnmi/tls/ca.crt --tls-cert ../gnmi/tls/client.crt --tls-key ../gnmi/tls/client.key --username root --password admin -d prompt-mode

./gnmic --address <IP_ADDRESS>:57400 --tls-ca ../gnmi/tls/ca.crt --tls-cert ../gnmi/tls/client.crt --tls-key ../gnmi/tls/client.key --username root --password admin -d prompt --dir ../gnmi/model/yang/ --file ../gnmi/model/yang/openconfig-interfaces.yang --file<EMAIL_ADDRESS>--exclude ietf-interfaces

2020-10-05 Added prompt mode

Added prompt mode subcommand to root command.
Added the path completion in the prompt mode.
Added ? key for the brief command help.
Separated flag initialization to reset the used subcommand flags in the prompt mode.
Updated path command to generate a schema file($HOME/.gnmic.schema) for tab completion of the prompt mode.
Added --dir, --file and --exclude flags to the prompt mode for single step schema loading.
Add command history to the prompt mode

Work Items remained for gnmic prompt mode
This prompt mode is still being developed. I think I can implement the first work item (The tab completion for boolean and enumeration values). But, the second and third items, they need to change the current framework. I hope that you check how to design and implement them.

boolean or enumeration values must be presented on the tab completion list upon set subcommand.
subcommand execution must return success or failure information to the terminal. (e.g. get doesn't any info upon get operation failure upon non-debug mode.)
Subscribe subcommand must be run in background and the prompt must be presented on the prompt mode. And the output flag configuration should be also supported for the gNMI telemetry streaming redirection in the prompt mode.

Thanks to check.!
neoul

Hi @neoul, great added features. Thanks for contributing.
This is a huge PR, please allow some time to read through and test it.
A couple of early questions:
a) Would it be possible to combine the rootCmd and promptCmd ?
Meaning if gnmic is ran without subcommands, it enters prompt mode. ( maybe via a --prompt? )
If this is too much work, don't worry about it, this can be addressed in a subsequent PR.
b) When in prompt mode, is there a way to still allow the user to set some global flags?
About item 3:

Currently output definition is supported via config file only, we can consider a --output <output_name> flag to support this.
Running the subscribe command in the background means we need to find a way to keep track of its state and be able to stop it.
This means another set of subcommands needs to be added to the prompt command.
I'm thinking subscription list,  subscription show/state, subscription start, subscription stop

Great stuff, thanks again.
Karim

Answer about early questions:
a)
I am not sure it is possible. We have to check go-prompt that binds and runs within the cobra Run or RunE function.  The separation of the commands (rootCmd and promptCmd) was the best choice to avoid the big change of the current command framework and much work. Could you let me know why you need the prompt flag, not the subcommand? (about your command concept)
b) It is possible now. you can see the global flags configuration if you type -- before typing subcommands in the prompt mode. I'd assume the global flags is already configured before the prompt mode starting. So, they are hid and not presented from the tab completion on which the subcommand is selected in the prompt mode.
gnmic> --
        --address             comma separated gnmi targets addresses
        --config              config file (default is $HOME/gnmic.yaml)
        --debug               debug mode
        --encoding            one of [json bytes proto ascii json_ietf]. Ca...
        --format              output format, one of: [protojson, prototext,...

About item 3:
Your idea is the same as I think!

about a) no specific reason for --prompt over prompt command, it just keeps the commands hierarchy clear
about b) ok, didn't notice that. but the global flags need to be given before the subcommand, while on shell mode the order does not matter. it's good enough this way :D
About items 1, 2 and 3, I think they can be added in future PRs
If I start gnmic in prompt mode with --dir and --file, the path command still requires a --file flag. Is it possible to set the flag path-file to the value of prompt-file if path is ran in prompt mode ?

If I start gnmic in prompt mode with --dir and --file, the path command still requires a --file flag. Is it possible to set the flag path-file to the value of prompt-file if path is ran in prompt mode ?

I think that would be possible.

Thanks for this awesome PR, @neoul
I'd like to discuss the YANG side of things

In your examples, why do you need to specify --file<EMAIL_ADDRESS>when you import the opeconfig-interfaces module? I think goyang can dynamically find the imported modules
What is the reasoning behind excluding ietf-interfaces module?

Thanks for this awesome PR, @neoul
I'd like to discuss the YANG side of things

In your examples, why do you need to specify --file<EMAIL_ADDRESS>when you import the opeconfig-interfaces module? I think goyang can dynamically find the imported modules

If we don't specify the iana-if-type.yang for --file option, we cannot get the identity schema data (e.g. ethernetCsmacd identity) defined in iana-if-type.yang from the goyang package. That identity schema data will be used for the tab completion suggestion on Set operation. (It is just a plan yet.)

What is the reasoning behind excluding ietf-interfaces module?

ietf-interfaces has the top node, interfaces. That is the same name to the top node in openconfig-interfaces and the ietf-interfaces module is only used for the type referencing in openconfig-interfaces module. So, this kind of referenced module should be excluded by using the --exclude option. This concept is coming from ygot package.

@neoul its strange about 1). I think goyang resolves identities when it builds the Entry by loading the modules dynamically.
At least when I build the paths with yangpath I do not need to pass any additional modules for goyang to succesfully build the entry with ms.Process() func. The reason I am after this is that I'd like the prompt process to be as easy as possible

can you please show me that concept in ygot if you have it somewhere?

@neoul its strange about 1). I think goyang resolves identities when it builds the Entry by loading the modules dynamically.
At least when I build the paths with yangpath I do not need to pass any additional modules for goyang to succesfully build the entry with ms.Process() func. The reason I am after this is that I'd like the prompt process to be as easy as possible

can you please show me that concept in ygot if you have it somewhere?

... oh.. sorry. I'd closed it..

@neoul if the<EMAIL_ADDRESS>file is under the directory in --dir, then there is no need to add it via a second --file right ?

Thanks @neoul
I was connfused because I didn't read the code at first =) I have a yangpath project with a similar goal (generate paths out of YANG modules), where I extract paths without ygot, just with goyang.
There I do path extraction out of a single module, therefore the modules that are required for type dereference or imported/included are not get in the way. The missing feature there was to understand the augmentation statements;

to my surprise, today in goyang repo the maintainers discussed the reasoning for making namespace-unaware merge of modules in ygot. That explains the need for -exlude https://github.com/openconfig/goyang/issues/146#issuecomment-705138643
So now I have the following mental notes in my head:

if we were to use only goyang to parse the modules, we would have avoided the need to make users aware of a clashing same-name root elements.
ygot uses namespace-unaware approach to simplify the developers experience by not including namespaces in the generated fund/struct names

@neoul if the<EMAIL_ADDRESS>file is under the directory in --dir, then there is no need to add it via a second --file right ?

That was what I expected the result of goyang package. But, that is not resulted out. The identities of iana-if-type.yang is not presented without --file option. The identity type information of iana-if-type.yang is not shown. Find type leaf (/interfaces/interface[name=*]/config/type) using the following path command. That leaf would be empty.
gnmic path --dir ../gnmi/model/yang/ --file ../gnmi/model/yang/openconfig-interfaces.yang --exclude ietf-interfaces --search

and the exclude is to avoid double auto completion ?

Yes.

to my surprise, today in goyang repo the maintainers discussed the reasoning for making namespace-unaware merge of modules in ygot. That explains the need for -exlude openconfig/goyang#146 (comment)
So now I have the following mental notes in my head:

if we were to use only goyang to parse the modules, we would have avoided the need to make users aware of a clashing same-name root elements.

goyang creates top root elements for the module info and lists the schema data to a slice. So, crashing same-name root can be avoided. If we have to use the same-name root, the YANG prefix must be presented and processed in the path representation.

ygot uses namespace-unaware approach to simplify the developers experience by not including namespaces in the generated fund/struct names

Yes. you are right.

Thanks @neoul
I was connfused because I didn't read the code at first =) I have a yangpath project with a similar goal (generate paths out of YANG modules), where I extract paths without ygot, just with goyang.
There I do path extraction out of a single module, therefore the modules that are required for type dereference or imported/included are not get in the way. The missing feature there was to understand the augmentation statements;

The path is not a problem. The data I mean YANG identity value is not loaded.

LGTM,
@hellt if you don't have more questions let's merge this.

I'm happy to merge.
The only outstanding piece from my end would be the missing resolved
Identity-ref that needs to be looked at in a separate issue, as I wanted it
to result either in a local fix or an issue against goyang/ygot
On Thu, 8 Oct 2020, 08:00 Karim Radhouani<EMAIL_ADDRESS>wrote:

LGTM,
@hellt https://github.com/hellt if you don't have more questions let's
merge this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/karimra/gnmic/pull/136#issuecomment-705349168, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABLKV5LIN6K4BFADOZ5437LSJVIQNANCNFSM4SEJ264A
.

yes, let's look at it in a separate issue. this is already a big PR


Update accessibility.md

Fixed grammar issue.

Closing because as @AlmeroSteyn said, the current grammar is correct.

@tesseralis The one sentence is indeed a little broken:

The same functionality can be achieved by using an appropriate event handlers instead, such as onBlur and onFocus:

should become
The same functionality can be achieved by using an appropriate event handler instead, such as onBlur and onFocus:
So let's re-open :-)

@AlmeroSteyn oh, you're right, I didn't see that.
My preference would be

The same functionality can be achieved by using the appropriate event handlers instead, such as onBlur and onFocus:

@tesseralis Yeah you are quite right! Also along the lines of what I suggested initially. Don't comment from your phone, haha!
@nathanlschneider Will you be able to update?


[proto] Enable GPU tests on prototype

cc @seemethere @bjuncek @pmeier

Also there might be an opportunity to simplify this using the generic Linux jobs (with GPU support) that @seemethere has built. You can find the documentation here: https://github.com/pytorch/test-infra/wiki/Writing-generic-linux-jobs

Also there might be an opportunity to simplify this using the generic Linux jobs (with GPU support) that @seemethere has built. You can find the documentation here: https://github.com/pytorch/test-infra/wiki/Writing-generic-linux-jobs

Ohh, this is nice and a much better option. TIL

@huydhn @osalpekar thanks for the review, I'll try to add --gpus=all flag to see if this enables the CI. Using generic linux jobs could be potentially fine, the only limitation I see from the example is that we should now create a single script vs multiple steps...

It is expected to have failures in cuda vs cpu tests, I'll xfail them in the PR that enables cuda tests and we'll fix the inconsistency in a follow-up PR

Unless I have missed something, there are all just closeness related. Thus, we only have to adjust the tolerances in our test suite. Or to put it differently: there is likely no bug in our implementation. I'm ok with doing that in a follow-up.

Given that there are very few differences between the GPU workflow and the CPU one, can we maybe merge the files?

IMO, this is complicated to refactor configuration for self-hosted and GHA runners. Can be done by someone else with better GHA knowledge.

IMO, this is complicated to refactor configuration for self-hosted and GHA runners. Can be done by someone else with better GHA knowledge.

Agreed. I can take that up in a follow-up.

@osalpekar I merged this PR to enable GPU tests for prototype module and now on another PR I have an issue with starting the container with --gpus=all option:

https://github.com/pytorch/vision/actions/runs/3297067787/attempts/1
https://github.com/pytorch/vision/actions/runs/3297067787/attempts/2

Do you have any ideas why this could happen ? Thanks


Extended Event class

Caldav seems not do play around with the objects itself (maybe I missed something). Therefore, I have extended the Event class to
a) provide a method to know if the current event and another's time frames intersect.
b) generate a new event whose time frame is the union of the current event's time frame and that of the other input.
In case I am doing something completely off (so that this functionality is already provided) please let me know.

Sorry for the slow feedback on this one.
I have two minor issues with this one, the first is that I feel it may be a bit out of scope for the caldav library, as this does not relate to caldav client/server communication but rather the iCalendar objects.
The other thing, there has for a long time been talks that we should move from the vobject to the icalendar module. Two pull requests have been written even, but both of them rejected as they don't preserve backward compatibility.
If you vouch to maintain this, as well as to rewrite to support the icalendar module if needed, I will merge it.

Closing this one because of inactivity and because I feel it's slightly out of the scope of the caldav library.


feature request: iphone and ipad screen size for android

Can you please add some android devices with the same screen as the iphone and ipad?
Would be nice to have them for people without IOS for testing the screen size.
Otherwise would be nice to add have the feature to add custom screen size
or that ripple reads a config file.

Hey @badpenguin - can't you get the same effect just by adding the ios platform to your Cordova project, then selecting an iPad in Ripple?

@TimBarham nope, it does not works if you're on linux, it only works if you have a mac.
I already did it "in a raw way" by hacking the minified ripple.js in node_modules.

@badpenguin - when you say "does not work", what exactly does happen?
I've tried this on Windows and it works fine there. I'm not aware of any reason it shouldn't work on Linux.

@TimBarham thanks! Maybe something changed in cordova, in the past i was unsable to add the IOS platform to linux, now it works (i just get a warning); then ripple works :)
BTW it still be nice to have the change to add custom display size when future devices come out (mobile world change each 3 months).


PDI-19757] added a check to make sure that the file exists

:x: Build failed in 7m 25s
Build command:
mvn clean verify -B -e -Daudit -amd -pl \
plugins/file-open-save-new/core

:ok_hand: All tests passed!
Tests run: 15, Failures: 0, Skipped: 0    Test Results

Errors:
Filtered log (click to expand)

script returned exit code 1

:information_source:  This is an automatic message

:x: Build failed in 7m 52s
Build command:
mvn clean verify -B -e -Daudit -amd -pl \
plugins/file-open-save-new/core

:ok_hand: All tests passed!
Tests run: 15, Failures: 0, Skipped: 0    Test Results

Errors:
Filtered log (click to expand)

script returned exit code 1

:information_source:  This is an automatic message


Add card components to gameplan page and add-new-matchup button

Value Proposition
As a user i want to see my upcoming matchups on a page so that I can keep track of them.
Description

Acceptance Criteria

[ ] Display headline: "Your Gameplan"
[ ] User can see cards with the following information

type of match
name
date
time
place
type of court

Tasks

[ ] create a feat/gameplan branch
[ ] create a gameplan.js page
[ ] create a MatchCard.js component
[ ] add example array for the matchup cards
[ ] map over example array

example array:
[
{
"id": Math.random().toString(20).substring(3)
"type": "Match",
"name": "Max",
"date": "22.01-10",
"time": "19:00",
"place": "Rothof",
"court": "Carpet",
}
{
"id": Math.random().toString(20).substring(3)
"type": "Training",
"name": "Sonja",
"date": "22.01-15",
"time": "20:00",
"place": "Fidelopark",
"court": "Sand",
}
{
"id": Math.random().toString(20).substring(3)
"type": "Match",
"name": "Steffi",
"date": "22.01-20",
"time": "10:00",
"place": "Sportscheck",
"court": "Gras",
}
]

I think the tasks are very specific. The tasks should be written in such a way that everyone understands them ( as I have understood it).


Clarifying system_domain_organization in spec and error

Thanks for contributing to the cloud_controller_ng. To speed up the process of reviewing your pull request please provide us with:

A short explanation of the proposed change:

An explanation of the use cases your change solves

[x] I have viewed signed and have submitted the Contributor License Agreement

[x] I have made this pull request to the master branch

[x] I have run all the unit tests using bundle exec rake

[ ] I have run CF Acceptance Tests on bosh lite

[#125727831]

Merged! Thanks for contributing.
@adowns01 && @thausler786
CAPI Team Members


Update issue templates

Summary
Information just for the issue creator in Comments (<!-- Text -->)

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: NoNamePro0 sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Can this be used with a strategy with multiple data streams?

@kiskoapeles Just a single data stream for the defined coin and timeframe. This is possible, but a code update is needed.


1.21 Neo variant crashes when clicking Config in the mods list

Log

NeoForge apparently made an incompatible change. This will affect all mods and I'll fix that when 1.21.1 releases. For now you can downgrade NeoForge to an older version.


MonoAdaptiveSampler2D should take a maximuim number of pixel samples

The MonoAdaptiveSampler2D class should have an optional keyword argument which is the maximum number of pixel samples per pixel. At the moment it does a good job of cutting of work on pixels which are nearing completeness. But it would be good to also abort after a specified maximum number of samples on "hard" pixels.

This functionality has already been addressed by the design of the class. You can change the fraction of pixels to be re-sampled as 100%, then just run a limited number of passes. The number of passes * pixel samples will equal the maximum number of samples per pixel. Any pixels that have already converged won't be re-run and hence the pixels being worked on will decrease with time.
Since the desired functionality is already met, this won't be fixed.


Activity log

using webhooks from the registry https://github.com/docker/distribution/blob/master/docs/notifications.md

Added in develop.


Run in worker environment if no job dependencies. Closes #1585

Darn. I didn't look at this closely enough and there are a few issues:

if conda isn't used, this will just error
if the job has dependencies, the incorrect environment will be used

Actually, it looks like the second case will be fine but the first is problematic


Jms reporter

Added xml reporter extension for JMS messages
It shows a table of message parameters and if the message is javax.jms.TextMessage, it will print it out

Generated reports

Generated reports

Depends on #148 - should be merged afterwards (and review in the meantime done based on the comparison between that branch and this)

Generated reports

Generated reports

Generated reports


Scroll behavior component

This is the work I outlined in https://github.com/linebender/druid/issues/73#issuecomment-658316701
Put simply this allows any widget to very easily support scrolling on its own while picking and choosing what behaviour to support yet remaining consistent with other scrolling widgets.

The original Scroll widget has been renamed to AbsoluteScroll to indicate that it provides bi-directional scrolling for a child which has an absolute size. It can no longer restrict scrolling to a specific axis.
List now manages its own scrolling instead of having to be wrapped in a Scroll. It has gained the ability to change the layout axis to horizontal with the .horizontal() builder fn. The layout code stretches children to full size on the non-primary axis like the Flutter ListView as this solves some issues specifically with inset scrollbars which will come after this patch.
The now public methods and such on the scroll_component have been documented, including making some things like scrollbar point hit tests more well defined

There are more things I want to do (specifically inset scrollbars) and a few existing bugs I noticed I want to fix but this patch should be functionally identical to existing behaviour to avoid issues with reviewing and scope.
As an example here is the list example after changing the .fix_height(50.0) to .fix_width(200.0) and adding .horizontal() to the second List construction

I currently don’t understand what the actual problem is with the widget composition model (having Scroll decorate its child).
It looks like you end up sort of calling back into ScrollComponent and as such recreating the nesting that existed before.
It feels like everyone who wants “good” scrolling behaviour will need to understand this ...
I think this should be split to 1 PR adding the direction to list that demonstrates what the actual problem is, 1 doing the split if it is justified, and a final one doing the rename which only seems to break backwards compatibility?

Various issues with the currently existing Scroll layout can be seen in https://github.com/linebender/druid/issues/799 and https://github.com/linebender/druid/pull/1031.
I'll use the example of a multi-line text editing widget as that's what I've been building for my application using Druid. A text edit widget wants to consume all paintable size it is given without overflow unless the text bounds exceed that area at which point it needs to scroll on that axis. Currently a child of Scroll cannot find out what the max paintable size is, instead it will get a constraint between 0 and infinity on both axis (unless the scrolling is restricted to a specific axis at which point the infinity only exists on that axis) as logically the child should be able to have a size within those bounds and the scroll is supposed to be able to handle scrolling around that large or small widget. Secondly a text edit widget wants to be able adjust its scrolling in order to keep the editing caret visible or jump to a textual search result ect. This is troublesome because if the widget is a normal widget which expects to be wrapped in Scroll, as List is prior to this patch, it won't always be guaranteed to be the child of a Scroll. In addition adding commands to pass this sort of information around feels very hacky to me specifically but that is personal preference.
This sort of thing was technically already possible by splitting the text edit widget into two parts, one which is the parent to the Scroll and another which is the child of the Scroll. Then the parent half can interact with the scroll's public functions and coordinate the actual drawing with the child half by grabbing it from Scroll::child_mut(&mut self) -> &mut W. However that is a bunch of indirection and complication to achieve the same embedding of scrolling behaviour that this patch makes handle-able in less than 20 lines and near identical widget architecture compared to how it might otherwise be written if it didn't handle its own scrolling.

Sidenote it seems that when I force pushed to fix a spelling mistake the CI has decided that harfbuzz_rs should no longer build. This CI really seems to not like me. I know we've had strange issues with CI not passing and then passing when re-ran with no changes :shrug:

What do you mean by "max paintable size"?
The portion of your widgets logical display that is currently visible is:
let rect = ctx.region().to_rect();  in paint.
I assume you mean something different?
That is what I've used in my druid_table repo.
I don't think its realistic to avoid or have a distaste for widget composition using a widget library.
Complex widgets are going to be composed, and the various parts need to be able to communicate.
If the ways of communication currently available are not sufficient that needs to be articulated.
The usual alternative is each complex widget making its own mini adhoc widget library internally.

The paint region is accessible specifically on the PaintCtx not the LayoutCtx when performing layout which is where it is needed in order to consume all paint-able space available. Adding it to the LayoutCtx or even on BoxConstraints would not make sense in other cases (a container for multiple widgets can ask each child to decide on a size but until those are all done and then the layout calculated then the container doesn't know the painting region for each widget and passing in the container's own size would be nonsensical).
This isn't a case against widget composition. This is some core functionality which needs to be flexible enough to handle several different cases for different widgets so the simplest solution seems to be refactor out the common logic and allow each widget that needs special handling do a very small amount of work to pull that logic in and handle its own technicalities itself, whether that be an widget which is shipping in Druid or a downstream widget. When you just need to have a set size and have scrolling handled for you can wrap in an AbsoluteScroll and when you need to shove a bunch of widgets in a scrolling list then reach for List.
I'll give another example of where continuing to use a single Scroll widget and composing would lead to a silly situation. You had mentioned adding the directionality to List without the rest of the changes. If that were the case then a horizontal list would require being wrapped in a scroll which is specifically horizontal in order to have the expected results. Put a vertical list in a horizontal scroll and now you have infinite width widgets with the bottom half of your list being clipped. Of course these are logical errors in the developer's layout but they are silly situations which shouldn't need to be possible. Furthermore think of widgets which just don't make sense when not wrapped in a Scroll, one could write the new fn in such a way that it returns it pre-wrapped in a Scroll (this could be applied for the previous example with a list in a scroll) but now it is returning a scroll with the expected widget instead of the expected widget which is surprising and would be less than idea for a builtin widget especially when now reaching into the widget required a call to child or child_mut on the scroll first.
I agree that inter-widget communication is an area which needs work. However I'll defer to Colin on how hacky it feels to use that sort of thing to solve this https://github.com/linebender/druid/issues/799#issuecomment-608700460 (do note that his opinion on the matter may have changed since this comment however much I agree with it, I don't want to put words in his mouth). The existing Scroll was becoming a rats nest of codepaths, especially when I added inset scrollbars in a now stale patch that never reached maturity. That would only get worse by continuing to add support for cases where a child needs some special attention. See https://github.com/linebender/druid/pull/1031#issuecomment-643747145 for an example of a widget which needs more communication with the parent scroll and would also be better suited to always be capable of scrolling.
At the end of the day this is about ergonomics, minimizing silly situations, and attempting to solve the thousand little cuts that have popped up with laying out in a Scroll by just getting out of the widget's way while still having the same outward consistency with much less mental load compared to passing information and requests around with commands.

I think we need a better protocol for the scroll component to talk to it’s children. It may be an event that gets passed down.
If something as simple as a list needs to jam this extra ‘component’ in it then pretty much every growable widget does, and then every widget needs to replicate the configuration parameters of scrolling and the events emission etc.
I’ll look into 799 which has a much more concise explanation of the issue. I’ll look at the mentioned flutter system.

To reply to the concerns about children knowing viewport size and that not being a part of this patch - We definitely need the functionality, and it definitely is not something that we're going to push down the lifecycle or event tree unconditionally. That's just too much extra noise.
We've had a few discussions about how and where we want to implement these notifications, but I don't think this PR should be blocked on them. It's a fairly orthogonal change, and it centralizes the place where we would make those changes (if we want them to apply to everything scrollable, and everyone uses ScrollComponent for scrolling).
I don't see why we wouldn't want to do this where we can - wrap up a set of behaviors that will be common among a few widgets, and make them usable as a component, rather than adding a layer of indirection. I think this helps with the issues we sometimes face where there are difficulties communicating with widgets that aren't your direct descendants, by making it possible to remove a layer in a lot of instances. I'd be interested if there's a case I'm not thinking of where this is a regression, though.

Could this be called ScrollBehaviour then? ScrollComponent is misleading. I also think Scroll should retain its name as AbsoluteScroll adds nothing

I'm not especially attached to any specific names but renaming Scroll to AbsoluteScroll does gain clarity that it is not intended to perform any fancy layout and it will accept a child which has an absolute size between 0 and infinity on either axis. You can't put a widget under it and expect that widget to be able to figure out some reasonable size from the constraints passed down to it as all it is told is somewhere between 0 to infinity which is part of the problem that needed to be solved for widgets which expect to be able to do that. The name specifies what specific focused usage case it has. I'm open to name suggestions but currently I don't want to keep it named Scroll because that sounds much more general when I expect most out in the wild usage cases to be better suited to the new supped up List.

AbsoluteScroll is a terrible name.
This is really going to complicate the callbacks in #1107 .
The callbacks would logically live in the scrollbehaviour.
But the containing widget will have to pass on their registration, and so will every owner of a ScrollBehaviour.
I still think we are going to have to actually fix this properly at some point.

I don't think "terrible" is a useful word for advancing this discussion.
Having said that, I also don't see the benefits of renaming Scroll right now. We're not planning to use the name Scroll for anything else yet, so it just introduces API breakage. In the hypothetical future when we have a richer set of scrollable widgets, I would be more inclined to support a rename. (Plus, in that hypothetical future it will be easier to devise a consistent naming scheme.)

These callbacks you're talking about aren't going to be registered by some sort of reference or anything. That's not how things are passed around in druid - you don't get a reference to other widgets you don't own across tree traversals.
Either they'll be set up at first instantiation by the setup code, where everything is owned by the function body before being arranged in the tree, or it will be some sort of command-like thing that traverses up the tree, rather than down.
In either of these cases, I don't see how this design hinders this. Is there some obstruction I'm not seeing? Having to pipe things through your own API (i.e. delegation) is common in composed (rather than inherited) systems.. that is, this doesn't seem that weird to me.
@rjwittams  I understand some frustration at having the design you just built (using the changes you're proposing in #1108) have APIs changed under it, but these kinds of changes are exactly why we are in 0.x versions; world-breaking changes are run-of-the-mill between releases.
I'm having a hard time understanding the reasons for your strong opposition here - I just want to understand what you're seeing that I'm not seeing.

I was under the impression people would rather I go away, but here goes.

The patch does a lot of moving around and renaming that makes it difficult to understand. It also seemed to remove functionality.
It took a long time to understand the motivation for it. That being "children of a scroll area do not know how large the scroll area is".
The solution being to jam together the scroll area and any widget who needs to know that.

I don't think it is clear that it is the right solution.
I don't understand how it would support something like SliverAppBar - I think there does need to be more stuff going on.
So we probably do need to actually deal with this 'in the system'  at some point.
The widget pod already knows the scroll offsets, so I just think it ends up needing to be handled at a higher level.
Two points have been brought up that seem very strange to me:

Do we think having wrapper widgets is in some way expensive and they should be reduced? If so why is the whole system based around wrapper widgets? IdWrapper, LensWrapper?
Do we think that communicating by event values is bad and can be 'noisy'?? Noisy in what sense?

Code? In which case every widgets event handling is going to be noisy, because... thats how events work.
Runtime cost?   If so handling animation frames and mouse moves is going to be a lot worse.

Both these arguments seem odd. Definitely .
In the callback case I think we need a general signals / slots mechanism handled by WidgetPod. Otherwise everyone will have to embed some SignalsBehaviour and also probably pass all their events to some other behaviours, and hope they don't eat each others events.

I don't want you to go away, but I am getting a "frustrated" vibe from your recent posts. And it's fine to be frustrated, but I think we'll have a more productive conversation if you can manage to keep it from leaking into your posts.
As for the rest of what you wrote, I agree with some of it and disagree with some of it, but I have to run and so I'll reply more substantively later.

* The patch does a lot of moving around and renaming that makes it difficult to understand. It also seemed to remove functionality.

I agree with this: I'd rather not change the name or functionality of Scroll right now.

* The solution being to jam together the scroll area and any widget who needs to know that.

I don't think it is clear that it is the right solution.

I agree that isn't clear whether this is the right solution, but it also isn't obvious to me that it's the wrong one. Clearly, our current system isn't rich enough for the sort of communication that goes on between scroll and its children. I would summarize this PR's approach as: provide utilities so that widgets can define their own scroll-like behavior. I think this is preferable to the current situation, but I also think it's worth thinking about other models. Like flutters, which is roughly that children of a scroll should not be generic Widgets, but should implement a richer interface.

I don't understand how it would support something like SliverAppBar - I think there does need to be more stuff going on.

I think the idea of this approach is to make it easy to make custom widgets with some scroll behavior. So you would write a ScrollWithAppBar widget combining the scrolling thing with the retractable bar.

Two points have been brought up that seem very strange to me:
* Do we think having wrapper widgets is in some way expensive and they should be reduced?

I don't think so. Can't speak for anyone else, though.

* Do we think that communicating by event values is bad and can be 'noisy'?? Noisy in what sense?

I don't think so. However, current widgets don't usually synthesize or propagate their own events (except for commands, which widgets synthesize but don't propagate on their own).

In the callback case I think we need a general signals / slots mechanism handled by WidgetPod. Otherwise everyone will have to embed some SignalsBehaviour and also probably pass all their events to some other behaviours, and hope they don't eat each others events.

I don't understand what you mean by "SignalsBehaviour", but I don't think (or at least, I hope we don't) need a signals/slots mechanism. I know that such a mechanism is common in traditional toolkits, but callbacks that can mutate state are often unergonomic in rust and other "data-centric" toolkits manage without a signals mechanism. I think we should first explore druid's existing mechanisms for propagating state (namely, Data and commands).

This is the wrong place to discuss signals etc but we seem to be doing it anyway.
But please tell me how I would approach this  function without callbacks of some kind. Having each widget use an adhoc callback mechanism is going to get unwieldy (currently I just have vecs of typedef'd func pointers).
I did at first try to do it with reactive data - specifically for the scrolling callbacks, I was trying to have a wrapper "own" the scroll offsets and have the various internal scrolls react to it , but it either leaks into application state (which is looney for the internal communication of the widget) or means you are synthesising data half way down, eg wrapping up your state as a (T, S) and then the last "container" part is unwrapping. This made the scroll widget very weird to use when you don't need to share the offsets. Also I got advised to give up on that approach on Zulip.

After thinking about it for a while over the past few days I can think of a number of situations where the AbsoluteScroll/Scroll widget will be used over List especially with the axis locking added back in as Finnerale mentioned. As a result my want to avoid such a general sounding name for it has lessened significantly so I'm willing to revert the rename to lessen the amount of downstream breakage as opposed to coming up with a more general but still different name. I still think that List is more generally useful in more situations but the application of the bare bones widget is more broad than I initially thought and if it turns out that it should indeed have a different name we can always come along later once we have more knowledge of the real world application.
I do have to say that I don't understand how the rename could make the patch harder to read, especially when git was smart enough to realize that scroll_component.rs is in effect a renamed and reformatted scroll.rs. As for the name ScrollComponent that is idiomatic with systems that use composition like this. I really don't want to come off with a hard edge but while I feel like bikeshedding is indeed important in moderation this is a bit silly and impedes discussion on the actual merits and drawbacks of the changes being proposed. I just felt I needed to say that as I would much rather have a technical merit based discussion rather than it being dragged through the mud discussing whether or not a name is "terrible" or not.
I'm going to look more into lifecycle events to better understand the hesitation around ScrollComponent::filter_lifecycle. That's an area that I'm not very familiar with so it'll be good to read through WidgetPod and other areas of interest in the handling of lifecycle events. If anyone has any more reservations or things to point out please do but if not I'm going to draft up a commit to address this review cycle and then we can start again :)

I think you'll need to rebase on master to get CI working again.
I agree (and I said so at the time) that "terrible" was an unproductive word.
Regarding the renaming and why it makes the patch harder to read, there are two reasons that I find it harder to review:

it causes the PR to contain certain "uninteresting" changes that I need so skip over, and
it's hard to see the differences between the old Scroll widget and the new ScrollAbsolute widget because the diff just shows everything as being new.

In comparison, if you make changes in one PR and then rename in a second PR, I can read the first PR carefully (because it has interesting changes and I want to understand what they do) and just skim the second one (which has lots of changes, but I know they're all boring).

There where very few locations which were affected by the rename and it was my opinion that the new Scroll/AbsoluteScroll should be reviewed as though it were a brand new widget because it shared/shares so little with the original widget source. Now that the renaming has been reversed I would go so far as to say that the diff is even harder to read due to how how massively scroll.rs changed (almost entirely deletions). It honestly really is a mess. The interesting changes are in scroll_component.rs which the rename actually enabled git to identify it as the closest file to the original scroll.rs file thus allowing a very nice diff comparing the two. Now it is a 450 line block of green while scroll.rs is almost entirely red with the few sections of remaining code being hidden in the mess. This is the stuff I was referring to when I said that I didn't understand how the rename made the diff harder to read. This holds whether the rename were to happen in a separate PR or not.
As a final note on the rename and reversion: I had wanted to avoid such a general sounding name when I felt that under most circumstances one would be better off reaching for List and I was not attached to any specific name. However as I previously mentioned, under more inspection and the re-adding of axis locking I could see much more general usage of that widget hence why I am okay with reverting back to Scroll. I sincerely hope that this is the end of this renaming drama which I'm sure all are tired of at this point.
Quick fire list of changes from the review:

AbsoluteScroll has been re-renamed back to Scroll
Lifecycle events are no longer filtered
Event events are now filtered using ctx.set_handled()
An event is now set as handled only when it is a timer which exactly matches our timer id. Please check my work here
Axis locking has been re-added to Scroll (this locks the child size on the opposite axis just like List also now does)
I performed a much more thorough documentation pass. Any suggestions on wording or information to add is greatly appreciated

Sorry for the delay, I've been exceedingly busy for the past few days.
I think the apprehension about this patch potentially having the affect of downstream developers embedding this component instead of trying to compose Scroll first is valid and understandable. However I think that not composing with widgets being treated as such a red flag is focusing on an ideal over potential practicality. I'm not saying that we should not explore more robust scrolling widget composition but instead that it shouldn't be grounds for dismissing the merits of other solutions out of hand.
I don't want to come off as though I hold this patch to be the one true way forward or any nonsense like that. If a better solution presents itself then that's awesome and this PR should go straight into the trash. I'm just not convinced that any of the ideas that have been tossed around to date using widget composition solve the problems that this PR does and they introduce additional complexity which feels like over-designing something that doesn't seem to require it.
You mention that one potential way forward can be to have a dedicated viewport widget which paints a child with an offset and then have a scrollbar widget housed in the custom widget. I have several practical and ergonomic issues with that approach. Firstly the viewport widget's logic is roughly three lines of code (with_save { transform; clip; paint as usual }). Initially I thought that it might have potential usage outside this specific domain and thus would justify existing to be able to layer atop any arbitrary widget but when inspecting the Cocoa and Flutter docs that doesn't seem to be the case in either of those toolkits. At that point it might as well exist as part of the scrollbar widget except at that point it's the same situation we have with Scroll in current master. That doesn't fix the issues that I'm attempting to solve here, mainly the difficulty in coordinating size between your widget and the scrolling widget that your widget is wrapped in. In addition to that the approach I took significantly simplifies any potential approach to allowing a widget to set its scroll offset (it owns the ScrollComponent), getting the current scroll offset for example to load more content as the user nears the bottom of the page.
The potential path that you brought up would not solve these issues, only add more layers of abstraction to the current system. I realize that you mentioned improvements to inter-widget communication, especially upwards, which is definitely needed but regardless of how much that improves, the general changes wouldn't address the primary motivators of this patch. Earlier in this thread I tossed out an example of a technique which would currently be required that I felt was undesirable and it appears that it would still apply in this hypothetical system. That technique was the idea that you would build two widgets and sandwich a Scroll in the middle, the top widget would control overall size and offset while the bottom widget would do all the painting. I find that a poor approach because now your widget logic is needlessly strewn between two widgets. The internal state probably ends up in the bottom widget and the logic in the top widget which is cumbersome to reach through the scroll to get a reference. The bottom widget is a glorified mime, just painting the data assigned to it by the top widget and not benefiting from being a widget. Add in the extra boilerplate and it just feels more clumsy. It's not outright horrible but in my opinion distasteful due to complicating and adding more layers to code which is already trying to solving some other task.
This PR is conceptually simple, doesn't rely on the runtime widget tree, and doesn't require much modification of an existing widget (such as List) to add the functionality. I generally value the simplicity and ease of application above following some pre-existing idiom, especially when it feels like the idiom fits the problem poorly. Here it feels like the goal of solving this via composing whole widgets is getting in the way of looking at the current papercuts and trying to solve them in the most straightforward way possible. Again I'm not against a different approach if it proves to be a better solution in the big picture. It's just frustrating having brainstormed a solution to a set of persistent issues, ask for feedback, get none, go ahead and come out with a simple and widely applicable solution but have it be held up because it doesn't solve it in the way others might want but without providing any alternative solutions to the actual issues on the table. That is not the fault of anyone, I just felt I had to clarify the specific frustrations I'm feeling in the hopes that it can give more context to the rest that I've said here.
I may be misinterpreting what you mean or missing some context about Cocoa or Flutter and I want to acknowledge that possibility. If this is the case please do let me know. I do know that regardless of the outcome of this PR I'm going to take a break from the topic of scrolling for a while. It's an area with plenty of potential for improvement (inset scrollbars, animated scrolling, various bugfixes) but there is a lot of disagreement about the direction forward without much investment from many others in the specific issues that are being solved here. Going on a bug fixing binge seems like fun :)
As a final note: if this PR ends up going through I am perfectly willing to strip out the changes to List which would allow them to have their own discussion of merits (I'm not 100% sure myself that List should be scrollable on it's own, it may be useful in some situations to not be able to). This thing needs a squash anyway...

Just want to directly address a few comments here; I'm going to avoid talking much about a possible alternative design, since I think that isn't especially relevant to whether or not we land this particular PR.

I think the apprehension about this patch potentially having the affect of downstream developers embedding this component instead of trying to compose Scroll first is valid and understandable. However I think that not composing with widgets being treated as such a red flag is focusing on an ideal over potential practicality. I'm not saying that we should not explore more robust scrolling widget composition but instead that it shouldn't be grounds for dismissing the merits of other solutions out of hand.

Happy to hear; I think we're all on the same page here about the fact that everything involves compromise, and that the real discussion here is about whether this compromise makes sense.

It's just frustrating having brainstormed a solution to a set of persistent issues, ask for feedback, get none, go ahead and come out with a simple and widely applicable solution but have it be held up because it doesn't solve it in the way others might want but without providing any alternative solutions to the actual issues on the table. That is not the fault of anyone, I just felt I had to clarify the specific frustrations I'm feeling in the hopes that it can give more context to the rest that I've said here.

I very much hear you here: I've personally definitely been pretty MIA the past month and a half, and haven't been able to participate in all of these discussions as much as I would have liked, and I recognize how frustrating it can be to want to move in some direction and feel blocked by other people's being busy.

I may be misinterpreting what you mean or missing some context about Cocoa or Flutter and I want to acknowledge that possibility. If this is the case please do let me know. I do know that regardless of the outcome of this PR I'm going to take a break from the topic of scrolling for a while. It's an area with plenty of potential for improvement (inset scrollbars, animated scrolling, various bugfixes) but there is a lot of disagreement about the direction forward without much investment from many others in the specific issues that are being solved here. Going on a bug fixing binge seems like fun :)

Scrolling is a fundamentally hard problem. I know that the flutter scrolling mechanics were rewritten multiple times, and were multi-month projects. It isn't a problem I've thought about in a lot of depth, which is why I'm reluctant to try and offer concrete proposals; all I know is that the flutter API was arrived at via contributions from multiple people smarter than I am, and there will be a strong rationale of some kind for the design they ended up with.

As a final note: if this PR ends up going through I am perfectly willing to strip out the changes to List which would allow them to have their own discussion of merits (I'm not 100% sure myself that List should be scrollable on it's own, it may be useful in some situations to not be able to). This thing needs a squash anyway...

This is a good question. I do suspect that list changes should, at the very least, be reviewed separately, but I'm not opposed to the idea of having scroll logic built into the list widget; this is also something that is the case in flutter, with the ListView widget.

Okay so: I am happy to get this in shortly. Some quick stuff:

this should get a rebase, so that you get the all the doc warnings, and those should be addressed
if it is feasible, the changes to list should be split out and done as a follow-up PR.

So basically: let's get this into a state where it's ready to merge, and then I'll do a last pass. 👌

Yes now that the List changes have been removed this is no longer a breaking change.
I had one concern I was looking into which turned out to be well founded. There were more cases where the component needed to consume events.


class title tags is too general

class title tags is too general it could be something line ti-tags. This goes tags-list as well. Because it is conflicting with our app's css.

Sorry for not replying sooner.
Is it ngTagsInput's stylesheet that's conflicting with your app's CSS or is it the other way around? I mean, I can see some tags class messing with the tags-input element, but the opposite shouldn't happen.
Just to be clear, I agree that ideally no conflict should exist whatsoever. I just want to understand exactly the issue you're experiencing.

This issue was selected to be spring-cleaned by a script. More information can be found here.
If anyone thinks this was a mistake and this issue should be reopened, please leave a message below explaining why. Before doing so, please consider reading the CONTRIBUTING file.


Make order=None work like default order

Fixes #590

I changed the code according to the comments.

Thank you for fix!
jenkins, test this please

LGTM.
Thank you very much!


Device model documentation issue

First of all Thank you for describing the thing in simple words
here is couple of advice
1)You can provide a link to API For HTTP & MQTT
2)Describe the "Meaning" for Reading section in better way.
3)Why Website is (if applicable) because I saw it Mandatory field. If its Mandatory then we have to provide url.
I think we can talk to device model team and ask them to not make it mandatory.

SHOW JSON button should be Red Mar. Its very nice feature in device model.

5)properties part can be improved.(its scary now)

Will talk to frontend team about required website field


avoid cgo

If I chose to use Lorca, is there a way to avoid cgo?

I believe the dialog package guark uses also requires cgo. so i don't think it is possible.

yes you can by using chrome engine and removing the dialog plugin from your app lib/config.go


Removed property which broke JSON deserialisation

Looks like that property causes issues with current api implementation

Thanks for the fix @floradu88!

You are welcome. I'll fix other issues if I find while I am using the API.


Add [Simple File Manager]/[Android File Manager]

Service Name

Simple File Manager
License: GPL v.3.0
Why do you think this helps users privacy?: Open license
Under what section should this service be listed?: Android File Manager
Additional comments / info: The developer has a whole suite of applications

https://github.com/SimpleMobileTools/General-Discussion/issues/241
https://github.com/SimpleMobileTools/General-Discussion/issues/244

Forgot about this: https://github.com/pluja/awesome-privacy/issues/399


Expose http connection eviction configs in the client level

Description:
This is related to https://github.com/wso2-enterprise/internal-support-ballerina/issues/670
This fix is already added in 8.x - https://github.com/ballerina-platform/ballerina-library/issues/5951

Closing as completed


Add possibilty to moving tasks between boards

Hi there. First of all, great job for this project !
I think the "moving tasks" issue is actually effective in the demo.
So it should be clause, right ? (Or it's considered done when you put it in a "milestone"?)
I'm not completely familiar with git-hub stuff, so please tell me if I'm wrong
Bye


Publishing next release

We're using the alembic_utils package to create PGViews but found we the latest published version 0.8.1 is missing a patch commit (6d6a6f17f0de90415ecb7dcb13f90146c50f2f6f) we need for our migrations to run properly, meaning we have to point to the latest git commit in our poetry.lock file.
Is there a planned release of a latest version including the latest commits?
Thanks!

thanks for the nudge. now available on pypi under 0.8.2


Pulls/2/elemental area publish permissions

Simple check of the parent page to determine whether the area can be edited (and thus published).
Considerations:

do we want a granular set of permissions for Elements?
do we want/need an equivalent canView() etc?

Fixes #156

I think we should assume that the content blocks belong to a page, therefore the page permissions should be sufficient. This PR looks good - is there anything left?

Only thing maybe left is to add a canView() as well - otherwise it's good to go

I think it would be sensible to add. Although there isn't a controller endpoint/route for viewing a single element, I think it's probably good to tidy up the loose end & make the consistency & relation to a Page and it's permissions exceedingly obvious.

@NightJar I tend to agree. Supplemented and re-pushed


Initial electron app. #npm start

Work towards #278
does nothing clever but gets it running in electron.
The webgl seems to work fine for me.
npm install
npm run build
npm start

closing as this PR is quite old, though electron is still something we should look at. sorry we didn't have a go at this sooner