Add core__procedure table

Puts another brick in the wall of #139
Checklist

[x] Consider if documentation in docs/ needs to be updated

If you've changed the structure of a table, you may need to run generate-md
If you've added/removed core study fields that not in US Core, update our list of those in core-study-details.md

[x] Consider if tests should be added
[x] Update template repo if there are changes to study configuration in manifest.toml

Should include Procedure Category , which "should" be implemented at most sites because it is easy, BCH Cerner is not a good indicator for procedure coding because it was DIY home grown.

Should include Procedure Category , which "should" be implemented at most sites because it is easy, BCH Cerner is not a good indicator for procedure coding because it was DIY home grown.

STU4 https://hl7.org/fhir/us/core/STU4/StructureDefinition-us-core-procedure.html
https://hl7.org/fhir/R4/valueset-procedure-category.html

Should include Procedure Category , which "should" be implemented at most sites because it is easy, BCH Cerner is not a good indicator for procedure coding because it was DIY home grown.

Done!


Review Design Issues

[ ] Guess Bounds
[ ] Analysis Methods (#18)
[ ] Time Formatting
[ ] Slicing
[ ] holocube - project and element names
[ ] Vector Field

We didn't look at it explicitly while we were brainstorming, but also have a wiki page that is useful to explain these issues in more detail.
I think everything mentioned on the wiki falls into the list above but it is worth looking at for some additional context.

#63 for guess bounds

#64 and #12 for methods

vecotr field : #66


Launching Flutter Webapp with Localization in Debug Mode crashes with TypeErrorImpl: Unexpected null value.

Steps to reproduce

Create a simple Flutter project targeting Web and configure localization support according https://docs.flutter.dev/ui/accessibility-and-internationalization/internationalization
Run the application via flutter run -d edge --debug

Expected results
The application opens in the browser and is operational.
Actual results
The browser opens and displays a red error page. In the command line this error is shown:
...
When the exception was thrown, this was the stack:
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/errors.dart 296:3       throw_
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/operations.dart 586:18  nullCheck
packages/localization_test/main.dart 15:44                                        build
packages/flutter/src/widgets/framework.dart 5557:22
...

The nullcheck error is because AppLocalizations.of(context) unexpectedly returns null when running Flutter in Debug Mode on Web.
Code sample
Code sample
localization_test.zip

Screenshots or Video

Screenshots / Video demonstration

Logs
Logs
> flutter run -d edge --debug
Launching lib\main.dart on Edge in debug mode...
Waiting for connection from debug service on Edge...               14,1s
This app is linked to the debug service: ws://<IP_ADDRESS>:62686/ffzbAU4e74k=/ws
Debug service listening on ws://<IP_ADDRESS>:62686/ffzbAU4e74k=/ws

  To hot restart changes while running, press "r" or "R".
For a more detailed help message, press "h". To quit, press "q".

A Dart VM Service on Edge is available at: http://<IP_ADDRESS>:62686/ffzbAU4e74k=
══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞═══════════════════════════════════════════════════════════
The following TypeErrorImpl was thrown building MyApp(dirty):
Unexpected null value.

The relevant error-causing widget was:
  MyApp MyApp:file:///D:/localization_test/lib/main.dart:5:16

When the exception was thrown, this was the stack:
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/errors.dart 296:3       throw_
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/operations.dart 586:18  nullCheck
packages/localization_test/main.dart 15:44                                        build
packages/flutter/src/widgets/framework.dart 5557:22                               build
packages/flutter/src/widgets/framework.dart 5487:15                               performRebuild
packages/flutter/src/widgets/framework.dart 5203:7                                rebuild
packages/flutter/src/widgets/framework.dart 5469:5                                [_firstBuild]
packages/flutter/src/widgets/framework.dart 5463:5                                mount
packages/flutter/src/widgets/framework.dart 4340:15                               inflateWidget
packages/flutter/src/widgets/framework.dart 3849:18                               updateChild
packages/flutter/src/widgets/framework.dart 5512:16                               performRebuild
packages/flutter/src/widgets/framework.dart 5203:7                                rebuild
packages/flutter/src/widgets/framework.dart 5469:5                                [_firstBuild]
packages/flutter/src/widgets/framework.dart 5463:5                                mount
packages/flutter/src/widgets/framework.dart 4340:15                               inflateWidget
packages/flutter/src/widgets/framework.dart 3849:18                               updateChild
packages/flutter/src/widgets/framework.dart 5512:16                               performRebuild
packages/flutter/src/widgets/framework.dart 5650:11                               performRebuild
packages/flutter/src/widgets/framework.dart 5203:7                                rebuild
packages/flutter/src/widgets/framework.dart 5469:5                                [_firstBuild]
packages/flutter/src/widgets/framework.dart 5641:11                               [_firstBuild]
packages/flutter/src/widgets/framework.dart 5463:5                                mount
packages/flutter/src/widgets/framework.dart 4340:15                               inflateWidget
packages/flutter/src/widgets/framework.dart 3849:18                               updateChild
packages/flutter/src/widgets/framework.dart 5512:16                               performRebuild
packages/flutter/src/widgets/framework.dart 5203:7                                rebuild
packages/flutter/src/widgets/framework.dart 5469:5                                [_firstBuild]
packages/flutter/src/widgets/framework.dart 5463:5                                mount
packages/flutter/src/widgets/framework.dart 4340:15                               inflateWidget
packages/flutter/src/widgets/framework.dart 3849:18                               updateChild
packages/flutter/src/widgets/framework.dart 5512:16                               performRebuild
packages/flutter/src/widgets/framework.dart 5203:7                                rebuild
packages/flutter/src/widgets/framework.dart 5469:5                                [_firstBuild]
packages/flutter/src/widgets/framework.dart 5463:5                                mount
packages/flutter/src/widgets/framework.dart 4340:15                               inflateWidget
packages/flutter/src/widgets/framework.dart 3849:18                               updateChild
packages/flutter/src/widgets/view.dart 291:16                                     [_updateChild]
packages/flutter/src/widgets/view.dart 314:5                                      mount
packages/flutter/src/widgets/framework.dart 4340:15                               inflateWidget
packages/flutter/src/widgets/framework.dart 3849:18                               updateChild
packages/flutter/src/widgets/framework.dart 5512:16                               performRebuild
packages/flutter/src/widgets/framework.dart 5203:7                                rebuild
packages/flutter/src/widgets/framework.dart 5469:5                                [_firstBuild]
packages/flutter/src/widgets/framework.dart 5463:5                                mount
packages/flutter/src/widgets/framework.dart 4340:15                               inflateWidget
packages/flutter/src/widgets/framework.dart 3849:18                               updateChild
packages/flutter/src/widgets/binding.dart 1581:16                                 [_rebuild]
packages/flutter/src/widgets/binding.dart 1550:5                                  mount
packages/flutter/src/widgets/binding.dart 1503:16                                 <fn>
packages/flutter/src/widgets/framework.dart 2845:11                               buildScope
packages/flutter/src/widgets/binding.dart 1502:12                                 attach
packages/flutter/src/widgets/binding.dart 1239:26                                 attachToBuildOwner
packages/flutter/src/widgets/binding.dart 1221:5                                  attachRootWidget
packages/flutter/src/widgets/binding.dart 1207:7                                  <fn>
dart-sdk/lib/_internal/js_dev_runtime/private/isolate_helper.dart 48:11           internalCallback

════════════════════════════════════════════════════════════════════════════════════════════════════
The Flutter DevTools debugger and profiler on Edge is available at: http://<IP_ADDRESS>:9101?uri=http://<IP_ADDRESS>:62686/ffzbAU4e74k=

Flutter Doctor output
Doctor output
> flutter doctor -v
[√] Flutter (Channel stable, 3.22.3, on Microsoft Windows [Version 10.0.19045.4651], locale de-DE)
    • Flutter version 3.22.3 on channel stable at D:\scoop\apps\flutter\current
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision b0850beeb2 (2 weeks ago), 2024-07-16 21:43:41 -0700
    • Engine revision 235db911ba
    • Dart version 3.4.4
    • DevTools version 2.34.3
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[√] Windows Version (Installed version of Windows is version 10 or higher)

[√] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at D:\dev\android-sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = D:\dev\android-sdk
    • Java binary at: D:\scoop\apps\android-studio\current\jbr\bin\java
    • Java version OpenJDK Runtime Environment (build 17.0.9+0--11185874)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • CHROME_EXECUTABLE = C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe

[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.10.4)
    • Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
    • Visual Studio Community 2022 version 17.10.35027.167
    • Windows 10 SDK version 10.0.22621.0

[√] Android Studio (version 2023.3)
    • Android Studio at D:\scoop\apps\android-studio\current
    • 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.9+0--11185874)

[√] Connected device (3 available)
    • Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.19045.4651]
    • Chrome (web)      • chrome  • web-javascript • unknown
    • Edge (web)        • edge    • web-javascript • Microsoft Edge 127.0.2651.74

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

Solved via documentation found at https://localizely.com/i18n-questions/flutter/why-flutter-returns-null-for-applocalizations-of-context/


SAP BTP OPERATOR in our k8s cluster is crashing infinitely

