Issue with PATH expansion in VSCode subprocess on macOS

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.82.3
OS Version: Ventura 13.6

This one was tricky to investigate and is impacting the Unity extension and C# & C# Dev Kit scenario. In that scenario, VS Code is started from one application using the macOS open command. This reproduces without requiring Unity and with no extension installed. This seems to be a macOS only issue.
When opening Visual Studio Code either from the macOS Finder or through open, the VS Code application will expand the PATH of its Code Helper subprocess so that extensions that depend on something in the path of the terminal will find it.
So in my case, if I start VS Code from the Finder, the processes will look like this:
Code (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin)

This is expected and good. Extensions can find dotnet in the PATH.
The issue is that now, if I want to open another workspace in the same instance (but launched from another application), the PATH doesn't get expanded in the second workspace and I get:
Code (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin)

So in my second workspace, dotnet will not be found in the PATH.
For this to happen, VS Code must be started from an application launched from the Finder (and not from the Terminal, otherwise it will inherit the PATH of the Terminal)
Steps to Reproduce:

With Xcode, create a new SwiftUI project (I mean, it doesn't have to be a SwiftUI project, you can re-create the issue with anything that is able to output a macOS .app but for this particular repro I used SwiftUI)
Disable the Sandbox for the project:

Make the ContentView.swift look like this:

import SwiftUI
import Darwin
import Foundation

struct ContentView: View {
    var body: some View {
        VStack {
            Image(systemName: "globe")
                .imageScale(.large)
                .foregroundStyle(.tint)
            Text("Hello, world!")
            Button("Click to Launch") {
                let path = String(utf8String: getenv("PATH"))!
                let newPath = path + ":/lol"
                setenv("PATH", newPath, 1)

                let open = "/usr/bin/open"
                let vscode = "/Applications/Visual Studio Code.app"
                let workspace1 = "/Users/jbevain/tmp/ReproMirror"
                let workspace2 = "/Users/jbevain/sources/com.unity.ide.visualstudio"

                let p = Process()
                p.executableURL = URL(fileURLWithPath: open)
                p.arguments = ["-n", vscode, "--args", workspace1]

                try! p.run()

                Thread.sleep(forTimeInterval: 5)

                let p2 = Process()
                p2.executableURL = URL(fileURLWithPath: open)
                p2.arguments = ["-n", vscode, "--args", workspace2 ]

                try! p2.run()
            }
        }
        .padding()
    }
}

Modify the variables workspace1 and workspace2 to point to 2 different workspaces.

Build the project, I personally use xcodebuild in command line.

Close all VS Code instances.

Start the .app from the Finder, it will be in build/Release if you built from the command line by default.

Press the Click to Launch! button

As you can see from the code, the .app will:
1. set the PATH with a marker `/lol`
2. open a new VS Code workspace on workspace1
3. wait a bit
4. open a new VS Code workspace on workspace2

Open activity monitor, find the child process ID:

In the terminal, look at their path:

ps eww 44049
(Your pid may vary)

Observe that the second child process doesn't have its PATH expanded, and only inherited the PATH from the .app:

Code (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/lol)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/lol:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/lol)

@joaomoreno I think you're best equip to handle this issue?

I can't repro this. To know more, please do the following:

Quit VS Code
From a Terminal, run open -n /Applications/Visual\ Studio\ Code.app --args WORKSPACE, this should open VS Code
In that window, run Developer: Set Log Level... and set it to Trace.
Then, from a Terminal, run open -n /Applications/Visual\ Studio\ Code.app --args WORKSPACE2, this should open the second window
On the second window, reveal the Output panel and the Window logs. Search for userEnv, what do you find?

@joaomoreno the entire point of long repro is to not start VS Code from the terminal, but from an app launched from macOS.
As I said in the bug:

For this to happen, VS Code must be started from an application launched from the Finder (and not from the Terminal, otherwise it will inherit the PATH of the Terminal)

@jbevain Using open -n APP is the same as launching from Finder. Let me know the result.

@joaomoreno I'm afraid it's not exactly the same as it exhibits a different behavior:

Using open -n twice will work as expected from the Terminal.
Using the repro steps to create an app that will call open -n on Visual Studio Code twice won't work as expected.

Thanks for testing! Very interesting, I was unaware of differences here. Last I saw this (when I did the macOS integration years ago), open did not propagate environments. It seems like it does now. 🤔
Can you try just once more with: open vscode-insiders://fileWORKSPACE, replacing WORKSPACE with the path to the workspace? Thanks, I really appreciate it!

With open vscode-insiders://fileWORKSPACE from the Terminal I get the same behavior as open --args:
Code (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin)

Same here guys. Just installed unity + vscode and have this message about missing net sdk.
I came from here. https://github.com/microsoft/vscode-dotnettools/issues/532

I came here from #532 as well – and I'm glad I did! I've been banging my head against the "dotnet isn't on the PATH" issue
(and related!) for quite a long while and with insight from the fantastic writeup for this issue was able to get it to work again. For me, the break comes down to how I open my Unity project in VS Code.
How I Usually Open Unity Projects
I generally open my Unity Projects is with the following:

Open the project in Unity.
Select "Open C# Project" from the Assets menu.

If the project isn't already open, Visual Studio Code will open up a new window and load the project. When this happens, I get all the "I can't find dotnet!" issues.
How to Open Unity Projects Without the Issue

Open a new VS Code window (keyboard shortcut/menu/palette/whatever).
Open the project from within VS Code.

In my case, I do this via the "Open Recent..." menu as what I'm looking for is usually listed there.

Regardless, if I open the project in VS Code in this manner, everything works as expected.

@jbevain, sorry for the silence here. Let's try to figure this one out.
First of all, I can't get your Swift sample to work. It launches VS Code but fails to open each workspace properly, even after triple checking that I've changed both workspace paths to something that exists. I really couldn't figure out why...
In any case, can I ask you for one more piece of info?

Open from Finder (main process regular PATH, Code Helper with sourced PATH)
From a Terminal, call the open command with the path to the second workspace.

What's the PATH of that second Code Helper process that comes up? Resolved?

That happened to me before I turned the sandbox off. See step 2 of the repro?

🤦 Sorry about that. It runs correctly now! And I can repro!
Funny: it seems to only affect the PATH variable. If, say, one adds export FOO=bar to .zshrc, that gets properly propagated to both extension hosts (Code Helper (Plugin)). Interesting, digging more...

And I can repro!

Nice! Good luck :)

Got it! 🥳

/verified


RX Error in tune threshold baseline scan

Scan is aborted due to RX errors.

fixed in development and master

Lower the trigger rate. This seems to be fixed in development and master branch.


[LIBCLOUD-1043] Fix Azure upload_object_via_stream used with iter

Fix Azure upload_object_via_stream used with iter
Description
As described in LIBCLOUD-1043, the Azure Blob Storage driver currently doesn't support use-cases like this:
driver.upload_object_via_stream(iter(something), ...)

This is due to the fact that the current implementation of upload_object_via_stream assumes that the passed-in iterator always implements seek. This pull request adds a fallback for iterators where this is not the case.
Status

done, ready for review

Checklist (tick everything that applies)

[x] Code linting
[x] Documentation Bugfix only
[x] Tests Added new unit test
[ ] ICLA (required for bigger changes) Code change is small

Note that the build fails but as of today and commit a1f9897 this is also the case for trunk (sample build).
The failing tests are unrelated to the changes in this pull request, namely:
ElasticContainerDriverTestCase.test_create_cluster
ElasticContainerDriverTestCase.test_deploy_container
ElasticContainerDriverTestCase.test_destroy_cluster
ElasticContainerDriverTestCase.test_ex_create_service
ElasticContainerDriverTestCase.test_get_container
ElasticContainerDriverTestCase.test_list_clusters
ElasticContainerDriverTestCase.test_list_containers
ElasticContainerDriverTestCase.test_restart_container
ElasticContainerDriverTestCase.test_start_container
ElasticContainerDriverTestCase.test_stop_container

Tagging @michaelperel since he last modified this code.

Codecov Report

Merging #1287 into trunk will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##            trunk    #1287      +/-   ##
==========================================
+ Coverage   85.98%   85.98%   +<.01%
==========================================
  Files         359      359
  Lines       73809    73824      +15
  Branches     6698     6698
==========================================
+ Hits        63466    63481      +15
  Misses       7666     7666
  Partials     2677     2677

Impacted Files
Coverage Δ

libcloud/test/storage/test_azure_blobs.py
92.08% <100%> (+0.15%)
:arrow_up:

libcloud/storage/drivers/azure_blobs.py
68.43% <100%> (+0.47%)
:arrow_up:

Continue to review full report at Codecov.

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

Merged, thanks.


Had to switch highlighting of the head and upstream lines to the highlighting api, because I don't know how to do the current highlighting with :syntax. The highlights may need to be cleaned up on refresh, but I wasn't able to actually refresh an open status buffer with a changed branch and I didn't want to implement blind.

LGTM, thank you!

LGTM, thank you!


feat(batcher): stream tx outside on build_proposal

This change is

crates/batcher/src/proposal_manager_test.rs line 172 at r7 (raw file):
Previously, dafnamatsry wrote…
In that case, is there a point in keeping the simulate_build_block above?
(Non blocking).

I will clean the code in a separate PR


Installing PBISO without rebooting AIX

Good morning,
Is there a way to get PBISO working "authenticating" ad group.
without rebooting the AIX box. I cant afford to perform reboots.
I have restarted the following...

(PBISO) /opt/pbis/bin/lwsm restart lwio
(AIX) telinit  q
(AIX) stopsrc -s sshd ; startsrc -s sshd
(PBISO) /opt/pbis/bin/ad-cache --delete-all

thank you
Ninos

Do you have issues with authenticating without a reboot? The rebooting warning is mostly a catch all for issues around gdm and nscd. Are you running a caching service like nscd?

GDM is the GNOME Display Manager - Not sure what the equivilent of this is for AIX
NSCD for AIX is netcd - Is not enable.
http://www-01.ibm.com/support/docview.wss?uid=swg21500565

What issues are you having around authentication? Can you provide some more details like steps to reproduce and error messages?

