Investigate how to create a richer system tray UI with Rust / Tauri

Our vision for the Ockam desktop application is to provide a system tray with a visually rich UI containing:

menu items triggering async actions
images
native icons
text with variable fonts
progress or status indicators
large on/off switch button
modal windows for complex input data

We've started implementing the application on top of tauri since it provides some of this functionality out of the box:

a system tray
menu items with actions
native icons (MacOS only)
modal windows

This is unfortunately limited and we want to explore richer alternatives:

either other libraries
or extensions to the tauri underlying libraries, tao and muda, tray_icon

@etorreborre this looks interesting
https://crates.io/crates/cocoa
Here's an example of someone calling the MacOS AppKit
https://github.com/olback/tray-item-rs/blob/master/src/api/macos/mod.rs

Tao and Muda seem to be using the same approach as the above example
https://github.com/tauri-apps/tao/blob/b31cb692df2b0a03d2fbdf2fbf7ba82591678e24/src/platform_impl/macos/system_tray.rs#L20
https://github.com/tauri-apps/muda/blob/e5324b76840dbe7414107ad4a1ea35296a63b425/src/platform_impl/macos/mod.rs#L62

@nazmulidris is this issue now part of a specific story?

I think this can be closed. It is part of this https://github.com/build-trust/ockam/issues/5774


Fixed #26162 -- Checked query name clashes of hidden relationships.

@Ian-Foote can you confirm you now get a check failure?

Yes, I do.


Add a Settings Tab in the Settings UI

Love your plugin, but would be great to configure settings visually. Here's the developer docs on the topic: https://docs.obsidian.md/Plugins/User+interface/Settings

Hi @mjmaurer ! Thank you! I'm working on the Settings page. However, I'm busy these days. It will take some time before available.

Hi @mjmaurer ! Setting Tab is now available in v0.12.0. Thank you.


Add missing cython dependency

Otherwise pip install will ignore cython

Hi @cscully-allison and @ilumsden, could you please let me know if there's any comments for this PR?

Hi @Jokeren. Sorry for not responding. I was in the process of relocating to Livermore for the summer.
The changes in this PR should not be necessary to add Cython. Hatchet and Thicket are both designed to be PEP 517 compliant. As a result, the process of installing Cython should be taken care of by pip based on the contents of pyproject.toml.
I also reviewed the GitHub Actions logs that you shared with me. Based on those logs, it looks like there are two main issues going on:

pip is rejecting the wheels that we provide on PyPI (which have the Cython code pre-compiled) due to a Python version mismatch
pip is not correctly handling pyproject.toml. More specifically, it parses the file but does not run the step to install the build system dependencies (namely Cython)

Given these issues, I have three questions:

What version of pip are you using?
What version of Python are you using?
Given that the CI is self hosted, what is the architecture of the system this is running on?

pip is not correctly handling pyproject.toml. More specifically, it parses the file but does not run the step to install the build system dependencies (namely Cython)

Yeah, I think this is probably the problem.

What version of pip are you using?

pip 22.0.2

What version of Python are you using?

Python 3.10.12

Given that the CI is self hosted, what is the architecture of the system this is running on?\

The problem appears on a several systems not only the CI machine.
My local WSL is Ubuntu 22.04.
The remote CI is also an Ubuntu 22.04 I suppose.

@Jokeren can you try adding the --use-pep517 flag to your pip install command?

That doesn't seem to install the cython package

pip is rejecting the wheels that we provide on PyPI (which have the Cython code pre-compiled) due to a Python version mismatch

Oh, I guess it might be that the python version on our CI node is too new? Let me ask

The remote CI is also an Ubuntu 22.04 I suppose.

I was wrong. The CI was Ubuntu 22.04 but got updated to 24.04. And the python version is 3.12.

@Jokeren sorry for the delay, but I might have an idea as to why Cython's not getting installed. Can you try running with both the --use-pep517 and the --check-build-dependencies flags?

@ilumsden @pearce8 we just removed --no-build-isolation in the CI, but recommend users as a tip to speedup compilation.
Thanks for investigating!

Of course. Happy to help!
I also wanted to share this @Jokeren: https://github.com/pypa/pip/issues/11440
Apparently, there is planned feature for pip to allow users to just build install or build dependencies for a package. With that feature, it will be possible to easily handle the build dependencies with:
$ python3 -m pip install --only-build-deps llnl-hatchet
$ python3 -m pip install --no-build-isolation llnl-hatchet

In terms of stuff that already exists, the pip-compile command from pip-tools can already support this with it's --build-deps-for, --all-build-deps, and --only-build-deps flags: https://pip-tools.readthedocs.io/en/latest/cli/pip-compile/

Actually, @Jokeren, it sounds like that pip feature may be delayed. It sounds like any implementation of that feature will be dependent on the in-progress PEP 735

Since removing --no-build-isolation seems to have fixed the issue in Triton, I'm going to go ahead and close this.


try packaging with abs

Please ignore for now. I wanted to test this on a repo with a values.schema.json

@piontec @oponder anything against merging this into the add-values-schema branch?

Sure! What does it do? 😅

Sure! What does it do? sweat_smile

Validate and packate the chart with app-build-suite and also generate metadata


[PDI-14797] Get Filenames Step issue with VFS and WinSSHD

added sftp windows supporting
added tests

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f core/build.xml clean-all resolve jacoco && ant -f core/build.xml checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  core/src/org/pentaho/di/core/fileinput/FileInputList.java
  core/src/org/pentaho/di/core/vfs/KettleVFS.java
  core/src/org/pentaho/di/core/vfs/SftpFileObjectWithWindowsSupport.java
  core/src/org/pentaho/di/core/vfs/SftpFileSystemWindows.java
  core/src/org/pentaho/di/core/vfs/SftpFileSystemWindowsProvider.java
  core/test-src/org/pentaho/di/core/vfs/SftpFileObjectWithWindowsSupportTest.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.vfs.KettleVFS

Branch Change:  + 1.28%
Complexity Change: -.34%:small_red_triangle_down:
Instruction Change: -.00%:small_red_triangle_down:
Line Change:  + .16%

org.pentaho.di.core.vfs.SftpFileObjectWithWindowsSupport

Branch New Coverage: 45.65%
Complexity New Coverage: 12.50%
Instruction New Coverage: 41.93%
Line New Coverage: 36.25%
Method New Coverage: 14.63%

org.pentaho.di.core.vfs.SftpFileSystemWindows

Complexity New Coverage: 3.85%
Instruction New Coverage: 1.49%
Line New Coverage: 1.20%
Method New Coverage: 11.11%

License header violations

:heavy_exclamation_mark: Copyright year is not the current year on core/src/org/pentaho/di/core/fileinput/FileInputList.java. Found 2016. Was expecting 2017

Checkstyle violations
The code submitted is not complying with one or more of our guidelines. To perform these checks locally, please use this tool.
/home/buildguy/project/core/src/org/pentaho/di/core/fileinput/FileInputList.java

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 235 Column: 112

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 238 Column: 43

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 238 Column: 53

/home/buildguy/project/core/src/org/pentaho/di/core/vfs/KettleVFS.java

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 157 Column: 11

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 157 Column: 47

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 159 Column: 72

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 159 Column: 99

/home/buildguy/project/core/src/org/pentaho/di/core/vfs/SftpFileObjectWithWindowsSupport.java

:heavy_exclamation_mark: '||' should be on a new line. at Line: 87 Column: 81

:heavy_exclamation_mark: '||' should be on a new line. at Line: 88 Column: 88

:heavy_exclamation_mark: '||' should be on a new line. at Line: 89 Column: 93

:heavy_exclamation_mark: 'if' construct must use '{}'s. at Line: 91

:heavy_exclamation_mark: '||' should be on a new line. at Line: 119 Column: 82

:heavy_exclamation_mark: 'if' construct must use '{}'s. at Line: 121

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 159 Column: 34

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 159 Column: 46

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 174 Column: 37

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 174 Column: 49

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 179 Column: 30

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 179 Column: 51

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 285 Column: 47

/home/buildguy/project/core/src/org/pentaho/di/core/vfs/SftpFileSystemWindowsProvider.java

:heavy_exclamation_mark: '(' is followed by whitespace. at Line: 38 Column: 19

:heavy_exclamation_mark: ')' is preceded with whitespace. at Line: 38 Column: 35

:heavy_exclamation_mark: '(' is followed by whitespace. at Line: 40 Column: 19

:heavy_exclamation_mark: ')' is preceded with whitespace. at Line: 40 Column: 35

/home/buildguy/project/core/test-src/org/pentaho/di/core/vfs/SftpFileObjectWithWindowsSupportTest.java

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 40 Column: 50

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 40 Column: 70

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 41 Column: 38

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 41 Column: 52

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 44 Column: 65

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 44 Column: 92

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 46 Column: 88

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 48 Column: 20

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 48 Column: 50

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 48 Column: 51

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 48 Column: 52

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 54 Column: 50

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 54 Column: 70

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 55 Column: 38

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 55 Column: 52

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 57 Column: 22

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 57 Column: 26

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 60 Column: 65

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 60 Column: 92

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 65 Column: 16

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 65 Column: 30

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 69 Column: 21

:heavy_exclamation_mark: ',' is not followed by whitespace. at Line: 69 Column: 36

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 69 Column: 41

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 70 Column: 85

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 70 Column: 89

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 72 Column: 88

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 81 Column: 50

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 81 Column: 70

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 82 Column: 38

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 82 Column: 52

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 85 Column: 65

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 85 Column: 92

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 87 Column: 88

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 89 Column: 20

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 89 Column: 50

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 89 Column: 51

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 89 Column: 52

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 97 Column: 50

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 97 Column: 70

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 98 Column: 38

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 98 Column: 52

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 100 Column: 22

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 100 Column: 26

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 103 Column: 65

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 103 Column: 92

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 108 Column: 16

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 108 Column: 30

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 112 Column: 21

:heavy_exclamation_mark: ',' is not followed by whitespace. at Line: 112 Column: 36

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 112 Column: 41

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 113 Column: 85

