Flutter's GIF renderer is too compatible with the GIF89a spec

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce
I apologize for the clickbaity title, but the opportunity was too good to pass.
The issue is that, unlike all other GIF renderers out there, Flutter's GIF renderer actually renders frames with the specified delay, even if it's 0 or 10ms (0 or 1 in the GIF file). While this behavior conforms to the GIF89a spec, the problem is that everybody else doesn't conform — such short delays are usually artificially set to 100ms.
You can read more about this fascinating phenomenon in this article: https://www.biphelps.com/blog/The-Fastest-GIF-Does-Not-Exist. The article contains example GIFs and is a deep dive into the topic.
Because of this behavior, there are already GIFs in the wild that render too fast in Flutter. I think it would make sense to align with the rest of the world, just to existing files render the same as everywhere else.
Expected results
Frames with the delay set to 0 (0ms) or 1 (10ms) have their delay expanded to 100ms.
Actual results
The frames are rendered so fast, they're imperceptible.
Code sample
Code sample
In this example, I've used the smallest GIF from the article mentioned above and added sliders to customize the delays of frames with black and red cells.
This is a customizable equivalent to the "No Delay" section of said article.
https://dartpad.dev/?id=00398769300a9e28c231ba37615828af

Screenshots or Video

Screenshots / Video demonstration
These images come from the article mentioned above.
Flutter's (spec-conformant) behavior.

The actual GIF as rendered by your current browser

Logs
No response
Flutter Doctor output
Doctor output
[✓] Flutter (Channel stable, 3.10.5, on macOS 13.4.1 22F770820d darwin-arm64, locale pl-CH)
    • Flutter version 3.10.5 on channel stable at /Users/evol/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 796c8ef792 (5 weeks ago), 2023-06-13 15:51:02 -0700
    • Engine revision 45f6e00911
    • Dart version 3.0.5
    • DevTools version 2.23.1

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0-rc2)
    • Android SDK at /Users/evol/Library/Android/sdk
    • Platform android-33, build-tools 33.0.0-rc2
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.3.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14E300c
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] IntelliJ IDEA Community Edition (version 2023.1.1)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart

[✓] VS Code (version 1.80.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension can be installed from:
      🔨 https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter

[✓] Connected device (2 available)
    • macOS (desktop) • macos  • darwin-arm64   • macOS 13.4.1 22F770820d darwin-arm64
    • Chrome (web)    • chrome • web-javascript • Google Chrome 114.0.5735.198

[✓] Network resources
    • All expected network resources are available.

• No issues found!

Related: https://github.com/flutter/flutter/pull/80030
Personally I just fix it in my personal fork by applying the above

Hi @evoL
I'm not familiar with GIF89a specs. Can you check the linked issue above https://github.com/flutter/flutter/issues/29130 if it's similar to this case?

Hey, https://github.com/flutter/flutter/issues/29130 does look like the same thing. Feel free to mark this as a duplicate.
Thanks everybody for letting me know!


replace  in  with lsearch commands

Modifies list searches in fast corner setup script to be compatible with older versions of tcl that don't support the <element> in <list> syntax.

thanks guys!


"null" empty arrays in API JSON responses

nil slices are marshaled to JSON as null. In some cases this can be easily fixed as in #1250. However in cases where the empty arrays are nested in deep within the returned object the fix is not as easy. For an example see the /wallet/transactions endpoint.
Is it desirable to return an empty array instead of null? I think it is reasonable to expect the API to be consistent. Googling around it seems like some APIs do return null for empty arrays. Another solution which seems more common is to omit the field if the array is empty. This is supported by Google's JSON Style Guide.
Furthermore would changing this behavior break our API stability promise?

Was this addressed?

I believe our API is still inconsistent on this. Some fields return an empty array, some return null. I think empty arrays are preferable because you can iterate over them, whereas iterating over null (or undefined) causes an error. However, it may be standard in the JS ecosystem to expect that APIs won't return an empty array. One benefit of this is smaller JSON values: our types.Transaction type would be a lot smaller if we used the // json:"omitempty" field tag, since its slices are frequently empty. But it's definitely too late to make such a breaking change.

I guess the best we can do is keep this in mind for API v2.


Add ayushi105's file

created a branch, created a file and made a commit, and opened a pull request

created a branch, created a file and made a commit, and opened a pull request


Split View

The editor currently has no support for splitting the view to show multiple files.  This must be fixed!

Fixed in 779f0aaaad765bf809ca7ce6174092b12790d3d3 and nelsam/gxui@473b8e227354ef22232a151c0952cb4b045938bf


Error: No 'version' key in the manifest file for custom integration 'prusa_connect'

Is your feature request related to a problem? Please describe.
I am getting an error on Home assistant (core-2021.4.3, supervisor-2021.03.9)
"No 'version' key in the manifest file for custom integration 'prusa_connect'. As of Home Assistant 2021.6, this integration will no longer be loaded. Please report this to the maintainer of 'prusa_connect'"
Describe the solution you'd like
I would like the error to be solved before "Home Assistant 2021.6" Since I like the use this addon
Additional context
The error code said to report this to the maintainer of 'prusa_connect'

HA, decided to require this field in lastest version. Fixed in  1.4a release.
Thanks for reporting the issue :)

Maybe the version format is not right :0(
WARNING (MainThread) [homeassistant.loader] '1.4a' is not a valid version for custom integration 'prusa_connect'. Please report this to the maintainer of 'prusa_connect'


style(TestScheduler): rename SetupableTestSubject

Rename SetupableTestSubject to SetupableHotObservable in TestScheduler.
As requested here https://github.com/staltz/RxJSNext/commit/ea6fefa49bec2a77ca74fa000f16d6d465436580#commitcomment-13527857

merged with e773b5e


XGB operations with GPU cause R to hang and restart

I'm having a problem with XGB operations causing R to restart. I'm compiling version 0.71.2, with commit hash
cliff@Makiling:~/xgboost/build$ git rev-parse HEAD
c004cea788748c293e2f9e5c9bd7469ff7e2c613

my sessionInfo is as follows:
R version 3.4.4 (2018-03-15)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)

Matrix products: default
BLAS: /usr/lib/openblas-base/libblas.so.3
LAPACK: /usr/lib/libopenblasp-r0.2.19.so

locale:
 [1] LC_CTYPE=en_PH.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=en_PH.UTF-8        LC_COLLATE=en_PH.UTF-8
 [5] LC_MONETARY=en_PH.UTF-8    LC_MESSAGES=en_PH.UTF-8
 [7] LC_PAPER=en_PH.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_PH.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_3.4.4 tools_3.4.4

nvidia-smi gives this:
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.77                 Driver Version: 390.77                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1070    Off  | 00000000:01:00.0 Off |                  N/A |
|  0%   42C    P0    32W / 151W |      0MiB /  8116MiB |      2%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

while nvcc -V gives:
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2018 NVIDIA Corporation
Built on Wed_Apr_11_23:16:29_CDT_2018
Cuda compilation tools, release 9.2, V9.2.88

I do get a warning during compilation about googletest not being found, even if I have installed both googletest and the dev lib, even mocktest, as well as compiling the dev tools
-- Could not find the GTest library. Looked in  system search paths.
CMake Warning at dmlc-core/test/unittest/CMakeLists.txt:36 (message):
  Google Test not found

and testing for gtest also does not show it,
cliff@Makiling:~/xgboost/build$ sudo ldconfig -v | grep gtest
ldconfig: Can't stat /lib/i686-linux-gnu: No such file or directory
ldconfig: Can't stat /usr/lib/i686-linux-gnu: No such file or directory
ldconfig: Can't stat /lib32: No such file or directory
ldconfig: Can't stat /usr/lib32: No such file or directory
ldconfig: Path `/lib/x86_64-linux-gnu' given more than once
ldconfig: Path `/usr/lib/x86_64-linux-gnu' given more than once
ldconfig: /lib/i386-linux-gnu/ld-2.24.so is the dynamic linker, ignoring

ldconfig: /lib/x86_64-linux-gnu/ld-2.24.so is the dynamic linker, ignoring

Steps to reproduce
I've reproduced this with any XGB operation using the GPU enabled build, whether using gpu_hist or not. If I install the XGBoost package from CRAN, it's fine, but if I recompile it with GPU support, it reoccurs.

Another thing, it was working well last week, but it seems to have started malfunctioning after I updated my Debian. I noticed first that the nvidia driver didnt seem to be working, so I had to reinstall that.

I don't think it has anything to do with the lack of googletest. (Aside: You can manually set the location of googletest by setting GTEST_ROOT.) Since you said you updated Debian, you may want to re-install CUDA toolkit as well. I notice that Debian is not listed in the list of officially supported OSes in the CUDA website. Is this commonly done?

Also, try compiling the CUDA samples and run them.

Thanks for the advice, hcho3! I reinstalled the latest CUDA (and the latest drivers in the process) and it works great now!
cliff@Makiling:~$ nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2018 NVIDIA Corporation
Built on Tue_Jun_12_23:07:04_CDT_2018
Cuda compilation tools, release 9.2, V9.2.148

cliff@Makiling:~$ nvidia-smi
Sat Jul 21 11:42:23 2018
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 396.37                 Driver Version: 396.37                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1070    Off  | 00000000:01:00.0 Off |                  N/A |
|  0%   54C    P8    13W / 151W |    287MiB /  8116MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0      6449      C   /usr/lib/rstudio-server/bin/rsession         277MiB |
+-----------------------------------------------------------------------------+


[bug] VSCode update 1.31.0  breaks pymakr addin

Issue Type: Bug
Start : working environment with pymakr

VSCode updates to 1.31.0

After update pymakr addin does not work anymore
any attempt to use results in an error such as:
command 'pymakr.listCommands' not found
Tried :

re-installation of add-in does not resolve the issue

Cross reference : https://github.com/pycom/pymakr-vsc/issues/28
Extension version: 1.0.5
VS Code version: Code 1.31.0 (7c66f58312b48ed8ca4e387ebd9ffe9605332caa, 2019-02-05T22:35:56.624Z)
OS version: Windows_NT x64 10.0.17763

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz (8 x 2112)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
15.93GB (6.54GB free)

Process Argv

Screen Reader
no

VM
0%

@bpasero very likely causes by the Electron update. Also you can't do anything I assign to you then we at least have one person knowing about them.

I already filed the issue with pycom as well so that they can look into this.
i have been working with some of their devs so im happy to help  where relevant.

Delete the .vscode folder from %userprofile%
Download Visual Studio Code version 1.30 from here: https://code.visualstudio.com/updates/v1_30
Install Visual Studio Code
Install the Pymakr Plugin.


Supporting exactOptionalPropertyTypes

signal key has defined its key as optional, not necessarily the value even though this happens implicitly. No key means no value which translates to undefined:
    signal?: AbortSignal | null;

To support exactOptionalPropertyTypes it would have to be defined as:
    signal?: AbortSignal | null | undefined;

While you could say the key isn't optional (removing ?), which then requires an explicit undefined value:
    signal: AbortSignal | null | undefined;

That would require an explicit undefined being passed.
Given this key is part of TS definitions and module augmentation is overkill, just "oring" from undefined to an expected value (in this case null) solves the problem.

@seivan please use next branch

@js2me
Closed in favour of https://github.com/acacode/swagger-typescript-api/pull/498