LWIO should restart most of the ADB services, lsass handles authentication. I would start narrowing down if it's lsass or sshd that requires the restart.
From our testing, no reboot is required after an install/domainjoin.


Update development with fixes from v9.4.0-rc

The referenced changes have already been approved. Since this is a release management task we are self approving the merge without any reviews.

@ohine Should this be merged?

@mitchelsellers the build failed because of a failure in the call to the Azure API, I think that's what @ohine was talking about being in the way of generating a new RC…

/azp run

/azp run


Pura MAX: Unknown pet

My Pura MAX sometimes doesn't detect the pet by weight.
The official app can still show the last use duration and weight ("Pet just spent 1m39s in the litter box, weighing record 4.1kg"), is there a way to have this info with the home assistant integration as well?

It would require building out a separate "Unknown" pet device and parsing through daily logs to see if there were any unknown pet usages and weights associated with them. There is a cutoff when it comes to PetKit associating a measured weight with a pet (I'm not sure what that is since I don't own their litter boxes) - the easiest way to fix this is to look at the most recent weights (including Unknown measurement that are associated with the pet) of the pet in question and adjust the set pet weight so that the set weight falls in the range that the litter box tends to measure for said pet.

I tried, but for some reason if a cat weighs 4.1kg, then 4.2kg is not recognized even if I manually adjust it over and over.
Also, sometimes the cat just leans on the box and it registers 3kg, so I'd lose that event (not a big issue). Thank you.


Fix missing argument list for DROP FUNCTION migrations

Description

Fixes missing argument list for DROP FUNCTION migrations.
CALC_SEVERITY can exist with both 3, and 4 arguments, depending on when the system was first deployed. CALC_SEVERITY was updated to take an additional "severity_override" VARCHAR argument in https://github.com/DependencyTrack/hyades-apiserver/commit/6845ea1b7c11f163d9d712fdeaac9593fc903469#diff-8a05bac09ccef76206adca46106e47020121bc13254146fc287fd1279ddfad8a, but the previous version of the function was not dropped back then.
This adds argument lists to all functions being dropped, to avoid ambiguity.
Addressed Issue

N/A
Additional Details

N/A
Checklist

[x] I have read and understand the contributing guidelines
[x] This PR fixes a defect, and I have provided tests to verify that the fix is effective
~This PR implements an enhancement, and I have provided tests to verify that it works as intended~
[x] This PR introduces changes to the database model, and I have updated the migration changelog accordingly
~This PR introduces new or alters existing behavior, and I have updated the documentation accordingly~

The failing test is getSARIFFindingsByProjectTest which was found to be flaky, and should be fixed in #748. Merging this anyway.


Read Console credentials from environment variables first

New contributor, I couldn't find any issues talking about this so I went for it directly.
I'll add whatever is missing/required.
The fact that the default credentials are known and always set is not very good from a security standpoint.
Having to mess around with config files and the entrypoint of the container seems a bit too tedious for something that could be resolved via, at most, two environment variables.
Other solutions:

Some people might not like getEnvOr existing in server/config.go, if at all, we could not set a fallback value by just using os.Getenv instead and modify all the Dockerfiles in build/ folder to set the default value(s) there, although that adds chore tasks for new architectures or updates happening in said files.
A better long-term solution would be to modify nakama/flags to support reading from env vars if some struct tag is set, perhaps an env one.

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


Goodbooks data

Description
This code adds the goodbooks-10k/ data to our AWS database. This is done through two files:

xml_parser.py which adds the 10,000 XML files
goodbooks_to_db.py which adds the .csv files

Type of change
IN PROGRESS

[x] New feature (non-breaking change which adds functionality)

Change Status

[ ] Complete, tested, ready to review and merge
[ ] Complete, but not tested (may need new tests)
[x] Incomplete/work-in-progress, PR is for discussion/feedback

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] My code has been reviewed by at least one peer
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[x] There are no merge conflicts

 Add Goodbooks Data to DB


Class not found expectation while using Java 14

The console gets spammed with class not found exceptions when trying to use java 14
https://paste.ee/p/IpTD4
Minecraft: 1.16.4
Forge: 35.1.3
Mod: forge-1.16.4-geckolib-3.0.0-beta.10

Show your build.gradle. Is this in production or dev?

This is the production running a 1.16 pack

@UnRealDinnerbone I need to see your build.gradle.

I dont have a build.gradle this is running as a built jar in a 1.16.4 modpack


vtk can be imported in console but it always report No module named 'vtk' in spyder

Description of your problem
I installed vtk7.0.0, and add followings in .bashrc (my OS is ubuntu16.04 64bit)
export LD_LIBRARY_PATH=/usr/local/VTK/lib:$LD_LIBRARY_PATH
export PYTHONPATH=/usr/local/VTK/lib:/usr/local/VTK/lib/python3.5/site-packages:/usr/local/VTK/bin:$PYTHONPATH
I can run it correctly in python3 console:
import vtk
print(vtk.vtkVersion())
but when I run same script in spyder3, it always report :ImportError: No module named 'vtk'
I add same path into PYTHONPATH manager, it doesn't work. Can not spyder3 use the same configure with system?
Versions and main components

Spyder Version: sypder3 Spyder 2.3.8
Python Version: 3.5.1
Operating system: ubuntu16.04

Spyder should use the PYTHONPATH as set in the environment. Do you start it from a bash console? .bashrc is not run If a program is started from an icon or menu item.
When you add a path to the PYTHONPATH manager, that only takes effect in new Python or IPython consoles, not in existing ones.
You can print the path used to find modules for import with import sys; print(sys.path)
I hope these hints help you figure out what's going on.

Thank you very much. When I started spyder3 in the console, it worked. I tried again if I start it from menu, spyder3 can not acquire the system's PYTHONPATH.
When I installed spyder3 in the software centre, it made a short-cut in the menu automatically. So I often start spyder3 from menu. It takes me half a day to find a way to solve the problem, because I like to use spyder3 in python programming. When I decided to give up it, you help me solve the problem, I can use spyder3 again.
Thank you.

@jitseniesen, we should grab environment variables even if Spyder is not started from a terminal. What do you think?

@ccordoba12 I think the issue is that the environment variable is not set when you start spyder from the menu. OP put the PYTHONPATH assignment in .bashrc which is only executed when you start an interactive shell.


itoa is really slow.

Suggest we migrate to another implementation where possible.
The GridPage implementation is surprisingly MUCH faster.
205   val[0] = (MidiClock.bar_counter % 100) / 10 + '0';
206   val[1] = (MidiClock.bar_counter % 10) + '0';
207   val[2] = '\0';

itoa deprecated.


Bug: SideMenu URL Matching not working against full URLs

Info
We have two URLs in question:
/components
/components/accordion

I expect /components to be the active link when /components is the URL. However, I don't expect /components to be the active link when /components/accordion is the URL.
You can see what I just defined happening, here, which is using our latest build.
You can see what we expect here which is using a previous build of our web-components.
Acceptance Criteria:

Our URL matching needs to be more robust to allow for children pages

:tada: This issue has been resolved in version 1.15.1-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 4.15.1-alpha.2 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 1.17.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 4.17.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 4.17.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 1.17.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 2.6.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Helm chart] Should CRDs be placed in the special crds/ directory?