:heavy_exclamation_mark: ')' is not preceded with whitespace. at Line: 113 Column: 89

:heavy_exclamation_mark: '(' is not followed by whitespace. at Line: 115 Column: 88

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f core/build.xml clean-all resolve jacoco && ant -f core/build.xml checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  core/src/org/pentaho/di/core/fileinput/FileInputList.java
  core/src/org/pentaho/di/core/vfs/KettleVFS.java
  core/src/org/pentaho/di/core/vfs/SftpFileObjectWithWindowsSupport.java
  core/src/org/pentaho/di/core/vfs/SftpFileSystemWindows.java
  core/src/org/pentaho/di/core/vfs/SftpFileSystemWindowsProvider.java
  core/test-src/org/pentaho/di/core/vfs/SftpFileObjectWithWindowsSupportTest.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.vfs.KettleVFS

Branch Change:  + 1.28%
Complexity Change: -.34%:small_red_triangle_down:
Instruction Change: -.00%:small_red_triangle_down:
Line Change:  + .16%

org.pentaho.di.core.vfs.SftpFileObjectWithWindowsSupport

Branch New Coverage: 45.65%
Complexity New Coverage: 12.50%
Instruction New Coverage: 41.93%
Line New Coverage: 37.80%
Method New Coverage: 14.63%

org.pentaho.di.core.vfs.SftpFileSystemWindows

Complexity New Coverage: 3.85%
Instruction New Coverage: 1.49%
Line New Coverage: 1.20%
Method New Coverage: 11.11%

License header violations

:heavy_exclamation_mark: Copyright year is not the current year on core/src/org/pentaho/di/core/fileinput/FileInputList.java. Found 2016. Was expecting 2017

Checkstyle violations
The code submitted is not complying with one or more of our guidelines. To perform these checks locally, please use this tool.
/home/buildguy/project/core/test-src/org/pentaho/di/core/vfs/SftpFileObjectWithWindowsSupportTest.java

:heavy_exclamation_mark: ',' is not followed by whitespace. at Line: 69 Column: 37

:heavy_exclamation_mark: ',' is not followed by whitespace. at Line: 112 Column: 37

Build Completed
:white_check_mark: This pull request has passed all validations.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f core/build.xml clean-all resolve jacoco && ant -f core/build.xml checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  core/src/org/pentaho/di/core/fileinput/FileInputList.java
  core/src/org/pentaho/di/core/vfs/KettleVFS.java
  core/src/org/pentaho/di/core/vfs/SftpFileObjectWithWindowsSupport.java
  core/src/org/pentaho/di/core/vfs/SftpFileSystemWindows.java
  core/src/org/pentaho/di/core/vfs/SftpFileSystemWindowsProvider.java
  core/test-src/org/pentaho/di/core/vfs/SftpFileObjectWithWindowsSupportTest.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.vfs.KettleVFS

Branch Change:  + 1.28%
Complexity Change: -.34%:small_red_triangle_down:
Instruction Change: -.00%:small_red_triangle_down:
Line Change:  + .16%

org.pentaho.di.core.vfs.SftpFileObjectWithWindowsSupport

Branch New Coverage: 45.65%
Complexity New Coverage: 12.50%
Instruction New Coverage: 41.93%
Line New Coverage: 37.80%
Method New Coverage: 14.63%

org.pentaho.di.core.vfs.SftpFileSystemWindows

Complexity New Coverage: 3.85%
Instruction New Coverage: 1.49%
Line New Coverage: 1.20%
Method New Coverage: 11.11%

@mbatchelor Could you please review and merge it?


http://<IP_ADDRESS>:5000/HomePage

Messes with my flask apps!
Every time  i run any app and try to navigate to http://<IP_ADDRESS>:5000/
it changes it to http://<IP_ADDRESS>:5000/HomePage
I'm not even using this app anymore I'm trying to use other flask apps that were working before.

Closed by #51 -- @DavidAwad thanks for the patch and bug report, and I'm really ashamed it took almost 3 years to get to this, I've been horrible to this project.

i am also getting the same issue .you can run it on other browsers as it will work over there.

goi kah

app = Flask(name)
@app.route('/user/')
def show_user_profile(username):
# show the user profile for that user
return (f'User {username}')
@app.route('/post/int:post_id')
def show_post(post_id):
# show the post with the given id, the id is an integer
return (f'Post {post_id}')
@app.route('/path/path:subpath')
def show_subpath(subpath):
# show the subpath after /path/
return (f'Subpath {subpath}')

when i run http://<IP_ADDRESS>:5000/ i am get this error Error occurred in request., ReadTimeout: HTTPSConnectionPool(host='lovakumari001.cognitiveservices.azure.com', port=443): Read timed out. (read timeout=100)


Unable to share vehicle

I have stepped through the process 3 times now and keep getting the below error after I scan the QR code on the tesla website and it launches the Tesla Phone App.
I have no idea whats wrong and would appreciate any ideas / feedback on how to troubleshoot

Things I have tried

Went over the docs multiple times and ensured all the steps work one after the other for the initial configuration
I have created a new app 3 times and stepped through the things methodically
I am certain the public key com.tesla.3p.public-key.pem is available on the FQDN

Here is a redacted log output that may help with investigation
Configuration options not set in /data/config.sh, exiting
Configuration Options are:
CLIENT_ID=<redacted>
CLIENT_SECRET=<redacted>
DOMAIN=tesla.<redacted>.website
PROXY_HOST=teslaproxy.local
REGION=North America, Asia-Pacific
Setting up for first launch
Setting up GnuPG and password-store
gpg: keybox '/data/gnugpg/pubring.kbx' created
gpg: /data/gnugpg/trustdb.gpg: trustdb created
gpg: directory '/data/gnugpg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/data/gnugpg/openpgp-revocs.d/<redacted>.rev'
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust:
gpg: next trustdb check due at 2027-04-26
/data/gnugpg/pubring.kbx
------------------------
pub   ed25519 2024-04-26 [SC] [expires: 2027-04-26]
      <redacted>
uid           [ultimate] myself
sub   cv25519 2024-04-26 [E]
created directory: '/data/password-store/'
Password store initialized for myself
Generating keypair
-----BEGIN PUBLIC KEY-----
<redacted>
-----END PUBLIC KEY-----
SSL certificate does not exist
Generating self-signed SSL certificate
-----
Starting temporary Python app for authentication flow. Delete /data/access_token to force regeneration in the future
[13:46:00] main:INFO: *** Starting Flask server... ***
[13:46:00] werkzeug:INFO: WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on all addresses (<IP_ADDRESS>)
 * Running on http://<IP_ADDRESS>:8099
 * Running on http://<IP_ADDRESS>:8099
[13:46:00] werkzeug:INFO: Press CTRL+C to quit
[13:46:03] werkzeug:INFO: <IP_ADDRESS> - - [26/Apr/2024 13:46:03] "GET / HTTP/1.1" 200 -
[13:46:29] main:INFO: callback args: ImmutableMultiDict([('locale', 'en-US'), ('code', '<redacted>'), ('state', '<redacted>'), ('issuer', 'https://auth.tesla.com/oauth2/v3')])
[13:46:29] main:INFO: Info to enter into Tesla Custom component:
Refresh token  : <redacted>
Proxy URL      : https://teslaproxy.local:4430
SSL certificate: /share/home-assistant/selfsigned.pem
Client ID      : <redacted>
[13:46:29] werkzeug:INFO: <IP_ADDRESS> - - [26/Apr/2024 13:46:29] "GET /callback?locale=en-US&code=<redacted>&state=<redacted>&issuer=https://auth.tesla.com/oauth2/v3 HTTP/1.1" 200 -
[13:46:34] main:INFO: *** Generating Partner Authentication Token ***
[13:46:34] main:INFO: {"access_token":"<redacted>","expires_in":28800,"token_type":"Bearer"}
[13:46:34] main:INFO: *** Registering Tesla account ***
[13:46:36] main:INFO: {"response":{"client_id":"<redacted>","name":"Tesla1 Home Assistant","description":"Home Assistant Integration for the Tesla Model Y","domain":"tesla1.<redacted>.website","ca":null,"created_at":"2024-04-26T13:46:36.182Z","updated_at":"2024-04-26T13:46:36.182Z","enterprise_tier":"free","account_id":"<redacted>","issuer":null,"csr":null,"csr_updated_at":null,"public_key":"<redacted>"}}
[13:46:36] werkzeug:INFO: <IP_ADDRESS> - - [26/Apr/2024 13:46:36] "GET /register-partner-account HTTP/1.1" 302 -
[13:46:36] werkzeug:INFO: <IP_ADDRESS> - - [26/Apr/2024 13:46:36] "GET /?success=1 HTTP/1.1" 200 -

As a side note does anyone know how to delete an app from their tesla developer dashboard?
I suspect its not possible?

Let me know how you got on. Can I close this Issue?

I  read through the other threads @iainbullock with no luck on their suggestions.
I decided to leave it for a while and give it a go again, I started from scratch and had the exact same outcome.
My next move is going to be to play with the fleet telemetry tools and instructions from
https://github.com/teslamotors/fleet-telemetry
Given no one else has reported this issue it seems to be isolated to myself.
Feel free to close

@ettiennegous I have the same problem... cannot fix the issue.

@tobik176 is your vehicle registered directly to you or was it bought through a company?


Process leak when unable to find exec-credential binary

What happened:
We use custom tooling (a krew installed kube plugin) for users to authenticate with kube clusters using the exec credential auth flow. Similar to that of kubelogin. We've found that if a client using the exec credential config is unable to find the binary, it'll start to spawn many kubectl processes bogging down cpu/memory. For example, this can occur due to ./krew not being in the path. This was discovered when someone using the vscode plugin Google Cloud Code  on windows noticed vscode wasn't reading the %USERPROFILE% var correctly in the PATH and only after manually adding the full .krew path to the PATH did it start to work. We have had reports that this has also occured with K9's. So while we now understand the issue, potential issue conditions, and the workaround, it seems odd that kubectl will start infinitely process spawning.
What you expected to happen:
Kubectl does not spawn new processes when it can't use the exec credentials auth and shortly returns an error.
How to reproduce it (as minimally and precisely as possible):