Version:
ghcr.io/sap/sap-btp-service-operator/controller:v0.5.4
I tried to make some changes and provision btp service instance and btp service binding.
But the service instance manifest had some issues and caused the BTP operator to crash .
2024-09-09T15:06:49Z    INFO    Observed a panic in reconciler: runtime error: invalid memory address or nil pointer dereference    {"controller": "servicebinding", "controllerGroup": "services.cloud.sap.com", "controllerKind": "ServiceBinding", "ServiceBinding": {"name":"argocd-key","namespace":"default"}, "namespace": "default", "name": "argocd-key", "reconcileID": "6379c665-8827-448e-b162-006030fc2bc2"}
I am currently trying to delete the BTP service binding manually or forcefully, but it is stuck because the deletion process attempts to communicate with the BTP operator, which is in a crashing state
And i do not have access to the btp operator namespace so I can not delete btp operator pod for reconciliation.
Logs
2024-09-09T15:06:49Z    INFO    Observed a panic in reconciler: runtime error: invalid memory address or nil pointer dereference    {"controller": "servicebinding", "controllerGroup": "[services.cloud.sap.com](http://services.cloud.sap.com/)", "controllerKind": "ServiceBinding", "ServiceBinding": {"name":"argocd-key","namespace":"default"}, "namespace": "default", "name": "argocd-key", "reconcileID": "6379c665-8827-448e-b162-006030fc2bc2"}
2024-09-09T14:50:46Z    INFO    Observed a panic in reconciler: runtime error: invalid memory address or nil pointer dereference    {"controller": "servicebpanic: runtime error: invalid memory address or nil pointer dereference [recovered]                                                                             panic: runtime error: invalid memory address or nil pointer dereference                                                                                [signal SIGSEGV: segmentation violation code=0x1 addr=0x1a0 pc=0x14a06f2]                                                                                goroutine 134 [running]:                                                                                sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile.func1()                                                                          /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:115 +0x1e5                                                     panic({0x1606840?, 0x25f2eb0?})                                                                                /usr/local/go/src/runtime/panic.go:914 +0x21f                                                                                github.com/SAP/sap-btp-service-operator/controllers.(*ServiceBindingReconciler).Reconcile(0xc00049b7f8, {0x1a5a1d8, 0xc000438fc0}, {{{0xc000396920, 0x7}, {0    /workspace/controllers/servicebinding_controller.go:96 +0x5b2                                                                                sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile(0x1a5a1d8?, {0x1a5a1d8?, 0xc000438fc0?}, {{{0xc000396920?, 0x155d620?}, {0xc0    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:118 +0xb7                                                      sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler(0xc000186140, {0x1a5a210, 0xc000024280}, {0x167c600?, 0xc00041d520?})     /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:314 +0x365                                                     sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem(0xc000186140, {0x1a5a210, 0xc000024280})                               /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:265 +0x1c9                                                     sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2()                                                                            /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:226 +0x79                                                      created by sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2 in goroutine 102                                                    /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.0/pkg/internal/controller/controller.go:222 +0x565                                                     Stream closed EOF for sap-btp-service-operator/sap-btp-operator-controller-manager-547cf79474-w7x85 (manager)
I also tried
try to delete the ServiceBinding argocd-key and remove its finalizer. but did not work.
error I am getting is
 error: servicebindings.services.cloud.sap.com "argocd-key" could not be patched: Internal error occurred: failed calling webhook "mservicebinding.kb.io": failed to call webhook: Post "https://sap-btp-operator-webhook-service.sap-btp-service-operator.svc:443/mutate-services-cloud-sap-com-v1-servicebinding?timeout=10s": no endpoints available for service "sap-btp-operator-webhook-service"
You can run `kubectl replace -f /var/folders/24/pdjyg77x30gdnd70pcm2z7jw0000gn/T/kubectl-edit-3513063779.yaml` to try this update again.

Need your help, Thanks

Hi @tarun00000
This issue has been resolved in v0.5.10, you are using a very old version of the operator. please upgrade the operator and try again.

Hi kerenlahav,
Thankyou for the response. I will test and close this issue.


ImportC: disallow implicit function declaration

As use of them became invalid 22 years ago.

As use of them became invalid 22 years ago.

This came up when compiling zlib though, which made use of an undeclared fseek.


Detect when external.addresses includes domain

What would you like to be added?
external.addresses can be a list of either IPs or subdomains. If subdomains, then it is either 1) used as the hostname if external.domain is set, or 2) used as the subdomain when external.domain exists.
If a user sets the following it results in an error:
external.addresses: ["redpanda.some.domain.com"]

This can be improved so that it's possible for domains to be used in `external.addresses
Why is this needed?
Users have expected to use only external.addresses. Also I can see that some users may want to have different domains for each broker.

subdomain means some.domain.com ... I think you mean shortname which is the hostname portion of the fully qualified domain name (e.g. redpanda).
Should be pretty straight forward to detect this by looking for any dots in the values of external.addresses.
The other thing that could be done is split each entry in external.addresses on dot and autoassemble the external.domain ... this would require us ensuring that the domain entries are all the same.


Adding explicit scopes excluded in All cloud apps

Customers tend to get confused on when we include Graph while applying the CA policy. Calling out the basic scopes explicitly should help to avoid such confusions.

@PramodKumarHK89 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


Add the new pipe usage for Command:stdin(), Command:stdout(), and Command:stderr()

Add the new pipe usage for Command:stdin(), Command:stdout(), and Command:stderr() to https://yazi-rs.github.io/docs/plugins/utils#command
The new stdin/stdout/stderr methods will accept the piped stdin, stdout, or stderr of another process. We need to show this in the documentation. Here’s a good example: https://github.com/sxyazi/yazi/pull/1033
It would also be good to include usage instructions for the new take_stdin, take_stdout, and take_stderr methods for Child.

Done in https://github.com/yazi-rs/yazi-rs.github.io/pull/102 by @AnirudhG07, thanks a lot!


Loading a saved game with an ongoing mission does not delete the task.

We no longer allow loading in the middle of the mission, so this is no longer applicable.


Add a submit() function to the response of superForm()

Is your feature request related to a problem? Please describe.
When using a Dialog from https://svelte-headlessui.goss.io/docs/dialog to confirm the submitting of the form, the submit button does not work because the Dialog is rendered at the root of the page, to provide better accessibility. With this, the button element stops being a child of the form element, not allowing the form to be submitted.
Describe the solution you'd like
I think a submit() function would be helpful in this scenario, so we can call it in the on:click of the submit button inside the Dialog.
Describe alternatives you've considered
Currently I've tried binding the form element to a variable and calling form.submit() in a handler function. However, I'm not sure how to preventDefault() in this case, so the page always refreshes when submitting.
Edit: a new workaround I've found that works but is questionable... Is to create a hidden submit button inside the form and bind it to a variable. Then call button.click() from the Dialog button, while also closing the Dialog on:click.

duplicate of #75


Jetbrains GoLand - Slow LSP

@ainsleyclark

It seems using the LSP with GoLand is incredibly slow within .templ files.
I have to reboot GoLand so types are recognised and it doesn't always work.
Would there by any reason for this? Or ways that it could be improved?

Copied from https://github.com/a-h/templ/issues/630

I have the same issue. I'm using Goland 2023.3.6 and Goland 2024.1 Release Candidate.
Also, I'm experiencing inconsistent code completion with the templ tool. I followed the installation instructions (go install... and go get...) and installed the plugin, but I'm unsure if additional setup is required.