This is related to https://github.com/antrea-io/antrea/issues/2641.
We now have a chart for Antrea, which is currently used to generate the Antrea deployment manifests. In this chart, CRDs are currently treated as regular templates. Helm 3 introduces "special treatment" for CRDs, with the ability to place CRD definitions (as plain YAML, not templated) in a special crds/ directory. When CRDs are defined this way, they will be installed before other resources (in case these other resources include CRs corresponding to these CRDs). CRDs defined this way will also never be deleted (to avoid accidental deletion of user-defined CRs) and will also never be upgraded (in case the chart author didn't ensure that the upgrade was backwards-compatible). The rationale for all of this is described in details in this Helm community document: https://github.com/helm/community/blob/main/hips/hip-0011.md
Some projects using Helm charts as their main installation mechanism (e.g. Istio) are following "best practices" for Helm 3 and placing CRDs into the crds/ directory. This means that when upgrading Istio, CRDs must be upgraded first and separately, by applying a CRDs manifest: https://istio.io/latest/docs/setup/upgrade/helm/. IMO, this defeats a bit the purpose of using Helm, since you have to apply a separate YAML...
cert-manager does not use the crds/ directory at all. Users have 2 options:

install & upgrade CRDs manually
use the installCRDs=true value when installing / upgrading the Helm chart, which will treat CRDs as regular templated resources

Other projects have a more customized installation mechanism: Cilium CRDs are not installed by Helm, but by Cilium at runtime.
I am having trouble deciding what the "best" approach is here, so I would like some feedback. It seems we have the following options:

keep treating CRDs as regular templated resources: this matches the current manifest-based installation mechanism (CRDs are upgraded when applying a new manifest, CRDs are deleted when deleting the Antrea manifest), but may be surprising for Helm users and lead to unfortunate events when we remove a deprecated API
use the Helm 3 "special treatment" for CRDs and use the crds/ directory (same as Istio): this has caveats as described above, but could be considered the safest approach
use a more custom / hybrid approach like cert-manager

We may want to select the best approach possible upfront and stick to it, as switching approaches across versions could lead to other issues. No matter which approach we choose, it will need to be documented.
The second approach is possibly the most common approach for Helm charts with CRDs and is well-documented by Helm itself: https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#method-1-let-helm-do-it-for-you. However, I am having trouble accepting that this is the "best" approach, given the extra step for upgrading.

@hangyan @tnqn for opinions

Well i think I'm against solution 1, because it's problematic，some other reasons i can recall:

The normal creation step for resources in templates wont wait for the discovery api to be refreshed. This is critical to the crd resource, because we need that. crds solution can handle this.
I'm not sure how the current helm' upgrade method works, it's kind of complicated, i think it's tree-way patch (consider new, old, existing resources). Maybe we need to do a few round of test (including compatible and non-compatible crd changes, if there is existing crds) then we can actually confirm this solution works.

solution 2 is not ideal, but it's what the community recommended, and it's the safest option. I don't have strong opinion to follow solution 2, maybe some extra yaml/script is needed, i'm okay with that. solution 2 with extra docs should works too.
I think the benefit comes from using helm to do the template is pretty good already, not sure how many customers will actually prefer helm charts instead single yaml, so i'm okay with don't' spend too much time on the charts release, it's kind of best-effort.
Also, i have found this repo: https://github.com/banzaicloud/crd-updater, it also contains some details explain for this topic and provided a interesting solution, use helm chart dependence.

The information I get from https://helm.sh/docs/chart_best_practices/custom_resource_definitions is that Helm adds special handling for CRDs because some charts have CRDs and CRs at the same time, and separating CRDs from chart can ensure CRDs are always installed first? If I get it correctly, I think we don't have such issue, right? We have some pre-defined CRs (the static Tiers) but we chose to install them at runtime, just like Cilium chose to install CRDs at runtime. If we stick to this strategy, will keeping CRDs as regular templated resources be a problem?
And there is method 2 in the best practice: https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#method-2-separate-charts, which just keep CRDs and CRs in different charts. If we don't even have CRs in chart, does it mean keeping CRDs and all other resources in single chart meets the best practice method 2?

(CRDs are upgraded when applying a new manifest, CRDs are deleted when deleting the Antrea manifest), but may be surprising for Helm users and lead to unfortunate events when we remove a deprecated API

I'm not sure if I get it. When a Helm user deletes a chart, you mean they normally don't want CRDs and CRs installed by the chart to be removed? don't charts using method 2 have same problem?

If we follow a strict policy to not add related CR to the templates, the CRD discovery api refresh is not needed in that case. Although i still won't recommend to put the crds in the templates dir, as it's  a unique resource compare to others. remove crds from the normal helm upgrade phase is a safe approach. I can think of anther corner case will cause data loss: If there was an incompatible crd api change (X->Y),  the normal upgrade will failed. But some users may have default settings or choose to use the --force flag to do a force update, the old crd will be deleted before the new is created, thus cr data is damaged.
I think both the hybird approach or the sinlge crds dir approach is good. The end users should already be familiar with them , all we need to do left is to add some clear document.

If there was an incompatible crd api change (X->Y), the normal upgrade will failed.

@hangyan could you explain this more? You mean helm will check whether CRD has incompatible change and fail the upgrade?
I think we are following the recommended API practice and have never made incompatible change to any API. If there is an incompatible change, we should have a new version, and would there be a problem with helm?
Is the case that CRD is removed accidently because of an incompatible change something we need to worry? It's easy to prevent by adding a upgrade test to CI, right?
When installCRDs is false in cert-manager, how does it make old CRDs not removed if they don't put them in crds dir? Or it requires consistent install/upgrade approach so manually installed CRDs will never be managed by helm?

When installCRDs is false in cert-manager, how does it make old CRDs not removed if they don't put them in crds dir? Or it requires consistent install/upgrade approach so manually installed CRDs will never be managed by helm?

The second one. Users needs to run kubectl apply first to apply a YAML manifest with CRDs only, then they can run helm upgrade. That means CRDs (and therefore CRs) won't be deleted during upgrade.
@tnqn do you know what happens is a CRD manifest is updated to remove a version (i.e. the version is removed from the spec.versions list) while there are still some CRs with that version stored in the apiserver. Are these deleted automatically? I guess we don't really do this in Antrea, instead we set served and storage to false for the version, but we keep it in the CRD.

For the sake of making progress on this, I have decided to go with option 2 (use the crds/ directory, with an approach similar to the Istio project). In the end, I based the decision on the following factors:

helm install is still straightforward (single-step process), as CRDs are installed from the chart.
helm upgrade requires an extra step (manual CRD upgrade from standalone YAML manifest), but an upgrade should never be a trivial process anyway (API changes, etc.) and this is the safest approach. This will be documented carefully of course.
most Helm users should be familiar with this pattern and what it implies.

I wanted to add that I also considered sticking with option 1 and adding the "helm.sh/resource-policy": keep annotation to all CRDs. This would have ensured that CRDs were never deleted during upgrade. However:

A CRD update can also be dangerous (e.g. removing a version from a CRD)
It may be better to follow the standard Helm pattern of using crds/


Support actor invocations from the control interface

Actor invocations (previously used by something like wash ctl call) should be a part of the control interface in order to directly invoke actor handlers.

How would this be different than just using the RPC connection to make regular RPC calls to the actors?

@autodidaddict It's not different, but putting it in the control interface creates an easy interface for the washboard to make such calls instead of having to manage an invocation struct, generate guids, etc. I was referring mostly to how the old control interface provided a function for calling actors, but the OTP control interface does not https://github.com/wasmCloud/wasmCloud/blob/main/crates/wasmcloud-control-interface/src/lib.rs#L136

I think what really needs to happen here is that wash needs to be able to reach for 2 different sets of credentials - one for the RPC connection and one for the CTL connection, and this call function should be moved from ctl to rpc. This whole dual connection thing has been inconsistently handled and I do not want to add RPC invocations to the control interface as that would be exposing functionality to one connection that should be isolated in another.

Brooks, re: needing to make invocation struct. Hostbridge in wasmbus-rpc/provider.rs has a send_actor fn that does all that. I need to refactor it so you can use it outside a provider.

@stevelr the wasmcloud-control-interface crate also has the creation of invocations, etc. The issue here is mainly that we shouldn't be using the control interface connection/credentials to send RPC calls, that needs to take place on the control connection.
This and other changes are being bundled in https://github.com/wasmCloud/wash/issues/149

Closing this as a "will not implement" - the control interface cannot be used to invoke actors (or providers) for security reasons. The RPC and control connection separation is essential for security and allowing an RPC bypass via the control interface would violate that separation.


Confirm page button problem

The confirm all button is very small and messed up.
https://keas.azurewebsites.net/caesdo/Confirm/Confirm

I think this is styling difference between input buttons and anchor tags with button classes. I think @cydoval just needs to apply the same styles to both.


Error accessing commands in PATH

Hi Lu!
I'm having this error right off the bat, the AWS cli package is installed via brew and in the PATH.
Am I missing some basic config for the plugin?

TIA
Eli

Hi, Eli,
Can you include the full AWS path in the  "AWS cli path" location? Likely
the AWS localization where brew installed it is not visible to the IDE.
Best,
Lu
On Wed, Sep 20, 2023, 16:41 Eli Shalnev @.***> wrote:

Hi Lu!
I'm having this error right off the bat, the AWS cli package is installed
via brew and in the PATH.
Am I missing some basic config for the plugin?
[image: image]
https://user-images.githubusercontent.com/134416718/269319697-9bffcaef-4ded-44b4-8534-9033aa67ff8b.png
[image: image]
https://user-images.githubusercontent.com/134416718/269321172-d8607ffb-4999-4a10-9eb1-a629e8c73f62.png
TIA
Eli
—
Reply to this email directly, view it on GitHub
https://github.com/coderazzi/aws_codeartifact_maven/issues/11, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH54IJXU4EIYW63B7WF3U3X3L6APANCNFSM6AAAAAA5ABOO6I
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hi Lu,
Yes the full path is working, but since I'm using credential_process with AWS config file, that invoke another executable in path like aws-vault, it fails the same on that executable, is the PATH is something you control within the plugin scope?

Hi, Eli,
Let me see if I understand the issue: you invoke AWS from the plugin, using
the complete path, then AWS is going to use the credentials process and
call AWS_VAULT, but it doesn't find it in the path?
And AWS_VAUT is specified in the profile using its full path?
If so, is AWS_VAULT invoking itself AWS, which it cannot find in the path?
Best,
Luis
On Thu, Sep 21, 2023 at 6:34 AM Eli Shalnev @.***>
wrote:

Hi Lu,
Yes the full path is working, but since I'm using credential_process
https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sourcing-external.html
with AWS config file, that invoke another executable in path like
aws-vault https://github.com/99designs/aws-vault, it fails the same on
that executable, is the PATH is something you control within the plugin
scope?
—
Reply to this email directly, view it on GitHub
https://github.com/coderazzi/aws_codeartifact_maven/issues/11#issuecomment-1728937989,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH54IK5VN4S6SR5TUDUSYTX3PNX3ANCNFSM6AAAAAA5ABOO6I
.
You are receiving this because you commented.Message ID:
@.***>

Hi, Eli,
I am eeally interested in understanding the cause of the issue, have you
found the solution?
Best,
Lu.
On Thu, Sep 21, 2023 at 11:28 AM coderazzi @.***> wrote:

Hi, Eli,
Let me see if I understand the issue: you invoke AWS from the plugin,
using the complete path, then AWS is going to use the credentials process
and call AWS_VAULT, but it doesn't find it in the path?
And AWS_VAUT is specified in the profile using its full path?
If so, is AWS_VAULT invoking itself AWS, which it cannot find in the path?
Best,
Luis
On Thu, Sep 21, 2023 at 6:34 AM Eli Shalnev @.***>
wrote:

Hi Lu,
Yes the full path is working, but since I'm using credential_process
https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sourcing-external.html
with AWS config file, that invoke another executable in path like
aws-vault https://github.com/99designs/aws-vault, it fails the same on
that executable, is the PATH is something you control within the plugin
scope?
—
Reply to this email directly, view it on GitHub
https://github.com/coderazzi/aws_codeartifact_maven/issues/11#issuecomment-1728937989,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH54IK5VN4S6SR5TUDUSYTX3PNX3ANCNFSM6AAAAAA5ABOO6I
.
You are receiving this because you commented.Message ID:
@.***>

Oh sorry, I had no chance to test yet.
Answering your question, the credential_process executable aws-vault is called by name since it is already in PATH, when called from terminal. aws vault itself leverages the aws SDK so every time i call aws cli with specific profile the available credentials are temporary ones.
I'll try to test a workaround tomorrow by using the full path for aws-vault in aws config file and will post back. It's interesting tho to get to the bottom of the issue and understand why a PATH available to the plugin is different.

Hey Lu,
Just checked and your suggestion works, when adding full paths the plugin is able to get and configure token.
However, it would be great to understand how we can modify the PATH that plugin receieve from the environment (apparently managed by IDEA itself)

Hi, Eli,
glad to see that the solution was possible through the full paths.
The PATH option could be useful, but I am very partial to always using full
paths, and, to avoid making more convoluted the plugin interface.
The plugin is calling a CLI utility, and overriding the path could be as
easy as creating yet another script that first sets the PATH, and then
invokes the 'real' aws / aws-vault script.
Of course, if everybody was using this script hop, adding the PATH option
would be indeed useful, but for the time being, I would prefer to leave the
interface as it is.
Thanks for your time working and reporting this issue!
Best,
Lu.
On Thu, Sep 28, 2023 at 1:59 PM Eli Shalnev @.***>
wrote:

Hey Lu,
Just checked and your suggestion works, when adding full paths the plugin
is able to get and configure token.
However, it would be great to understand how we can modify the PATH that
plugin receieve from the environment (apparently managed by IDEA itself)
—
Reply to this email directly, view it on GitHub
https://github.com/coderazzi/aws_codeartifact_maven/issues/11#issuecomment-1739005978,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH54IOU37JEE7CQ7YPPNTTX4VRAHANCNFSM6AAAAAA5ABOO6I
.
You are receiving this because you commented.Message ID:
@.***>


Test and verify that all links are working

Links in all README.md files need to be tested and verified to be working.

done


SVG OSD from file Resize

Good moring,
Ive found this code pen which attaches an external svg overlay on top of a tile image.  Its exactly what I need so many thanks to the author.  (due to restrictions of browsers you cannot try it directly, but here is the code:
`

Now its working and resizing. Did not change anything. Guess somehitng was wrong in my browser.

Interesting. Glad to hear it sorted itself out; let us know if it pops up again!


Remove recurse when creating the base OMERO directory

To address the Ansible E208 lint error, a default permission has been added to the directory creation task of this role. However, the combination of mode and recurse causes idempotence tests to fail. This does not happen in this repository per se but any downstream role (ome.omero_server, ome.omero_web) or playbook (see e.g. https://github.com/ome/ansible-example-omero-onenode/runs/1857468587?check_suite_focus=true) will fail.
This PR proposes to remove recurse: true which means the role will only set the permissions for the directory. Every downstream role should be responsible for managing its content permissions which feels like the correct behavior. Additionally, when running the playbook against already deployed OMERO servers or web deployments, I have noticed that this task can take tens of seconds depending on the number of objects so it also improves the overall performance.
The alternative option would be to revert the mode field but I could not identify the rational for recurse: true from the code/history so I suppose it might have been here for historical reasons.
Proposed tag: 0.3.4

Technically someone could set omero_common_basedir to /my/very/long/custom/path so recurse was needed to create the parent directories. You could of course make it non-configurable and avoid that problem :smile:

Thanks for the feedback @manics. From the Ansible 2.8 documentation it looks like state: directory would automatically create intermediate directories with the specified permissions no?

I think it makes sense for each role/level to only enforce its own permissions. If another task/option is needed to create parent paths (mkdir -p) then it seems that we could do that separately.

Preliminary test overriding omero_common_basedir to use a nested folder suggest the role is currently doing the right behavior without the recurse: true.
I'll give it some thoughts over the day but my plan is likely move forward with a patch release tonight including this fix to make progress on the Ansible 2.8 lint fixes for the remaining ome.omero* roles. If issues are raised due to the usage of custom omero_common_basedir variables, we can fix them as necessary.


added arm64 core types and optimized gemm kernels

Compiling for target XGENE1 does not work. There are wrong symbols ( v0.d ) in sgemm_kernel_4x4.S. I don't know, who wrote this kernel.

delete this immediately - it should not be publicly available

deleted.
On 03/27/2015 12:42 PM, cbergstrom wrote:

delete this immediately - it should not be publicly available
—
Reply to this email directly or view it on GitHub
https://github.com/xianyi/OpenBLAS/pull/524#issuecomment-86908374.

Not yet - you have to delete the whole repo and refork to remove the commit. github doesn't gc commits so it stays online


Bump llvm to 5c116d50e42f93ef4fa9a9719121378ec6b99b69

Bump LLVM to 5c116d50e42f93ef4fa9a9719121378ec6b99b69
217988819 iree-dialects fixes (createOperation -> create and OpAsmParser::OperandType -> OpAsmParser::UnresolvedOperand)
5d06650d6 Assert on PDL native function call type mismatches.
8b2abae7b Add missing include in iree-dialects
e6491bf94 Rename OpAsmParser::OperandType to OpAsmParser::UnresolvedOperand globally in IREE
c50542572 Rename createOperation -> create globally
11614987b Bump MHLO to e918d22b258375050a140b320eeb1d1167079e43
0762fbfe7 clang-format
cdf96f56c Update PDL usage in linalg_transforms tests
1807fd24f Fix IREE tests for LLVM bump

LLVM revision: 5c116d50e42f93ef4fa9a9719121378ec6b99b69
MHLO revision: e918d22b258375050a140b320eeb1d1167079e43
Piper CL: 437369768

Thanks! Did we have a script to help generate the initial commit messages for these integrate PRs? We've had a few different styles of commit descriptions and there is usually useful information that could be included (links to commit hashes, brief description of code/test changes).
For example: #8612, #8542 (ideally all of those commit hashes would be clickable)

Updated by hand, please lmk if I should add something else.

Thanks! Did we have a script to help generate the initial commit messages for these integrate PRs? We've had a few different styles of commit descriptions and there is usually useful information that could be included (links to commit hashes, brief description of code/test changes).
For example: #8612, #8542 (ideally all of those commit hashes would be clickable)

Updated by hand, please lmk if I should add something else.

Thanks, that description LGTM! I edited out the PiperOrigin-RevId since that's something special in Copybara and will actually create issues if it sneaks into a commit that Copybara itself didn't author (it uses that field for its own bookkeeping).

Thanks! Did we have a script to help generate the initial commit messages for these integrate PRs? We've had a few different styles of commit descriptions and there is usually useful information that could be included (links to commit hashes, brief description of code/test changes).
For example: #8612, #8542 (ideally all of those commit hashes would be clickable)

Updated by hand, please lmk if I should add something else.

Thanks, that description LGTM! I edited out the PiperOrigin-RevId since that's something special in Copybara and will actually create issues if it sneaks into a commit that Copybara itself didn't author (it uses that field for its own bookkeeping).

SGTM, thanks!


Remove usages of shell=True in AWS provisioner (resolves #1183)

jenkins, test this please

@hannes-ucsc ready for review

Jenkins, test this please

Jenkins, test this please

@hannes-ucsc ready for review - let me know if have ideas for more special character tests! I think I covered the basics we talked about.

jenkins, test this please

jenkins, test this please

jenkins, test this please

@hannes-ucsc ready for review

jenkins, test this please

jenkins, test this please

Looks like a pip outage...
jenkins, test this please

I've addressed all of @hannes-ucsc comments and the code I've added since his last review is simple and has a test so I'm sure it works. Since Github complains when I try to approve my own PR I'll hold off on merging this for now, but it may start blocking #1300. At that point I'll go ahead and merge the PR anyway.


feat: add support for TMUX

I am not sure if you wouldn't add complexity to the plugin but maybe you can integrate, I could just have an autocommand in my config but I thought it would be nice to contribute.
Thank you for this plugin

Hey all, What is the state/status of this? I would love to have the support for TMUX added to this plugin, as I'm a TMUX user as well.

Hey sorry for the delay and thanks for the PR :+1:


Format version 1 stabilization

We have two format versions; version 1 has some smaller fixes, but nothing critical.
This issue should track stabilizing format version 1, and any changes we want to make to it now

https://github.com/ostreedev/ostree/pull/2532#discussion_r796389513

Thanks for opening this! While working on the PR you referenced above, I noticed a few other things we may want to change now.

Dropping the double extension .file.xattrs in favor of a single .file-xattrs. This should avoid potential future pitfalls, and we had consensus on this at https://github.com/ostreedev/ostree/pull/2532#discussion_r796628804.
Making .file-xattrs a first class object type. This stems from the change above, and would make both C and Rust implementations cleaner.

One thing to discuss separately is the repo/xattrs/ hierarchy. We could skip that and turn all .file-attrs object into regular files. From an integrity point of view, that content should be already covered by the usual checksumming through their corresponding companion .file object.
My understanding is that the tradeoff here is about saving space by de-duplicating xattrs across filepaths.
If we like to keep this property we could perhaps take an approach similar to the existing .payload-link object type, and have two different object types with (soft-?hard-?)links between them. Thoughts?

I assembled a PoC at https://github.com/ostreedev/ostree-rs-ext/pull/237, trying to somehow stay close to the current layout.
I'm not much convinced about the link objects .file-xattrs-link. For the on-disk bare-split-xattrs mode, we can't read the link-target of an hardlink. Thus I moved to a symlink, which however at some point will make pruning more expensive by requiring reachability scans. On top of that, a symlink target and a SELinux label are similar in size, so I think we aren't actually saving much space.

Making .file-xattrs a first class object type. This stems from the change above, and would make both C and Rust implementations cleaner.

The C code is a bit confused on this because things like to higher level code, I think OSTREE_OBJECT_TYPE_PAYLOAD_LINK is actually an implementation detail.  And that's definitely true for this xattrs thing which will only appear in this new repository format.
I dunno...I lean towards basically just tweaking the name of the xattrs file and keeping it a hardlink.
That said, there is an entirely different approach which is to use a "pack file" like mapping table.  OCI containers are just tarballs wrapped with JSON.  But the thing is, tar is designed as a streaming format - but we don't actually need streaming here.
We could e.g. compute all xattrs in advance, and generate a serialized mapping table from checksum -> xattr reference and just ship that whole thing as /ostree/repo/xattrs.table or so.
That said, such an approach makes writing more difficult.

On top of that, a symlink target and a SELinux label are similar in size, so I think we aren't actually saving much space.

True, but at least for the current approach of hard links, when written to disk, it is less expensive because the hard link path serialized in tar is "consumed" into a directory entry reference for an inode, which is less space in the general case (I think anyways).

Thanks for the lengthy feedback! I'm leaving the pack-file suggestion aside here, as I think its design may not play well in the future (wrt layered sharding, incremental changes, and parallel logic).

I dunno...I lean towards basically just tweaking the name of the xattrs file and keeping it a hardlink.

Given all of the above, I think I'm agreeing with you, let's stick to that.
I pushed a further commit on #237 which reverts to use hardlinks references instead.
Still, it is bringing xattrs content into the sharded object space, by having two dedicated types (file-xattrs for the content and file-xattrs-link for the hardlink) and dropping the separate repo/xattrs/ flat directory.
Is that ok for you, or did I miss some useful properties behind the separate repo/xattrs/?

One more thing about files with an empty xattrs set (which do not happen with SELinux, but may exist otherwise).
Right now those do not get an xattr reference. Thus when importing we do actually rely on the absence of an xattrs object. In that case, we currently do generate a synthetic empty set.
This is a bit fragile, as we also rely on the ordering (xattrs before file objects) for proper imports; so it makes it harder to detect buggy exports vs empty set.
Given that we deduplicate through hardlinks, we should really write an xattrs object for the "empty xattrs set" case and link to that. That would also ensure that each file is strictly composed of a pair of objects (content, xattrs).

I think we should probably write an empty file for empty xattrs, rather than hardlinking to a null set.  The reason for that is https://github.com/ostreedev/ostree/pull/2197

Thanks for bringing up this "too many links" corner case, it absolutely wasn't on my radar.
I guess the same failure mode may happen as well for a swarm of files sharing the same generic label (e.g. bin_t), so I think we can generally expand to "fallback to a plain copy on EMLINK".

Closing this as I believe what we have in the current format should be declared stable.


To Show Error when Bad Credentials

Description
To show an error message when Github API credentials are not intruded or are intruded wrong.
Expected behavior

To show up the counted PR as usual if the connection to Github's API has succeed.
To show an error message if the connection was not possible (and the message Github's API is returning to have more info).

Implementation

Controlling the HTTP Request response to check if it has an error message.
Resolve or reject the promise of the HTTP request depending on the error message.
To catch properly the rejected promise and manage the error message.
To control when the request fails and show up the error message.

Fixes

#17
#22 -> Not able to test, but in theory is the same pattern.

Closed until this repo gets alive again


Add support to control the backgroundColor of each section of the yAxis individually

Like so:

Would be great to have this option.

Thanks, @Golannnnn for requesting this feature. I will release it in the next version.

Hi @Golannnnn 👋
Sorry for the late response. This feature is now available from version 1.4.15 onwards. 🎉
We can now use the prop sectionColors to set the background color of the horizontal sections of the chart. It is an array of ColorValues (or strings denoting colors). So, each section can have a different background color now.
Please use the latest version of the library.


Unable to open PDF File on android

════════ Exception caught by widgets library ═══════════════════════════════════
The following _CastError was thrown building NotificationListener<KeepAliveNotification>:
Null check operator used on a null value

The relevant error-causing widget was
PDFViewer
lib/components/pdfViewer.dart:107
When the exception was thrown, this was the stack
#0      _PDFPageState._repaint
package:advance_pdf_viewer/src/page.dart:54
#1      _PDFPageState.didChangeDependencies
package:advance_pdf_viewer/src/page.dart:42

I have working where I create a pdf file and display on page.
It is working fine on ios devices.
But on android devices, it is showing this error message. Even share button is also sharing file but pdf view showing this error.
Please help to solve this error. After upgrade flutter 2 i am getting this message.
[✓] Flutter (Channel stable, 2.2.2, on Mac OS X 10.15.7 19H1217 darwin-x64, locale en-PK)
    • Flutter version 2.2.2 at /Users/student/Developer/flutter_2
    • Framework revision d79295af24 (4 weeks ago), 2021-06-11 08:56:01 -0700
    • Engine revision 91c9fc8fe0
    • Dart version 2.13.3

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Users/student/Library/Android/sdk
    • Platform android-30, build-tools 30.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[!] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.5, Build version 11E608c
    ✗ Xcode 11.5.0 out of date (12.0.1 is recommended).
      Download the latest version or update via the Mac App Store.
    • CocoaPods version 1.10.1

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

[✓] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.58.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.24.0

[✓] Connected device (3 available)
    • AOSP on IA Emulator (mobile) • emulator-5554 • android-x86    • Android 9 (API 28) (emulator)
    • macOS (desktop)              • macos         • darwin-x64     • Mac OS X 10.15.7 19H1217 darwin-x64
    • Chrome (web)                 • chrome        • web-javascript • Google Chrome 91.0.4472.114

! Doctor found issues in 1 category.

Did you found a solution?

Did you found a solution?

No, But I changed the plugin which is working fine.

I am also facing this error. @amaajid001 which plugin are you using now ?

I'm also having this issue.
It seems that on the first try to open the file it returns null from the here:
var data = await _channel         .invokeMethod('getPage', {'filePath': _filePath, 'pageNumber': page});
(From document.dart file)
And the interesting thing is that after I reopen my app everything works fine

I am also facing this error. @amaajid001 which plugin are you using now ?

I am using syncfusion_flutter_pdfviewer this package.

I am also facing this error. @amaajid001 which plugin are you using now ?

I am using syncfusion_flutter_pdfviewer this package.

This syncfusion_flutter_pdfviewer works very well, too bad it is not a free package.

I am also facing this error. @amaajid001 which plugin are you using now ?

I am using syncfusion_flutter_pdfviewer this package.

This syncfusion_flutter_pdfviewer works very well, too bad it is not a free package.

Its free brother. I am using it.

Its free brother. I am using it.

You applied for the community license ?

Its free brother. I am using it.

You applied for the community license ?

No Just installed package from pub,dev
https://pub.dev/packages/syncfusion_flutter_pdfviewer

Its free brother. I am using it.

You applied for the community license ?

No Just installed package from pub,dev
https://pub.dev/packages/syncfusion_flutter_pdfviewer

But it stated "Disclaimer: This is a commercial package. To use this package, you need to have either a Syncfusion commercial license or Free Syncfusion Community license."
I have never used this kind of package before. Does it mean that we will have to have a license if we want to publish our app the app store?

Any news on this topic or should I use another library?

Any news on this topic or should I use another library?

Go get another library named pdf_native_viewer by serge.software


Change audio driver to a better one

The current implementation is sketchy at best. It works fine on fedora, but only fedora. Since its so dependant on the systems configuration, and pulse audio is appearantly hard to configure, maybe something else should be used.

appearantly the awnser was an easy one, the portable library SFML was used, as of 1de4d6ebbdb83d39b04f20d8c62881394f707cf6


No effect after fine-tuning

Nothing is recognized after fine-tuning

I met the same problem

Even I tried it out the output deteriorates after training with each epoch

It needs to be used with bbox prompting.

How to use  bbox prompting for segmenting?


Refactor Custom Serving Runtime enablement

Description

Closes: #1205
How Has This Been Tested?

Custom Serving Runtime Panel Admin

Create several Custom Serving Runtimes
Start to enable/disable
You should see the serving runtime names added into the OdhDashboardConfig attribute templateDisablement

Custom Serving Runtimes available in DS Projects

Enable/Disable Custom Serving Runtimes
Go to DS Projects
Check that users only list the enables Serving Runtimes
Go back to Custom Serving Runtime
Check that the state of enablement is correct for every Serving Runtime

Migration with no OdhDashboardConfig

Add the annotation opendatahub.io/template-enabled: 'false' to existing templates
Delete the existing OdhDashboardConfig object
Restart the backend/restart the pods
A new OdhDashboardConfig object should be created
This object should contain a list in templateDisablement with the templates with the opendatahub.io/template-enabled: 'false' annotation
This object should have all the attributes
Inspecting api/config should contain  status.dependencyOperators field

Migration with OdhDashboardConfig

Add the annotation opendatahub.io/template-enabled: 'false' to existing templates
Ensure OdhDashboardConfig does not contain templateDisablement
Restart the backend/restart the pods
OdhDashboardConfig should now contain a list in templateDisablement with the templates with the opendatahub.io/template-enabled: 'false' annotation
Inspecting api/config should contain  status.dependencyOperators field if disablePipelines is set to false

Migration with OdhDashboardConfig and templateDisablement

Add the annotation opendatahub.io/template-enabled: 'false' to existing templates
Ensure OdhDashboardConfig has the attribute `templateDisablement``
Restart the backend/restart the pods
OdhDashboardConfig should maintain the same templateDisablement list
Inspecting api/config should contain  status.dependencyOperators field if disablePipelines is set to false

Test Impact

I'm going to add this testsuite alongside the testing efforts for https://github.com/opendatahub-io/odh-dashboard/issues/1198
Request review criteria:

[X] The commits have meaningful messages (squashes happen on merge by the bot).
[X] Included any necessary screenshots or gifs if it was a UI change.
[ ] Included tags to the UX team if it was a UI/UX change.
[X] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[X] The developer has manually tested the changes and verified that the changes work
[X] The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

@DaoDaoNoCode @alexcreasy I've just updated the testing efforts in this PR, since it's refactoring a part of the resource utils

It should be now ready to go.

I dont see any issues with the code itself. changes in resourceUtils look good. I dont have a cluster up so i have not been able to check it live yet

@Gkrumbach07 if you need a cluster let me know, I can share you mine!

When adding a new custom serving runtime and setting it to disabled, it is still visible in the to be selected in ds-projects after refresh too. it shows disabled in the config.
deleting a custom serving runtime that is disabled, does not remove it from the config

When adding a new custom serving runtime and setting it to disabled, it is still visible in the to be selected in ds-projects after refresh too. it shows disabled in the config.
deleting a custom serving runtime that is disabled, does not remove it from the config

@Gkrumbach07 that's a great catch, I've already updated it to remove lingering templates that might not be present.
btw, the disabled runtimes should not appear, I've tested it again and it's working fine for me, can we take a look at it later?

/lgtm

@lucferbux can this be merged now or do we need another review


Drop variables in a batch in normalize_entity

Dropping the additional_variables from the original dataframe takes a significant portion of the time of normalize_entity, and this increases with the number of additional_variables. For example, with 10 variables about 40% of the time is spent in df.drop, compared to 10% for 1 variable.
Currently we call df.drop once for each variable. The number of variables passed to df.drop does not affect its running time (in my benchmarking), so dropping them all at once is O(1) instead of O(n).
Entity.delete_variable is no longer used, but I wasn't sure if it is considered public.

Another significant part of the run time is this sort call: https://github.com/Featuretools/featuretools/blob/master/featuretools/entityset/entityset.py#L744
It's unclear to me why this would be necessary, and removing it doesn't break any of the tests.

the reason we do the sort is because we have an assumption that dataframes are sorted by their time index. This assumption is import so a primitive like cumulative sum can assume it is getting values in sorted order.
That being said, the sorting here might just be defensive coding and unnecessary if we can verify the dataframe is sorted prior to this call or after this call.


Automated Package Upgrade

:tada: This PR is included in version 26.0.106 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Solved issue #142- Adding suitable icons .

Added suitable icons for different sections in the navbar
By default the icons were coming white so I changed the color to black for better visibility
PFA the screenshot

@CSEdgeOff
Kindly review the PR


Feature/config ns bind

Configurable Namespace Bindings
Adjusted Config Pojos as configuration source
XPathHelper as configuration goal
New Tests and adjusted Tests

Builds, new feature is covered with tests.


List does not update if vue-list-scroller is used inside an overflow container

Your event mixins appear to only target the window, which breaks any cases where it is used inside an overflow container.
In this case, vue-list-scroller isn't listening to the scroll event on my overflow container, so when I scroll down the overflow container, vue-list-scroller isn't updating which items are rendered.
Check this jsfiddle (scroll down to see the problem): http://jsfiddle.net/jv6k0L37/

Yes, I wrote about it in README. I just don't need that feature right now and not gonna implement it any time soon. But PR's are welcome.


Dev

Implemented some rpc calls from TODOs

It seems that CI fails through some problem with dependencies version. Can i fix it and send PR?

I fixed the build issue, sorry about that.
Which one of the two PRs (#19, #20) is the current one now? They both seem to contain the same changes.

I fixed the build issue, sorry about that.
Which one of the two PRs (#19, #20) is the current one now? They both seem to contain the same changes.

#19

Would you mind closing the other one then? Thanks!

Would you mind closing the other one then? Thanks!

Yeah, I've closed #20.

Is there any block to merge this PR?

Unfortunately yes - the test you added is failing :)
Also, as mentioned above, I wasn't sure which of the two PRs you actually intended to contribute so I gave my feedback on the other one because it was more recent.
Do you plan on integrating that feedback? I added some thoughts on why the tests might be failing and suggested a way to solve it.
The branch will need a rebase against current master before it can be merged but that can happen as the last step. Note that I already integrated the formatting changes that occurred due to the latest Rust stable release. Means you can drop your formatting commit when rebasing against the current master.

In #19 PR I was added two rpc calls getblockhash, getbestblockhash and tests for it. It seems working fine(all tests passed, OK with CI).
In #20 i plan to implement more complex call getblockverbose and I've faced with some problem which I've mentioned.
I think you can merge this PR and afterthat I'll finish implementation of getblockverbose RPC call in other PR and take into account your feedback.
I think I've confused you because #20 contains some changes from #19.

Ah okay, now I understand. Sorry about that, I thought it was the same PR!
About the test: You are right, seemed like a small hickup with the docker container. I re-triggered it and it worked now.
I'll rebase the PR against current master and then merge it!


AssertionError: [<VariableDeclaration PyObject * tmp_constant_value_1 = None>]

Hello,
I found a code where CPython works and nuitka fails compiling.
python -m nuitka --standalone nuitka_test.py
Problem with <Node 'STATEMENT_CONDITIONAL'> at nuitka_test.py:2
Problem with <Node 'STATEMENT_TRY'> at nuitka_test.py:1
Nuitka:WARNING:Problem creating function code '__main__$$$function_1_test'.
Nuitka:WARNING:Problem creating code for module <Node 'PYTHON_MAIN_MODULE' with {'filename': 'nuitka_test.py', 'main_added': False, 'mode': 'compiled'}>.
Traceback (most recent call last):
  File "C:\Python37-32\lib\site-packages\nuitka\__main__.py", line 184, in <module>
    main()
  File "C:\Python37-32\lib\site-packages\nuitka\__main__.py", line 177, in main
    MainControl.main()
  File "C:\Python37-32\lib\site-packages\nuitka\MainControl.py", line 756, in main
    result, options = compileTree(main_module=main_module)
  File "C:\Python37-32\lib\site-packages\nuitka\MainControl.py", line 649, in compileTree
    makeSourceDirectory(main_module=main_module)
  File "C:\Python37-32\lib\site-packages\nuitka\MainControl.py", line 377, in makeSourceDirectory
    module_name=module.getFullName(),
  File "C:\Python37-32\lib\site-packages\nuitka\codegen\CodeGeneration.py", line 413, in prepareModuleCode
    function_body=function_body, context=context
  File "C:\Python37-32\lib\site-packages\nuitka\codegen\CodeGeneration.py", line 352, in generateFunctionBodyCode
    cross_module=function_body.isCrossModuleUsed()
  File "C:\Python37-32\lib\site-packages\nuitka\codegen\FunctionCodes.py", line 535, in getFunctionCode
    needs_exception_exit=needs_exception_exit,
  File "C:\Python37-32\lib\site-packages\nuitka\codegen\FunctionCodes.py", line 572, in _getFunctionCode
    context=context,
  File "C:\Python37-32\lib\site-packages\nuitka\codegen\CodeHelpers.py", line 246, in generateStatementSequenceCode
    statement_sequence=statement_sequence, emit=emit, context=context
  File "C:\Python37-32\lib\site-packages\nuitka\codegen\CodeHelpers.py", line 217, in _generateStatementSequenceCode
    statement=statement, emit=statement_codes, context=context
  File "C:\Python37-32\lib\site-packages\nuitka\codegen\CodeHelpers.py", line 173, in generateStatementCode
    statement=statement, emit=emit, context=context
  File "C:\Python37-32\lib\site-packages\nuitka\codegen\TryCodes.py", line 87, in generateTryCode
    statement_sequence=tried_block, emit=emit, allow_none=False, context=context
  File "C:\Python37-32\lib\site-packages\nuitka\codegen\CodeHelpers.py", line 246, in generateStatementSequenceCode
    statement_sequence=statement_sequence, emit=emit, context=context
  File "C:\Python37-32\lib\site-packages\nuitka\codegen\CodeHelpers.py", line 208, in _generateStatementSequenceCode
    statement_sequence=statement, emit=emit, context=context
  File "C:\Python37-32\lib\site-packages\nuitka\codegen\FrameCodes.py", line 128, in generateStatementsFrameCode
    statement_sequence=statement_sequence, emit=local_emit, context=context
  File "C:\Python37-32\lib\site-packages\nuitka\codegen\CodeHelpers.py", line 217, in _generateStatementSequenceCode
    statement=statement, emit=statement_codes, context=context
  File "C:\Python37-32\lib\site-packages\nuitka\codegen\CodeHelpers.py", line 177, in generateStatementCode
    assert not context.getCleanupTempnames(), context.getCleanupTempnames()
AssertionError: [<VariableDeclaration PyObject * tmp_constant_value_1 = None>]

Please check whether the bug was already reported or fixed.
Does not seem to
Please check out if the develop version of Nuitka works better for you.
Running pre-release already :)

If you want to post a problem/bug, to help us understand and resolve your issue
please check that you have provided at least the information below, and discard
up to here:

Nuitka version, full Python version and Platform (Windows, OSX, Linux ...)
0.6.4rc3
Python: 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 21:26:53) [MSC v.1916 32 bit (Intel)]
Executable: C:\Python37-32\python.exe
OS: Windows
Arch: x86

How did you install Nuitka and Python (pip, anaconda, deb, rpm, from source,
what is a virtualenv ...), this is very important usually.
Installed from pre-release msi file on windows.

If possible please supply a Short, Self Contained, Correct, Example
that demonstrates the issue i.e a small piece of code which reproduces
the issue and can be run with out any other (or as few as possible)
external dependencies.

Smallest example I could make:
def test(somelist=None):
    if 'element' in somelist if somelist is not None else []:
        print('yes')
    else:
        print('no')

test(['some', 'element'])
test()

Ok, I managed to reproduce it. Obviously related to the list in the conditional expression, if I change it in a tuple, I am getting this:

Nuitka:INFO:Missing optimization for constant to C bool.

So, there is something there not done, and the message catches it, but these things ought to be easy, let's see.
Yours,
Kay

Well, actually with the list it is being output as well.

def test():
    if [] if (somelist is not None) else []:
        print('yes')
    else:
        print('no')

So this probably getting us closer to the point:

AssertionError: [<VariableDeclaration PyObject * tmp_constant_value_1 = None>, <VariableDeclaration PyObject * tmp_constant_value_2 = None>]

Notice, how this warns about both. There must be a problem with how the conditional expression juggles with references of left and right hand side. The constants are created with other names initially, namely:

('tmp_condition_result_1', '->', [])
('tmp_condition_result_1', '->', [])

Not sure if that should use the same variable, but there is definitely something in the transfer of ownership to be looked at.

Ok, turns out, that because this is roughly the only case where a constant value PyObject * used as nuitka_bool is not yet optimized properly away, this ran into code that produced the nuitka_bool from the constant object (which in case of the list, is actually created and needs a release), which then is complained about. This would have been reference leaking, which Nuitka caught itself doing.
So we see this only because it's in a conditional expression in a conditional statement with a constant value that takes a reference.
I am going to put this through my Buildbots, then on factory for the immanent next release.

So this is in the latest pre-release and ought to work now.

Released as 0.6.4


[Dev] Zulip streams for GitHub issues

Describe the enhancement requested
While the migration to GitHub issues is taking place, we should think about the value of streams in the Zulip. There is one Zulip stream already set up: https://ursalabs.zulipchat.com/#narrow/stream/180246-github, but we might benefit from stream receiving only newly created GitHub issues etc.
Component(s)
Developer Tools

One of the problems with the current notifications is that every time a new issue is created as we are adding labels, assignee, etcetera we get double or tripled notifications. As an example the creation of this issue and the addition of the labels, see the time is the same because it is basically the same action (issue created):

Zulip integration is implemented by webhook: https://zulip.com/integrations/doc/github
It was configured by https://issues.apache.org/jira/browse/INFRA-17602 .
Zulip's GitHub integration is implemented in https://github.com/zulip/zulip/blob/main/zerver/webhooks/github/view.py . GitHub sends all issue related events (except issue comment events) as "issues" event and Zulip's GitHub integration accepts all of them.
It seems that Zulip's GitHub integration is needed to be improved to adapt our use case. How about creating an issue on https://github.com/zulip/zulip/issues for this or ask this on https://chat.zulip.org/ ?


Bug:  Changing ship from Hunter to default ship: null reference exception

The exception occurred at the starting port.  I attempted to change to default ship and received the error in the attached screenshot.  I was able to reproduce this a second time with the same prevship.ini.   These we do need on GitHub :-)