Have a cluster context that uses a kubectl plugin installed via krew to auth via exec credentials
Open a process monitor (activity monitor for mac, task manager for windows) to see kubectl processes running
Either move/rename the plugin or remove the .krew path from the PATH
run kubectl get po -A

Anything else we need to know?:
Environment:
Simple Testing

Kubernetes client and server versions (use kubectl version):

WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.2", GitCommit:"7f6f68fdabc4df88cfea2dcf9a19b2b830f1e647", GitTreeState:"clean", BuildDate:"2023-05-17T14:13:27Z", GoVersion:"go1.20.4", Compiler:"gc", Platform:"darwin/arm64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"25+", GitVersion:"v1.25.12-eks-2d98532", GitCommit:"0aa16cf4fac4da27b9e9e9ba570b990867f6a3d8", GitTreeState:"clean", BuildDate:"2023-07-28T16:52:04Z", GoVersion:"go1.20.6", Compiler:"gc", Platform:"linux/amd64"}
WARNING: version difference between client (1.27) and server (1.25) exceeds the supported minor version skew of +/-1

Cloud provider or hardware configuration:
aws
OS (e.g: cat /etc/os-release):
monterey
ProductName:    macOS
ProductVersion: 12.6.9
BuildVersion:   21G726

VSCode User Testing

Kubernetes client and server versions (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"23+", GitVersion:"v1.23.14-dispatcher-dirty", GitCommit:"35498c8a8d141664928467fda116cd500d09bc21", GitTreeState:"dirty", BuildDate:"2022-11-16T20:14:00Z", GoVersion:"go1.17.13", Compiler:"gc", Platform:"windows/amd64"}

Cloud provider or hardware configuration:
aws
OS (e.g: cat /etc/os-release):
windows 10

client-go executes plugin in https://github.com/kubernetes/kubernetes/blob/f638e2849fbddeb201b8290586a4747af99086bf/staging/src/k8s.io/client-go/plugin/pkg/client/auth/exec/exec.go#L436 by using the builtin function in go. I doubt that we have an option to fix this problem inside of k8s codebase.

I modified the kubeconfig to use non-existed cred exec plugin to reproduce this issue. After executing the kubectl, I saw cred exec plugin execution error. In another terminal, when I checked the processes via ps -aux, I couldn't see spawned processes.
Is it possible that some other process(for instance, vscode) causes this process spawning because there is no reason that kubectl can cause this.
/triage needs-information

/close


Instantly crashes when trying to specifically upload pictures - Alpine only

This regression is back #267 using the ghost:3.42.9-alpine
  ghost:api:shared:pipeline stages: input serialisation +20ms
  ghost:api:shared:serializers:handle input +10s
  ghost:api:shared:serializers:handle [ [Function: serializeAllShared], [Function: serializeOptionsShared] ] +0ms
  ghost:api:shared:serializers:input:all serialize all +11s
  ghost:api:shared:serializers:input:all omit internal options +0ms
  ghost:api:v3:utils:serializers:input:posts edit +11s
  ghost:api:v3:utils:serializers:input:posts add +0ms
  ghost:api:shared:pipeline stages: permissions +5ms
  ghost:api:v3:utils:permissions handle +11s
  ghost:api:v3:utils:permissions check admin permissions +0ms
  ghost:web:shared:mw:url-redirects getAdminRedirectUrl localhost:2368 /ghost/api/v3/admin/images/upload/ localhost:2368 localhost:2368 +75ms
  ghost:web:shared:mw:url-redirects no url redirect +0ms
  ghost:api:shared:pipeline stages: query +73ms
  ghost:models:plugins:filter custom (status:[draft,published,scheduled])+type:post +11s
  ghost:models:plugins:filter extra null +0ms
  ghost:models:plugins:filter enforced null +0ms
  ghost:models:plugins:filter default type:post+status:published +0ms
Segmentation fault
/var/lib/ghost #

Disabling it to imageOptimization  fix the issue.
    "imageOptimization": {
        "resize": false
    },

It may need to upgrade the libs-dev underlying as one of the threads here TryGhost/Ghost#12967

Sorry for the late reply getting to this. That specific version ghost:3.42.9-alpine isn't currently supported, but testing the latest alpine variant I'm not able to reproduce any issue (although I did test it with that version and the issue is present, uploading an image just crashes the container with exit 139)
Using the latest Alpine and Debian variants works fine with the docker-compose.yml from https://github.com/docker-library/docs/tree/master/ghost#-via-docker-stack-deploy-or-docker-compose and switching the image to the latest Alpine variant


Takes control of my game launching

I can attach more files later but gonna add this real quick as it just releaseD;
When I start a game (in this case, League, in the game loading screen) it makes the screen completely grey and you can see BD loading in the bottom-right corner, only way to fix is to reload Discord

https://i.imgur.com/X7Izjwj.png

Redownload the installer, just implemented a fix in the injection.


Device model vs Device template

First off all, thanks for this feature known as a VETER (Validate-Enrich-Transform-Enrich-Route) pattern.
The reason why I am sending this feedback is, that all documents (included also the REST APIs) are written without any respect to the device model based on the DTDL version 2.
The device model (represented by its modelId) is the common part between the IoT ends such as the device and IoT Central App (IoT Hub), but for REST APIs and in the new feature such as a Data Transformation are used an internally instance of the device template and all queries are sourced based on that.
From the device model point of the view (such as the device and app sides) we can have multiple shareable interfaces, components, etc. across multiple different device templates.
So, my question is, how the query or/and data transformation can be done in the respect of the shareable device model interfaces, components, etc. I have tried to make a very simple transformation query to export a simple property such as the modelId, but with no result.
Note, that the query for device template is used an undocumented name such as a capabilityModelId, which it is a hardcoded name for modelId (this indicates no consistencies between the device model and device template)
Thanks
Roman

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

ID: f02dd3c7-73e6-5178-b2b2-6b849a63ae3c
Version Independent ID: c82392d3-4ac6-7df6-5652-54071e48b0a7
Content: Transform data inside Azure IoT Central
Content Source: articles/iot-central/core/howto-transform-data-internally.md
Service: iot-central
GitHub Login: @dominicbetts
Microsoft Alias: dobett

Hello @romankiss Thanks for the feedback.
Our SME will review and get back on this.

Hi @romankiss - thanks for the detailed feedback. Can I make sure that I've understood the key points correctly. I'll focus on the transformation feature in data export for now, rather than the REST API. Ill also use the "Temperature Controller" multiple component sample for reference:

I believe you're asking about accessing information about the device template and its device model in the transformation queries?

The raw data that's available to the transformation looks like (some details removed for brevity):
{
  "applicationId": "450b9a64-8ea3-417d-8540-a7b2288c292b",
  "enrichments": {},
  "messageSource": "telemetry",
  "telemetry": [
    {
      "id": "dtmi:com:example:Thermostat:__temperature;1",
      "name": "temperature",
      "value": 49.51243191047629
    }
  ],
  "enqueuedTime": "2021-12-02T14:17:02.382Z",
  "messageProperties": {},
  "device": {
    "types": [],
    "templateName": "Temperature Controller",
    "properties": {
      "reported": [
        {
          "id": "dtmi:com:example:Thermostat:__maxTempSinceLastReboot;1",
          "name": "maxTempSinceLastReboot",
          "value": 86.87871839450773,
          "component": "thermostat1"
        },
        ...
      ]
    },
    "blocked": false,
    "templateId": "urn:modelDefinition:irbkwhz46hi:xypyc9osr5",
    "approved": true,
    "provisioned": true,
    "name": "Temperature controller",
    "simulated": false,
    "modules": [],
    "id": "tc-01",
    "cloudProperties": [],
    "organizations": []
  },
  "component": "thermostat1"
}

The templateId field contains the system assigned ID for the device template.
The DTML modelID dtmi:com:example:TemperatureController;2 isn't in the raw data.
The DTDL component that sent the data is identified by name in the component field.

It is possible to reference the component name and use it in a transformation. For example:
import "iotc" as iotc;
if .component then
    {
        deviceId: .device.id,
        component: .component,
        timestamp: .enqueuedTime,
        temperature: .telemetry | iotc::find(.name == "temperature").value
    }
else
    empty
end

If your model uses interface inheritance, you have no access to the interface IDs in the transformation. For example, this model:
{
    "@id": "dtmi:com:example:TemperatureController;2",
    "@type": "Interface",
    "contents": [ … ],
    "displayName": {
        "en": "Temperature Controller"
    },
    "extends": [
        "dtmi:myContosoQuickstartApp:Battery;1"
    ],
    "@context": [
        "dtmi:iotcentral:context;2",
        "dtmi:dtdl:context;2"
    ]
}

{
    "@id": "dtmi:myContosoQuickstartApp:Battery;1",
    "@type": "Interface",
    "contents": [
        {
            "@id": "dtmi:myContosoQuickstartApp:Battery:Level;1",
            "@type": "Telemetry",
            "displayName": {
                "en": "Level"
            },
            "name": "Level",
            "schema": "integer"
        }
    ],
    "displayName": {
        "en": "Interface"
    },
    "@context": [
        "dtmi:iotcentral:context;2",
        "dtmi:dtdl:context;2"
    ]
}

Generates raw data that looks like this for the level telemetry:
{
  "applicationId": "450b9a64-8ea3-417d-8540-a7b2288c292b",
  "messageSource": "telemetry",
  "messageProperties": {},
  "enrichments": {},
  "telemetry": [
    {
      "name": "level",
      "value": 80
    }
  ],
  "enqueuedTime": "2021-12-02T14:17:03.523Z",
  "device": {
    "types": [],
    "organizations": [],
    "provisioned": true,
    "modules": [],
    "id": "tc-01",
    "name": "Temperature controller",
    "templateId": "urn:modelDefinition:irbkwhz46hi:xypyc9osr5",
    "templateName": "Temperature Controller",
    "properties": {
      "reported": [  …  ]
    },
    "approved": true,
    "cloudProperties": [],
    "simulated": false,
    "blocked": false
  }
}