Since I installed the latest version I even hat some crashes when working on templ files. Not very concerning (I'm also using some beta-versions of plugins) but mentionable.

The latest version of the plugin contains some config options that will aid in troubleshooting. I've updated the docs, however the new plugin version is still in the approval process.
https://templ.guide/commands-and-tools/ide-support#troubleshooting-1

Same here. In my case it only works like 10% of the time, to a point that I consider it to not being slow but not working at all.
This on:

Windows 11 (No WSL)
Goland 2024.1
templ plugin version 0.14
gopls 0.15.2

And I dont see much when tracking the logs for troubleshooting, just:
{"level":"error","ts":"2024-04-09T14:48:16+08:00","caller":"proxy/client.go:65","msg":"unable to complete because the sourcemap for the URI doesn't exist in the cache","uri":"file:///C:xxxxxxxxxxx
And:
{"level":"warn","ts":"2024-04-09T14:48:16+08:00","caller":"proxy/server.go:380","msg":"completion: got gopls error","error":"context canceled"}

@heagma if you enable troubleshooting, can you see anything on the web server?
You should see a file that matches the URI that is mentioned in that error log.

@joerdav The file mentioned in the error is just my template file. The full line is:
{"level":"error","ts":"2024-04-09T14:48:16+08:00","caller":"proxy/client.go:65","msg":"unable to complete because the sourcemap for the URI doesn't exist in the cache","uri":"file:///C:xxxxx/internal/templates/home.templ", "stacktrace":"github.com/a-h/templ/cmd/templ/lspcmd/proxy.Client.PublishDiagnostics
 C:/Users/xxxxx/go/pkg/mod/github.com/a-h/templ@v0.2.648/cmd/templ/lspcmd/proxy/client.go:65
github.com/a-h/protocol.clientDispatch
 C:/Users/xxxxx/go/pkg/mod/github.com/a-h/protocol@v0.0.0-20230224160810-b4eec67c1c22/client.go:102
github.com/a-h/protocol.NewClient.ClientHandler.func1
  C:/Users/xxxxx/go/pkg/mod/github.com/a-h/protocol@v0.0.0-20230224160810-b4eec67c1c22/client.go:36
github.com/a-h/protocol.Handlers.ReplyHandler.func1
  C:/Users/xxxxx/go/pkg/mod/go.lsp.dev/jsonrpc2@v0.10.0/handler.go:35
github.com/a-h/protocol.Handlers.AsyncHandler.func2.2
  C:/Users/xxxxx/go/pkg/mod/go.lsp.dev/jsonrpc2@v0.10.0/handler.go:114"}

Also, the gopls is not outputing anything on the logs (I confirmed it is running on Windows task manager), only the templ is giving any sort of info:

Sorry, what I mean is the debug web server, if you look in the trouble shoot guide it gives a value to put in the http option of the extension, this should start a web server that exposes the internal state of the plugin, it would be useful for troubleshooting to see that page :)

Yes, the server displays the filename with few links (source code for .templ/.go files), nothing else :

I actually encounter slow LSP as well. The Go Templ VSCode is working fine without any issues. In the image below, the suggestion keeps on loading in Goland.
Image: Goland.

In VSCode, the suggestion can run without any problems.
Image: VSCode.

Here is what I observed. This issue happens with importing struct from outer package.
For example, I tried to use a struct belonging to another package. Templ was not able to load the suggestion.

However, if I include the struct inside the same page, it worked.

By the way, I think the issue is now resolved by Goland 2024.1.1. I no longer had the slow response from templ and all completion now is working fine.
Before the 2024.1.1 version, Goland had issue with the code inspection. Therefore, I assume that this was the root cause.
Image: Code completion is now working.

Image: Release note of Goland 2024.1.1

Okay, great outcome! I'll close this for now and we can track any other issues seperately.


Revert "Added functionality to switch title depending on if app is in patient…"

Reverts standardhealth/flux#80

This needs to be rebased with greg's pull request that just got merged


DBZ-1698 Handle toasted unknown column values

https://issues.redhat.com/browse/DBZ-1698

Any idea about the test failure?

@gunnarmorling Fixed another timing issue

Applied; thx!


app not response when use payload local api in hook like afterRead

Link to reproduction
No response
Payload Version
3.0.0-beta.47
Node Version
20.14.0
Next.js Version
15.0.0-rc.0
Describe the Bug
app not response when use payload local api in hook like afterRead
Reproduction Steps
in collection afterRead hook, i want to use payload.find ,but then the app crushed
Adapters and Plugins
No response

Hey, happy to take a closer look if you can provide a reproduction. I'll close this issue until we have further information.


⚠ Bofrost.de has degraded performance

In cbe21d7, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1614 ms

Resolved: Bofrost.de performance has improved in a763594 after 6 minutes.


Sketch Palettes not working on Sketch 56.3

Nothing happens when trying to save/load/clear palette with the latest Sketch update.
Sketch 56.3 | MacOS Mojave 10.14.6

I just checked it out, and I was not able to reproduce the issue. Could you double-check you are using the latest version of the plugin? And if so, and you still have the issue, could you share the palette you are trying to load so I can see if that helps me reproduce the bug?

Hi @andrewfiorillo — I uninstalled and reinstalled and the problem went away. My apologies!!


Implement ingest store/database

@cbush can you include a brief overview in the PR description of what's included in this PR?


Fix demo link in README

The description was fixed after this comment, but I noticed that the link in README is still broken. This PR aims to fix it.

Thanks for fixing this! :heart:


Fix access level for default Kubelet file discovered with CIS 1.8 benchmark

What type of PR is this?

/kind bug
What this PR does / why we need it:
Changes the access level to 600 for the default kubelet file
From Kube-Bench
[FAIL] 4.1.9 If the kubelet config.yaml configuration file is being used validate permissions set to 600 or more restrictive (Automated)
== Remediations node ==
4.1.9 Run the following command (using the config file location identified in the Audit step)
chmod 600 /etc/default/kubelet
Which issue(s) this PR fixes:

Fixes #
Requirements:

[ ] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Special notes for your reviewer:
Release note:
none

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 75.969%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2627

Relevant Lines:
3458

💛  - Coveralls

I think you're missing a make generate

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 75.969%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2627

Relevant Lines:
3458

💛  - Coveralls

Why do we need to change the access to 600? Is it to tighten the access level?

Why do we need to change the access to 600? Is it to tighten the access level?
From Kube-Bench
[FAIL] 4.1.9 If the kubelet config.yaml configuration file is being used validate permissions set to 600 or more restrictive (Automated)

== Remediations node ==
4.1.9 Run the following command (using the config file location identified in the Audit step)
chmod 600 /etc/default/kubelet

will let abe2e's run

fixing abe2e's at the moment, then will let it run :)


[BUG]: Query builder does not work with mutiple schemas

Report hasn't been filed before.

[X] I have verified that the bug I'm about to report hasn't been filed before.

What version of drizzle-orm are you using?
0.36.3
What version of drizzle-kit are you using?
0.36.3
Other packages
No response
Describe the Bug
For my drizzle setup, I am using 3 files (example simplified) and postgresql db:
index.ts
import dotenv from "dotenv";
import { drizzle } from "drizzle-orm/postgres-js";
import postgres from "postgres";

import * as schema2 from "./schema2";
import * as schema from "./schema";
dotenv.config();

const globalForDb = globalThis as unknown as {
  conn: postgres.Sql | undefined;
};
const conn = globalForDb.conn ?? postgres(process.env.DATABASE_URL!);
if (process.env.NODE_ENV !== "production") globalForDb.conn = conn;

export const db = drizzle(conn, { schema: schema });
export const db2 = drizzle(conn, { schema: schema2 });

schema.ts
export const createTable = pgTableCreator((name) => `schema1_${name}`);

export const users = createTable("user", {
  id: varchar("id", { length: 255 })
    .notNull()
    .primaryKey()
    .$defaultFn(() => crypto.randomUUID()),
  name: varchar("name", { length: 255 }),
  email: varchar("email", { length: 255 }).notNull(),
  emailVerified: timestamp("email_verified", {
    mode: "date",
    withTimezone: true,
  }).default(sql`CURRENT_TIMESTAMP`),
  image: varchar("image", { length: 255 }),
  role: varchar("role", { length: 255 }).notNull().default("user"),
});

schema2.ts
export const createTable = pgTableCreator((name) => `schema2_${name}`);

export const comments = createTable(
  "comments",
  {
    id: serial("id").primaryKey(),
    content: text("content").notNull(),
    createdAt: timestamp("created_at", { withTimezone: true })
      .default(sql`CURRENT_TIMESTAMP`)
      .notNull(),
    updatedAt: timestamp("updated_at", { withTimezone: true }).$onUpdate(
      () => new Date()
    ),
    votes: integer("votes").default(0).notNull(),
  }
);

export const commentsRelations = relations(comments, ({ one }) => ({
  user: one(users, { fields: [comments.userId], references: [users.id] }),
}));

The user in the schema2 are imported from schema1.
The problem is that I can see the relation in drizzle studio and I can get the table with select(), but I can't get the comments with user in the query builder.
Example select() (this works):
    const comments1 = await db
      .select()
      .from(comments)
      .innerJoin(users, eq(comments.userId, users.id));

Example query builder (this doesnt work):
    const comments2 = await db.query.comments.findMany({
      with: {
        user: true,
      },
    });

If I try to use query builder, I am getting following error
Error: Cannot read properties of undefined (reading 'columns')

Okay, so I've changed my approach and combined my schemas like that:
const combinedSchema = { ...schema, ...schema2 };

export const db = drizzle(conn, { schema: combinedSchema });

And now i can use queries, tested on 0.38.2. Seems like you cannot have multiple db instances when using queries. I dont think its ideal cause it may lead to migration issues or namespace related issues, but at least it works.


Update the find command to support search by freetime at a specified …

…day and update user guide for find and editft command

Changed as suggested.


improved lazy loading

see if we can get the backoff decorator working with another way of lazy loading (in e.g. cohere, openai generators)
options:

https://docs.python.org/3/library/importlib.html#importlib.util.LazyLoader
https://github.com/bwesterb/py-demandimport/
https://peps.python.org/pep-0690/

even better would be to ditch the explicit constructor-based module instantiation & ownership entirely

same applies in perspective detector -scope the backoff exception a bit tighter also

one proposal:

move items required for listing plugins & getting started to class attributes
make validation a static method, splitting it out of constructor
constructor manages plugin configuration and also loading

this gives a pattern that can be applied consistently, and that enables quick use of classes for some purposes without requiring instantiation
tagging @jmartin-tech for vis for this issue


Guideline cleanup

Cleaned up various sections of the guidelines.
Added some missing sections.

I'd like to understand where some of the new requirements come from before approving.

They come from guidance that all languages share.

I'd like to understand where some of the new requirements come from before approving.

They come from guidance that all languages share.

In general, when we have C++ guidelines that come from the core guidelines, I think it's important to include links to the origin of the guidelines. That way it's clear that the guideline is azure-wide rather than being language specific.
And FWIW, it doesn't appear that any languages support the X-MS-AZSDK-Telemetry policy :). No idea why but I couldn't find any examples of this.


Flutter barcode SDK crashs my release of the app

this is my flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 2.0.5, on Linux, locale en_US.UTF-8)
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
[✓] Chrome - develop for the web
and everything is working well, but the plugin adds about 18 mega to the app release size, and crush it when we open it.

@nimr77 Android or web? Can you provide detailed information?

@nimr77 Android or web? Can you provide detailed information?

Yes, it's on android level 23

@nimr77 can you provide the crash log?

@nimr77 can you provide the crash log?

How it's on the release only,
The app just crashed

@nimr77 it seems to be a known issue caused by Flutter release build. I've solved the issue by disabling minifyEnabled  and shrinkResources  in build.gradle：
buildTypes {
        release {
            // TODO: Add your own signing config for the release build.
            // Signing with the debug keys for now, so `flutter run --release` works.
            signingConfig signingConfigs.debug
            minifyEnabled false
            shrinkResources false
        }
    }

You can then build the apk with the following command to shrink the apk size:
flutter build apk --release --split-per-abi

@nimr77 it seems to be a known issue caused by Flutter release build. I've solved the issue by disabling minifyEnabled  and shrinkResources  in build.gradle：
buildTypes {
        release {
            // TODO: Add your own signing config for the release build.
            // Signing with the debug keys for now, so `flutter run --release` works.
            signingConfig signingConfigs.debug
            minifyEnabled false
            shrinkResources false
        }
    }

You can then build the apk with the following command to shrink the apk size:
flutter build apk --release --split-per-abi

So in order to use the plug-in I must disable the minify and the shrink resources, and what about the app size

@nimr77 I've found the perfect workaround. You just need to add -keep class com.dynamsoft.dbr.** { *; }  to proguard-rules.pro, and edit the build.gradle file:
buildTypes {
        release {
            // TODO: Add your own signing config for the release build.
            // Signing with the debug keys for now, so `flutter run --release` works.
            signingConfig signingConfigs.debug
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }


Performance Discrepancy in jax.value_and_grad for Different argnums

Description
I'm experiencing a significant performance difference when using jax.value_and_grad with different argnums values. Specifically, when setting argnums=0, the computation is about 3x faster compared to using argnums=2. Here is a brief description of my setup:

Function: I am computing the gradient of a loss function. The loss is computed using model parameters (params) and an input image (image).
Observation: When I set argnums=0 to compute the gradient with respect to params, the execution is significantly faster than when I set argnums=2 to compute the gradient with respect to image.

I am performing adversarial training, which requires me to compute gradients with respect to the input image in order to generate adversarial examples. However, this results in a substantial performance slowdown compared to when I'm computing gradients with respect to the model parameters (params). For example, on a TPUv4-8, the code runs at approximately 35.20it/s when using argnums=0 (i.e., computing gradients with respect to params), but drops to around 13.20it/s when using argnums=2 (i.e., computing gradients with respect to image).
Here’s a simplified version of the code:
def block_all(xs):
	jax.tree_util.tree_map(lambda x: x.block_until_ready(), xs)
return xs

state = create_train_state(args)
b = 32
batch = (jnp.ones((b, 224, 224, 3,)), jnp.ones((b,)))
img = batch[0]
img = img.astype(jnp.float32)
label = batch[1].astype(jnp.int32)

@functools.partial(jax.jit)
def test2(image, label, state, ):
	def adversarial_loss2(params, state, image, label):
		logits = state.apply_fn({"params": params}, image)
		loss_value = jnp.mean(optax.softmax_cross_entropy_with_integer_labels(logits, label))
		return loss_value

	grads = jax.grad(adversarial_loss2, argnums=0)(state.params, state, image, label)
	return grads

for step in tqdm.trange(1, args.training_steps + 1, dynamic_ncols=True):
	out = block_all(test2(img, label, state, ))

### System info (python version, jaxlib version, accelerator, etc.)

jax:    0.4.31
jaxlib: 0.4.31
numpy:  2.0.1
python: 3.10.13 (main, Sep 11 2023, 13:44:35) [GCC 11.2.0]
jax.devices (4 total, 4 local): [TpuDevice(id=0, process_index=0, coords=(0,0,0), core_on_chip=0) TpuDevice(id=1, process_index=0, coords=(1,0,0), core_on_chip=0) TpuDevice(id=2, process_index=0, coords=(0,1,0), core_on_chip=0) TpuDevice(id=3, process_index=0, coords=(1,1,0), core_on_chip=0)]
process_count: 1
platform: uname_result(system='Linux', node='t1v-n-f526ddc0-w-0', release='5.19.0-1022-gcp', version='#24~22.04.1-Ubuntu SMP Sun Apr 23 09:51:08 UTC 2023', machine='x86_64')

It's hard to say much definitive without a full reproduction, including what operations state.apply_fun are doing, but in general it's not surprising that taking derivatives with respect to different inputs leads to different performance characteristics. After all, they're different quantities computed via different sequences of operations, and those different sequences will have different performance characteristics.
If you want to get a sense for what's happening in each case, you might look at the HLO that's being generated: see e.g. Ahead of time lowering and compilation.

It's hard to say much definitive without a full reproduction, including what operations state.apply_fun are doing, but in general it's not surprising that taking derivatives with respect to different inputs leads to different performance characteristics. After all, they're different quantities computed via different sequences of operations, and those different sequences will have different performance characteristics.
If you want to get a sense for what's happening in each case, you might look at the HLO that's being generated: see e.g. Ahead of time lowering and compilation.

Hi @jakevdp. Apologies for the unclear code earlier—it was a bit complex due to the way I handle parameter passing. I've taken some time to simplify it and removed the use of state, now calling the model directly. This should make things more intuitive. In reality, the state was just a standard ViT-B/16 without any special modifications. Below is my updated main function code, where I no longer use state and made some adjustments when computing the gradients. argnums=0 calculates gradients with respect to the model parameters, while argnums=1 computes gradients with respect to the input image.
import jax.numpy as jnp
import jax
import optax
import tqdm
from modeling import ViT

def block_all(xs):
    jax.tree_util.tree_map(lambda x: x.block_until_ready(), xs)
    return xs

def main():
    rng = jax.random.PRNGKey(0)
    b, h, w, c = 8, 224, 224, 3
    batch = (jnp.ones((b, h, w, 3)), jnp.ones((b,)))
    img = batch[0].astype(jnp.float32)
    label = batch[1].astype(jnp.int32)

    model = ViT(layers=12, dim=768, heads=12, labels=1000, layerscale=True)
    params = model.init(rng, img)['params']

    def test2(image, label, params):
        def adversarial_loss2(params, image, label):
            logits = model.apply({"params": params}, image)
            loss_value = jnp.mean(optax.softmax_cross_entropy_with_integer_labels(logits, label))
            return loss_value

        grads = jax.grad(adversarial_loss2, argnums=1)(params, image, label)
        return grads

    test2_jit = jax.jit(test2)

    for step in tqdm.trange(1, 10000000 + 1, dynamic_ncols=True):
        out = block_all(test2_jit(img, label, params))

if __name__ == "__main__":
    main()

And here is the ViT code:

from dataclasses import dataclass, fields
from functools import partial
from typing import Any, Literal
import einops
import flax.linen as nn
import flax.linen.initializers as init
import jax.numpy as jnp
from chex import Array

DenseGeneral = partial(nn.DenseGeneral, kernel_init=init.truncated_normal(0.02))
Dense = partial(nn.Dense, kernel_init=init.truncated_normal(0.02))
Conv = partial(nn.Conv, kernel_init=init.truncated_normal(0.02))

@dataclass
class ViTBase:
    layers: int = 12
    dim: int = 768
    heads: int = 12
    labels: int | None = 1000
    layerscale: bool = False

    patch_size: int = 16
    image_size: int = 224
    posemb: Literal["learnable", "sincos2d"] = "learnable"
    pooling: Literal["cls", "gap"] = "cls"

    dropout: float = 0.0
    droppath: float = 0.0
    grad_ckpt: bool = False

    @property
    def kwargs(self) -> dict[str, Any]:
        return {f.name: getattr(self, f.name) for f in fields(ViTBase)}

    @property
    def head_dim(self) -> int:
        return self.dim // self.heads

    @property
    def hidden_dim(self) -> int:
        return 4 * self.dim

    @property
    def num_patches(self) -> tuple[int, int]:
        return (self.image_size // self.patch_size,) * 2

class PatchEmbed(ViTBase, nn.Module):
    def setup(self):
        self.wte = Conv(
            self.dim,
            kernel_size=(self.patch_size, self.patch_size),
            strides=(self.patch_size, self.patch_size),
            padding="VALID",
        )
    def __call__(self, x: Array) -> Array:
        x = (self.wte(x)).reshape(x.shape[0], -1, self.dim)
        # x = x.reshape(x.shape[0], -1, self.dim)
        return x

class Attention(ViTBase, nn.Module):
    def setup(self):
        self.wq = DenseGeneral((self.heads, self.head_dim))
        self.wk = DenseGeneral((self.heads, self.head_dim))
        self.wv = DenseGeneral((self.heads, self.head_dim))
        self.wo = DenseGeneral(self.dim, axis=(-2, -1))
        self.drop = nn.Dropout(self.dropout)

    def __call__(self, x: Array, det: bool = True) -> Array:
        z = jnp.einsum("bqhd,bkhd->bhqk", self.wq(x) / self.head_dim ** 0.5, self.wk(x))
        z = jnp.einsum("bhqk,bkhd->bqhd", self.drop(nn.softmax(z), det), self.wv(x))
        return self.drop(self.wo(z), det)

class FeedForward(ViTBase, nn.Module):
    def setup(self):
        self.w1 = Dense(self.hidden_dim)
        self.w2 = Dense(self.dim)
        self.drop = nn.Dropout(self.dropout)

    def __call__(self, x: Array, det: bool = True) -> Array:
        return self.drop(self.w2(self.drop(nn.gelu(self.w1(x)), det)), det)

class ViTLayer(ViTBase, nn.Module):
    def setup(self):
        self.attn = Attention(**self.kwargs)
        self.ff = FeedForward(**self.kwargs)

        self.norm1 = nn.LayerNorm()
        self.norm2 = nn.LayerNorm()
        self.drop = nn.Dropout(self.droppath, broadcast_dims=(1, 2))

        self.scale1 = self.scale2 = 1.0
        if self.layerscale:
            self.scale1 = self.param("scale1", init.constant(1e-4), (self.dim,))
            self.scale2 = self.param("scale2", init.constant(1e-4), (self.dim,))

    def __call__(self, x: Array, det: bool = True) -> Array:
        x = x + self.drop(self.scale1 * self.attn(self.norm1(x), det), det)
        x = x + self.drop(self.scale2 * self.ff(self.norm2(x), det), det)
        return x

class ViT(ViTBase, nn.Module):
    def setup(self):
        self.embed = PatchEmbed(**self.kwargs)
        self.drop = nn.Dropout(self.dropout)

        # The layer class should be wrapped with `nn.remat` if `grad_ckpt` is enabled.
        layer_fn = nn.remat(ViTLayer) if self.grad_ckpt else ViTLayer
        self.layer = [layer_fn(**self.kwargs) for _ in range(self.layers)]

        self.norm = nn.LayerNorm()
        self.head = Dense(self.labels) if self.labels is not None else None

    def __call__(self, x: Array, det: bool = True) -> Array:
        # x = (images - IMAGENET_DEFAULT_MEAN) / IMAGENET_DEFAULT_STD
        # x = self.drop(self.embed(x), det)
        x = self.embed(x)

        for layer in self.layer:
            x = layer(x, det)
        x = self.norm(x)

        # If the classification head is not defined, then return the output of all
        # tokens instead of pooling to a single vector and then calculate class logits.
        if self.head is None:
            return x

        if self.pooling == "cls":
            x = x[:, 0, :]
        elif self.pooling == "gap":
            x = x.mean(1)
        return self.head(x)

When running the code above, I noticed that 124 it/s for argnums=0 and 15 it/s for argnums=1, indicating that computing gradients with respect to parameters is significantly faster than computing gradients with respect to the input. However,after computing gradients with respect to the parameters, calculating the gradients for the input should not take that much more time.
I suspected that the root cause might be in the PatchEmbed class, specifically in the Conv operation.
class PatchEmbed(ViTBase, nn.Module):
    def setup(self):
        self.wte = Conv(
            self.dim,
            kernel_size=(self.patch_size, self.patch_size),
            strides=(self.patch_size, self.patch_size),
            padding="VALID",
        )
    def __call__(self, x: Array) -> Array:
        x = (self.wte(x)).reshape(x.shape[0], -1, self.dim)
        # x = x.reshape(x.shape[0], -1, self.dim)
        return x

So, I tried to comment out the convolution and replace it with a simple reshape operation (since ViT-B's reshaped dimensions match the output dimensions, so no errors occurred). The new code looks like this:
class PatchEmbed(ViTBase, nn.Module):
    def setup(self):
        self.wte = Conv(
            self.dim,
            kernel_size=(self.patch_size, self.patch_size),
            strides=(self.patch_size, self.patch_size),
            padding="VALID",
        )
    def __call__(self, x: Array) -> Array:
        #x = (self.wte(x)).reshape(x.shape[0], -1, self.dim)
        x = x.reshape(x.shape[0], -1, self.dim)
        return x

Surprisingly, this resulted in 128 it/s for argsnum=0 and 195 it/s for argsnum=1, meaning that computing the gradients with respect to the input became much faster than computing gradients with respect to the parameters.
I looked into the flax.linen.Conv implementation, which mostly wraps JAX code without anything special, and I can't quite pinpoint the issue. I'm really puzzled by this behavior and would appreciate any insights you could share.Thank you!

I observed the same issue on the GPU. Since it seems that there is no capacity for TPUv4 right now, I can only report the situation on the GPU. I did further testing and found that the problem seems to stem from convolutions with a large kernel size. When I reduced the kernel size to 14, 8, or even lower, the problem of extreme slowness disappeared. On the contrary, when I increased the kernel size to 32 or higher, it became very slow, which really confuses me.
When running on the GPU, if the kernel size is greater than or equal to 16, this warning appears. There is no such warning on the TPU, and it was because of this warning that I pinpointed the problem to the convolution layer.
2024-08-17 17:59:38.059112: W external/xla/xla/service/gpu/nvptx_compiler.cc:760] The NVIDIA driver's CUDA version is 12.3 which is older than the ptxas CUDA version (12.4.131). Because the driver is older than the ptxas version, XLA is disabling parallel compilation, which may slow down compilation. You should update your NVIDIA driver or use the NVIDIA-provided CUDA forward compatibility packages.
2024-08-17 17:59:49.517143: E external/xla/xla/service/slow_operation_alarm.cc:65] Trying algorithm eng54{k2=5,k12=-1,k13=1,k14=2,k15=0,k17=384,k18=1,k23=0} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:02:30.275067: E external/xla/xla/service/slow_operation_alarm.cc:133] The operation took 2m41.758073871s
Trying algorithm eng54{k2=5,k12=-1,k13=1,k14=2,k15=0,k17=384,k18=1,k23=0} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:02:31.275216: E external/xla/xla/service/slow_operation_alarm.cc:65] Trying algorithm eng56{k2=8,k12=1,k13=1,k14=3,k15=0,k17=384,k18=1,k22=0,k23=0} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:04:14.350876: E external/xla/xla/service/slow_operation_alarm.cc:133] The operation took 1m44.075748815s
Trying algorithm eng56{k2=8,k12=1,k13=1,k14=3,k15=0,k17=384,k18=1,k22=0,k23=0} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:04:15.351085: E external/xla/xla/service/slow_operation_alarm.cc:65] Trying algorithm eng54{k2=1,k12=11,k13=0,k14=3,k15=0,k17=64,k18=1,k23=0} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:07:00.626353: E external/xla/xla/service/slow_operation_alarm.cc:133] The operation took 2m46.275419584s
Trying algorithm eng54{k2=1,k12=11,k13=0,k14=3,k15=0,k17=64,k18=1,k23=0} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:07:01.626488: E external/xla/xla/service/slow_operation_alarm.cc:65] Trying algorithm eng41{k2=0,k12=15,k13=2,k14=3,k15=0,k17=48,k18=1,k22=0,k23=0} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:12:24.320609: E external/xla/xla/service/slow_operation_alarm.cc:133] The operation took 5m23.694191845s
Trying algorithm eng41{k2=0,k12=15,k13=2,k14=3,k15=0,k17=48,k18=1,k22=0,k23=0} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:12:25.320784: E external/xla/xla/service/slow_operation_alarm.cc:65] Trying algorithm eng55{k2=8,k13=1,k14=3,k18=1,k22=0,k23=0} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:14:17.146178: E external/xla/xla/service/slow_operation_alarm.cc:133] The operation took 1m52.825500921s
Trying algorithm eng55{k2=8,k13=1,k14=3,k18=1,k22=0,k23=0} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:14:17.146233: W external/tsl/tsl/framework/bfc_allocator.cc:291] Allocator (GPU_0_bfc) ran out of memory trying to allocate 3.82GiB with freed_by_count=0. The caller indicates that this is not a failure, but this may mean that there could be performance gains if more memory were available.
2024-08-17 18:14:18.146408: E external/xla/xla/service/slow_operation_alarm.cc:65] Trying algorithm eng53{k2=5,k13=1,k14=2,k18=1,k23=0} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:17:22.133083: E external/xla/xla/service/slow_operation_alarm.cc:133] The operation took 3m4.986817998s
Trying algorithm eng53{k2=5,k13=1,k14=2,k18=1,k23=0} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:17:23.133236: E external/xla/xla/service/slow_operation_alarm.cc:65] Trying algorithm eng35{k2=5,k5=2,k14=6} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:21:55.612832: E external/xla/xla/service/slow_operation_alarm.cc:133] The operation took 4m33.479687455s
Trying algorithm eng35{k2=5,k5=2,k14=6} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:21:56.613141: E external/xla/xla/service/slow_operation_alarm.cc:65] Trying algorithm eng55{k2=3,k13=2,k14=2,k18=1,k22=0,k23=0} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:27:24.615041: E external/xla/xla/service/slow_operation_alarm.cc:133] The operation took 5m29.002143139s
Trying algorithm eng55{k2=3,k13=2,k14=2,k18=1,k22=0,k23=0} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:27:25.615199: E external/xla/xla/service/slow_operation_alarm.cc:65] Trying algorithm eng0{} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...
2024-08-17 18:28:13.739699: E external/xla/xla/service/slow_operation_alarm.cc:133] The operation took 49.124595719s
Trying algorithm eng0{} for conv (f32[3,1,224,224]{3,2,1,0}, u8[0]{0}) custom-call(f32[3,768,16,16]{3,2,1,0}, f32[1,768,209,209]{3,2,1,0}), window={size=209x209 pad=208_208x208_208 rhs_reversal=1x1}, dim_labels=bf01_oi01->bf01, custom_call_target="__cudnn$convForward", backend_config={"operation_queue_id":"0","wait_on_operation_queues":[],"cudnn_conv_backend_config":{"conv_result_scale":1,"activation_mode":"kNone","side_input_scale":0,"leakyrelu_alpha":0},"force_earliest_schedule":false} is taking a while...