Worked example is confusing if worked at standalone without instructor input

There are multiple things in the worked example which might be hard for someone following alone outside the workshop setting to understand within some more explanation.  While we can provide that in the workshop, it might be useful to include this directly in the notebook?
In particular:

The use of Unitful - Perhaps we could add some text explaining what it does?
Some additional information about Optim could be provided in the notebook to explain (a) the existence of the dropdown; (b) the syntax going into the optimize function.

Do we care about this?  If so I'll be happy to add a few lines into the notebook to address the above, but if we only really intend for this notebook to live within the setting of a taught workshop we can leave it as is.

Thanks for the suggestions!  I pushed some changes in 982d1f112a9d12bc7aaac0d784aac724d283b4d0 which I hope address the main concerns.


badlion-client: 3.15.0 -> 4.3.0

Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

The title of this should be changed to badlion-client: 3.15.0 -> 4.3.0, and the commit name should be the same. See the pkgs commit conventions

Please reword the commit message.

Looks like this older PR does the same and is ready: https://github.com/NixOS/nixpkgs/pull/315505 :)


Functions for controlling the brightness of the display backlight. Ideas and suggestions.

Sorry for the many symbols.
I was pleased that a built-in function for controlling the brightness of the display backlight appeared.
But when trying to integrate the disp_backlight_set () function into my project, I ran into an unsolvable problem for me.
For the disp_backlight_set () function to work properly, a pointer to an initialized disp_backlight_h is required. Initialization occurs inside the function void * disp_driver_init (void), inside the function disp_backlight_h bckl_handle is also declared.
Inside the function void * disp_driver_init (void) there is a return bckl_handle, but that doesn't give us anything, because (void) in Africa is also (void).
In the beginning, the idea was to suggest that you change the function type void * disp_driver_init (void) to disp_backlight_h * disp_driver_init (void) to get a pointer when initializing the display.
On reflection, I came to the conclusion: all this is worthless.
There are only three channels for PWM. We cannot change the channel number for the display, it is always numbered #0. And for me this channel is used to reproduce sound signals. I do not foresee two display, as for the majority of users of your wonderful library.
To begin with, I propose to bring the backlight brightness control functions to a working state and simplify them to control only one display.
My edits:
components\lvgl_esp32_drivers\lvgl_tft\Kconfig
@@ -956,6 +956,20 @@ menu "LVGL TFT Display controller"
             help
                 Display backlight is controlled by pulse-width modulation, allowing brightness settings.