Unable to get accurate date/time

When getting the current time with time.Now() we get back incorrect time. I assume this is because tinygo isn't accessing the system clock properly.
Could it be possible to have some function which gets the date and time from the JavaScript side of things?

@Airyzz
Thank you for feedback. And I'm sorry about very late response.
I've created 2 examples.

go-date-example

https://github.com/syumai/workers-playground/tree/main/go-date-example

tinygo-date-example

https://github.com/syumai/workers-playground/tree/main/tinygo-date-example

Each example only does output result of time.Now().
And I've confirmed that the time in local development with tinygo was the only broken case.
Is it about this case that you intend in this report?

The results of these examples are below.
local result
# go-date-example
$ curl http://localhost:8787/now
2024-01-01 23:44:54.185 +0900 UTC+9 m=+0.016000001 # not broken

# tinygo-date-example
$ curl http://localhost:8787/now
2078-01-01 14:39:27.168999936 +0900 UTC+9 m=+3408241167.168999937 # broken

remote result
# go-date-example
$  curl https://go-date-example.syumai.workers.dev/now
2024-01-01 14:56:29.363 +0000 UTC+0 m=+0.000000001 # not broken

# tinygo-date-example
$ curl  curl https://tinygo-date-example.syumai.workers.dev/now
2024-01-01 14:56:33.423000064 +0000 UTC+0 m=+1704120993.423000065 # not broken

Alternatively, you can use the Date class directly.
Example code
https://github.com/syumai/workers-playground/blob/0828c616610cadff6c09b4d4be534fe56e4500b6/tinygo-date-example/main.go#L15-L19
result
$ curl http://localhost:8787/now
2078-01-01 15:25:45.472 +0900 UTC+9 m=+3408243945.472000001 # broken
$ curl http://localhost:8787/date
2024-01-01T15:14:10.439Z # not broken

According to this issue, in local worker development, performance.now() behaves the same as Date.now().
Originally, performance.now() is supposed to return the time elapsed since the start of the script execution, but it seems that the behavior is different in this case (local dev env).
https://github.com/cloudflare/workerd/issues/390
TinyGo's time.Now() is calculated by Date.now() + performance.now(). Therefore, time.Now() in the local environment is the only case of the broken value.
					// func ticks() float64
					"runtime.ticks": () => {
						return timeOrigin + performance.now();
					},

https://github.com/tinygo-org/tinygo/blob/731532cd2b6353b60b443343b51296ec0fafae09/targets/wasm_exec.js#L290


Allow configuration of an external webhook and its associated certs in the Porch API server

This change is related to https://github.com/nephio-project/nephio/issues/554 and previous PR https://github.com/nephio-project/porch/pull/53
This PR implements an optional porch package which can be used to allow web-hooks to be externally defined in yaml files, have cert manager automatically create and update the certificates which these web-hooks will utilize.
This optional package Requires cert manager to be installed in the system and as such to not make porch dependent on cert manager has been made optional.
Note: The version used for the porch-server image is set to v3.0.0 which does not exist yet as it requires the code written in the previously mentioned porch PR to function and as such v2.0.0 would not work.

Note: the only changes in this package compared to the default porch package are found in issuer-cert, validating-webhook and porch-server yaml files. all other files have stayed the same

To aid reviewers:
% diff -qr nephio/core/porch  nephio/optional/porch-cert-manager-webhook
Only in nephio/optional/porch-cert-manager-webhook: 2-2-issuer-cert.yaml
Only in nephio/optional/porch-cert-manager-webhook: 2-3-validating-webhook.yaml
Files nephio/core/porch/3-porch-server.yaml and nephio/optional/porch-cert-manager-webhook/3-porch-server.yaml differ
Files nephio/core/porch/9-porch-controller-packagevariants-clusterrole.yaml and nephio/optional/porch-cert-manager-webhook/9-porch-controller-packagevariants-clusterrole.yaml differ
Files nephio/core/porch/9-porch-controller-packagevariantsets-clusterrole.yaml and nephio/optional/porch-cert-manager-webhook/9-porch-controller-packagevariantsets-clusterrole.yaml differ

% diff -w nephio/core/porch/3-porch-server.yaml nephio/optional/porch-cert-manager-webhook/3-porch-server.yaml

40c40,41
<           emptyDir: {}
---
>           secret:
>             secretName: porch-system-server-tls
46c47
<           image: docker.io/nephio/porch-server:v2.0.0
---
>           image: docker.io/nephio/porch-server:v3.0.0
68a70,71
>             - name: USE_CERT_MAN_FOR_WEBHOOK
>               value: "true"

% diff -w nephio/core/porch/9-porch-controller-packagevariants-clusterrole.yaml nephio/optional/porch-cert-manager-webhook/9-porch-controller-packagevariants-clusterrole.yaml

34,41d33
<   - config.porch.kpt.dev
<   resources:
<   - repositories
<   verbs:
<   - get
<   - list
<   - watch
< - apiGroups:

%  diff -w nephio/core/porch/9-porch-controller-packagevariantsets-clusterrole.yaml nephio/optional/porch-cert-manager-webhook/9-porch-controller-packagevariantsets-clusterrole.yaml

51,58d50
< - apiGroups:
<   - config.porch.kpt.dev
<   resources:
<   - repositories
<   verbs:
<   - get
<   - list
<   - watch

To aid reviewers:
% diff -qr nephio/core/porch  nephio/optional/porch-cert-manager-webhook
Only in nephio/optional/porch-cert-manager-webhook: 2-2-issuer-cert.yaml
Only in nephio/optional/porch-cert-manager-webhook: 2-3-validating-webhook.yaml
Files nephio/core/porch/3-porch-server.yaml and nephio/optional/porch-cert-manager-webhook/3-porch-server.yaml differ
Files nephio/core/porch/9-porch-controller-packagevariants-clusterrole.yaml and nephio/optional/porch-cert-manager-webhook/9-porch-controller-packagevariants-clusterrole.yaml differ
Files nephio/core/porch/9-porch-controller-packagevariantsets-clusterrole.yaml and nephio/optional/porch-cert-manager-webhook/9-porch-controller-packagevariantsets-clusterrole.yaml differ

% diff -w nephio/core/porch/3-porch-server.yaml nephio/optional/porch-cert-manager-webhook/3-porch-server.yaml

40c40,41
<           emptyDir: {}
---
>           secret:
>             secretName: porch-system-server-tls
46c47
<           image: docker.io/nephio/porch-server:v2.0.0
---
>           image: docker.io/nephio/porch-server:v3.0.0
68a70,71
>             - name: USE_CERT_MAN_FOR_WEBHOOK
>               value: "true"

% diff -w nephio/core/porch/9-porch-controller-packagevariants-clusterrole.yaml nephio/optional/porch-cert-manager-webhook/9-porch-controller-packagevariants-clusterrole.yaml

34,41d33
<   - config.porch.kpt.dev
<   resources:
<   - repositories
<   verbs:
<   - get
<   - list
<   - watch
< - apiGroups:

%  diff -w nephio/core/porch/9-porch-controller-packagevariantsets-clusterrole.yaml nephio/optional/porch-cert-manager-webhook/9-porch-controller-packagevariantsets-clusterrole.yaml

51,58d50
< - apiGroups:
<   - config.porch.kpt.dev
<   resources:
<   - repositories
<   verbs:
<   - get
<   - list
<   - watch

thanks for the diff for clarity. there should be no changes made to the cluster-roles for pkg variants and pkg variant sets it must have been due to myself making this copy of the nephio/core/porch pkg before PR#37 was pulled in. this has been addressed in latest update.

Thanks @Catalin-Stratulat-Ericsson
/approve

/approve

/approve
/lgtm


Cinnamon updates 2022-09-05

Description of changes
Previous one: #189389
Closes https://github.com/bobby285271/what-changed/issues/6

cinnamon.bulky: 2.4 -> 2.5
cinnamon.cinnamon-common: 5.4.11 -> 5.4.12
cinnamon.cinnamon-control-center: 5.4.6 -> 5.4.7
cinnamon.muffin: 5.4.6 -> 5.4.7
cinnamon.warpinator: 1.2.13 -> 1.2.14
cinnamon.xapps: 2.2.14 -> 2.2.15

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@ofborg test cinnamon

@bobby285271 fyi, there's a github project with all the current cinnamon issues lined out https://github.com/NixOS/nixpkgs/projects/46

I was aware of those issues but haven't started investigating, will try to


Bridge: Show buildId more prominently as it makes it easy to find your deployments

The "buildId" is a special label that is already used in e.g: SLO evaluation heatmap. The buildId would also make the event list better to read as we could immediately see which version was deployed in case the deployment wasnt triggered through a keptn trigger delivery --image --tag
see here a screenshot when I trigger a delivery workflow with Argo rollouts

Many thanks for the feedback!
The service screen will be revamped and this is great input therefore.
I cross-link it with the research issue on how we can improve the UX for that screen: #3630


Application Context is not being passed the packageJsonPath from Context Constructor

The Context Constructor accepts a path to the package.json file but it is being dropped and not passed to the function which uses it.
https://github.com/microsoft/ApplicationInsights-node.js/blob/c8f3326447c97c4ffbedbf97fb59cc558a9126fc/Library/Context.ts#L21
This leaves the user forced to call the _loadApplicationContext manually, which feels off.

<3


Bootstrap dropdown menu in header not visible

The dropdown menu inside a table header is not visible, it looks like it's container is floating header and not the initial table, changing the z-index does nothing.
https://jsfiddle.net/8qr65o64/

Chrome v 54.0.2840.98
Macosx el capitan

this is required to make certain really bad things which happen sometimes from happening, you dont need it but need some css:
https://jsfiddle.net/8qr65o64/7/

it does not work in your jsfiddle, the menu looks still hidden in the container, i don't get, why you closed the issue ?

i closed it because i thought i had it fixed, but i must have pasted the wrong link. try this:
https://jsfiddle.net/8qr65o64/9/

does that solve it for you?

Yes perfect! Thank you!


Dynamic Authorization Endpoint URL

I'm creating a shopify app which I've gotten to work perfectly using a predetermined authorization endpoint url and this module.  But in practice, what shopify apps do is ask the user for their shop name before calling shopname.myshopify.com/authorize....
I can't figure out how to dynamically call that URL.  The regular Satellizer module seems to have solved this problem in this thread: https://github.com/sahat/satellizer/issues/259 using SatellizerConfig.
How can that be achieved here?

As is tradition, I solved this 10 minutes after posting my issue.
Closing.


MLA Commons shows "join group" buttons twice

Describe the bug
On MLA Commons groups, the "join group" button is showing up twice for all groups. This is only affecting MLA Commons and not HCommons generally or the other member nodes.
To Reproduce
Steps to reproduce the behavior:

Go to 'MLA Commons'
Click on 'Groups and Forums'
Scroll down to the list of groups. "Join Group" will appear twice next to each listed group.

Context
Does this bug on production, development, or both?

[ ] Tested on development instance
[ ] Occurs on development instance
[x] Tested on production
[x] Occurs on productions

Screenshots

Doubled join button removed with temporary fix while plan for removing cbox-auth is developed.


[📑 Docs]: Update the AsyncApi release specification version from 2.3.0 to 2.4.0