I'm having trouble running your code: can you point to what the modeling package is?
These details help, but my first response still holds: differentiating with respect to different arguments results in a different computation, implemented in terms of a different sequence of operations, and it's entirely expected that different sequences of operations will have different performance characteristics.
Also a side note: instead of defining block_all, you could use jax.block_until_ready, which is basically a more robust and performant version of what you wrote.

I'm having trouble running your code: can you point to what the modeling package is?
These details help, but my first response still holds: differentiating with respect to different arguments results in a different computation, implemented in terms of a different sequence of operations, and it's entirely expected that different sequences of operations will have different performance characteristics.
Also a side note: instead of defining block_all, you could use jax.block_until_ready, which is basically a more robust and performant version of what you wrote.

Apologies for the unclear description earlier. The modeling package refers to the ViT code I provided above. That code represents the entire content of the modeling package. You can create a modeling.py file and copy the ViT code from above into it. It should be runnable this way.

I'm having trouble running your code: can you point to what the modeling package is?
These details help, but my first response still holds: differentiating with respect to different arguments results in a different computation, implemented in terms of a different sequence of operations, and it's entirely expected that different sequences of operations will have different performance characteristics.
Also a side note: instead of defining block_all, you could use jax.block_until_ready, which is basically a more robust and performant version of what you wrote.