+        config LV_DISP_BACKLIGHT_PWM_CHANNEL
+            int "PWM channel" if LV_DISP_BACKLIGHT_PWM
+            default 0
+            range 0 3
+            help
+                The channel number for controlling the brightness of the display backlight.
+
+        config LV_DISP_BACKLIGHT_PWM_BRIGHTNESS_PERCENT
+            int "Brightness display backlight" if LV_DISP_BACKLIGHT_PWM
+            default 100
+            range 0 100
+            help
+                Display brightness as a percentage.
+
     endchoice

     config LV_BACKLIGHT_ACTIVE_LVL

Result:

lvgl_esp32_drivers/lvgl_tft/disp_driver.c
@@ -7,7 +7,7 @@
 #include "esp_lcd_backlight.h"
 #include "sdkconfig.h"

-void *disp_driver_init(void)
+void disp_driver_init(void)
 {
 #if defined CONFIG_LV_TFT_DISPLAY_CONTROLLER_ILI9341
     ili9341_init();
@@ -61,13 +61,10 @@ void *disp_driver_init(void)
         .output_invert = true, // Backlight on low
 #endif
         .timer_idx = 0,
-        .channel_idx = 0 // @todo this prevents us from having two PWM controlled displays
+        .channel_idx = CONFIG_LV_DISP_BACKLIGHT_PWM_CHANNEL
     };