@Sekhar-Kutikuppala - do you have any comments to add at this point?
Thanks,
Dominic

Hi @dominicbetts, Thank you for your details. I understood, that the data transformation is depended from the input raw data and there is no problem if we have some internal data in the transformation like is a templateId, etc. (for instance: urn:modelDefinition:tadwaslrkxh:jo5kwjqgjp7, dtmi:com:example:TemperatureController:__serialNumber;2, ...)
Note, that exporting those internal data is useless because the IoT PnP ends are related to the device model described by the DTDL spec v2, which it is represented by its unique modelId property. This modelId property is well-known by IoT Central App as a common resource between the IoT PnP ends, therefore it should be as a part of the system properties available anywhere in the IoT Central App included also in the data transformation.
Currently, we have to use a REST call to obtain a modelId property based on the exported templateId.
Once again, the data transformation is a great feature and help in the integration pipeline with other services directly, for instance ingesting a telemetry data to the IoT Hub and/or IoT Central App, firing a property changes to the Event Grid, etc.
The data transformation is the great part of the VETER pattern and I hope that also the destination (R part of the VETER) will be possible to handle dynamically, for instance using an expression in the header value and url string (like we have it in the Event Grid).
Thanks
Roman

Hi @romankiss,
It sounds like you have two key requests:

The DTDL model ID is included in the raw data and available to a transformation query.
Dynamic destination handling.

If that's correct, can I suggest you add them to the feedback portal: https://feedback.azure.com/d365community/forum/35b59d83-f424-ec11-b6e6-000d3a4f0da0#  -I notice you've already used it :).
I don't think any documentation update is needed right now? If you agree, I'll go ahead and close this issue.
Regards,
Dominic

Hi @dominicbetts,
that's correct. The following example shows firing an event to the Event Grid topic with CloudEventSchema:
Data transformation is a simple query:
{
    applicationId: .applicationId,
    deviceId: .device.id,
    modelId: "??",
    modelName: .device.templateName,
    messageType: .messageSource,
    enqueuedTime: .enqueuedTime,
    messageProperties: .messageProperties,
    enrichments: .enrichments,
    component: .component
}

The Webhook destination:

Event message received by AEG subscriber:
{
  "id":"123456",
  "source":"abc",
  "specversion":"1.0",
  "type":"dataexport",
  "data":{
    "modelId":"??",
    "deviceId":"device2000",
    "applicationId":"f6b559e3-1001-4a35-8209-090562865253",
    "enrichments":{},
    "properties":[
      {
        "value":38.88,
        "module":null,
        "component":"thermostat2",
        "name":"maxTempSinceLastReboot"
      }
    ],
    "enqueuedTime":"2021-12-06T12:37:56.835Z",
    "messageType":"devicePropertyReportedChange",
    "modelName":"Temperature Controller"
  }
 }

As you can see, the webhook endpoint headers are hardcoded, so in this case such as a cloud event message it can be OK as a part of the configuration, but in the case of ingestion a modified telemetry data back to the IoT Central App, we need something like the following:
url:
https://{.hostmame}.azure-devices.net/devices/{.device.id}/messages/events?api-version=2021-04-12
headers:
dt-subject: {.component}
iothub-creation-time-utc: {.enqueuedTime}
So, I am going to write this needs as a feedback for next consideration features.
Thanks
Roman

Thanks!
#please-close

Hi @dominicbetts,
I am facing a runtime problem with an enqueuedTime property (it is a struct type) in the text like is shown in the following example:

As you can see the above screen snippet, there is no issue during the design time (the property is shown as a string type), but during the runtime there is an error:

Please, could you look at that issue.
Thanks
Roman

Hi @dominicbetts,
did you have a chance to look at the issue around the enqueuedTime property described in my previously comment ?
Thanks
Roman

Hi @romankiss - You say that your enqueuedTime property is a struct type - can you show me an example of what it looks like in your input message? Thanks!

Hi @dominicbetts, thanks for your reply. The enqueuedTime property is created by IoT Central, it's not my property.
The following screen snippet shows an input message for IoT Plug and Play mobile model, but it will be a part of every input message:

Thanks
Roman

Hi @romankiss - thanks for replying. I'm not sure what's happening here. When I try out your transformation with some sample data it works fine. Here's my transformation code that looks identical to yours:
{
    typeOfEnqueuedTime: (.enqueuedTime | type),
    msg: "XXX \(.enqueuedTime | tostring) YYY"
}

I'm sending to a webhook destination - here's the result:

@Sekhar-Kutikuppala - can you help out with this question?

@romankiss - glad to hear it's all working as expected now.


Invert merge order in common so it feels more natural

Also fixes the issue where a bundle-specific configuration defined as a string would get overwritten by same-key ones fromm baseConfig (e.g. entries).
I tapped into done hook and confirmed configuration does not change after these changes. Still, a 2nd check wouldn't hurt ;)

Thanks will give it a look tonight!

Thanks @dGilli @davilima6 !


Tool 'microsoft.cst.devskim.cli' failed to install

https://github.com/ben-manes/caffeine/actions/runs/3279477252
/usr/bin/docker build -t 8d5581:d182c176c6074ef38b83ea8b6dbb4126 -f "/home/runner/work/_actions/microsoft/DevSkim-Action/v1/Dockerfile" "/home/runner/work/_actions/microsoft/DevSkim-Action/v1"
[90](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:90)
  Sending build context to Docker daemon  15.36kB
[91](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:91)

[92](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:92)
  Step 1/6 : FROM mcr.microsoft.com/dotnet/sdk:5.0
[93](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:93)
   ---> 9fec788bd1f9
[94](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:94)
  Step 2/6 : RUN mkdir /tools
[95](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:95)
   ---> Using cache
[96](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:96)
   ---> 7e55326a1bf8
[97](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:97)
  Step 3/6 : RUN dotnet tool install --tool-path /tools Microsoft.CST.DevSkim.Cli
[98](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:98)
   ---> Running in 6a075c1ef3ad
[99](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:99)
  error NU1202: Package Microsoft.CST.DevSkim.CLI 0.6.30 is not compatible with net5.0 (.NETCoreApp,Version=v5.0) / any. Package Microsoft.CST.DevSkim.CLI 0.6.30 supports: net6.0 (.NETCoreApp,Version=v6.0) / any
[100](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:100)
  The tool package could not be restored.
[101](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:101)
  Tool 'microsoft.cst.devskim.cli' failed to install. This failure may have been caused by:
[102](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:102)

[103](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:103)
  * You are attempting to install a preview release and did not use the --version option to specify the version.
[104](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:104)
  * A package by this name was found, but it was not a .NET tool.
[105](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:105)
  * The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
[106](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:106)
  * You mistyped the name of the tool.
[107](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:107)

[108](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:108)
  For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool
[109](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:109)
  The command '/bin/sh -c dotnet tool install --tool-path /tools Microsoft.CST.DevSkim.Cli' returned a non-zero code: 1
[110](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:110)