What Dev Docs changes are you proposing?
I saw that the Specification 2.4.0 has been added into the Asyncapi docs and that it is the latest specification version right now!
But the "Introduction" section mentions that the spec 2.3.0 is the latest. Here it is:

Expected Outcome
We should update this section to include specification 2.4.0
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Nice found! @pratik2315


Need to wait a second before the first page.goto with Puppeteer 23.4

🐛 Bug Report
Filing here for visibility, though it seems to be wholly caused by upgrading Puppeteer 23.4. (I wonder if it's to do with how jest-puppeteer initializes the browser?)
To Reproduce

Ensure Puppeteer 23.4
Run a test suite containing multiple await page.goto('...');
The first one or two will fail: net::ERR_CONNECTION_REFUSED at ...
Subsequent tests will pass

The failures can be fixed by sleeping for a second before the first page.goto, as though somehow the browser isn't ready, or isn't immediately connected to the network properly.
https://github.com/tinyplex/tinybase/blob/248bb46c69e7963bede5e9c2d25768335f9d093b/test/e2e/common.ts#L40-L47
Expected behavior

With Puppeteer 23.3 they all pass.

npx envinfo
## System:
 - OS: macOS 14.5
 - CPU: (8) arm64 Apple M2
 - Memory: 826.06 MB / 16.00 GB
 - Shell: 5.9 - /bin/zsh
## Binaries:
 - Node: 22.8.0 - /opt/homebrew/bin/node
 - npm: 10.8.2 - /opt/homebrew/bin/npm
 - pnpm: 9.1.4 - /opt/homebrew/bin/pnpm
 - bun: 1.1.3 - ~/.bun/bin/bun
 - Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
## npmPackages:
 - jest-puppeteer: ^10.1.1 => 10.1.1

Hello @jamesgpearce, maybe you should fill an issue in Puppeteer. Because browser should be ready, I mean there is no reason to warm it up on our side.


Android - User defined process.env.NODE_ENV is overwritten on build

Environment
react-native-cli: 2.0.1
react-native: 0.47.1
Steps to Reproduce

Added staging flavor to android/app/build.gradle
Run export NODE_ENV=staging && cd android && ./gradlew assembleStaging
Review the value using console.log(process.env.NODE_ENV);

Expected Behavior
It would printed 'staging'
Actual Behavior
It printed 'production'
Additional Info
It could be an effect of this line
https://github.com/facebook/react-native/blob/9347583d8a0747f476b8f2ecaa5dcbc6a91502f9/local-cli/bundle/buildBundle.js#L43-L45
Upon further inspection, my expected behavior is already implemented in a this commit https://github.com/facebook/react-native/commit/402e7eaac2f15b98bb15ce13198afe2393cb2503 but it gets undone when this commit gets merged https://github.com/facebook/react-native/commit/e8b508144fdcdea436cf4d80d99daec757505c70#diff-39b89923b957ebc1221d83f686f77f41
Another user already mentioned about the same thing, as can be seen in the image below.

Info added

0.47.1 is quite old and we're only tracking issues on the latest release (0.55 as of this writing).


i am using this package in app and getting issue after adding library

/Users/rajeev/Desktop/huc_android_ios_app/App2/App2.iOS/MTOUCH: Error MT2101: Can't resolve the reference 'ObjCRuntime.TrampolineBlockBase', referenced from the method 'System.Void Google.SignIn.Authentication::GetTokens(Google.SignIn.AuthenticationHandler)' in 'Xamarin.iOS, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'. (MT2101) (App2.iOS)

i am facing same isuue from last 1 week plz suggest solution .


Improve RelationalExpressionPrinter to also print shaper lambdas.

Since the lambdas are compiled into the expression we are now producing a string representation for them before compiling, and store it in the shaper.

@anpete

new version up

@maumar I don't think we should flow the materializer string around. We need a solution that is pay-per-play. Easiest might just be to log the materializer expression at the time it is being created.

will open another one


[Spark-18614][SQL] Incorrect predicate pushdown from ExistenceJoin

What changes were proposed in this pull request?
ExistenceJoin should be treated the same as LeftOuter and LeftAnti, not InnerLike and LeftSemi. This is not currently exposed because the rewrite of [NOT] EXISTS OR ... to ExistenceJoin happens in rule RewritePredicateSubquery, which is in a separate rule set and placed after the rule PushPredicateThroughJoin. During the transformation in the rule PushPredicateThroughJoin, an ExistenceJoin never exists.
The semantics of ExistenceJoin says we need to preserve all the rows from the left table through the join operation as if it is a regular LeftOuter join. The ExistenceJoin augments the LeftOuter operation with a new column called exists, set to true when the join condition in the ON clause is true and false otherwise. The filter of any rows will happen in the Filter operation above the ExistenceJoin.
Example:
A(c1, c2): { (1, 1), (1, 2) }
// B can be any value as it is irrelevant in this example
B(c1): { (NULL) }
select A.*
from   A
where  exists (select 1 from B where A.c1 = A.c2)
or A.c2=2
In this example, the correct result is all the rows from A. If the pattern ExistenceJoin around line 935 in Optimizer.scala is indeed active, the code will push down the predicate A.c1 = A.c2 to be a Filter on relation A, which will incorrectly filter the row (1,2) from A.
How was this patch tested?
Since this is not an exposed case, no new test cases is added. The scenario is discovered via a code review of another PR and confirmed to be valid with peer.

Test build #69262 has started for PR 16044 at commit 8e34c50.

@nsyca this was not uncovered because we didn't add tests, could you add one? org.apache.spark.sql.catalyst.optimizer.FilterPushdownSuite seems a good place (they could be similar to the ones for Left Anti).

@hvanhovell I can add a new test case but I want to reiterate that this is not an exposed case because ExistenceJoin does not exist in the course of the PushPredicateThroughJoin rule. The ExistenceJoin is rewritten at the RewritePredicateSubquery rule, which is currently placed at the very last batch of the Optimizer phase, after the batch that have PushPredicateThroughJoin rule.

I know it is currently not exposed due to the way we optimize plans. However this may change, and it is better to be safe than sorry. Also note that we typically only test the rule at hand in optimizer unit tests, so it should be relatively straightforward to create such a test case, by explicitly creating a join using ExistenceJoin.

Hmm. ExistenceJoin is not exposed via DataFrame APIs. Let me study the way org.apache.spark.sql.execution.joins.ExistenceJoinSuite was written then I will add a new test case.

You just need to add test cases to FilterPushdownSuite, like what @hvanhovell did: https://github.com/apache/spark/pull/16039/files#diff-acd51a263163be1e40af0b8b41f2b073

You can just write an optimizer test case. You can for example add this to the FilterPushdownSuite:
  test("joins: only push down join conditions to the right of an existence join") {
    val x = testRelation.subquery('x)
    val y = testRelation.subquery('y)
    val filerVal = 'val.boolean
    val originalQuery =
      x.join(y,
        ExistenceJoin(filerVal),
        Some("x.b".attr === "y.b".attr && "y.a".attr > 10 && "x.a".attr > 10)).analyze
    val optimized = Optimize.execute(originalQuery)
    val correctAnswer =
      x.join(
        y.where("y.a".attr > 10),
        ExistenceJoin(filerVal),
        Some("x.b".attr === "y.b".attr && "x.a".attr > 10))
        .analyze
    comparePlans(optimized, analysis.EliminateSubqueryAliases(correctAnswer))
  }

This probably passes.

Test build #69262 has finished for PR 16044 at commit 8e34c50.

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

Merged build finished. Test PASSed.

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

Test build #69287 has started for PR 16044 at commit 7c3bca0.

@hvanhovell Thank you for the detailed instruction on the test case.
@gatorsmile Also thanks for the directive.
In addition to the white box testing on the Optimized Logical Plan, I also added two black box test cases in org.apache.spark.sql.JoinSuite. Hopefully it's a right place to put.
This is just to share my experience: The good thing about writing white box test cases, such as doing plan comparison as in org.apache.spark.sql.catalyst.optimizer._, are good in verifying internal behaviour, such as whether an optimization does happen or not. It may also catch problems that are not exposed externally. However, the down side is writing white box test cases are more time-consuming and more sensitive to future code changes. It could create a huge cost of test cases maintenance in the future.

Test build #69287 has finished for PR 16044 at commit 7c3bca0.

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

Merged build finished. Test PASSed.

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

Test build #69341 has started for PR 16044 at commit d4002c7.

LGTM - pending jenkins

LGTM - pending jenkins

Test build #69341 has finished for PR 16044 at commit d4002c7.

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

Merged build finished. Test PASSed.

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

LGTM - merging to master/2.1. Thanks!


Add Async Support to XCTest, Take 2

This PR contains the changes from #326, plus a change which conditionally compiles out the new async setUp/tearDown variants on Windows, since there's a compilation error in XCTest. We plan on removing this limitation once the underlying compilation error is reproduced and resolved in a CI environment.

@swift-ci Please test

@swift-ci Please test

What about tests discovery and LinuxMain autogeneration, by the way?

AFAIK test discovery is implemented in SwiftPM and this question may not be relevant to this PR. Additionally, it has been enabled by default since Swift 5.4, and --generate-linuxmain has been deprecated.

Of course I know, I mean, SPM doesn't know anything about asyncTest wrapper, does it?

Curious, would this not be available  until Swift 5.6? Considering adding some async tests to a library of mine, but plan to wait until this is publicly available.

@joshuawright11 I managed to run async tests in Linux using some code (in a polyfill form) from this PR. Rather dirty solution, but the alternative is nothing.

🥳

Wohoo!


SQL Enterprise Licensing

Hi everyone
I could not find anything about the SQL Enterprise License which is used by MABS on this or any other Docs-Page. Just on some other websites i found that I don't need to pay for the SQL Enterprise License. Is that true? Could you please add this here? I just found that if I'm using MABS, I don't need any System Center License.
Best Regards
Dave

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

ID: 76dad6d5-9991-e15e-0283-1d8d49c35df4
Version Independent ID: baa58543-1be8-aa7c-15b9-db35f071f4fb
Content: Use Azure Backup Server to back up workloads to Azure
Content Source: articles/backup/backup-azure-microsoft-azure-backup.md
Service: backup
GitHub Login: @dcurwin
Microsoft Alias: dacurwin

@DaveZimmermann Thanks for comment. We are actively investigating on the issue and will get back to you shortly with an update.

@DaveZimmermann  MABS has been bundled with inbuilt SQL, unless if you want to use separate SQL instead of inbuilt one. This has been documented, here is snapshot for you.

Hope this helps!

Yes we know that it uses an SQL Enterprise, but I've read on many other websites that this SQL-Enterprise License is free - but never found that on an official site and also not in that statement. This statement just says that SQL Enterprise is needed - but the license as well?

Assigning to content author @dcurwin  to consider adding a note regarding the same in the document.

@naven  - Please provide the exact wording for the update to the document.

The document has been updated.
#please-close


ability to fetch dependants

I'd love to be able to fetch which libraries depend on a given library
E.g. https://www.npmjs.com/package/query-registry?activeTab=dependents

Hmm. Doesn't appear to be available from the registry APIs though, so I'll close this. Thanks!

Hi @benmccann,
as you said I don't think there is an official API for this for that but if you happen to find more info I could look into it.


generate client errors out because of a nullable field in a definition

Problem statement
go-swagger errors out on a nullable fied in a definition:
   "definitions": {
        "AddLabel": {
            "description": "Adds a label to a manifest",
            "properties": {
                "media_type": {
                    "description": "The media type for this label",
                    "enum": [
                        "text/plain",
                        "application/json",
                        null
                    ],
                    "type": [
                        "string",
                        "null"
                    ]
                }

The (not obvious at all) error is:
template: schemavalidator:370:65: executing "schemavalidator" at <.>: wrong type for value; expected

I'm not well versed into swagger, a quick glance at the 2.0 spec tells me it may not be a valid swagger document, but I gathered I may as well file an issue just in case.
Swagger specification
Not sure, https://quay.io/api/v1/discovery.
Steps to reproduce

Download swagger definition at https://quay.io/api/v1/discovery
Try go generate client library with swagger generate client -f api.json -A client -c quay -a quay
This error out with:

2017/11/13 13:49:22 rendering 1 templates for model AddLabel
2017/11/13 13:49:22 name field AddLabel
2017/11/13 13:49:22 package field models
2017/11/13 13:49:22 creating "add_label.go" in "models" as definition
template: schemavalidator:370:65: executing "schemavalidator" at <.>: wrong type for value; expected string; got interface {}

Environment
swagger version: dev (master, b015bda48dfc648fdd95e7bc81dbb5cefc17c975) as of today
go version: 1.9.0
OS: Linux

All properties are optional unless you list them in the required section.  As such, you don't have to do anything with "null" there to make it so.

in addition openapi 2.0 doesn't allow for multiple types in a type field.

Thanks for the quick answer. Based on that I think we can close this issue.


added windows 11

after reading this article, i confirmed windows 11 is supported

Learn Build status updates of commit bdb14bf:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

windows/security/threat-protection/security-policy-settings/accounts-rename-administrator-account.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel


fixing a minor typo in err message

Spotted the typo while reading the code - thought I'd just make a quick fix for it

Thanks!


Elevation data

This is a big project, but with small steps. Roughly:

Get better elevation data, either fixing the bugs in the srtm.rs impl or preferably using the better LIDAR data around Seattle. I have some pointers for that in an email somewhere; remind me to post them

Figure out how elevation change affects the standard bicyclist speed. Incorporate that in the simulation and pathfinding cost function

Render the elevation layer much more understandably. Isochrones are the thing people are familiar with, probably should give that a shot

I can give pointers to relevant code when needed

http://brouter.de/brouter/elevation.html for reference

All those references to better lidar data for washington, thanks to Michael Patrick from CUGOS:

presentation: https://www.dnr.wa.gov/publications/ger_presentations_wa_gis_day_2016_gleason.pdf?ko7ffe
downloading as multiple tiles: https://lidarportal.dnr.wa.gov/#47.49215:-122.29706:9
As a single file:

NOAA Portal https://coast.noaa.gov/htdata/raster2/elevation/WA_King_DEM_2016_8589/
Tile Index: https://coast.noaa.gov/htdata/raster2/elevation/WA_King_DEM_2016_8589/tileindex_WA_King_DEM_2016.zip
ftp://ftp.coast.noaa.gov/pub/DigitalCoast/raster2/elevation/WA_King_DEM_2016_8589/
a 5GB geotiff: ftp://ftp.coast.noaa.gov/pub/DigitalCoast/raster2/elevation/WA_King_DEM_2016_8589/kingcounty_delivery1_be.tif

Seattle only and old data, but looks detailed: https://data-seattlecitygis.opendata.arcgis.com/datasets/contour-lines-1993

There's an R package that takes OSM data and calculates gradients in the surrounding area that can provide ideas/inspiration for this: https://github.com/ITSLeeds/slopes The main computational tasks are quite generally applicable so I would suggest splitting this out as a separate cargo crate, either within this repo (or perhaps better?) as a separate repo. Vested interest: I want the functionality in the slopes package to be faster. Thinking of eventually using the Rust implementation as a back-end via the libR-sys crate https://github.com/extendr/libR-sys  . Another advantage of this approach: Rust is a solid and future-proof language with interfaces to many lanuages so a Rust implementation could help make the awesome functionality in slopes available for more communities, beyond the small (but highly active and rapidly growing #rspatial community).

There's an R package that takes OSM data and calculates gradients in the surrounding area that can provide ideas/inspiration for this: https://github.com/ITSLeeds/slopes The main computational tasks are quite generally applicable so I would suggest splitting this out as a separate cargo crate, either within this repo (or perhaps better?) as a separate repo. Vested interest: I want the functionality in the slopes package to be faster. Thinking of eventually using the Rust implementation as a back-end via the libR-sys crate https://github.com/extendr/libR-sys  . Another advantage of this approach: Rust is a solid and future-proof language with interfaces to many lanuages so a Rust implementation could help make the awesome functionality in slopes available for more communities, beyond the small (but highly active and rapidly growing #rspatial community).

In terms of Rust/R integration it's early days but I just ran the following commands from the extendr/libR-sys repo and it works fine:
libR-sys on  master via 𝗥 v1.48.0
➜ cargo build
    Updating crates.io index
   Compiling libR-sys v0.2.1 (/mnt/57982e2a-2874-4246-a6fe-115c199bc6bd/orgs/extendr/libR-sys)
    Finished dev [unoptimized + debuginfo] target(s) in 12.26s

libR-sys on  master is 📦 v0.2.1 via 𝗥 v1.48.0 took 12s
➜ cargo test -- --nocapture --test-threads=1

In terms of Rust/R integration it's early days but I just ran the following commands from the extendr/libR-sys repo and it works fine:
libR-sys on  master via 𝗥 v1.48.0
➜ cargo build
    Updating crates.io index
   Compiling libR-sys v0.2.1 (/mnt/57982e2a-2874-4246-a6fe-115c199bc6bd/orgs/extendr/libR-sys)
    Finished dev [unoptimized + debuginfo] target(s) in 12.26s

libR-sys on  master is 📦 v0.2.1 via 𝗥 v1.48.0 took 12s
➜ cargo test -- --nocapture --test-threads=1

Good news: it seems the approach is fast. Faster than R's very mature C++ bindings according to a small benchmark here: https://github.com/extendr/rextendr/issues/11#issuecomment-755119346

Good news: it seems the approach is fast. Faster than R's very mature C++ bindings according to a small benchmark here: https://github.com/extendr/rextendr/issues/11#issuecomment-755119346

Reproducible example on a machine that has R and Rust installed. Not 100% sure what's going on here, imagine @dabreegster you'll have a better idea if you can reproduce it...
library(rextendr)

# create a Rust function
rust_function("fn add(a:f64, b:f64) -> f64 { a + b }")
#> build directory: /tmp/RtmphEpi9F/file6a284aec7f99

# call it from R
add(2.5, 4.7)
#> [1] 7.2

Created on 2021-01-09 by the reprex package (v0.3.0)

Reproducible example on a machine that has R and Rust installed. Not 100% sure what's going on here, imagine @dabreegster you'll have a better idea if you can reproduce it...
library(rextendr)

# create a Rust function
rust_function("fn add(a:f64, b:f64) -> f64 { a + b }")
#> build directory: /tmp/RtmphEpi9F/file6a284aec7f99

# call it from R
add(2.5, 4.7)
#> [1] 7.2

Created on 2021-01-09 by the reprex package (v0.3.0)

And with regard to the question of which elevation data source to use... There has been an updated to SRTM but it's not that easy to download. In the slopes package as far as I can recall we use the https://docs.mapbox.com/help/troubleshooting/access-elevation-data/ via the ceramic package, source code of which can be found here: https://github.com/hypertidy/ceramic/blob/7980c9f4134c0770ab3de351049e7dd511aac002/R/tile-providers.R

And with regard to the question of which elevation data source to use... There has been an updated to SRTM but it's not that easy to download. In the slopes package as far as I can recall we use the https://docs.mapbox.com/help/troubleshooting/access-elevation-data/ via the ceramic package, source code of which can be found here: https://github.com/hypertidy/ceramic/blob/7980c9f4134c0770ab3de351049e7dd511aac002/R/tile-providers.R

The Mapbox API is quite convenient. Did you hit any licensing or API limit issues with caching data from them?
For a general purpose crate, having a method that winds up making a Mapbox request would be very useful. For the A/B Street case, we likely want to use some kind of bulk API or to find and operate on a DEM file. I'd be a little surprised if Mapbox just lets you dump elevation data for a huge reason, cache it on your end, redistribute it, etc.

The Mapbox API is quite convenient. Did you hit any licensing or API limit issues with caching data from them?
For a general purpose crate, having a method that winds up making a Mapbox request would be very useful. For the A/B Street case, we likely want to use some kind of bulk API or to find and operate on a DEM file. I'd be a little surprised if Mapbox just lets you dump elevation data for a huge reason, cache it on your end, redistribute it, etc.

Did you hit any licensing or API limit issues with caching data from them?

Not yet, I have an unpaid mapbox API key that is quite generous and not even sure if you need one for the terrain data.

Did you hit any licensing or API limit issues with caching data from them?

Not yet, I have an unpaid mapbox API key that is quite generous and not even sure if you need one for the terrain data.

Huh, https://www.mapbox.com/legal/tos/ doesn't mention anything against redistributing data from their APIs. Nice!

Huh, https://www.mapbox.com/legal/tos/ doesn't mention anything against redistributing data from their APIs. Nice!

But to be fair haven't been bulk downloading data in a way that I have been doing for OSM/STATS19 data. I'm sure lack of DEM data will not be a limiting factor for this issue in any case!

But to be fair haven't been bulk downloading data in a way that I have been doing for OSM/STATS19 data. I'm sure lack of DEM data will not be a limiting factor for this issue in any case!

https://valhalla.readthedocs.io/en/latest/sif/elevation_costing/ reference for how to use elevation data for cycle routing

SRTM has been superseded by NASADEM:
https://earthdata.nasa.gov/esds/competitive-programs/measures/nasadem

Thanks, good to know! We could try hooking up NASDEM with https://github.com/eldang/elevation_lookups#raster-elevation-data pretty easily. If GDAL can read it, should be easy.

Summarizing how things work currently.

We use https://github.com/eldang/elevation_lookups to deal with LIDAR data for Seattle, and with SRTM for other cities. This Python library has an API for elevation at a point and, more importantly, plugging in a polyline representing a street and getting the total incline.
The A/B Street importer calls out to this library during the first step of importing a map. We just store elevation per intersection, currently. Everything downstream just uses that; we're not keeping around the raw elevation datasets.
Walking and biking account for incline by costing pathfinding and in the simulation. Walking speed is here, based on Tobler's hiking function. Biking is here, loosely based on Valhalla -- I was unable to find a simple formula here.
We have a few dataviz things hooked up, some https://github.com/a-b-street/abstreet/blob/master/game/src/layer/elevation.rs. Contour map, showing steep streets, and per-trip elevation profiles:

Future work / help needed:

Pure Rust solutions without heavy GDAL dependencies would be nice. Especially to parallelize querying; because of some mutable caching layer, it's expensive to spawn multiple threads to query a large vector or raster input source.
I've only carefully checked the end-to-end elevation results for Seattle, which uses LIDAR. Everywhere else uses SRTM, and the results look quite suspect -- as a quick sanity test, the contour map will jump from totally flat to 100m without anything in between. Not sure where the issue is yet.
If NASDEM has worldwide coverage and is better than SRTM, we should switch to it.
Things break near bridges, because I think the input dataset gives the value for the water/ground below. From the abst importer, we know when we are querying near a bridge, so there were some ideas to just ask for the polyline's endpoints, instead of sampling every few meters.

Keeping my eye on https://github.com/pka/georaster as another pure-Rust geotiff reader. Instead of memmap or similar for handling massive files, we could split the big UK and Seattle files into tiles (or possibly even download them that way to begin with)

https://opendem.info/


fix(support): redirect to ticket link

Hey team!
The Support team is currently in a process of removing<EMAIL_ADDRESS>email from all GitHub repos and updating it to link to the new ticket form. We kindly ask that you review the changes made removing references to<EMAIL_ADDRESS>Thanks!

ah yes it will never pass env from forks, i'll re-open the pr with you as co author


HttpClientRequest buffer issue with setChunked(true)

The request sometimes looses single chunks probably due to an buffer handling issue:
Independent from the max chunk size provided the request sometimes seems to (re-)use some buffer with an arbitrary size for the first chunks. The chunks from this buffer are always received on the server side.
This first buffer is often sufficient for the complete request and everything works.
But as soon as this first big buffer is full and the request has not ended yet, the request seems to switch to buffers with the correct max chunk size. The next chunk after the first (big) buffer is not sent out (in the test run below the chunk with identifier : 3).
All further chunks work again as expected:
112
{"identifier" : "0", "type_of_item" : "hardcover_book", "title_of_item" : "test record 0"}, {"identifier" : "1", "type_of_item" : "hardcover_book", "title_of_item" : "test record 1"}, {"identifier" : "2", "type_of_item" : "hardcover_book", "title_of_item" : "test record 2"}
5c
, {"identifier" : "4", "type_of_item" : "hardcover_book", "title_of_item" : "test record 4"}
5c
, {"identifier" : "5", "type_of_item" : "hardcover_book", "title_of_item" : "test record 5"}
5c
, {"identifier" : "6", "type_of_item" : "hardcover_book", "title_of_item" : "test record 6"}
5c
, {"identifier" : "7", "type_of_item" : "hardcover_book", "title_of_item" : "test record 7"}
5c
, {"identifier" : "8", "type_of_item" : "hardcover_book", "title_of_item" : "test record 8"}
5c
, {"identifier" : "9", "type_of_item" : "hardcover_book", "title_of_item" : "test record 9"}
3
...
0
HTTP/1.1 500 Internal Server Error
Content-Length: 14
missing doc: 3
The test code code can be found here - might have to be run several times till the problem occurs...
dx.test.http.zip

I have reproduced this and it appears to be a race condition.
I notice you are interacting with the request from outside an event loop. This should work, but is not the recommended/optimal way of using Vert.x.
You're using Vert.x 3.2.1 and I also notice that @vietj has made various threading related changes/fixes in the http client since then. Can you try with 3.3.0-SNAPSHOT and see if the problem continues?

I've tested the test program with Vert.x 3.3.0-SNAPSHOT and I can't replicate the issue, so I will assume Julien has already fixed this.

Hi Tim,
thanks for checking - will try v3.3.0 first thing tomorrow German time (today is a public holiday)...
Thanks, Peter

3.3.0-SNAPSHOT works!
Thanks for your quick help!!!


Sometimes Git can't authenticate against GitHub

That domain cropped in the quick input looks suspicious.

I'm surprised this even worked until today.
cc @eamodio

I'm surprised this even worked until today.
cc @eamodio

Verification: please code review https://github.com/microsoft/vscode/commit/75ff8b113101d1362ef87c588cebfd4f16daf0a4 and https://github.com/microsoft/vscode/commit/9e07bfd5946172f0b7bece7b0cec2b58102944d2. This was just wrong, since it was cropping too much:
	const host = argv[4].substring(1, argv[4].length - 2);

Verification: please code review https://github.com/microsoft/vscode/commit/75ff8b113101d1362ef87c588cebfd4f16daf0a4 and https://github.com/microsoft/vscode/commit/9e07bfd5946172f0b7bece7b0cec2b58102944d2. This was just wrong, since it was cropping too much:
	const host = argv[4].substring(1, argv[4].length - 2);

I may have broken this today:
➜  vscode git:(master) git push
Missing or invalid credentials.
Error: Bad status code: 500
    at ClientRequest.<anonymous> (/home/joao/.vscode-server-insiders/bin/9ee751e859d655e1e80fa0d57253304c01c65732/extensions/git/dist/askpass-main.js:1:2200)
    at Object.onceWrapper (events.js:422:26)
    at ClientRequest.emit (events.js:315:20)
    at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:596:27)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:119:17)
    at Socket.socketOnData (_http_client.js:469:22)
    at Socket.emit (events.js:315:20)
    at addChunk (_stream_readable.js:295:12)
    at readableAddChunk (_stream_readable.js:271:9)
    at Socket.Readable.push (_stream_readable.js:212:10)

I may have broken this today:
➜  vscode git:(master) git push
Missing or invalid credentials.
Error: Bad status code: 500
    at ClientRequest.<anonymous> (/home/joao/.vscode-server-insiders/bin/9ee751e859d655e1e80fa0d57253304c01c65732/extensions/git/dist/askpass-main.js:1:2200)
    at Object.onceWrapper (events.js:422:26)
    at ClientRequest.emit (events.js:315:20)
    at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:596:27)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:119:17)
    at Socket.socketOnData (_http_client.js:469:22)
    at Socket.emit (events.js:315:20)
    at addChunk (_stream_readable.js:295:12)
    at readableAddChunk (_stream_readable.js:271:9)
    at Socket.Readable.push (_stream_readable.js:212:10)

Another fix: https://github.com/microsoft/vscode/commit/7b0cfdd04ad530a9c8d782c618afd79290be3d64

Another fix: https://github.com/microsoft/vscode/commit/7b0cfdd04ad530a9c8d782c618afd79290be3d64


[LOC] Invalid link in an article

There is an invalid link in an article.
Repro steps:

Go to https://docs.microsoft.com/en-us/MicrosoftTeams/quality-of-experience-review-guide
Search for "www.skypepreview.com" link
Click on the link

Actual results:
Link redirects to 404 error
Expected results:
Link redirects to an existing page or is removed from the article
GH article:
https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/blob/live/Teams/quality-of-experience-review-guide.md

@officedocsbot assign @scanum

Hi @scanum  The PR #2199 solved this issue! please review and merge !

@OfficeGlobal Thank you for submitting feedback. We understand that this issue has been resolved.
Please feel free to re-open this issue if there is a specific area of the docs that we can improve or make better. Thank you.
@officedocsbot close

@officedocsbot close


[proposal] remove PARSL_TRACKING environment variable

Is your feature request related to a problem? Please describe.
Currently Parsl takes usage tracking configuration from both Config (like other configuration) and from the $PARSL_TRACKING environment variable.
The interactions between these two parameters, as well as two conflicting defaults (one in Config and one in usage.py), are quite subtle and hard to understand intuitively and in the code.
PR #3400 makes that configuration more complicated: instead of a bool, the usage tracking level becomes an int (of restricted range). In reviewing that PR, along with @khk-globus, it's become pretty apparent that fusing two configurations and defaults together is even more complex in this situation.
Other configuration options in Parsl do not have this "specify multiple configuration values, fuse them together" behaviour: configuration comes from the Config object (and objects contained within that class).
Describe the solution you'd like
I would like to simplify this piece of Parsl by removing $PARSL_TRACKING: this removes a bunch of complexity both for user understanding of what usage level they have actually configured, and for programmers trying to understand these code paths.
Describe alternatives you've considered
A more generalised fuseable configuration mechanism that can fuse any configuration options, not only usage tracking level.
Additional context
This is part of a funded deliverable for usage tracking coordinated by @kylechard and @yadudoc, which @NishchayKarle is working on right now.

Makes sense to put it all in the configuration.


Cipherstring parsing does not recognize TLSv1.3

In test_ssl_old, we have the following block
my $ciphers = "-EXP:-PSK:-SRP:-kDH:-kECDHe";
my @protocols = ();
# FIXME: I feel unsure about the following line, is that really just TLSv1.2, or is it all of the SSLv3/TLS protocols?
push(@protocols, "TLSv1.3") unless $no_tls1_3;
push(@protocols, "TLSv1.2") unless $no_tls1_2;
push(@protocols, "SSLv3") unless $no_ssl3;
my $protocolciphersuitcount = 0;
my %ciphersuites =
  map { my @c =
    map { split(/:/, $_) }
              run(app(["openssl", "ciphers", "${_}:$ciphers"]),
              capture => 1);
    map { s/\R//; } @c;  # chomp @c;
    $protocolciphersuitcount += scalar @c;
    $_ => [ @c ] } @protocols;

However this doesn't actually end up testing TLS1.3 ciphers. Rather, it fails with
Error in cipher list
47344346143168:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:../openssl/ssl/ssl_lib.c:2348:
../util/shlib_wrap.sh ../apps/openssl ciphers 'TLSv1.3:-EXP:-PSK:-SRP:-kDH:-kECDHe' => 1

because 'TLSv1.3' is not a recognized cipher string.
@mattcaswell

I'm not sure it's a good idea to introduce TLS1.3 as a cipher string. Having SSLv3 in there has already caused enough confusion. What does this test use it for?

I strongly agree, it's a protocol version not a cipher string.

Is there a reason it does recognise TLSv1.0 and TLSv1.2, considering they are also protocol versions?

see kurt's comment.

That didn't answer at all why it recognise some TLS version strings as cipher strings.
: ; ./util/shlib_wrap.sh apps/openssl ciphers TLSv1.0
ECDHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-CAMELLIA256-SHA384:RSA-PSK-CAMELLIA256-SHA384:DHE-PSK-CAMELLIA256-SHA384:PSK-AES256-CBC-SHA384:PSK-CAMELLIA256-SHA384:ECDHE-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-CAMELLIA128-SHA256:RSA-PSK-CAMELLIA128-SHA256:DHE-PSK-CAMELLIA128-SHA256:PSK-AES128-CBC-SHA256:PSK-CAMELLIA128-SHA256:ECDHE-PSK-NULL-SHA384:ECDHE-PSK-NULL-SHA256:RSA-PSK-NULL-SHA384:RSA-PSK-NULL-SHA256:DHE-PSK-NULL-SHA384:DHE-PSK-NULL-SHA256:PSK-NULL-SHA384:PSK-NULL-SHA256

It's a mis-feature.  We can't kill it, but we shouldn't make it worse.  The meaning of those strings is confusing to everyone.

Ok.
I'll have a look to see if I can figure out a better way to get the desired ciphers...

Just name the ciphers as we currently do.  It is deliberate that TLS 1.3 didn't create any new ciphers.  The TLS1.1,etc., strings mean (I think) ciphers that were introduced in that version.

Have a look at #2956


Fix wrong scopes of locale.PrettyNumber

Fix the scopes for locale.PrettyNumber on repo project list and user dashboard milestone list. Regression from #24134

That's why we need this:

https://github.com/go-gitea/gitea/pull/24056


Request: Provide docker-compose file for running tests.

Currently tests can not run successfully unless local MySQL service started.
Request: provide docker-compose file to start up redis, mysql service for running tests.

it is provided here: helper/compose.store.yml
develop document is here: http://d.dtm.pub/other/develop.html

the file is not provided at project root dir, because I want to keep it clean and easy to understand for most users.


fix(CI): provide password for docker login retries

Description
The use of herestrings for logins with the retry() wrapper is problematic because <<< only provides the password for the first attemps. e.g. - the first failure is a timeout, subsequent attempts fail as the login gets no password.
Checklist

[x] Investigated and inspected CI test results - scanner v4 tests are pretty flaky

Testing Performed
Here I tell how I validated my change
CI is sufficient.
Reminder for reviewers
In addition to reviewing code here, reviewers must also review testing and request further testing in case the
performed one does not seem sufficient. As a reviewer, you must not approve the change until you understand the
performed testing and you are satisfied with it.

Looks like it's broken:
scripts/lib.sh: line 164: _login: command not found
INFO: Thu Feb 29 03:04:39 UTC 2024: Retry 1/5 exited 127
INFO: Thu Feb 29 03:04:39 UTC 2024: Retrying in 1 seconds...

Its unclear to me why that did not work. But chasing bash in yaml weirdness is not in the direction of making CI greener. So I switched them to use the lib.sh functions.

/retest


cucumber format with a path not working?

Hello, I'm trying to have cucumber output a json report using the format configuration key. Features run fine, but nothing gets written to the specified file:
    cucumberOpts: {
...
        format: ['pretty', 'json:bdd-report.json'], // <string[]> (type[:path]) specify the output format, optionally supply PATH to redirect formatter output (repeatable)
...
    },

Any clues?

We overwrite the reporter in the adapter so this property actually doesn't do anything. I don't know if it makes much sense to allow cucumber reporting since WebdriverIO has its own reporter tools that are especially designed for concurrent test suites.
We should remove this option in the description though.

Ah thank you for explaining... Would there be a way to get the json report at this point in time though?

Would there be a way to get the json report at this point in time though?

No, you can tweak the compiled framework code though

We need json report to generate cucumber-html-report (from here https://github.com/leinonen/cucumber-html-report ). Any thought how we can do this ?

I need the cucumber json output to send from a CI server to a external service that parses the JSON.
The WebdriverIO reporters are ok, but sometimes we need the original cucumber output.
If we can get the cucumber json ouput, It will be fantastic.
I wrote a ugly workaround to achieve this (it was written in a few minutes could be improved):
1- in wdio.conf.js
onPrepare: function (config, capabilities) {
    const resultsJsonLocation = path.join(__dirname, 'tests_result.json')
    if (fs.existsSync(resultsJsonLocation)) {
      fs.unlinkSync(resultsJsonLocation)
    }
  },

2- a cucumber hook to write the json file or append if exists (test/acceptance/step_definitions/support/jsonOutput.js):
const path = require('path')
var Cucumber = require('cucumber')
var JsonFormatter = Cucumber.Listener.JsonFormatter()
var fs = require('fs')

module.exports = function JsonOutputHook () {
  JsonFormatter.log = function (resultString) {
    const jsonFileLocation = path.join(__dirname, '../../../../tests_result.json')

    if (fs.existsSync(jsonFileLocation)) {
      const allResults = JSON.parse(fs.readFileSync(jsonFileLocation).toString())
      allResults.push(JSON.parse(resultString)[0])
      fs.writeFileSync(jsonFileLocation, JSON.stringify(allResults))
    } else {
      fs.writeFileSync(jsonFileLocation, resultString)
    }
  }

  this.registerListener(JsonFormatter)
}

Hi @christian-bromann, I know this issue has some time and there seems to be an existing workaround, but I will like to point that cucumber seems to accept multiple reporters, maybe you guys want to reconsider just honor the format property? I tested the following code in my fork on the adapter.js file and it just worked. Would you guys be open to accept a PR for this functionality?
var formatters = cucumberConf.getFormatters();
formatters.forEach(function (formatter) {
    runtime.attachListener(formatter);
});

just after this line
https://github.com/webdriverio/wdio-cucumber-framework/blob/master/lib/adapter.js#L60
with these 3 lines the reporters in webdriver continue to work normally

Thanks for all the downvotes 👍  😆
The decision to block cucumber reporters was intentional. These reporters only work when running feature specs synchronously one after each other. This is different when running Selenium tests. Since they take longer than unit test you want to run them in parallel. All reporter output becomes nonsense then, here is an example by just running one feature with 3 browser:

Feature: Example feature

    As a user of WebdriverIO
    I should be able to use different commands
    to get informations about elements on the page

Feature: Example feature

    As a user of WebdriverIO
    I should be able to use different commands
    to get informations about elements on the page

  Scenario: Get size of an element
  Scenario: Get size of an element
Feature: Example feature

    As a user of WebdriverIO
    I should be able to use different commands
    to get informations about elements on the page

  Scenario: Get size of an element
  ✔ Given I go on the website "https://google.com/"
  ✔ Given I go on the website "https://google.com/"
․․  ✔ Given I go on the website "https://google.com/"
․  ✔ Then should the element "#gb_70" be 74px wide and 29px high
․
  Scenario: Get title of website
  ✔ Then should the element "#gb_70" be 74px wide and 29px high
․  ✔ Then should the element "#gb_70" be 74px wide and 29px high
․

  Scenario: Get title of website
  Scenario: Get title of website
  ✔ Given I go on the website "https://google.com/"
․  ✔ Given I go on the website "https://google.com/"
․  ✔ Then should the title of the page be "Google"
․  ✔ Given I go on the website "https://google.com/"
․
2 scenarios (2 passed)
4 steps (4 passed)
0m04.090s
  ✔ Then should the title of the page be "Google"
․
2 scenarios (2 passed)
4 steps (4 passed)
0m03.937s
  ✔ Then should the title of the page be "Google"
․
2 scenarios (2 passed)
4 steps (4 passed)
0m03.822s

Looks pretty right? You don't know which browser ran which feature so if there is an error you don't know which browser has caused it. The same would happen with cucumbers json reporter. It would just overwrite the json reports.
 These reporters take into consideration the fact that tests run concurrently. Here is an example on how the spec reporter would look like running the same test:
------------------------------------------------------------------
[phantomjs #2-0] Session ID: 89597bf3-58a0-4b76-9324-71ed3d705895
[phantomjs #2-0] Spec: /Users/christianbromann/Sites/Webprojekte/webdriverjs/DEV/examples/wdio/runner-specs/cucumber/features/my-feature.feature
[phantomjs #2-0] Running: phantomjs
[phantomjs #2-0]
[phantomjs #2-0]   Example feature
[phantomjs #2-0]
[phantomjs #2-0]   Get size of an element
[phantomjs #2-0]       ✓ I go on the website "https://google.com/"
[phantomjs #2-0]
[phantomjs #2-0]   Get title of website
[phantomjs #2-0]       ✓ I go on the website "https://google.com/"
[phantomjs #2-0]       ✓ should the title of the page be "Google"
[phantomjs #2-0]
[phantomjs #2-0]
[phantomjs #2-0] 3 passing (7s)
[phantomjs #2-0]

------------------------------------------------------------------
[chrome #0-0] Session ID: 3802171a-e05a-4f37-9d04-f272789f33f4
[chrome #0-0] Spec: /Users/christianbromann/Sites/Webprojekte/webdriverjs/DEV/examples/wdio/runner-specs/cucumber/features/my-feature.feature
[chrome #0-0] Running: chrome
[chrome #0-0]
[chrome #0-0]   Example feature
[chrome #0-0]
[chrome #0-0]   Get size of an element
[chrome #0-0]       ✓ I go on the website "https://google.com/"
[chrome #0-0]
[chrome #0-0]   Get title of website
[chrome #0-0]       ✓ I go on the website "https://google.com/"
[chrome #0-0]       ✓ should the title of the page be "Google"
[chrome #0-0]
[chrome #0-0]
[chrome #0-0] 3 passing (9s)
[chrome #0-0]

------------------------------------------------------------------
[firefox #1-0] Session ID: ad6941a9-954d-4fc9-b0b2-16f268a784f8
[firefox #1-0] Spec: /Users/christianbromann/Sites/Webprojekte/webdriverjs/DEV/examples/wdio/runner-specs/cucumber/features/my-feature.feature
[firefox #1-0] Running: firefox
[firefox #1-0]
[firefox #1-0]   Example feature
[firefox #1-0]
[firefox #1-0]   Get size of an element
[firefox #1-0]       ✓ I go on the website "https://google.com/"
[firefox #1-0]
[firefox #1-0]   Get title of website
[firefox #1-0]       ✓ I go on the website "https://google.com/"
[firefox #1-0]       ✓ should the title of the page be "Google"
[firefox #1-0]
[firefox #1-0]
[firefox #1-0] 3 passing (10s)
[firefox #1-0]

I think there is no need to have support for cucumber backed reporters. Especially since they are useless in the context of integration testing. Thanks for understanding.

Is there any option in wdio to display the usage of step definitions similiar as the cucumber formatter usage?


[authorization] Implement OAuth-related library+plugin. Contributes to JB#53788 OMP#JOLLA-58

Also @atatarov @okoshkin

I use Contributes because at least it used to be the case that some bot would automatically close the related bug once a commit with Fixes was tagged, even if there are multiple repositories involved or even if further testing is required to determine whether the issue is indeed fixed or if regressions are introduced etc.  Drove me crazy.

I use Contributes because at least it used to be the case that some bot would automatically close the related bug once a commit with Fixes was tagged, even if there are multiple repositories involved or even if further testing is required to determine whether the issue is indeed fixed or if regressions are introduced etc. Drove me crazy.

It's a good habit use to Fixes for the "last" PR.

It's impossible to know if it's the last PR, or whether testing will find an issue with the implementation, etc.


have .net core exe for analysis of migrated components

https://github.com/AAATechGuy/NetCoreMigrationUtils/commit/5ea98fa42d148285a39d3f14043f6c39c7bdcb6d


build: fix screenshot-tool app deployment

Fixes mismatching dependencies that lead to build errors inside of the screenshot-tool app.

Note: Hopefully the CI won't install any other dependencies once it's merged. Locally it works fine and with a lock-file it may work more safely too. But not sure its worth pushing another lock file.

Needs rebase


DHT11 / DHT22 do not work with microbit v2

Hi @microbit-carlos @dpgeorge
Many of our users from https://en.vittascience.com/microbit/ complain about the poor performance of the DHT11 and DHT22 sensors with the micro:bit v2 board and MicroPython. Is there anything we can do to make it work with this version.
I note that the DHT11 sensor works correctly with the micro:bit v1 and the one wire protocol. However, it requires a lot of memory.
Waiting for your help. Thanks very much !
Link to dht11.py : https://github.com/vittascience/microbit-libraries/blob/master/dht11.py

Hi @leomlr,
Do you have any specifics on how it is different in micro:bit V2 and MicroPython? In what way is the performance poor?
If you could provide a simple way to replicate this difference with a V1 and V2 that would also be useful.

For the following program, the behaviour of micro:bit v1 and v2 is different.
from microbit import *
from dht11 import DHT11
import time

dht11_1 = DHT11(pin1)

while True:
  print(dht11_1.getData(d=1))
  print(dht11_1.getData(d=2))
  time.sleep(1)

The v1 is working fine and return the temperature and moisture correctly.
For the v2, the measure do not work. The sensor return this error:

It seems the protocol of linked library dht11 do not work in same way for the 2 versions of micro:bit.

It looks like there is quite a bit of assembly in that library. Have you checked if the assembly is compatible with the nRF52833 (Cortex-M4f) of the micro:bit V2 and that any pins or register you might be accessing are compatible?

Thanks for replies. The assembly is quite different with nRF52833 of micro:bit v2. I try a fix by using work of sndmdk https://github.com/sndmtk/microbit-v2-dht11
Effectively, the DELAY loop needs to be increased by changing r7 to 0xb4 (x4 compared to micro:bit v1).
GPIO pins are different by checking CPU at https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fgpio.html&cp=4_2_0_19&anchor=concept_zyt_tcb_lr
The library is not as stable as with microbit v1. However, measurements are valid approximately every 20 seconds with microbit v2. Unfortunately, my skills are limited in assembler. This library could be greatly improved.

Effectively, the DELAY loop needs to be increased by changing r7 to 0xb4 (x4 compared to micro:bit v1).

V1 runs at 16MHz and V2 at 64Mhz, so the 4 multiplier needed makes sense.

The library is not as stable as with microbit v1. However, measurements are valid approximately every 20 seconds with microbit v2.

Could you expand a little bit more what's the different between V1 and V2 after those changes?

It looks like you're using utime.sleep_ms(...) with interrupts disabled.  That probably won't work well.  You can try instead to use utime.sleep_us(...).
In upstream MicroPython there is a DHT driver which uses C code for the low-level bit operations.  That works well on a variety of MCUs.  Maybe we can bring it into microbit?

have you tried the code in repository https://github.com/rhubarbdog/microbit-dht11 which i think your repository is cloned from?
I also had issues with version 2 microbits. i now have more microbits, but only one sensor so when i do further testing i may discover what the problem is.

@leomir the dht11 should only be sampled every 2 seconds as in the pdf


Docs.rs fails to build on latest version

Currently latest version availableon docs.rs is 0.1.2. All other versions fail to build with an error that is caused by some required features not being enabled.
docs.rs build log link
Also duplicating the full text here:
# rustc version
rustc 1.68.0-nightly (0b90256ad 2023-01-13)
# docs.rs version
docsrs 0.6.0 (19c77a92 2023-01-08)

# build log
[INFO] running `Command { std: "docker" "create" "-v" "/home/cratesfyi/workspace/builds/bevy_mod_scripting-0.2.2/target:/opt/rustwide/target:rw,Z" "-v" "/home/cratesfyi/workspace/builds/bevy_mod_scripting-0.2.2/source:/opt/rustwide/workdir:ro,Z" "-v" "/home/cratesfyi/workspace/cargo-home:/opt/rustwide/cargo-home:ro,Z" "-v" "/home/cratesfyi/workspace/rustup-home:/opt/rustwide/rustup-home:ro,Z" "-e" "SOURCE_DIR=/opt/rustwide/workdir" "-e" "CARGO_TARGET_DIR=/opt/rustwide/target" "-e" "DOCS_RS=1" "-e" "CARGO_HOME=/opt/rustwide/cargo-home" "-e" "RUSTUP_HOME=/opt/rustwide/rustup-home" "-w" "/opt/rustwide/workdir" "-m" "3221225472" "--cpus" "3" "--user" "1001:1001" "--network" "none" "ghcr.io/rust-lang/crates-build-env/linux@sha256:9042d5c95763f71f7b0904716b98ccadf9fc47b0f382ee962aaaed2ac70c9b8d" "/opt/rustwide/cargo-home/bin/cargo" "+nightly" "rustdoc" "--lib" "-Zrustdoc-map" "--features" "lua rhai lua_script_api rhai_script_api teal" "-Z" "unstable-options" "--config" "build.rustdocflags=[\"-Z\", \"unstable-options\", \"--emit=invocation-specific\", \"--resource-suffix\", \"-20230113-1.68.0-nightly-0b90256ad\", \"--static-root-path\", \"/-/rustdoc.static/\", \"--cap-lints\", \"warn\", \"--disable-per-crate-search\", \"--extern-html-root-takes-precedence\"]" "--offline" "-Zunstable-options" "--config=doc.extern-map.registries.crates-io=\"https://docs.rs/{pkg_name}/{version}/x86_64-unknown-linux-gnu\"" "-Zrustdoc-scrape-examples" "-j3" "--target" "x86_64-unknown-linux-gnu", kill_on_drop: false }`
[INFO] [stdout] 174db56665a4e7c628ba6a7b5cf800ee417f0556e9d9af23b34586d031af6fc0
[INFO] [stderr] WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap.
[INFO] running `Command { std: "docker" "start" "-a" "174db56665a4e7c628ba6a7b5cf800ee417f0556e9d9af23b34586d031af6fc0", kill_on_drop: false }`
[INFO] [stderr] warning: Rustdoc did not scrape the following examples because they require dev-dependencies: console_integration_lua, console_integration_rhai, complex_game_loop_lua, game_of_life_lua, game_of_life_rhai, event_recipients_lua, coroutines_lua, documentation_gen_lua, bevy_api_lua, bevy_api_rhai, wrappers
[INFO] [stderr]     If you want Rustdoc to scrape these examples, then add `doc-scrape-examples = true`
[INFO] [stderr]     to the [[example]] target configuration of at least one example.
[INFO] [stderr] warning: Target filter specified, but no targets matched. This is a no-op
[INFO] [stderr]     Checking bevy_ui v0.9.1
[INFO] [stderr]    Compiling mlua v0.8.7
[INFO] [stderr]    Compiling rustls v0.20.8
[INFO] [stderr] error: You must enable one of the features: lua54, lua53, lua52, lua51, luajit, luajit52, luau
[INFO] [stderr]   --> /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/mlua-0.8.7/build/main.rs:52:5
[INFO] [stderr]    |
[INFO] [stderr] 52 | /     compile_error!(
[INFO] [stderr] 53 | |         "You must enable one of the features: lua54, lua53, lua52, lua51, luajit, luajit52, luau"
[INFO] [stderr] 54 | |     );
[INFO] [stderr]    | |_____^
[INFO] [stderr]
[INFO] [stderr] error: could not compile `mlua` due to previous error
[INFO] [stderr] warning: build failed, waiting for other jobs to finish...
[INFO] running `Command { std: "docker" "inspect" "174db56665a4e7c628ba6a7b5cf800ee417f0556e9d9af23b34586d031af6fc0", kill_on_drop: false }`
[INFO] running `Command { std: "docker" "rm" "-f" "174db56665a4e7c628ba6a7b5cf800ee417f0556e9d9af23b34586d031af6fc0", kill_on_drop: false }`
[INFO] [stdout] 174db56665a4e7c628ba6a7b5cf800ee417f0556e9d9af23b34586d031af6fc0

Interestingly, latest git version builds fine with cargo doc

I found the reason, PR soon

That's annoying, I will look into having a CI action check this automatically

@makspll Hey, I've noticed that bevy_mod_scripting doesn't build for docs.rs
Also weird that I couldn't find the docs.rs page for main crate on google in top search results... Usually it works for other crates. Search engines are weird...


[Legacy color picker] Use zoomed preview at the mouse position instead of Label.

Replaces the label with a 3x zoom preview that is following mouse cursor.
https://github.com/user-attachments/assets/861aa3ff-d189-4854-859b-b31d6bd310b5
Can be combined with https://github.com/godotengine/godot/pull/88950 to do the same for a normal color picker.

I get a compilation error on MSVC:
Compiling scene\gui\popup_menu.cpp ...
scene\gui\color_picker.cpp(1576): error C2027: use of undefined type 'Panel'
C:\Users\Hugo\Documents\Git\godotengine\godot\scene/gui/control.h(42): note: see declaration of 'Panel'
scene\gui\color_picker.cpp(1576): error C2672: '_post_initialize': no matching overloaded function found
C:\Users\Hugo\Documents\Git\godotengine\godot\core/os/memory.h(120): note: could be 'T *_post_initialize(T *)'
scene\gui\color_picker.cpp(1577): error C2027: use of undefined type 'Panel'
C:\Users\Hugo\Documents\Git\godotengine\godot\scene/gui/control.h(42): note: see declaration of 'Panel'
scene\gui\color_picker.cpp(1578): error C2027: use of undefined type 'Panel'
C:\Users\Hugo\Documents\Git\godotengine\godot\scene/gui/control.h(42): note: see declaration of 'Panel'
scene\gui\color_picker.cpp(1579): error C2664: 'void Node::add_child(Node *,bool,Node::InternalMode)': cannot convert argument 1 from 'Panel *' to 'Node *'
scene\gui\color_picker.cpp(1579): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or parenthesized function-style cast
C:\Users\Hugo\Documents\Git\godotengine\godot\scene/main/node.h(455): note: see declaration of 'Node::add_child'
scene\gui\color_picker.cpp(1579): note: while trying to match the argument list '(Panel *)'
scene\gui\color_picker.cpp(1581): error C2027: use of undefined type 'Panel'
C:\Users\Hugo\Documents\Git\godotengine\godot\scene/gui/control.h(42): note: see declaration of 'Panel'
scene\gui\color_picker.cpp(1581): error C2672: '_post_initialize': no matching overloaded function found
C:\Users\Hugo\Documents\Git\godotengine\godot\core/os/memory.h(120): note: could be 'T *_post_initialize(T *)'
scene\gui\color_picker.cpp(1582): error C2027: use of undefined type 'Panel'
C:\Users\Hugo\Documents\Git\godotengine\godot\scene/gui/control.h(42): note: see declaration of 'Panel'
scene\gui\color_picker.cpp(1583): error C2027: use of undefined type 'Panel'
C:\Users\Hugo\Documents\Git\godotengine\godot\scene/gui/control.h(42): note: see declaration of 'Panel'
scene\gui\color_picker.cpp(1584): error C2027: use of undefined type 'Panel'
C:\Users\Hugo\Documents\Git\godotengine\godot\scene/gui/control.h(42): note: see declaration of 'Panel'
scene\gui\color_picker.cpp(1585): error C2027: use of undefined type 'Panel'
C:\Users\Hugo\Documents\Git\godotengine\godot\scene/gui/control.h(42): note: see declaration of 'Panel'
scene\gui\color_picker.cpp(1591): error C2027: use of undefined type 'Panel'
C:\Users\Hugo\Documents\Git\godotengine\godot\scene/gui/control.h(42): note: see declaration of 'Panel'
scene\gui\color_picker.cpp(1594): error C2027: use of undefined type 'Panel'
C:\Users\Hugo\Documents\Git\godotengine\godot\scene/gui/control.h(42): note: see declaration of 'Panel'
scene\gui\color_picker.cpp(1597): error C2027: use of undefined type 'Panel'
C:\Users\Hugo\Documents\Git\godotengine\godot\scene/gui/control.h(42): note: see declaration of 'Panel'
scene\gui\color_picker.cpp(1666): error C2027: use of undefined type 'Panel'
C:\Users\Hugo\Documents\Git\godotengine\godot\scene/gui/control.h(42): note: see declaration of 'Panel'
scons: *** [scene\gui\color_picker.windows.editor.x86_64.obj] Error 2
scons: building terminated because of errors.

I get a compilation error on MSVC 2022

Rebased and updated, this should be fixed now.

You can use minimum size instead of size, so ignore will work correctly.

Hi, note that this causes a regression with the canvas_items scaling mode.

Working in canvas_items scaling mode should be fixed.

Zoom preview is a bit blurry in a scaled mode.

This may be due to https://github.com/godotengine/godot/issues/86563. I've been meaning to investigate that one for a while, likely using RenderDoc to make sure the glyph texture sizes match the size that should be used according to the oversampling factor and viewport resolution.

The non-legacy picking could get the same treatment, but it's more tricky.

I have updated https://github.com/godotengine/godot/pull/88950 to do the same for native picker.

Superseded by https://github.com/godotengine/godot/pull/88950 (not includes the same for both native and legacy pickers).


Ether to Fiat Converter

As a user, I should see an ether balance that can be converted to a Fiat currency. Optionally the ether amount could be displayed and toggled to a visual amount of Fiat currency on click.

Closing this issue in rimble-ui. Will re-open a related issue in appropriate repo.


Upgrade Jasmine source to 1.3.1

Thanks for the awesome grunt task. I use it all of the time.

can probably close this now.


huggingface-hub: 0.0.18 -> 0.1.1

Motivation for this change
Useful for transformers python lib
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 144886 run on x86_64-linux 1

10 packages failed to build:

python38Packages.datasets
python38Packages.huggingface-hub
python38Packages.spacy-transformers
python38Packages.tokenizers
python38Packages.transformers
python39Packages.datasets
python39Packages.huggingface-hub
python39Packages.spacy-transformers
python39Packages.tokenizers
python39Packages.transformers

Seems like upstream changed from ruamel-yaml to pyyaml:
diff --git a/pkgs/development/python-modules/huggingface-hub/default.nix b/pkgs/development/python-modules/huggingface-hub/default.nix
index a2afa52f53f..844171d4df7 100644
--- a/pkgs/development/python-modules/huggingface-hub/default.nix
+++ b/pkgs/development/python-modules/huggingface-hub/default.nix
@@ -6,7 +6,7 @@
 , importlib-metadata
 , packaging
 , requests
-, ruamel-yaml
+, pyyaml
 , tqdm
 , typing-extensions
 }:
@@ -27,7 +27,7 @@ buildPythonPackage rec {
   propagatedBuildInputs = [
     filelock
     requests
-    ruamel-yaml
+    pyyaml
     tqdm
     typing-extensions
   ] ++ lib.optionals (pythonOlder "3.8") [ importlib-metadata ];

Closing after #147426


Revert to object-based contracts

Change-type: patch
Signed-off-by: Stevche Radevski<EMAIL_ADDRESS>

@balena-ci I self-certify!


Alvr error

Closing as nothing is specified please respond in a few days with a description of the issue and I'll open it again.


linfa-kernel fails to compile

When I try to build the wine quality example for linfa-svm, I get the following error:
   Compiling linfa-kernel v0.6.1
error[E0599]: no method named `mul` found for reference `&CsMatBase<F, usize, Vec<usize>, Vec<usize>, Vec<F>>` in the current scope
  --> C:\Users\[username]\.cargo\registry\src\index.crates.io-6f17d22bba15001f\linfa-kernel-0.6.1\src\inner.rs:64:14
   |
64 |         self.mul(rhs)
   |              ^^^ method not found in `&CsMatBase<F, usize, Vec<usize>, Vec<usize>, Vec<F>>`

error[E0599]: no method named `mul` found for reference `&CsMatBase<F, usize, &'a [usize], &'a [usize], &'a [F]>` in the current scope
   --> C:\Users\[username]\.cargo\registry\src\index.crates.io-6f17d22bba15001f\linfa-kernel-0.6.1\src\inner.rs:109:14
    |
109 |         self.mul(rhs)
    |              ^^^ method not found in `&CsMatBase<F, usize, &[usize], &[usize], &[F]>`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `linfa-kernel` (lib) due to 2 previous errors

I am on windows 10 with rustc version 1.70.0. I also tried version 0.5.1 which gives me the same error, and it also happens when I try it on my Arch Linux machine with rustc version 1.68.0.
I looked around in the source files, and it appears that this problem is related to the trait binding of the generic F:
impl<F: linfa::Float> Inner for CsMat<F>

and
impl<'a, F: linfa::Float> Inner for CsMatView<'a, F>

Any help would be appreciated.

I have the same issue. Seems like CsMat which is imported from sprs cannot implement std::ops:Mul for some reason. Multiplication of a CsMat with an ArrayView2 is the issue which was  handled by the std::ops::Mul trait previously from what I can see. But for some reason this is now broken.

Yes. I tried creating a new CsMat in a test crate, and I was able to call mul() on it. So I think the issue is related to CsMat not liking linfa::Float as the generic.

I changed the start of the impl block to this:
impl<F: Float> Inner for CsMat<F> where
    CsMat<F>: Mul {
        ...
}

which results in several errors that look like this:
error[E0277]: cannot multiply `CsMatBase<F, usize, Vec<usize>, Vec<usize>, Vec<F>>` by `CsMatBase<F, usize, Vec<usize>, Vec<usize>, Vec<F>>`
   --> algorithms/linfa-kernel/src/lib.rs:196:20
    |
196 | impl<'a, F: Float> Kernel<F> {
    |                    ^^^^^^^^^ no implementation for `CsMatBase<F, usize, Vec<usize>, Vec<usize>, Vec<F>> * CsMatBase<F, usize, Vec<usize>, Vec<usize>, Vec<F>>`
    |
    = help: the trait `Mul` is not implemented for `CsMatBase<F, usize, Vec<usize>, Vec<usize>, Vec<F>>`
    = help: the following other types implement trait `Mul<Rhs>`:
              <&'a CsMatBase<N, I, IpS, IS, DS, Iptr> as Mul<&'b ndarray::ArrayBase<DS2, Dim<[usize; 1]>>>>
              <&'a CsMatBase<N, I, IpS, IS, DS, Iptr> as Mul<&'b ndarray::ArrayBase<DS2, Dim<[usize; 2]>>>>
              <&'a CsMatBase<N, I, IpS1, IS1, DS1, Iptr> as Mul<&'b CsMatBase<N, I, IpS2, IS2, DS2, Iptr>>>
              <&'a CsMatBase<N, I, IpS1, IS1, DS1, Iptr> as Mul<&'b CsVecBase<IS2, DS2, N, I>>>
              <&'a CsMatBase<f32, I, IpStorage, IStorage, DStorage, Iptr> as Mul<f32>>
              <&'a CsMatBase<f64, I, IpStorage, IStorage, DStorage, Iptr> as Mul<f64>>
              <&'a CsMatBase<i16, I, IpStorage, IStorage, DStorage, Iptr> as Mul<i16>>
              <&'a CsMatBase<i32, I, IpStorage, IStorage, DStorage, Iptr> as Mul<i32>>
            and 8 others
note: required for `CsMatBase<F, usize, Vec<usize>, Vec<usize>, Vec<F>>` to implement `Inner`
   --> algorithms/linfa-kernel/src/inner.rs:60:16
    |
60  | impl<F: Float> Inner for CsMat<F> where
    |                ^^^^^     ^^^^^^^^
61  |     CsMat<F>: Mul {
    |               --- unsatisfied trait bound introduced here

Could be related to https://github.com/sparsemat/sprs/issues/278

This is a regression introduced with the sprs::MulAcc trait in 0.11 https://github.com/sparsemat/sprs/blob/master/changelog.rst

It works now. Thanks!

I still get this issue. What version is the fix on?

Thanks! @AVS-Origami

I;ve just opened https://github.com/sparsemat/sprs/issues/330

I'm having this issue again today on linfa 0.7.0.
Thanks to the above I resolved by pinning sprs = "=0.11.1" and everything is compiling again. Would you accept a pull request to pin the sprs version?


Provide sample app

[x] Use oav's validate example with redis swagger
[x] Provide sample package.json ith oav as dependency

Sent an email.


six.iterbytes name collision with (deferred) PEP 0467

https://www.python.org/dev/peps/pep-0467/#addition-of-optimised-iterator-methods-that-produce-bytes-objects
>>> tuple(b"ABC".iterbytes())
(b'A', b'B', b'C')

in an ideal world I'd like to see:
six.iterbytes(b"ABC")
(b'A', b'B', b'C')

six.iterords(b"ABC")
(65, 66, 67)

but that would require a major version change, as it's changing iterbytes to do the opposite thing

/cc @ncoghlan @ethanfurman


Deploy to maven central

[ ] retrieve credentials for deployment
[ ] make a separate gradle task for deployment (skip jacodb-http module)
[ ] create deployment action

groupId: org.jacodb
artifactId: jacodb


⚠ ClamAV has degraded performance

In 9d45419, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 466 ms

Resolved: ClamAV performance has improved in 825e1f7 after 5 minutes.


Subtract 1 from sequence length of models on Together

Together has input validations errors such as
Input validation error: `inputs` tokens + `max_new_tokens` must be <= 2048. Given: 2019 `inputs` tokens and 30 `max_new_tokens`

but the number of inputs tokens is exactly one more than the actual number.

Sure: #2080
I already sent this to Discord two months ago.


Add recurrenceLastExpansion billing event logic code

This change is

I haven't gotten to the tests yet, so it's not ready for LGTM, but please look at the approach in this code and let me know if you can think of any issues with it.
And yes, as currently written, it's going to take a full year until all existing recurrings are updated so that they don't all count as in scope, as the existing recurring is only updated when a new one time billing event is being expanded.  I might change so that so that the recurrenceLastExpansion is updated (to replace for the default value of 2021-06-01 in the DB), even if no one time billing event is yet being written.  E.g., if the recurrenceLastExpansion has its default value of 2021-06-01, but this runs and determines that the last one-time billing event that was expanded is from 2022-03-04, then the recurrenceLastExpansion should be updated to 2022-03-04 as well.  I guess I'll add in that logic too (but even without it, it's still doing the correct thing, albeit with more work for the first year).


WIP use BorrowedFd in arguments

Implementation of https://github.com/Smithay/wayland-rs/issues/592.
This is required for IO safety. Or perhaps AsFd generics would be useful.
This will be a breaking API change, and require Rust 1.65.
Currently wayland-client compiles here, but server-side needs the same changes, and things need to be cleaned up a bit.

Hm, an awkward API stability concern here: adding Request/Event enums are non-exhastive. So adding a variant is considered a non-breaking change. But as this is currently implemented in this PR, adding a variant with an FD adds a type generic, which is breaking.
That is needed because an enum can't have a type generic unless a variant uses that type parameter. Maybe if it's non-exhaustive anyway, it could have a variant that's never constructed with a PhantomData? And an uninhabited type for good measure.

Currently Request/Event types and methods also accept String and Vec<u8> instead of &str and &[u8]. Not that much of an issue since those types aren't the most common in Wayland, but presumably with a GAT here those could also be changed, avoiding an extra allocation and provide a more idiomatic API.

Added generation of a #doc(hidden) phantom variant for API stability.
This should be good now.