-    disp_backlight_h bckl_handle = disp_backlight_new(&bckl_config);
-    disp_backlight_set(bckl_handle, 100);
-    return bckl_handle;
-#else
-    return NULL;
+    disp_backlight_new(&bckl_config);
+    disp_backlight_set(CONFIG_LV_DISP_BACKLIGHT_PWM_BRIGHTNESS_PERCENT);
 #endif
 }

lvgl_esp32_drivers/lvgl_tft/disp_driver.h
@@ -67,7 +67,7 @@ extern "C" {
  **********************/

 /* Initialize display */
-void *disp_driver_init(void);
+void disp_driver_init(void);

 /* Display flush callback */
 void disp_driver_flush(lv_disp_drv_t * drv, const lv_area_t * area, lv_color_t * color_map);

lvgl_esp32_drivers/lvgl_tft/esp_lcd_backlight.c
@@ -17,21 +17,23 @@ typedef struct {
     int index;        // Either GPIO or LEDC channel
 } disp_backlight_t;

+disp_backlight_t *bckl_dev = NULL;
+
 static const char *TAG = "disp_backlight";

-disp_backlight_h disp_backlight_new(const disp_backlight_config_t *config)
+void disp_backlight_new(const disp_backlight_config_t *config)
 {
     // Check input parameters
     if (config == NULL)
-        return NULL;
+        return;
     if (!GPIO_IS_VALID_OUTPUT_GPIO(config->gpio_num)) {
         ESP_LOGW(TAG, "Invalid GPIO number");
-        return NULL;
+        return;
     }
-    disp_backlight_t *bckl_dev = calloc(1, sizeof(disp_backlight_t));
+    bckl_dev = calloc(1, sizeof(disp_backlight_t));
     if (bckl_dev == NULL){
         ESP_LOGW(TAG, "Not enough memory");
-        return NULL;
+        return;
     }

     if (config->pwm_control){
@@ -67,20 +69,18 @@ disp_backlight_h disp_backlight_new(const disp_backlight_config_t *config)
         gpio_matrix_out(config->gpio_num, SIG_GPIO_OUT_IDX, config->output_invert, false);
     }

-    return (disp_backlight_h)bckl_dev;
 }

-void disp_backlight_set(disp_backlight_h bckl, int brightness_percent)
+void disp_backlight_set(int brightness_percent)
 {
     // Check input paramters
-    if (bckl == NULL)
+    if (bckl_dev == NULL)
         return;
     if (brightness_percent > 100)
         brightness_percent = 100;
     if (brightness_percent < 0)
         brightness_percent = 0;

-    disp_backlight_t *bckl_dev = (disp_backlight_t *) bckl;
     ESP_LOGI(TAG, "Setting LCD backlight: %d%%", brightness_percent);

     if (bckl_dev->pwm_control) {
@@ -92,16 +92,15 @@ void disp_backlight_set(disp_backlight_h bckl, int brightness_percent)
     }
 }

-void disp_backlight_delete(disp_backlight_h bckl)
+void disp_backlight_delete(void)
 {
-    if (bckl == NULL)
+    if (bckl_dev == NULL)
         return;

-    disp_backlight_t *bckl_dev = (disp_backlight_t *) bckl;
     if (bckl_dev->pwm_control) {
         ledc_stop(LEDC_LOW_SPEED_MODE, bckl_dev->index, 0);
     } else {
         gpio_reset_pin(bckl_dev->index);
     }
-    free (bckl);
+    free (bckl_dev);
 }

lvgl_esp32_drivers/lvgl_tft/esp_lcd_backlight.h
@@ -18,12 +18,6 @@ extern "C" { /* extern "C" */
  * GLOBAL PROTOTYPES
  **********************/

-/**
- * @brief Display backlight controller handle
- *
- */
-typedef void * disp_backlight_h;
-
 /**
  * @brief Configuration structure of backlight controller
  *
@@ -46,7 +40,7 @@ typedef struct {
  * @param[in] config Configuration structure of backlight controller
  * @return           Display backlight controller handle
  */
-disp_backlight_h disp_backlight_new(const disp_backlight_config_t *config);
+void disp_backlight_new(const disp_backlight_config_t *config);

 /**
  * @brief Set backlight
@@ -57,8 +51,8 @@ disp_backlight_h disp_backlight_new(const disp_backlight_config_t *config);
  * @param bckl                   Backlight controller handle
  * @param[in] brightness_percent Brightness in [%]
  */
-void disp_backlight_set(disp_backlight_h bckl, int brightness_percent);
-void disp_backlight_delete(disp_backlight_h bckl);
+void disp_backlight_set(int brightness_percent);
+void disp_backlight_delete(void);

 #ifdef __cplusplus
 } /* extern "C" */

If you like my idea, I will be glad.
There will be an incentive to develop the idea of using multiple display drivers in one project.
Once again I apologize for such a long text.

Hi, I'm in a road travel right now, but we're working on improving all the drivers on the develop branch.
I've separated the backlight initialization from the driver initialization function, but that branch will be changing a lot for a couple of weeks (a.k.a not ready for projects).
Please let me know if the work we're doing there is something along the lines of your patches.
Regards

carlos

Please let me know if the work we're doing there is something along the lines of your patches.

#endif

    return disp_backlight_init();
}