[111](https://github.com/ben-manes/caffeine/actions/runs/3279477252/jobs/5399124373#step:2:112)
Error: Docker build failed with exit code 1

@ben-manes I think this was the release prior to it that moved support to .NET 6.
https://github.com/microsoft/DevSkim/releases/tag/v0.6.29
Either way all actions are currently failing.


Pending snapshot in nested crate is double-counted

What happened?
We have a layout like:
prql-compiler
|- Cargo.toml
|- src
|- ...
|- prqlc
   |- Cargo.toml
   |- src
   |- ...

When there's a single pending snapshot inside prqlc:

insta reports "2 pending snapshots"
On cargo insta review, if the first is accepted or rejected, we get an "File not found" error when it attempts to find the file for the second time (#380)
If we skip, the only change between the two within cargo insta review is that the crate changes from prqlc to prql-compiler

Insta Version
1.30
rustc Version
1.68

Merging & closing with #396


Fix missing caching.

The decorator was not updating the cache. This improves performance and enables persistence of the state between sessions.

What I'm curious about is: isn't the old writing style equivalent to the new writing style.
What situation led to the necessity of this modification ?
But I believe you have your point. If possible, please share it with me.

Let me go back to the code - I messed around with my own code and might have to go for a different solution.
Comparing x and y separately was a leftover and clearly the positions should be compared directly.
The whole caching thing is aimed to persist the graph layout e.g. in a json file.
What I am struggling at the moment is to find an elegant way to write the data from the json file back via the onLoad function without it being instantaneously overwritten by the compute function. ;-)
Will get back to you on the PR.


Add console logger

Purpose

Add a logger that prints messages only to the console (System.err). This is to be used by standard libraries when they need to log some messages to the console. Logger uses the DefaultLogFormatter() log format.

Fixes #17884
Approach

To use this feature, get the logger with the name "b7a.log.console"

import static org.ballerinalang.logging.util.Constants.CONSOLE_LOGGER;

private static final Logger log = LoggerFactory.getLogger(CONSOLE_LOGGER);

The log level can be configured using the config b7a.log.console.loglevel. Ballerina user log level b7a.log.level is used by default as the log level.
Samples

Provide high-level details about the samples related to this feature.

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[ ] Read the Contributing Guide
[ ] Required Balo version update
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

This PR is to address your requirement of logging only to the console. We have provided that functionality using a new logger. Why can't you use that for logging to the console?

The requirement as I have mentioned in the previous comment is that whenever a new logger is created by using say the following semantic by us or by any third party library it should go to the console:
private static final Logger log = LoggerFactory.getLogger(CLASS_NAME);
And that it should be configurable so that user does not normally see this logs unless he wants to as these logs are used for debugging purposes by the ballerina language developers.
There has to be another logger like the one you created (say INTERNAL_LOG_LOGGER) that would be used by the lang side code to log crash logs. This need not be configurabal. It shouldn't be used in stdlib code unless required.
Please refer this mail on the discussion on this topic.
Also we had an offline chat with @Kishanthan and he agreed with this change request.


Its updates a lot

Dear sir, please do update the loader.js file according to the the latest version of noje .js and  npm. I just the love concepts of whole terminal based operating system inside the web-browser.
The last commiting was been done 2yr a go....please  update these repository ...its really very good

Thanks @progxy75, can you please check if my latest PR filled your needs?
https://github.com/NicolaLC/nica-os/pull/45
everything is on master branch


[1.2] Set bmc ip only when ip source is static when flashing quanta bmc

Fix ODR 771 in flashing quanta BMC scripts, about error to set BMC IP after flashing Quanta BMC, if ip source is DHCP.
It happened in MN lab, where BMC IP source is DHCP. Though the "sudo ipmitool lan set 1 ipaddr xxx" after flashing returns the same message as in static IP source, the exit code is 1 rather than 0. Modify the script to skip these network setting steps if the source is DHCP.
Add retry count after mc reset so that total wait time (maximum) is 90s, the same as suggested by vendor after flashing BMC. The original value is 60s, which is not sufficient for stack 13 node 1 at a certain ratio.
@uppalk1 @zyoung51

:+1:

:+1:

:+1:

if some PR message is also added to codes annotation, it's more readable in future's codes maintaince

@anhou add comments.

Thanks @iceiilin


Fix local state updates for GraphQL Query Variables

Closes #7204

 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.

 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.


Preview text on new lines

When a post has new lines, but no spaces after the new line, the preview text runs together such that
Hey
How
Are You?

becomes "HeyHowAre You?", an easier to read format would be "Hey How Are You?"

This is an API problem, stonedonkey botches the preview text :(
But it would be super cool if we didn't need that field anymore.  We should be able to generate it ourselves from the real text, I think.


[research] Consider moving CRDs to beta, and making beta "hub" versions

In an effort move to 1.0, we should consider moving our CRDs to beta to imply stability. Things we should consider:

releasing beta CRD versions (all CRDs)
making the beta version the conversion "hub" so those objects are referenced in most functional code
making sure documentation is clear
deprecating all other CRDs
removing deprecated APIs

FYI @odubajDT, this sounds like something you might be interested in.

I would love to do this, but I guess the team needs to decide on the specs of the resources for beta

I would love to do this, but I guess the team needs to decide on the specs of the resources for beta

Yes, it's not a "right now" issue. I just wanted to you to aware of it. I think once we complete (or get closer to completing) the flagd-kube-proxy, we will have a better candidate for the beta CRD.

Great, @toddbaert would it be possible to organize a team meeting to align on the specification of the CRDs ? Therefore I can start with this ticket and create a PoC

My take on this is to wait till we finalize kube-proxy related implementations. We will see more changes with proxy deployment and in my view, it's best to push those changes to alpha version.
Once we have the proxy changes and stability on the solution, we can draft the beta version of the API.
Timeline wise, this is 1 ~ 2 sprints of waiting

Consider addressing https://github.com/open-feature/open-feature-operator/issues/433 along with this change

Thanks all for the effort 🙌  I have some questions about the points listed by @odubajDT

v1beta1 (and therefore OFO 1.x)

why a stable release with a beta API version? I would vote for having stable APIs for OFO 1.x

clean up leftover logic in v1alpha* API, but keep the CRD definitions

what type of clean up do you envision? 🤔 I would expect to drop any code line that deals with these CRDs

Thanks all for the effort 🙌 I have some questions about the points listed by @odubajDT

v1beta1 (and therefore OFO 1.x)

why a stable release with a beta API version? I would vote for having stable APIs for OFO 1.x

True, but we actually cannot skip beta API version, maybe worth waiting for some time before releasing OFO 1.x with a stable API? @toddbaert

clean up leftover logic in v1alpha* API, but keep the CRD definitions

what type of clean up do you envision? 🤔 I would expect to drop any code line that deals with these CRDs

With this I meant removing the struct functions, for example here https://github.com/open-feature/open-feature-operator/blob/main/apis/core/v1alpha1/featureflagconfiguration_types.go#L111. There is no reason to keep these functions, as they won't be used anywhere. Also we can remove the conversion webhooks between alpha versions. According to k8s standards, the structs defining the CRDs should stay in the repo, but everything around it can be removed

@odubajDT thank you for the summary
I also like to discuss our CRD naming. Right now, our naming of two CRDs is a little confusing FlagSourceConfiguration  vs FeatureFlagConfiguration. At least I time to time I mix the naming as they are too similar. Given we are going for a breaking change, shall we consider our options on renaming the CRDs ?

Flagd feature flag configuration CRD : FeatureFlags
Feature flag source configuration CRD : SourceConfigurations

@odubajDT thank you for the summary
I also like to discuss our CRD naming. Right now, our naming of two CRDs is a little confusing FlagSourceConfiguration vs FeatureFlagConfiguration. At least I time to time I mix the naming as they are too similar. Given we are going for a breaking change, shall we consider our options on renaming the CRDs ?
* Flagd feature flag configuration CRD : `FeatureFlags`

* Feature flag source configuration CRD : `SourceConfigurations`

Fine by me :+1: But we should keep it singular, as according to k8s standards, CRD should be named as singular and k8s explicitly adds a plural value [1]. So I would suggest FeatureFlag and SourceConfiguration.
[1] https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#create-a-customresourcedefinition

One more note/question about the API of v1alpha2.FetaureFlagConfiguration. In the definition we can see that the variants field (along with some others) is of type json.RawMessage [1]. Was there a reason why this parameters is basically a []byte ? For the users it's completely unredable. Let's look at the same CR in v1alpha1 and v1alpha2:
apiVersion: core.openfeature.dev/v1alpha2
kind: FeatureFlagConfiguration
metadata:
  name: end-to-end-test
spec:
  featureFlagSpec:
    flags:
      "simple-flag":
        state: "ENABLED"
        variants: [123 10 32 32 32 32 32 32 32 32 32 32 32 32 34 111 110 34 58 32 116 114 117 101 44 10 32 32 32 32 32 32 32 32 32 32 32 32 34 111 102 102 34 58 32 102 97 108 115 101 10 32 32 32 32 32 32 32 32 32 32 125]
        defaultVariant: "on"

apiVersion: core.openfeature.dev/v1alpha1
kind: FeatureFlagConfiguration
metadata:
  name: end-to-end-test
spec:
  featureFlagSpec: |
    {
      "flags": {
        "simple-flag": {
          "state": "ENABLED",
          "variants": {
            "on": true,
            "off": false
          },
          "defaultVariant": "on"
        }
      }
    }

In v1alpha1 the variants are readable, but in v1alpha2 it's very user unfriendly in my opinion. I would suggest to use type string for this parameter or a struct which we all can agree on.
 See the spec here: https://github.com/open-feature/spec/blob/main/specification/types.md#structure

a PoC of a working solution is available here:
https://github.com/open-feature/open-feature-operator/pull/527
Please note that some of the E2E tests are failing due to the usage of flagD, which is not yet adapted to use v1beta1 (kubernetes/flagd-proxy providers)

@odubajDT thank you for the summary
I also like to discuss our CRD naming. Right now, our naming of two CRDs is a little confusing FlagSourceConfiguration vs FeatureFlagConfiguration. At least I time to time I mix the naming as they are too similar. Given we are going for a breaking change, shall we consider our options on renaming the CRDs ?
* Flagd feature flag configuration CRD : `FeatureFlags`

* Feature flag source configuration CRD : `SourceConfigurations`

Fine by me 👍 But we should keep the names singular, as according to k8s standards, CRD should be named as singular and k8s explicitly adds a plural value [1]. So I would suggest FeatureFlag and SourceConfiguration. Or also SidecarConfiguration might work on my side.
[1] https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#create-a-customresourcedefinition

I still find SourceConfiguration name a bit redundant 🤔 in the end the CR itself is a configuration,  what I want to define as a user is a FeatureFlag and a Source so I would call them like that 😄

@odubajDT thank you for the summary
I also like to discuss our CRD naming. Right now, our naming of two CRDs is a little confusing FlagSourceConfiguration vs FeatureFlagConfiguration. At least I time to time I mix the naming as they are too similar. Given we are going for a breaking change, shall we consider our options on renaming the CRDs ?
* Flagd feature flag configuration CRD : `FeatureFlags`

* Feature flag source configuration CRD : `SourceConfigurations`

Fine by me 👍 But we should keep the names singular, as according to k8s standards, CRD should be named as singular and k8s explicitly adds a plural value [1]. So I would suggest FeatureFlag and SourceConfiguration. Or also SidecarConfiguration might work on my side.
[1] https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#create-a-customresourcedefinition

I still find SourceConfiguration name a bit redundant 🤔 in the end the CR itself is a configuration, what I want to define as a user is a FeatureFlag and a Source so I would call them like that 😄

Source sounds too general for me, I would be more for SourceConfiguration or SidecarConfiguration

I agree more with Anna on the naming. Maybe something like FeatureFlag and FeatureFlagSource could also work?

I agree more with Anna on the naming. Maybe something like FeatureFlag and FeatureFlagSource could also work?

The main issue is sharing the same prefix FeatureFlag. I think this is one reason the existing naming is misleading 😞
@odubajDT  I like the SourceConfiguration as this name clearly highlight the purpose of the crd - configurations of the side car
So the current candidates,

Feature flag string -  FeatureFlag,
Sidecar/sources configurations - SourceConfiguration, SidecarConfiguration, FeatureFlagSource , Source

Let's create a pool, the name for the FeatureFlag is quite clear, let's vote for the configurations CRD:

:1st_place_medal: - SourceConfiguration
:+1: - SidecarConfiguration
:100: - FeatureFlagSource
:1234: - Source

Please vote by marking this comment with the emoji, which represents your favorite name

I'd like to bring a bit more context on how it would feel to use each version to support the voting:
SourceConfiguration
kubectl get sourceconfiguration -A
apiVersion: core.openfeature.dev/v1beta1
kind: SourceConfiguration
metadata:
  name: end-to-end-test
spec:
  featureFlagSpec: |

SidecarConfiguration
kubectl get sidecarconfiguration -A
apiVersion: core.openfeature.dev/v1beta1
kind: SidecarConfiguration
metadata:
  name: end-to-end-test
spec:
  featureFlagSpec: |

FeatureFlagSource
kubectl get featureflagsource -A
apiVersion: core.openfeature.dev/v1beta1
kind: FeatureFlagSource
metadata:
  name: end-to-end-test
spec:
  featureFlagSpec: |

Source
kubectl get source -A
apiVersion: core.openfeature.dev/v1beta1
kind: Source
metadata:
  name: end-to-end-test
spec:
  featureFlagSpec: |

I guess we have a winner, it will be FeatureFlagSource. I will adapt the PR https://github.com/open-feature/open-feature-operator/pull/535

Fine by me 👍 But we should keep the names singular, as according to k8s standards, CRD should be named as singular and k8s explicitly adds a plural value [1]. So I would suggest FeatureFlag and SourceConfiguration. Or also SidecarConfiguration might work on my side.

I agree with this after learning the background.

The research as well as the implementation is done, closing this issue


SSE2 compatibility should be warranted

See the actual discussion here https://github.com/lemire/simdcomp/commit/1a6ea48fb9ba53888470e891b321164ab61ecb39, but in short - while various SSE versions have useful features, SSE2 is the standard set. The suggestion is to retain the compatibility with SSE2 even while some features from the upper SSE versions are used.
This is done by the following steps

retaining the emulation layer for the features that aren't available with SSE2
provide a legacy option to the makefiles, so then a fully SSE2 compatible version of the library can be compiled. This shouldn't involve any run time feature replacement (by usage of cpuid, etc).

This emulation of smmintrin.h (adapted from SSEPlus) suffices to compile. I wanted to see what Emscripten would make of this, but the generated javascript floods the CPU...
smmintrin.h.txt
Good luck with the project.

Correction: the first two tests work, the simple_demo() hangs.

Hi,
i've started to work on this having half a free day. But it is somehow strange :) I had to find out that i have no single machine not supporting sse4.1. Nevertheless, i made this small patch locally in the makefile:
diff --git a/makefile b/makefile
index 0e1c8de..228e737 100644
--- a/makefile
+++ b/makefile
@@ -2,10 +2,17 @@
 .SUFFIXES:
 #
 .SUFFIXES: .cpp .o .c .h
+
+ifeq ($(SSE),2)
+SSE_ARG=-msse2
+else
+SSE_ARG=-msse4.1
+endif
+
 ifeq ($(DEBUG),1)
-CFLAGS = -fPIC  -std=c89 -ggdb -msse4.1 -march=native -Wall -Wextra -pedantic
+CFLAGS = -fPIC  -std=c89 -ggdb $(SSE_ARG) -march=native -Wall -Wextra -pedantic
 else
-CFLAGS = -fPIC -std=c89 -O3 -msse4.1  -march=native -Wall -Wextra -pedantic
+CFLAGS = -fPIC -std=c89 -O3 $(SSE_ARG) -march=native -Wall -Wextra -pedantic
 endif # debug
 LDFLAGS = -shared
 LIBNAME=libsimdcomp.so.0.0.3

And then i compile like make SSE=2.  Surprisingly, everything compiles fine and unit tests pass through. It is strange - firstly, it should not even compile, should it? Or, it could be good, that gcc already emulates something. Or gcc ignores this option as the VM supports SSE4_1. I have no chance to move the binaries and test on a machine without SSE4_1 as i don't have such HW. Can someone explain this?
Thanks.

@wshager thanks for the interest. Could you please be more verbose about how you compile and test it, and what HW was used?
Thanks.

@weltling I used Emscripten to compile, and since it only supports SIMD intrinsics up to SSE2, newer headers simply won't be found in the Emscripten lib. The HW doesn't seem relevant in this case. The current lack of SIMD support in javascript kinda puts this project on hold for me, since I'm looking for a solution in the browser.

@weltling
SSE 4.1 was introduced ~ 2007. I am not sure if anyone makes x64 CPUs today without SSE 4.1.
Anyone knows?

Checked in a version of the code that should compile fine given the proper compiler settings.
@wshager  Hopefully, the code should be compilable by Emscripten if there is SIMD support.

@lemire, yeah, i was linking this  ttp://store.steampowered.com/hwsurvey in another thread which tells that sse4.1 is still used by round 83% in the gaming, which should be the indicator.
I was planning long to go for the emulation layer, just it was quite busy times on my side inbetween. But now when i've came to it, the strange thing was that gcc -msse2 was compiling just fine the existing code even before your patch. So maybe gcc already inserts some emulation, or ignores the option. That's why I was wondering :) BTW Visual Studio seems to not to have options to enforce some specific SSE version compatibility, seems the runtime will do the job. But by the plan I had was to implement a compatibility layer explicitly.
Thanks.

The goal of my fix is to allow @wshager  to go forward with his plan to compile this library with Emscripten. I'd be very interested in hearing about the results...

yeah, i was linking this http://store.steampowered.com/hwsurvey in another thread which tells that sse4.1 is still used by round 83% in the gaming, which should be the indicator.

It is an interesting reference.

the strange thing was that gcc -msse2 was compiling just fine the existing code even before your patch. So maybe gcc already inserts some emulation, or ignores the option.

I do not think that -msse2 precludes SSE 4.1. If you want to forbid the compiler to use SSE 4.1, you have to use a negative flag like -mno-sse4.1.
You can certainly emulate SSE 4.1 functions, but you will get awful performance. It is probably not worth it. Better not use SIMD instructions in the first place if you have to support obsolete hardware.

@lemire great, -msse2 -mno-sse4.1 worked as expected. Looks like gcc expects the least version with -m, instead of a most one. Was my wrong interpretation. With these options now it properly fails to compile.
I got it exactly the way you told. With your fix it satisfies SSE2. But effectively it excludes several functionality. I was more talking about keeping the APIs, but having necessary parts emulated. Regarding performance - clear, SSE 2 were worse than 4.1. But I were more about compatibility. It's just down to whether to retain APIs compatible vs. moving forward with features.
Another point is also, that SIMD in any form will certainly provide a better performance compared to plain C/C++. More practical applicability vs. speed within SSE versions, as round 1/5 of cases sounds still significant to me. OFC i don't insist on this, just it was what we discussed earlier, why i opened this issue back then. I'm likely to call it a day then, mostly for the time reasons for my part.
Thanks.

SIMD in any form will certainly provide a better performance compared to plain C/C++.

Some non-SSE2 SIMD instructions we  use (e.g., pshufb) cannot be emulated using SSE2 instructions. So you need to write the SIMD register to memory, reload it into regular registers, do the computation, then reload a SIMD register. That's going to be atrociously slow in some cases.
Even when the SIMD instruction can be emulated with SSE2 instructions (e.g., pmaxud), it may involve more operations than a non-SIMD algorithm would use. On the whole, you may end up with a significantly worse latency and throughput.

@lemire thanks! The example now compiles to Emscripten. Steps to reproduce:
emcc -O2 src/simdbitpacking.c -o simdbitpacking.bc -msse2 -Iinclude
emcc -O2 src/simdcomputil.c -o simdcomputil.bc -msse2 -Iinclude
emcc -O2 src/simdintegratedbitpacking.c -o simdintegratedbitpacking.bc -msse2 -Iinclude
emcc -O2 example.c -o example.bc -msse2 -Iinclude
emcc -O2 example.bc simdbitpacking.bc simdintegratedbitpacking.bc simdcomputil.bc -o project.html -s ALLOW_MEMORY_GROWTH=1
I'll puzzle some more on dynamic calls from JS later, and report my experiences in #13. Moving forward, I expect Emscripten to support SSE4.1 in short term.
https://github.com/kripken/emscripten/issues/4030

This looks like a very interesting use case of SIMD.js! I'd be very curious to see comparison graphs of native scalar vs native SIMD vs JS scalar vs JS SIMD performance to get a reality check of the suitability of the upcoming SIMD.js specification on your SIMD use case. If you generate such benchmark results at some point, please ping me in for the numbers!

@juj I'd be happy to.

@wshager
Which version of emscripten do you use? The fact that there is no -msse2 flag on my version does not make me hopeful.
$ emcc --version
emcc (Emscripten GCC-like replacement) 1.10.0 ()
Copyright (C) 2013 the Emscripten authors (see AUTHORS.txt)
This is free and open source software under the MIT license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ emcc -O2 src/simdbitpacking.c -o simdbitpacking.bc -msse2 -Iinclude
clang: warning: argument unused during compilation: '-msse2'
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:6:1: error: redefinition of '_mm_set_ps'
_mm_set_ps(float z, float y, float x, float w)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:6:1: note: previous definition is here
_mm_set_ps(float z, float y, float x, float w)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:12:1: error: redefinition of '_mm_set1_ps'
_mm_set1_ps(float w)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:12:1: note: previous definition is here
_mm_set1_ps(float w)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:18:1: error: redefinition of '_mm_setzero_ps'
_mm_setzero_ps(void)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:18:1: note: previous definition is here
_mm_setzero_ps(void)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:24:1: error: redefinition of '_mm_store_ps'
_mm_store_ps(float *p, __m128 a)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:24:1: note: previous definition is here
_mm_store_ps(float *p, __m128 a)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:30:1: error: redefinition of '_mm_movemask_ps'
_mm_movemask_ps(__m128 a)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:30:1: note: previous definition is here
_mm_movemask_ps(__m128 a)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:36:1: error: redefinition of '_mm_add_ps'
_mm_add_ps(__m128 a, __m128 b)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:36:1: note: previous definition is here
_mm_add_ps(__m128 a, __m128 b)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:42:1: error: redefinition of '_mm_sub_ps'
_mm_sub_ps(__m128 a, __m128 b)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:42:1: note: previous definition is here
_mm_sub_ps(__m128 a, __m128 b)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:48:1: error: redefinition of '_mm_mul_ps'
_mm_mul_ps(__m128 a, __m128 b)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:48:1: note: previous definition is here
_mm_mul_ps(__m128 a, __m128 b)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:54:1: error: redefinition of '_mm_div_ps'
_mm_div_ps(__m128 a, __m128 b)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:54:1: note: previous definition is here
_mm_div_ps(__m128 a, __m128 b)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:60:1: error: redefinition of '_mm_min_ps'
_mm_min_ps(__m128 a, __m128 b)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:60:1: note: previous definition is here
_mm_min_ps(__m128 a, __m128 b)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:66:1: error: redefinition of '_mm_max_ps'
_mm_max_ps(__m128 a, __m128 b)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:66:1: note: previous definition is here
_mm_max_ps(__m128 a, __m128 b)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:72:1: error: redefinition of '_mm_sqrt_ps'
_mm_sqrt_ps(__m128 a)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:72:1: note: previous definition is here
_mm_sqrt_ps(__m128 a)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:80:1: error: redefinition of '_mm_cmplt_ps'
_mm_cmplt_ps(__m128 a, __m128 b)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:80:1: note: previous definition is here
_mm_cmplt_ps(__m128 a, __m128 b)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:86:1: error: redefinition of '_mm_cmple_ps'
_mm_cmple_ps(__m128 a, __m128 b)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:86:1: note: previous definition is here
_mm_cmple_ps(__m128 a, __m128 b)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:92:1: error: redefinition of '_mm_cmpeq_ps'
_mm_cmpeq_ps(__m128 a, __m128 b)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:92:1: note: previous definition is here
_mm_cmpeq_ps(__m128 a, __m128 b)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:98:1: error: redefinition of '_mm_cmpge_ps'
_mm_cmpge_ps(__m128 a, __m128 b)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:98:1: note: previous definition is here
_mm_cmpge_ps(__m128 a, __m128 b)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:104:1: error: redefinition of '_mm_cmpgt_ps'
_mm_cmpgt_ps(__m128 a, __m128 b)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:104:1: note: previous definition is here
_mm_cmpgt_ps(__m128 a, __m128 b)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:110:1: error: redefinition of '_mm_and_ps'
_mm_and_ps(__m128 a, __m128 b)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:110:1: note: previous definition is here
_mm_and_ps(__m128 a, __m128 b)
^
In file included from src/simdbitpacking.c:4:
In file included from include/simdbitpacking.h:14:
In file included from include/simdcomputil.h:11:
In file included from /usr/share/emscripten/system/include/emscripten/emmintrin.h:1:
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:116:1: error: redefinition of '_mm_andnot_ps'
_mm_andnot_ps(__m128 a, __m128 b)
^
/usr/share/emscripten/system/include/emscripten/xmmintrin.h:116:1: note: previous definition is here
_mm_andnot_ps(__m128 a, __m128 b)
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
ERROR    root: compiler frontend failed to generate LLVM bitcode, halting

@lemire I use  1.35.0. Choose 'emsdk_portable install latest' / 'emsdk_portable activate latest'.

@wshager  Makes sense. Thanks.

@wshager  Right. It builds.
$ emcc --version
emcc (Emscripten gcc/clang-like replacement) 1.35.0 (commit 42fb486c53d627b203b77af6e5d0c088c0ad03ad)
Copyright (C) 2014 the Emscripten authors (see AUTHORS.txt)
This is free and open source software under the MIT license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ emcc -O2 src/simdbitpacking.c -o simdbitpacking.bc -msse2 -Iinclude
INFO:root:(Emscripten: Running sanity checks)
$ emcc -O2 src/simdcomputil.c -o simdcomputil.bc -msse2 -Iinclude
$ emcc -O2 src/simdintegratedbitpacking.c -o simdintegratedbitpacking.bc -msse2 -Iinclude
$ emcc -O2 example.c -o example.bc -msse2 -Iinclude
$ emcc -O2 example.bc simdbitpacking.bc simdintegratedbitpacking.bc simdcomputil.bc -o project.html -s ALLOW_MEMORY_GROWTH=1
WARNING:root:generating system library: libc.bc...

WARNING:root:                                     ok
WARNING:root:generating system library: dlmalloc.bc...
WARNING:root:                                         ok

@lemire you can add -s EXPORTED_FUNCTIONS="['_main', '_compress_decompress_demo','_varying_bit_width_demo','_simple_demo']" to export functions separately.

Thanks.
I am just checking things out in case others want to try it out (so that it is documented).

@lemire great. I'm going to try to rewrite some functions using SIMD.js. I'll report that too.


CUDA out of memory despite having a lot of free GPU memory

torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 1.37 GiB. GPU .
The GPU memory is totally free and i still get this error each run?!

What is the resolution of your images? And how about the total GPU memory of your device?

Test Image Resolution:  612x408
My GPU memory: 6144MiB

A little bit odd (⊙_⊙). I tried an image with a resolution of 685x609, but it only required 2947MiB of memory.
Have you enabled half precision?

I got the same error even with the infer.sh script on the example images with half precision enabled by default inside infer.sh.

I tested Lotus on google colab [T4 gpu] and ran the infer.sh script and got the same error.

Thanks for pointing out the problem, let me check the code.

Hi, you can add torch.cuda.empty_cache() after each inference. Please refer to this line.

Thank you for your prompt response. I'll try the fix and let you know the update.
Thank once again for your great work.

Issue closed, please re-open it upon any problems :hugs:


Hello Hacktoberfest in React

@Kinshu-Learner  Also do checkout the other repo of ToDoApp and give both stars if you like the repo.


Next.js and Payload API route error: Response body object should not be disturbed or locked

Link to reproduction
https://github.com/infonomic/payload-custom-server
Describe the Bug
In both the Payload custom server example, and the current website template and when using Next.js App router, if there is an 'api' route handler in Next.js - for example...
.
├── layout.tsx
├── api
│   └── set-theme
│       └── route.ts
└── page.tsx

.. and the route handler is a POST, PUT, PATCH request with a body payload, then Next.js will throw the following error:
TypeError: Response body object should not be disturbed or locked
    at extractBody (node:internal/deps/undici/undici:4323:17)
    at new _Request (node:internal/deps/undici/undici:5272:48)
    at new NextRequest (/payload-custom-server/node_modules/.pnpm/next@14.0.4_react-dom@18.2.0_react@18.2.0/node_modules/next/src/server/web/spec-extension/request.ts:24:10)
    at Function.fromNodeNextRequest (/payload-custom-server/node_modules/.pnpm/next@14.0.4_react-dom@18.2.0_react@18.2.0/node_modules/next/src/server/web/spec-extension/adapters/next-request.ts:98:12)

The error is being caused because of the shared /api route prefix between Payload and Next.js.
With Payload routes / init registered first, Payload middleware is being applied before the route is rejected, and passed on to Next.js - which then errors as above because the body stream has already been read by Payload (which is what undici is complaining about).
The current 'fix' or workaround, is to either rename the /api path prefix in Payload via payload.config.ts  and the routes option, for example...
routes: {
  admin: '/admin',
  api: '/papi',
},

Or to rename the api folder (which is there by convention) inside the Next.js App router app folder - for example from api to napi
.
├── layout.tsx
├── napi
│   └── set-theme
│       └── route.ts
└── page.tsx

To Reproduce
The repo above includes two buttons with onClick handlers on a /test-page route that will call test POST and test GET route handlers in Next.js.
Remove the 'fix' from payload.config.ts - i.e. rename the Payload api path prefix back to /api and then run the project pnpm install pnpm dev
When you visit /test-page - and click on the 'Test POST API Call'  button you'll see the error.
Payload Version
2
Adapters and Plugins
No response

@58bits I added it to my todo to look into updating the readme in that repo

@paulpopus why was this issue closed? I agree with @58bits here:

This might not possible - but the 'nice' thing to do would be for Payload / Express to reject the route as a 'miss' instead of processing the request via middleware before letting 'other' handlers take over - like Next.js.

Is this possible? This would be the best solution imo. For the record, our move to Next.js will completely solve this, but it might be wise for us to do one of the following things in the meantime:

Look into this above solution
Rename our Next.js API route handlers as suggested and add documentation to the README (I don't love this solution, because it means there's a "gotcha" to look out for)
Do nothing and wait for 3.0, using this issue for others to find so they can wire in their own workaround

At the very least we need to update the README, but since that has not been done yet I am going to re-open this issue.

Hey @58bits sorry I didn't mean to close this issue on you entirely without a resolution.
We discussed this internally and we agreed on making changes to documentation (inside Readme and each Nextjs API route) as well as default configuration of the templates https://github.com/payloadcms/payload/pull/4725
This issue will be more elegantly fixed in 3.0


[Toggle] adding label

Adding label to toggle like checkbox, that when you click on the label toggle excecute

The new FormGroup component updated in #487 should handle this already. It is however not released yet but you can try it on the Edge version: https://ui.nuxtlabs.com/dev/getting-started/installation#edge


dashboard: being able to like datasets in data library

right now you can sort datasets by like in data-library of your dashboard, as we are removing this feature from public data-library we should consolidate behaviour in both places
thus, the request will be to implement the liking in the data-library of the dashboard, then in the public data-library

Wouldn't implement this for the time being


Teams web site tab with SharePoint site page doesn't load returning SDK initialization timed out error

Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Developer environment
Windows
What browser(s) / client(s) have you tested

[ ] 💥 Internet Explorer
[X] 💥 Microsoft Edge
[ ] 💥 Google Chrome
[ ] 💥 FireFox
[ ] 💥 Safari
[ ] mobile (iOS/iPadOS)
[ ] mobile (Android)
[ ] not applicable
[X] other (enter in the "Additional environment details" area below)

Additional environment details

Teams App team tab

Describe the bug / error
We have for several years been using web site tabs in Teams to display SharePoint site pages with SPFx webparts/extensions but a few weeks ago this stopped working. All that is displayed when we go to one of those tabs now is the SharePoint logo and nothing else happens.
The reason that we need to use web site tabs instead of SharePoint tabs is that it is that Graph only supports creating web site tabs with configuration, SharePoint tabs is only supported to be created without configuration. Since we do alot of provisioning of the tabs this is a no-go for us.
SharePoint library pages with SPFx extensions can still be displayed using web site tabs, it only seem like site pages has the issue.
This happens in both Teams in the browser and in the Teams app.
We see this issue in multiple tenants.
We have also tried raising this issue with MS Support through the contact support panel in the admin console but they just said that we should use SharePoint tabs and doesn't seem to understand the real issue since it is more of a developer related one.
The following error is logged in the browser console when loading the tab:
Uncaught (in promise) Error: SDK initialization timed out.
at e.exports.e.initialize (sp-teams-lib_en-us_aadf626ba98cc1a8678b.js:1:188078)
at e._initialize (sp-teams-lib_en-us_aadf626ba98cc1a8678b.js:1:108609)
at new e (sp-teams-lib_en-us_aadf626ba98cc1a8678b.js:1:108838)
at e.getInstance (sp-teams-lib_en-us_aadf626ba98cc1a8678b.js:1:108923)
at e.getTeamsV2SDKInitializer (sp-teams-lib_en-us_aadf626ba98cc1a8678b.js:1:114935)
at e._getTeamsSDKInitializer (sp-teams-lib_en-us_aadf626ba98cc1a8678b.js:1:115131)
at sp-teams-lib_en-us_aadf626ba98cc1a8678b.js:1:122611
at new Promise ()
at e._setTeamsAppEntityIdLocalStorage (sp-teams-lib_en-us_aadf626ba98cc1a8678b.js:1:122579)
at e.onBeforePageLoad (sp-teams-lib_en-us_aadf626ba98cc1a8678b.js:1:112723)
Steps to reproduce
1.Create a SharePoint site page with som webparts on it
2.Create a Team and in the General channel create a new tab of type web site
3.Set the url of the web site tab to the url of the page created in 1
4.When going to this tab it will only display the SharePoint logo
Expected behavior
The SharePoint site page should be displayed correctly.

@patrikhellgren - unfortunately, I will tell you the same as MS Support.
Website app is not intended to load SP pages. It should be used for non opinionated websites.
We don't support such a scenario. It could work in some scenarios and don't work in others. It may also stop working in future.
From other side, the case with MS Graph is valid and I have started an internal conversation to allow static configuration for SharePoint App.
No promises here though.


Show project for currently running task

Describe the new feature

In a previous version of the Toggl Button, the project for the currently running task was visible when you clicked on the Toggl Button. Now only the task description is shown. I would like to see the project name when I click on the Toggl Button.
How does this help you?

I have some projects that don't have tasks associated with them: I just go to Project "Email" or project "Meals". With the current version, I only see "(no description)" when one of these logs is running.
If we couldn't add this feature, is there a compromise you can think of?

No, sorry

Thanks for pointing this out. We'll make it happen 👍


[Google Chrome Profiles] ...

Extension
https://www.raycast.com/frouo/google-chrome-profiles
Description
It would be great to just be able to switch to that profile, opening the existing window and active tab without forcing either an about:blank or a Google Search to open.
Who will benefit from this feature?
Everyone.
Anything else?
No response

Also would be good to be able to search open tabs (like shift + command + A) for that profile, then open to the selected open tab.

Hello, thank you for your feature request. Unfortunately this not possible, or at least I did not find the way to achieve that..
Maybe there is a way by using a more complex Apple Script which would check active windows (?) but I haven't had the time to dig more.
Feel free to contribute, I would really love that feature too! :)