I'm having trouble running your code: can you point to what the modeling package is?
These details help, but my first response still holds: differentiating with respect to different arguments results in a different computation, implemented in terms of a different sequence of operations, and it's entirely expected that different sequences of operations will have different performance characteristics.
Also a side note: instead of defining block_all, you could use jax.block_until_ready, which is basically a more robust and performant version of what you wrote.

Yes, it is expected that computing derivatives with respect to different argnums will take different amounts of time. However, if I understand correctly, when computing the derivative with respect to the input, it should be part of the backpropagation process, where the gradient is first computed with respect to the parameters up to the first layer, and then further differentiated to obtain the gradient with respect to input. So, I believe the computation time should not differ that significantly between the two cases.


--audio option behaves differently with and without equals sign

expected behavior:
wf-recorder --audio=alsa_output.pci-0000_00_1f.3.analog-stereo.monitor and wf-recorder --audio alsa_output.pci-0000_00_1f.3.analog-stereo.monitor should behave the same, both capturing audio from the specified device (my system's audio output), regardless of whether or not an equals sign is present
actual behavior:
wf-recorder --audio=alsa_output.pci-0000_00_1f.3.analog-stereo.monitor works as expected, but wf-recorder --audio alsa_output.pci-0000_00_1f.3.analog-stereo.monitor seemingly ignores the specified device and records my microphone instead

We're using getopt_long for parsing arguments, and whlie the getopt(3) documentation doesn't say anything on the matter, getopt(1) says this about optional arguments (which -a is):
If the option has an optional argument, it must be written directly after the option character if present.

Compare this with the text for options with required arguments:
If the option has a required argument, it may be written directly after the option character or as the next parameter (i.e., separated by whitespace on the command line).

So basically, wf-recorder behaves as getopt programs should. You cannot use space as separator for options which have optional arguments.
The question then becomes, should -a/--audio have a required argument? I personally use --audio very rarely, so I don't have an opinion on this. What do the other people think? Do you think -a is useful for selecting the default pulseaudio device?

Do you think -a is useful for selecting the default pulseaudio device?

I do think the default behavior is useful.  It would at the very least be nice to see the behavior for overriding that default be documented.


.ipynb to .py fails with encoding error

A Jupyter notebook that contains Unicode characters seems to be failing when converted to Python code:
  …
  File "/…/anaconda/envs/py2/lib/python2.7/site-packages/ipymd/utils/utils.py", line 133, in _write_text
    f.write(contents)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 15310: ordinal not in range(128)

Encoding the Python file in UTF-8 instead works (f.write(contents.encode("utf-8"))), but then probably this should also add a # coding=UTF-8 at the beginning of the generated Python file.
Also, the conversion back to a Jupyter notebook might have to be adapted so as to be compatible with this change.

It's a bit difficult to test: pip install installs under Python 2. Running the ipymd script with Python 3 doesn't find the ipymd module…


Build a new release process for this repository

Like with the wasm-tools repository in bytecodealliance/wasm-tools#1416, this repository is going to follow suit with the same release process. Notably everything should now be largely automated in terms of publication and such so anyone can make a release so long as they have write access to the repository.

I'll note that my plan here, like with https://github.com/bytecodealliance/wasm-tools/pull/1416, is to perform a release right after this merges.
Unlike with wasm-tools however I have performed no testing of this on my own repos yet. I'm crossing my fingers that I copied everything over from wasm-tools correctly and figure I can try to clean up any issues afterwards.


libp2p (and friends) index.d.ts for TypeScript

Version: latest
Platform: TypeScript
Subsystem: libraries

Type: Question

Severity: Very Low
Description:
I've been starting with TypeScript definitions, https://github.com/polkadot-js/ts/blob/master/types/libp2p/index.d.ts - these are exceptionally early, ugly, hacky, untested with still some way to go.
My question is the following: would be be appropriate to make a PR across the js-libp2p repos to add these as they are actually ready and usable or is there no appetite to have these single-definitions-per-repo included?
(Alternatively could submit them to the community DefinitelyTyped repo, but it is better if they are in the source, i.e. just installing the library allows you to use it with TS projects).

I'm not opposed to including the TypeScript bindings in each of the libp2p projects, my main concern is ensuring they are kept up to date and automatically verifiable. I have not spent much time with TypeScript as of yet to understand how we could go about making sure these are always accurate.
What tests can we run on CI to ensure these are up to date?
What support is there to autogenerate types for new js code? Can we generate them from JSDocs, etc?
cc: @mikerah

There are several options. The one I'm currently using is to use Polkadot-js's type definitions for libp2p. For odd reasons, I am having difficulties with this. The other option is to provide accurate JSDocs for all js-libp2p code and generate typescript definition files from those. I found this package that does this.

For odd reasons, I am having difficulties with this

Not sure if it's contributing but the recent version of libp2p includes changes that aren't yet reflected there. This is one of the things I'd like to be able to avoid if we include the definitions in the modules.
We're working on improving JSDocs across libp2p and it's easy enough for us to keep those up to date. Being able to generate from JSDocs could be a reasonable path to getting support added.

Hey guys, did any more types get published, any progress on this issue?

@patwhite, For our ETH2 client, what we do is set the types ourselves. This does require familiarity with libp2p. We didn't create .d.ts files. If you want an example of how to use js-libp2p in a typescript project, check out lodestar on github.

We released<EMAIL_ADDRESS>with typedefs generated on release 🎉
Closing this issue, thank you all! There is https://github.com/libp2p/js-libp2p/issues/659 to track the remaining work


ebiten: MaximizeWindow does not work even when maximum window size is not limited

In 2.4.0 #2259 tried to fix unexpected window flickering when window size limits are determined, this does not work properly because maximization should not depend on the window's min size. If a game determined minimum without restriction of maximum size, ebiten.MaximizeWindow() should still be available.
package main

import (
	_ "image/png"

	"github.com/hajimehoshi/ebiten/v2"
)

func main() {
	ebiten.SetWindowResizingMode(ebiten.WindowResizingModeEnabled)
	ebiten.SetWindowSizeLimits(50, 50, -1, -1)
	ebiten.MaximizeWindow() // does not work
	ebiten.RunGame(&game{})
}

type game struct{}

func (game) Update() error {
	return nil
}

func (game) Draw(screen *ebiten.Image) {
}

func (game) Layout(outsideWidth, outsideHeight int) (int, int) {
	return outsideWidth, outsideHeight
}

Thanks, I'll take a look later!

it is resolved in #2291 but I forgot to mention it in the commit


s-s-d: warn about non-root writable pidfile

Since start-stop-daemon is run as root, non-root writable pidfiles can
be used to make start-stop-daemon signal processes other than the daemon
the pidfile is supposed to be for.
Reported-By: Michael Orlitzky<EMAIL_ADDRESS>Tested-By: Michael Orlitzky<EMAIL_ADDRESS>

s-s-d can run as non-root just fine, so warning in that case is incorrect
also, can't s-s-d let the target program create/manage the pid, and then re-use it to stop ?  in which case it'll be owned by non-root ?

s-s-d can run as non-root just fine, so warning in that case is incorrect

I'll make the st_uid != 0 check also require geteuid() == 0.

also, can't s-s-d let the target program create/manage the pid, and then re-use it to stop ? in which case it'll be owned by non-root ?

Daemons should be creating their pidfiles before they drop privileges, so the pidfile would be root-owned.  s-s-d's own --make-pidfile writes the pidfile before applying any --user/--group changes

I'll make the st_uid != 0 check also require geteuid() == 0.

Thinking further, st_uid != geteuid() would probably be better.  Thoughts?

i don't see how being root owned is a requirement or even an improvement.  if s-s-d was launched as root, and it was responsible for creating the pid file, then sure, it'll be root owned.  but it's not inconceivable that the main daemon sets up the pid file so an unprivileged child can manage it.  i don't see that being a bug.
on my active system, i see transmission running with its pid file as owned by non-root.
i'm not really seeing the bug/issue this is trying to fix.

A simple arbitrary code execution vulnerability in transmission could lead to a system-wide DoS when running-as-root s-s-d reads a pid from the non-root writable pidfile and signals that process, and somebody has used that vulnerability to write, say, '1' in that pidfile.

And it doesn't even have to be arbitrary code execution; writing to a path that the attacker can specify with content the attacker can provide would be sufficient.

that's why you pass the program name to the --stop function -- it does a sanity check on the target process.  if you aren't passing that, your init script is already broken and needs fixing.
there is no diff between "server crashed and pid was recycled to a diff program" and "a diff pid was manually injected to an existing process".

It doesn't.  If --pidfile is provided to --stop or --signal, it is considered the only source of truth.  I imagine this was inherited from Debian's implementation when OpenRC forked it many many moons ago.

https://github.com/OpenRC/openrc/blob/master/src/rc/start-stop-daemon.c#L407 is where that happens

Can someone check Debian's s-s-d for sure and let us know if it just treats the pidfile as the source of truth or if it requires the program name as well?

I've found another common mistake along the same lines. Often, people don't realize that command_background=true will write the PID file as root:root regardless of command_user. As a result, they change ownership of the PID file's containing directory to the daemon user, and the PID file (owned by root:root) gets written into a directory that a  non-root user controls. For example:

Bug 628542, app-admin/consul-template
Bug 628544, app-admin/consul
Bug 628546, app-admin/filebeat
Bug 628548, app-admin/glance

Even if it's only as a QA warning, it's looking like it would be extremely useful to extend this warning to the containing directory (i.e. if a non-root user can replace the PID file).

Can someone check Debian's s-s-d for sure and let us know if it just treats the pidfile as the source of truth or if it requires the program name as well?

I haven't tested it, but reading the source at
https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/utils/start-stop-daemon.c
suggests that the PID file takes precedence over the program name.

Can this be updated so I can merge it, or should we close it?
Thanks,
William

@dwfreed What is the status of this p/r? should I close it, or can you give me an update?


Fix default values for texture channels in BaseMaterial3D shader conversion

The defaults now match the Red default channel used in BaseMaterial3D.

See https://github.com/godotengine/godot/pull/93449#issuecomment-2188807847.

I wonder what is going on here. Most uniforms don't have defaults in the shader and they still convert to a ShaderMaterial just fine.
When converting to a ShaderMaterial, we pull the current values from the RenderingServer and then apply them to the new material.
The RenderingServer should have the default value because we set it in the initializer:
https://github.com/godotengine/godot/blob/6b281c0c07b07f2142b1fc8a6b3158091a9b124c/scene/resources/material.cpp#L3394-L3397
This is the same pattern we do for all uniforms, so I wonder why it is only these ones that are getting lost


Area-51ALX  AlienFX

Please increase support 0x513(Area-51ALX )

Area51(0x187c, 0x513)
led name="Alienhead"        		code="0x1"
led name="Front Lower LEDs"     	code="0x2"
led name="Left Vent"  	     	        code="0x40"
led name="Left Side"  	                code="0x80"
led name="Right Side"       	        code="0x100"
led name="Right Vent"       	        code="0x200"

Would also like to see this, my Area 51 Case lights up random mismatched colors with Aurora running. So it's trying, though failing to integrate the case


[BUG] Find-TwitterMastodonLinks - Incorrect parsing

Describe the bug
Some Mastodon addresses don't quite work work
To Reproduce
Try to find a mastodon address from the following users
https://twitter.com/alexandair (actual<EMAIL_ADDRESS>| result: @alex@dair-community)
https://twitter.com/jandedobbeleer (actual<EMAIL_ADDRESS>| result<EMAIL_ADDRESS>https://twitter.com/madebygps (actual: http://hachyderm.io/web/@gps | result<EMAIL_ADDRESS>https://twitter.com/justinjbird7 (actual: data-folks.masto.host/@justinjbird | result<EMAIL_ADDRESS>Alexandair and Jan have emojis in their name. Maybe that's why? But justin doesn't have an emoji.
Also, I've noticed a few that broke with madebygp's issue. It is a valid mastodon address with that /web/.
Expected behavior
handles it
PowerShell Environment (please complete the following information):
GitHub Runner ubuntu-latest
Additional context
https://github.com/potatoqualitee/influx/actions/runs/3543655833/jobs/5950338108

Oh, also https://twitter.com/janfishankhan (actual<EMAIL_ADDRESS>| result<EMAIL_ADDRESS>

Closed via #190


Fixed incorrect comment from #2883

As in the commit message, this fixes #2883.

Thanks! Merged manually.


Show list of all users on the right

The basic idea would be to ape Discord's right-hand list of users.
We could show: people in your room, people online but not in your room, and offline people.

I see no benefit to showing offline people, especially since you can't e.g. DM them while they're offline
The benefit to showing people in other rooms is to make it easy to whisper to them. If we build a separate DM UI, that would make this less relevant.
We already show who's in your current room in the room description. This merely makes this less MUD-y.

I am mildly against this entire feature, but could be convinced otherwise.

I think whether this is a good idea or not depends entirely on whether we build out a fancier DM interface.
If we build that interface, it will happen after the meetup, so this isn't part of that milestone.

If you've been DMing with someone but hid their profile, finding them again can be a pain. I think this is a good idea.
My instinct is the simplest version of this is a list with two sections, sorted alphabetically within sections: people in your current room, and online people in other rooms.
I wouldn't do these first — there are more important things to do — but two natural improvements from there:

A first section that's "people you've DMed with recently", sorted by recency
A search filter box

From the standpoint of someone new approaching this: we already have a list of all online users (state.userMap) and a list of all users in the current room (state.roomData[state.roomId].users), so this should be purely a front-end task.

Thinking about 2022: This is a very good feature if we choose to prioritize DMing as a feature. That's a big if.


"brightWhite" color in solarized light theme is the same as background

Environment
Windows build number: 10.0.18363.836
Windows Terminal version (if applicable): 1.0.1401.0

Steps to reproduce
Configure a WSL terminal with colorScheme: Solarized Light
Open a WSL terminal and run "top"
The values in the summary at the top of the display are invisible with this color scheme.  The "brightWhite" color used in the Solarized Light theme is the same as "background."
In a terminal that supports bold fonts, I would suggest using the same value as "foreground", but for now, I think the value for brightBlack is probably best.  I've fixed this by creating a scheme identical to Solarized Light, except for:
"brightWhite": "#002B36"

Expected behavior
brightWhite text should be foreground color, but bold.
Actual behavior
brightWhite text is invisible.

I suppose this is the same as #5682

I don't think so.  The issue here is simply that the color scheme Solarized Light uses the same color value for a foreground color as it does for the background color.  This was probably an error made while importing the color scheme, because in any other terminal application, the "brightWhite" value in the Solarized Light color scheme is the same as the foreground color (but bold), not the background color.

The official Solarized repo has bright white as the same color as the background. You can see an image of the colors here: https://github.com/altercation/solarized/tree/master/putty-colors-solarized
And if you look at the iTerm2 definition, this is bright white:
https://github.com/altercation/solarized/blob/master/iterm2-colors-solarized/Solarized Light.itermcolors#L68-L76
And this is the background color:
https://github.com/altercation/solarized/blob/master/iterm2-colors-solarized/Solarized Light.itermcolors#L149-L157
And again for the Xfce definition, this bright white:
https://github.com/altercation/solarized/blob/master/xfce4-terminal/light/terminalrc#L20
And this is the background color:
https://github.com/altercation/solarized/blob/master/xfce4-terminal/light/terminalrc#L4
The dark version has a similar problem in that it makes bright black invisible. This is a well known problem with the Solarized  schemes (see https://github.com/altercation/solarized/issues/220 and https://github.com/altercation/solarized/issues/376).
According to the author, this choice was "very intentional", and a "considered compromise". I'm not sure what the compromise was, but I'm guessing some unspeakable horror would be unleashed if common color combinations were allowed to be visible. So if you like visible text, it's probably best you use something else.
That said, if we were to get color correction like the proposal in issue #2638, that could potentially help with this problem.

DAYS SINCE DUSTIN FELT REGRET SHIPPING
          SOLARIZED COLORS

                  ###
                 #   #
                #     #
                #     #
                #     #
                 #   #
                  ###

You are correct, and I apologize.  I agree that Solarized is bad in this respect.
However, I think there are two issues in Terminal, and I'd like to close this issue and open two new ones.
The first is the real underlying problem with this issue, and that is that Terminal interprets the uncolored "bold" ANSI sequence as a request for "briteWhite", and that is only a reasonable thing to do if the color scheme is light text on a dark background.   For One Half Light, Tango Light, and Solarized Light, text that should be displayed in bold is either invisible or very difficult to see.  Lacking support for bold text, Terminal should simply use the foreground color for bold text.
The second issue would resolve the first, if you are willing to consider it, but I am guessing that is less likely.  In src/renderer/vt/VtSequences.cpp, a comment indicates,  "in fact most terminals display the bright color when displaying bolded text" and I don't believe that's actually the case.  Some do.  Some make this an optional behavior.  I've seen this behavior described as a "hack" for terminals that don't support aixterm ANSI sequences (90-97).  Ideally Terminal should support both bold text and bright text individually, and not substitute one for the other.  If bold can't be supported, it would be better, in my opinion, to simply ignore the bold sequence and use the standard palette for 30-37, and the bright palette for 90-97.  If a survey of other terminal emulators would sway your mind, I'd be happy to determine which ones exhibit which behavior.
In any case, this bug doesn't actually have anything to do with Solarized (which admittedly does have a glaring flaw), which may alleviate your regret.  :)
Please let me know if I should go ahead with separating this into two new issues.

The first is the real underlying problem with this issue, and that is that Terminal interprets the uncolored "bold" ANSI sequence as a request for "briteWhite"

That is a genuine bug (issue #2661).

In src/renderer/vt/VtSequences.cpp, a comment indicates, "in fact most terminals display the bright color when displaying bolded text" and I don't believe that's actually the case. Some do. Some make this an optional behavior.

I know of only one terminal that doesn't support bold applying brightness to the SGR 30-37 colors, although as you say some do make it an optional behavior. I don't know if we have a dedicated issue for that option, but it's discussed in issue #109.

Alright, so, this sounds like it's a combo /dupe of #2661/#5682/#4047/#2622/#4818/solarized-is-bad, and I'm gonna close it as such. I think we all regret shipping Solarized as a default Terminal theme, because it's simply bad, and we'll likely be removing it in the near future (see #6617).


Unknown OpenSSL error

I'm trying to install puppetboard and I always get an InternalError: Unknown OpenSSL error
mod_wsgi (pid=3677): Target WSGI script '/var/www/localhost/htdocs/puppetboard/wsgi.py' cannot be loaded as Python module.
 mod_wsgi (pid=3677): Exception occurred processing WSGI script '/var/www/localhost/htdocs/puppetboard/wsgi.py'.
 Traceback (most recent call last):
   File "/var/www/localhost/htdocs/puppetboard/wsgi.py", line 6, in <module>
     from puppetboard.app import app as application
   File "/usr/lib64/python2.7/site-packages/puppetboard/app.py", line 19, in <module>
     from pypuppetdb import connect
   File "/usr/lib64/python2.7/site-packages/pypuppetdb/__init__.py", line 61, in <module>
     from pypuppetdb.api import BaseAPI
   File "/usr/lib64/python2.7/site-packages/pypuppetdb/api.py", line 6, in <module>
     import requests
   File "/usr/lib64/python2.7/site-packages/requests/__init__.py", line 53, in <module>
     from .packages.urllib3.contrib import pyopenssl
   File "/usr/lib64/python2.7/site-packages/requests/packages/urllib3/contrib/pyopenssl.py", line 53, in <module>
     import OpenSSL.SSL
   File "/usr/lib64/python2.7/site-packages/OpenSSL/__init__.py", line 8, in <module>
     from OpenSSL import rand, crypto, SSL
   File "/usr/lib64/python2.7/site-packages/OpenSSL/rand.py", line 12, in <module>
     from OpenSSL._util import (
   File "/usr/lib64/python2.7/site-packages/OpenSSL/_util.py", line 6, in <module>
     from cryptography.hazmat.bindings.openssl.binding import Binding
   File "/usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 225, in <module>
     Binding.init_static_locks()
   File "/usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 181, in init_static_locks
     cls._ensure_ffi_initialized()
   File "/usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 176, in _ensure_ffi_initialized
     cls._register_osrandom_engine()
   File "/usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 141, in _register_osrandom_engine
     _openssl_assert(cls.lib, cls.lib.ERR_peek_error() == 0)
   File "/usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 63, in _openssl_assert
     errors_with_text
 InternalError: Unknown OpenSSL error. This error is commonly encountered when another library is not cleaning up the OpenSSL error stack. If you are using cryptography with another library that uses OpenSSL try disabling it before reporting a bug. Otherwise please file an issue at https://github.com/pyca/cryptography/issues with information on how to reproduce this. ([_OpenSSLErrorWithText(code=151441516L, lib=9, func=109, reason=108, reason_text='error:0906D06C:PEM routines:PEM_read_bio:no start line'), _OpenSSLErrorWithText(code=151441516L, lib=9, func=109, reason=108, reason_text='error:0906D06C:PEM routines:PEM_read_bio:no start line')

How can I find what is causing this issue ?
Apache/2.2.31
OpenSSL/1.0.2j
mod_wsgi/4.4.21
Python/2.7.10
puppetdb/4.0.2
puppetboard/0.2.0

What version of: urllib3.  your OpenSSL maybe updated but your python library was linked to what used to be installed.

urllib3 is 1.12
request version is 2.8.1 and pyopenssl is 16.2.0

Can you look at this article and see if it helps.
http://raspberrypi.stackexchange.com/questions/28176/python-and-openssl-error-on-import

Any update on this, @nfeutry?  I really think something is wrong with your ssl libs and python.

Yes, I tried a few thing suggested in the link. Mostly uninstall/reinstall libs with/without pip.
It did not fix the error but when I refresh 5 or 6 six time in a row, it starts working for a few minutes and break randomly after (don't know if it was the case before, I may not have tried hard enough).
I will try on a fresh install to see if it change something.

The last line of that trace is interesting.
InternalError: Unknown OpenSSL error. This error is commonly encountered when another library is not cleaning up the OpenSSL error stack. If you are using cryptography with another library that uses OpenSSL try disabling it before reporting a bug. Otherwise please file an issue at https://github.com/pyca/cryptography/issues with information on how to reproduce this. ([_OpenSSLErrorWithText(code=151441516L, lib=9, func=109, reason=108, reason_text='error:0906D06C:PEM routines:PEM_read_bio:no start line'), _OpenSSLErrorWithText(code=151441516L, lib=9, func=109, reason=108, reason_text='error:0906D06C:PEM routines:PEM_read_bio:no start line')

Yes, but I don't know wich other library is not cleaning up the OpenSSL error stack or how to find out.
I have also checked all pem on the server and found none with no start line.
And I don't understand how it can work sometimes but never on the first try.

Very odd. Do you mind sharing your mod wsgi and settings.py?
Also how is your puppetdb DNS/load balancer. configured. Wondering if you have something causing a round robin on puppetboard trying to connect to the API.

I found this as well.
https://github.com/pyca/cryptography/issues/3275

Here is my wsgi.py:
import os

# Needed if a settings.py file exists
os.environ['PUPPETBOARD_SETTINGS'] = '/var/www/localhost/htdocs/puppetboard/settings.py'
from puppetboard.app import app as application
application.secret_key = '1gf5s2yJ6sFcvY28D4mGt2hF'

and settings.py :
PUPPETDB_PORT = 8080
PUPPETDB_SSL_VERIFY = False
PUPPETDB_KEY = None
PUPPETDB_CERT = None
PUPPETDB_TIMEOUT = 20
DEFAULT_ENVIRONMENT = 'production'
DEV_LISTEN_HOST = '<IP_ADDRESS>'
DEV_LISTEN_PORT = 5000
UNRESPONSIVE_HOURS = 2
ENABLE_QUERY = True
LOCALISE_TIMESTAMP = True
LOGLEVEL = 'debug'
REPORTS_COUNT = 10
OFFLINE_MODE = False
ENABLE_CATALOG = False

But whatever I put in the settings, the behaviour does not change. If I mess with the settings file , I can have the Unknown SSL error before the Syntax Error happen.
There is no loadbalancing/roundrobin in my installation, everything run on the same server. But yes It really looks like that.

Your not even using SSL to talk to puppetdb.  This looks to be something going on with your system and it's python libraries.  https://github.com/pyca/cryptography/issues/2699
Do you have m2crypto installed?  Which distro is this?

m2crypto is not installed. The only ssl or crypt lib installed was pycrypto and I removed without any change.
I'm using gentoo.

@nfeutry, I'm not sure how to fix your issue.  It looks to be a messed up crypto problem on gentoo and python.

Good news, I have successfully installed a functional puppetboard based on the puppet module.
Bad news, I still don't known why my manual installations all failed with the same error.
I have absolutely no clue where this comes from. It does not seems to be related with puppetboard, I guess we can close this issue.
Thanks for your time and all the leads you shared!


Feature: Create an account

As a customer/visitor, I want to be able to:

[x] create an account so I can have a logged-in experience.

Bug: new user should be redirected to home page after signing up, but shows sign up again.


Change checkbox "Register VS Code to be the editor for associated file types" to be checked by default

After discussing with John Falcone and @joaomoreno we have decided to change the checkbox Register "VS Code to be the editor for associated file types" to be turned on by default.
Since we are wrapping up the June milestone, and July I am out on vacation we will do this start of the August milestone.
Related discussion https://github.com/microsoft/vscode/issues/8687#issuecomment-234303525
Main motivation for this: improve user experience on windows to more easily open associated file types in VS Code.

To make sure nothing gets broken:

[ ] put the change in a branch and create a build from it
[ ] in a fresh VM, install Code before your change with all defaults (no association)
[ ] in that same fresh VM, install the new Code with the change the same way the update does it. from a command line, run VSCodeSetup.exe /silent confirm that the associations were not set and that the user's decision at install time was preserved

@xandfis thanks for elaborating. We will keep this in mind in August when we flip the default.

Could this be scoped out to also include adding VS Code as a folder opener? This would be helpful for not getting into the "broken" case of having only single files open as opposed to project folders.
Either here:

Or here:

@JacksonKearl can you please create a new issue for that?
This milestone I want to do a minimal change (to minimise risk of breaking users) to only add more associated file types and to change the default.


Show help message with error

Hello,
Thanks for this tool that is quiet helpful.
On my first try, I've asked for the help panel with docker image (digest: sha256:cf129091b5bb20338c8985ef26d5705fb39adf860bf1ee998a2a9048f1a197b5) by running command :
docker run --rm -t lightswitch05/php-version-audit:latest --help

And I got this output
{
    "level": "error",
    "time": "2023-02-13T06:04:21+0000",
    "message": "Missing required argument: --version"
}
PHP Version Audit
usage: php-version-audit        [--help] [--version=PHP_VERSION]
                                [--fail-security] [--fail-support]
                                [--fail-patch] [--fail-latest]
                                [--no-update] [--silent]
                                [--v]
optional arguments:
--help                          show this help message and exit.
--version                       set the PHP Version to run against. Defaults to the runtime version. This is required when running with docker.
--fail-security                 generate a 10 exit code if any CVEs are found, or security support has ended.
--fail-support                  generate a 20 exit code if the version of PHP no longer gets active (bug) support.
--fail-patch                    generate a 30 exit code if there is a newer patch-level release.
--fail-latest                   generate a 40 exit code if there is a newer release.
--no-update                     do not download the latest rules. NOT RECOMMENDED!
--silent                        do not write any error messages to STDERR.
--v                             Set verbosity. v=warnings, vv=info, vvv=debug. Default is error. All logging writes to STDERR.

None soft should return error when asking help. Does it make sense for you ?

Hello! Yes, when people ask for help, it doesn't make sense to throw an error message at them. Thanks for the feedback 😄


Add i18n

tappy should be internationalized. It does not have a lot of strings which means this should be a no brainer.
The strings need to be marked up. POT file generated. Transifex account team started. Translation completed. PO file integration. Test suite updates to run through with different languages.

This is in progress...

:white_check_mark: Strings marked for i18n.
:white_check_mark: POT file generated.
:white_check_mark: Transifex account team started.
Translation completed (will start with Spanish).
PO file integrated.
Test suite updated for language check.

Done.


On the iPhone an error is thrown when cropping, when the photo is taken - undefined is not an object (evaluating 'normalizedImageResultItem.toCanvas')

iPhone Model: XS Max - iOS 17.3
Steps:
Click select File
Take a picture with the iPhone Camera
Open Cropper
Confirm
Error:
Unhandled Promise Rejection: TypeError: undefined is not an object (evaluating 'normalizedImageResultItem.toCanvas')
The Error appeared with the newest Version.
Notes: I downloaded the Repo, added my license, served on Port:3334. Connected my iPhone to Mac. Served $myIP:3334 on my iPhone and checked the console on my Mac.

i think i found the error.
If you don’t use
templateName as parameter
in
let normalizedImagesResult:CapturedResult = await this.cvr.capture(img);
in
@Method()
async getCroppedImage(options:CropOptions):Promise
It works just fine, even after taking the picture with the camera.

This is caused by the inconsistent coordinates due to scaling down of high-resolution photos. I've released a new version 2.2.1 to fix this.


Changes of errors on selectin the scope.

Coverage remained the same at 97.753% when pulling bd0e7c2d6a9bcc88757b4586110490f585d04b8a on GerardoHP:master into 7fc39f23df91c72b8b14ab8bceb6f80ef235b07e on unosquare:master.

Coverage remained the same at 97.753% when pulling f2de6fa4edf07cbd1c8bc98a7eaa47709adf556b on GerardoHP:master into 7fc39f23df91c72b8b14ab8bceb6f80ef235b07e on unosquare:master.