void *disp_backlight_init(void)
{

This separation of the backlight initialization function from the driver initialization function is really just a formality.
What's the point of separating the backlight initialization function this way? When exiting the driver initialization function, the backlight initialization function anyway called. In my opinion, this approach only complicates the understanding of the code.
In the rest of the code, alas, I did not see anything similar to my edits.

Hello @SinglWolf
Thank you very much for this issue. When we merged the backlight function, we left few TODOs, so it's good that you pointed them out. Most importantly, there is no good example how to use the new API (my bad).
We definitely want to go with multi-display support, so I'll fix the issues you mentioned in that manner.

We definitely want to go with multi-display support, so I'll fix the issues you mentioned in that manner.

Multiple display support? On different controllers? Will my dreams and aspirations come true?


Preparing for the next sprint

[ ] Sprint planning
[ ] Sprint review
[ ] Retro
[ ] Customer meeting scheduled and meeting room booked
[ ] Aleksi has invitation to the retro
[ ] Agenda done and sent to Denis
[ ] Roles clear: puheenjohtaja, demovastaava, kirjuri
[ ] Retro documented
[ ] Customer meeting documented

Sprint planning
Sprint review 30.5
Retro 30.5
Customer meeting scheduled: 30.5.
Roles clear: puheenjohtaja Joni, demovastaava Pia, kirjuri Iisak


Android chrome keyboard hides input when Component is used in a Dialog

What is the expected behavior?
Input should be visible
What is the current behavior?
Hidden by keyboard
What are the steps to reproduce?
Dialog config
dialog.open(LoginFormComponent, {
 disableClose: true,
});

Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Angular 7.1.3
Material 7.1.1
Chrome on Android (GOOGLE NEXUS 6, Android, v5)
Screen Size6.0 in - 2.9 x 5.2 in
Resolution1440 x 2560 px
Viewport411 x 731 dp
Is there anything else we should know?

It looks similar on iOS based on my testing as there is not enough space to show the full dialog. The difference (and inconvenience) in Android is that the page cannot be scrolled through. i.e. in iOS one can still scroll the page to make the dialog form-field visible.


Refs #34517 -- Skipped ImageFileField.update_dimension_fields without dimensions fields

https://code.djangoproject.com/ticket/34517
Avoids reading the image size when the dimensions fields (image_width,
image_height) do not exist, as that operation may be expensive.
Partially reverts ea53e7c09f1b8864c20c65976bbeaeab77abdaec, that dropped
the check for the dimension fields in update_dimension_fields(), because
the post_init signal was no longer registered without dimension fields.
However, another code path to that function exists: when the
ImageFileField is save()d, the name from the storage is setattr()ed on
the field, and ImageFileDescriptor calls update_dimension_fields()
because the image size might have changed.
Keep bailing out early when dimensions are unused.
Besides, computing the image dimensions causes to close() the file,
resulting in a backward-incompatible change. The test protects against
that change.

I didn’t include it in the test, because the current version is more precise, but here’s how a regular user (developer) would trigger this issue:
    def test_save_does_not_close_file_bis(self):
        p = self.PersonModel(name="Joe", mugshot=self.file1)
        p.save()
        with p.mugshot as f:
            # Underlying file object wasn’t closed.
            self.assertEqual(f.tell(), 0)

@francoisfreitag Thanks for the patch and early testing :dart: :+1:


Replace Toblerity/Shapely -> shapely/shapely

This is very similar to #1255 but for the shapely-1.8 maintenance branch.

@sgillies just realized there is one follow-up task that only you are able to complete, which is to re-create an AppVeyor installation for shapely/shapely done here: https://ci.appveyor.com/account/frsci/projects/new . Not sure if existing project can be re-assigned to a new repo, or if the former needs to be rename, and a new one created with the same project name. This will hopefully fix the "build unknown" badge now shown in README.rst for maint-1.8

I activated the AppVeyor app (github "Integration") again, but it might need a new commit on maint-1.8 to see if that is working again?
But quite likely it also needs some updates in the settings of https://ci.appveyor.com/project/frsci/shapely, which I don't have access too

I've update it to only run for maint-1.8 branch. I'll test a new commit directly...

Hmm, seems like it didn't work. But also not a big deal. Not sure if it's worth investing too much time in getting some of the shapely-2.0 GitHub Actions to work for maint-1.8

Not sure if it's worth investing too much time in getting some of the shapely-2.0 GitHub Actions to work for maint-1.8

I think that should actually be pretty straightforward.
The main change was the optional numpy or not, speedups or not, etc that made it more complicated. But could also just add windows to the current github actions workflow in maint-1.8, and copy over the windows specific bits of the workflow file in main:
https://github.com/shapely/shapely/blob/907c7ee19219b74c45e032f085d3dd3020e0544d/.github/workflows/tests.yml#L64-L68
https://github.com/shapely/shapely/blob/907c7ee19219b74c45e032f085d3dd3020e0544d/.github/workflows/tests.yml#L101-L105
https://github.com/shapely/shapely/blob/907c7ee19219b74c45e032f085d3dd3020e0544d/.github/workflows/tests.yml#L134-L142
(they should all have a if: ${{ matrix.os == 'windows-2019' }})


What is the performance/complexity when we add MATCH and WHERE to a command

Unable to find anywhere in the docs the complexity for MATCH and WHERE commands when added on top of NEARBY/INTERSECT.
I am using it with hooks and I want to understand which one performs better, because I have option to use both.
I have a key called person.
SET person alice FIELD name alice POINT 25.42513145100104 75.63783657767418
Now while setting hook which one of the following will give better performance ->

SETHOOK test kafka://<IP_ADDRESS>:9092/bbb INTERSECTS person MATCH alice MATCH bob FENCE DETECT enter,exit GET area test

SETHOOK test kafka://<IP_ADDRESS>:9092/bbb INTERSECTS person WHERE name 2 alice bobFENCE DETECT enter,exit GET area test

Also is there any performance benefit of referring the geofence as GET area test  v/s defining it directly like ->
SETHOOK test kafka://<IP_ADDRESS>:9092/bbb INTERSECTS person WHERE name 2 alice bobFENCE DETECT enter,exit OBJECT {"type":"Polygon","coordinates":[[[75.63783657767418,25.43318147102104],[75.6392084514683,25.43305944145809],........[75.63783657767418,25.43318147102104]]]}
Which one is a better approach in terms of performance.

MATCH and WHERE add some complexity to a query. Both are linear, and are performed on each potential record. MATCH is probably a little faster than WHERE because it directly performs a comparison operation on the ID, while the WHERE needs to dig into the object fields. Both should be pretty fast in most cases, yet workflows vary so I recommend testing on your side to see which is best of you.

Also is there any performance benefit of referring the geofence as GET area test  v/s defining it directly

No, both will perform the same.

@tidwall just had one more question regarding this. Please refer to the following query ->
SETHOOK test kafka://<IP_ADDRESS>:9092/bbb INTERSECTS person WHERE name 2 alice bob FENCE DETECT enter,exit OBJECT {"type":"Polygon","coordinates":[[[75.63783657767418,25.43318147102104],[75.6392084514683,25.43305944145809],........[75.63783657767418,25.43318147102104]]]}
SETHOOK test kafka://<IP_ADDRESS>:9092/bbb INTERSECTS person WHERE name 2 rob lob FENCE DETECT enter,exit OBJECT {"type":"Polygon","coordinates":[[[75.63783657767418,25.43318147102104],[75.6392084514683,25.43305944145809],........[75.63783657767418,25.43318147102104]]]}
as you can see the geofence is same in both the case. Does it internally treat it as 2 geofences? Or it keeps the hook on the same geofence?
If it does not treat it as same geofence i think creating a geofence first and then defining the hooks makes more sense.

it'll be treated as two geofences and if a devices enters the polygon it'll send two events to kafka


AUR build fails when python-installer is not installed

Hey,
when you try to install from the AUR the build fails, when python-installer is not installed.
Successfully built mov_cli_youtube-1.2.3-py3-none-any.whl
==> Entering fakeroot environment...
==> Starting package()...
/usr/bin/python: No module named installer
==> ERROR: A failure occurred in package().
    Aborting...
 -> error making: python-mov-cli-youtube-exit status 4

Looks like you forgot to add it to the dependencies in the pkgbuild.
cheers

Could you try installing mov-cli-youtube again?
Added python-installer to the makedepends.

Works now! thanks


observations plants stats info cards + charts

info cards for observation details' and zone level details' plants stats
extracted out plants dashboard chart for reusability
added charts for root level observation details and planting zone observations
updated generated types to account for species in observation details (requires a BE PR to be merged.. to build)

added charts

updated screenshots


Comfyui compatibility

What would it take to make this happen?

In progress.
BTW, what do you mainly want from comfyUI? It will help us to do it better

In progress. BTW, what do you mainly want from comfyUI? The more we clarify your demand, we will finish this feature better.

SDXL models seem to run better in ComfyUI, and in general ComfyUI tends to perform faster then 1111. So I personally would love to be able to run SD using ComfyUI instead of 1111 in Photoshop.

Just the speed and vram usage. The features aren't important to me. Thank you!

In progress. BTW, what do you mainly want from comfyUI? The more we clarify your demand, we will finish this feature better.

I'm currently using a lot img2img, inpainting, Loras, and control net.

+1


Alias health in lieu of a separate binding

Hey 👋
This PR addresses an issue that arises when using Laravel's Container Events.
Given the following excerpt from an actual ServiceProvider:
public function register(): void
{
    $this->app->afterResolving(Health::class, $this->registerChecks(...));
}

private function registerChecks(Health $health)
{
    $health->checks([
        CacheCheck::new(),
        // ommitted for brevity...
    ]);
}

Triggering the health:schedule-check-heartbeat command makes the application crash with the following exception:
Spatie\Health\Exceptions\DuplicateCheckNamesFound
Digging a bit deeper reveals that the command eventually makes use of the Health Facade on L17.
The problem with this, is that the Facade makes use of the health binding instead of the singleton Health::class binding. A kinda hidden and notorious behaviour of the Facade class is that it creates a completely separate service context, ie. non-singleton bindings will be treated as singletons when making use of a Facade.

TL;DR By aliasing health to Health, we can ensure the same instance is used across all possible use cases.
(I have also removed the Closure defined on L39 because the IoC container will be able to auto-wire that without any problems.)
Thanks!

Thank you!