Not very a very helpful contribution from me but UPVOTE!! Absolutely love the extension, thanks!

Don't know if this is helpful but this extension appears to be getting closer: https://www.raycast.com/Codely/google-chrome


[Problem] Unexpected Character (with small images)

Dear @reinink and community,
thank you very much for this awesome plugin. Today, I implemented Glide in my application in order to allow Clients to request the images according to their needs based on request params as explained here: http://glide.thephpleague.com/1.0/config/integrations/laravel/ (Note that I am using Laravel).
I have installed glide using composer require league/glide-laravel, which then installed the latest version of glide ( v 1.2.2)
In my controller i run the following code:

public function deliverMedia(Request $request)
{
   $glide = ServerFactory::create([
      'cache' => Storage::disk('media')->getDriver(),
      'cache_path_prefix' => 'cache',
      'source' => Storage::disk('media')->getDriver(),
      'response' => new LaravelResponseFactory(),
   ]);

   $params = $request->query();

   $path = $request->imagepath;

   return $glide->getImageResponse($path, $params);
}

Then i call it via
GET /media/uploads/path/to/my/image.jpg

and this returns the image correctly..
If I am calling
GET /media/uploads/path/to/my/image.jpg?w=200

this still works, and a smaller version of the image is returned.. This even works with additional params, like filt=sepia or whatever.
However, there seems to be some kind of "lower bound" for the w parameter. If i call the same image like this:
GET /media/uploads/path/to/my/image.jpg?w=100

this returns
Unexpected '�'

ï¿½ï¿½ï¿½ï¿½JFIFï¿½ï¿½;CREATOR: gd-jpeg v1.0 (using IJG JPEG v90), quality = 80
ï¿½ï¿½C  %# , #&')*)
-0-(0%()(ï¿½ï¿½C   (((((((((((((((((((((((((((((((((((((((((((((((((((ï¿½ï¿½ "
ï¿½ï¿½	ï¿½ï¿½ï¿½}
!1AQa"q2ï¿½ï¿½ï¿½#Bï¿½ï¿½Rï¿½ï¿½$3brï¿½
%&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyzï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½
ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿
½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿
½ï¿½ï¿½ ï¿½ï¿½ï¿½w
!1AQaq"2ï¿½Bï¿½ï¿½ï¿½ï¿½	#3Rï¿½brï¿½ $4ï¿½%ï¿½
&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyzï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿
½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿
½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿
½ï¿½?ï¿½ï¿½oï¿½YkPï¿½ï¿½ï¿½ï¿½bï¿½ï¿½tï¿½Ûªï¿½ï¿½ï¿½ï¿½#Üï¿½
ï¿½Zï¿½oï¿½ï¿½ï¿½ï¿½ï¿½`ï¿½ï¿½ï¿½wï¿½ï¿½cï¿½ï¿½ï¿½@l|ï¿½ï¿½ï¿½%ï¿½`ï¿½ï¿½qï¿½3
V1<ï¿½ï¿½^ï¿½ï¿½ï¿½*ï¿½q0Ppsï¿½\ï¿½&ï¿½8ï¿½Rï¿½&ï¿½ï¿½ï¿½ï¿½

This might be related to this issue here https://github.com/thephpleague/glide/issues/198 ?
Do you have some ideas what the problem might be?
Thank you so much for your help!
All the best,
Johannes

Ok, using
$glide->outputImage($path, $params);

works better (e.g., i can convert images) but it does not work entirely..

I am just adding a few more details on my development setup here:

PHP 7.1.x (running an XAMPP)
Windows 8.1
glide 1.2.2

okeeeeeeee~
After reading nearly all issues on glide, i stumbled upon this one here: https://github.com/thephpleague/glide/issues/154
Using
$glide->outputImage($path, $params);
exit;

solved my problem (for now). But this is (clearly) not the intended way to use it. Even the docs says, one should use getImageResponse($path, $params); instead.. So how can i use the latter?


Optimise the gridDim.n * blockDim.m idiom

Not quite sure what the fundamental problem is if I'm honest. If it's the integral division required to get the number of groups, we can probably address that one fairly easily too, although I suspect that this idiom is far more commonly encountered.

Yes, the fundamental issue is the integer division used in the implementation of __ockl_get_num_groups, and also the apparent omission of enable_sgpr_grid _workgroup_count_X/Y/Z
https://llvm.org/docs/AMDGPUUsage.html#initial-kernel-execution-state

Is it really the fundamental problem?  In a separate context, I thought you said that the performance impact is minimal.

Yeah I don't know how fundamental that one is, but "fixing" it should be straightforward. Let us discuss separately.

@b-sumner the performance impact was small, for the kernels I was studying at that moment. So I wasn't pushing for a change. And this PR should nicely optimize away issues found in those kernels.
But there are other kernels from other workloads which directly access hipGridDim_x/y/z without following this idiom in performance-critical loops. Again it's hard to quantify the potential impact yet without truly dive down into the ISA for those kernels. So I'm not requesting having a change either, yet. We might revisit this issue again in a couple of weeks when we have better understanding on these kernels.

@whchung I agree it is a problem if the division is not lifted out of a performance critical loop.  But the fundamental issue then is not the specifics of the computation, but rather that an invariant computation is not being identified and lifted out of that loop.

@b-sumner perhaps we are interpreting the term "fundamental issue" differently.
To me the "fundamental issue" is that reading hipGridDim_x/y/z involves integer division and makes derivative values reside in VGPR, not in SGPR. On the other hand, all other indexing values in HIP/ROCm-Device-Libs are nicely stored in SGPRs.
Should v_readlane be used in ROCm-Device-Libs implementation, to put hipGridDim_x/y/z values back into SGPR we may be able to at least keep most derivative values in SGPR, which may reduce some instructions and VGPR register usage.

As a side note, we've been starting to upstream our works on MLIR and the very first step is to enable integrating ROCm-Device-Libs into MLIR.
https://github.com/tensorflow/mlir/pull/146

@whchung I think you're observing side effects of the base or "fundamental" problem which has not been identified.  Using readfirstlane in the device libs would simply be a workaround that could affect other optimizations and I would oppose it until found necessary after the fundamental problem has been identified.

@b-sumner I agree we postpone this discussion until further understanding the nature of these new kernels which don't follow idiom fixed in this PR.