Havana Airjet device climate missing

Hi,
From the app i can control climate temp and switch on/off the heating, but in HA the climate entity is missing and the on/off switch as well.
Thanks!

1st error:
Logger: homeassistant.loader
Source: custom_components/bestway/climate.py:25
Integration: Bestway (documentation, issues)
First occurred: 17:39:44 (1 occurrences)
Last logged: 17:39:44
Unexpected exception importing platform custom_components.bestway.climate
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/loader.py", line 833, in get_platform
cache[full_name] = self._import_platform(platform_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/loader.py", line 850, in _import_platform
return importlib.import_module(f"{self.pkg_path}.{platform_name}")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/importlib/init.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 1204, in _gcd_import
File "", line 1176, in _find_and_load
File "", line 1147, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/config/custom_components/bestway/climate.py", line 25, in
| ClimateEntityFeature.TURN_OFF
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/enum.py", line 783, in getattr
raise AttributeError(name) from None
AttributeError: TURN_OFF
2nd error:
Logger: homeassistant.setup
Source: setup.py:379
First occurred: 17:39:44 (1 occurrences)
Last logged: 17:39:44
Unable to prepare setup for platform bestway.climate: Platform not found (Exception importing custom_components.bestway.climate).

Hah, commented out line 25 26 in climate.yaml and it just works!:D
_CLIMATE_FEATURES = (
ClimateEntityFeature.TARGET_TEMPERATURE
# | ClimateEntityFeature.TURN_OFF
# | ClimateEntityFeature.TURN_ON
)

Solved

Possible old version of HA?


Account wide AMI public block

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-intro.html#block-public-access-to-amis
This may require an SDK update in SFN before working

Implemented in https://github.com/aws-samples/aws-control-tower-account-setup-using-step-functions/commit/a5aeb83031a6a8cc6a840d725bf83af89a55c68f


this._getSession is not a function while use HttpsProxyAgent

Hi, I encounter a bug when I use proxy for requests
TypeError: this._getSession is not a function
    at HttpsProxyAgent.createConnection (node:https:140:26)
    at MockHttpSocket.passthrough (example/node_modules/@mswjs/interceptors/src/interceptors/ClientRequest/MockHttpSocket.ts:160:25)
    at _ClientRequestInterceptor.onRequest (example/node_modules/@mswjs/interceptors/src/interceptors/ClientRequest/index.ts:151:21)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)

Example repo https://github.com/WhoisUnknown/example-interseptor
I used version 0.36.10

Seeing this as well, with 0.37.1 and Node v20.12.0. My use case is MSW running in a Vitest test, and trying to access (unmocked) HTTPS endpoints.
I think the code in the Node repo is here: https://github.com/nodejs/node/blob/v20.x/lib/https.js#L163
Possibly a situation in the way that the createConnection method is used here? It gets bound to something without a _getSession method, but an _agentKey is still being passed into options?

https://github.com/mswjs/interceptors/blob/c338da8363660fbd08e794511e35678dae095670/src/interceptors/ClientRequest/agents.ts#L67-L82
Looks like what happens is that this.customAgent is there, but it isn't an instance of https.Agent, so createConnection is taken from super.createConnection. Then when we go to bind at L75-L79, it binds super.createConnection to this.customAgent. No good!
Given that createConnection does exist on the HttpsProxyAgent (this.customAgent), I think it shouldn't be that super.createConnection is now bound to this instead of this.customAgent, instead that the check isn't if this.customAgent is an instance of https.Agent but something else?
I'm not sure of the intent here. Hopefully somebody who knows better what's intended to happen here, might just be @kettanaito


classname instead of className on macosx

I convert class to classname, but expect className on macosx.
Invalid DOM property classname. Did you mean className?

This happens on windows as well. Also, I see this issue is over 3 years old ☠


When exporting vertex colors as GLTF, the imported result doesn't match the exported object

Describe the bug
Hi, when I am exporting my model with vertex colors, it doesn't import with the same colors. I am not sure where the discrepancy is, or if it's a limitation and I should be adjusting my workflow to match the GLTF format.
To Reproduce
Steps to reproduce the behavior:

Create a new scene, enable GLTF plugin
With the default cube, color 3 of the faces using the vertex paint view

Select a face in edit mode
Switch to vertex paint mode via the options wheel when holding ctrl+tab
Paint that face you've selected

Export as GLTF, including vertex color information in the data dropdown
Reimport, and notice that the vertex colors are present but, incorrect.

Expected behavior
I'd expect it to import as it was exported, and not switch/remove colors. To be clear, this isn't an issue with the auto-generated material and shader nodes. This is the actual vertex color data.
Screenshots

Here on the left is the incorrect, imported result. On the right is the original cube. A few things are strange to me:

Where are the green and blue vertices?
Why is the red face not on the top?

.blend file/ .gltf
vertex-color-repro.zip
I've attached the blender file containing the original cube and the incorrect cube. I've attached the gltf as well, which was just the original cube exported. This was imported again, and that's the second cube in the blend file.
I've even assigned the GLTF-generated material to my original cube for a direct comparison. So you just need to view materials in the viewport to see it side by side.
Version

OS: Windows 11
Blender Version: 3.4.1
GLTF Version: v3.4.50 (default from blender, not built from source)

#1815

Hello,
This bug is already fixed in main branch.
Thanks!

@julienduroure Thanks! I had a quick question, not specifically related to this issue but, the addon in general, since this vertex color issue is blocking me and my team (I've developed a GLTF extension addon for the tool).
When these changes are pushed to the official release, will that automatically be used by Blender? Does it auto-update addons? Blender and addons in general are new to me. Does Blender need to be re-installed or is there an updater for official addons?
And is there a roadmap, an estimate for when this branch will be stable? I tried installing the dev version and ran into an issue about a missing key, saying "KeyError: 'bpy_prop_collection[key]: key "io_scene_gltf2" not found'". Not sure if this is some user-install error on my end, or just an issue with 3.5.13
Thanks, in advance!

When these changes are pushed to the official release, will that automatically be used by Blender? Does it auto-update addons? Blender and addons in general are new to me. Does Blender need to be re-installed or is there an updater for official addons?

Every fixes here are commited to Blender master branch a few minutes later. So this fix is already in Blender 3.5 alpha.
This 3.5 version will be release as stable on March 15, 2023
Any new version needs to be re-installed, there is no updater in Blender

"KeyError: 'bpy_prop_collection[key]: key "io_scene_gltf2" not found'"
Not sure what you did, but seems you deleted the addon from Blender, and didn't install a new one.
The best way for you is to download a daily build here: https://builder.blender.org/download/daily/
These builds contains the latest version of the addon


Adding AmbigNQ Critic Prompts

🤔 Reasoning
Feature request to add AmbigNQ benchmark prompts to critic implementation.
🚧 Changes
Appended prompts for AmbigNQ benchmark to beginning of cog/prompts/critic.py (because they appeared first in the paper). Reviewing the repo and paper it did not appear that the implementation for AmbigNQ benchmark requires additional logic, so the only update was adding the appropriate QA/Plausibility/Critiquing examples. The specific examples implemented were pulled directly from the paper's repo.
✅ PR Checklist

[x] Using this PR template?
[x] Linked issue? -> #71
[x] Added feature?

[ ] Added/updated docs?
[ ] Added/updated tests?

@alckasoc Removed NB from PR, can be accessed here. Agent pulled in the appropriate examples and prompt logic. PR description also updated to better explain implementation.

@alckasoc Committed changes to mock google CSE, all tests are passing. Updated PR description to include information about that.


"review-submitted" automation does not work

We have added this to our triagebot.toml in Miri in the hopes of getting automatic labels when submitting a "changes requested" review:
[review-submitted]
# This label is added when a "request changes" review is submitted.
reviewed_label = "S-waiting-on-author"
# These labels are removed when a "request changes" review is submitted.
review_labels = ["S-waiting-on-review"]

However, this does not seem to work -- I submitted such a review in https://github.com/rust-lang/miri/pull/4054, and the labels were not updated.
We copied the config here from the Rust repo. This slightly different than what the documentation says:
[review-submitted]
# These labels are removed when a review is submitted.
review_labels = ["S-waiting-on-review"]
# This label is added when a review is submitted.
reviewed_label = ["S-waiting-on-author"]

In the docs, reviewed_label is still a list, even though the name is singular -- that's confusing. Not sure if the docs are right or the rustc repo is right?

Looking at https://github.com/rust-lang/triagebot/blob/d7d4babe564e264ea4824bba1ba55a8088d8a9fd/src/config.rs#L305, it seems like the docs are wrong here. So the Miri config should be right -- but it doesn't work.
Cc @oli-obk

@RalfJung Does https://github.com/rust-lang/rust-forge/pull/784 resolve this issue?

That fixes the docs. But the feature still just doesn't seem to work in the Miri repo.

You must be an assignee for it to work. https://github.com/rust-lang/miri/pull/4054 has no assignees.

Oh, I see. I didn't expect that, and the docs don't seem to mention it.
In Miri we typically don't use assignees. Is there any way to lift this restriction, and apply the label change whenever the review was submitted by someone who could be an assignee (i.e., by a project member)?


[aes] Idle signal feedback to clkmgr

The clock manager needs an "idle" indication so that it can ensure the clock is not manipulated while operations are ongoing. This is primarily to ensure software cannot inject clock glitches into a running design.
It would be preferable is such a signal were level.

Sounds reasonable. There is already a bit in the status register indicating that. I will expose this on the top level and connect it. Is there already a corresponding port in the clock manager?

I think there is (need to double check).
But I should also double check if i intended to change how that idle is
generated.
On Fri, Jun 26, 2020 at 11:10 AM Pirmin Vogel<EMAIL_ADDRESS>wrote:

Sounds reasonable. There is already a bit in the status register
indicating that. I will expose this on the top level and connect it. Is
there already a corresponding port in the clock manager?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/issues/2647#issuecomment-650321376,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSUZGHNNDCRQNZOVLBLRYTP7RANCNFSM4OJQY2HQ
.

Hi @tjaychen,
sorry for my late response. I now did a first PR for bronze to add the connection. I am not sure if interconnection is done correctly and would be happy if you could take a look.

I think we can close this issue. The signal is connected both in bronze and master. what do you think @tjaychen ?

yep! thanks!
On Fri, Jul 24, 2020 at 7:09 AM Pirmin Vogel<EMAIL_ADDRESS>wrote:

I think we can close this issue. The signal is connected both in bronze
and master. what do you think @tjaychen https://github.com/tjaychen ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/issues/2647#issuecomment-663557216,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSUXXQHT7NNA2H6U3DTR5GIZHANCNFSM4OJQY2HQ
.


Update udocker.py

At some systems '--delay-directory-restore' is not available. In that case, import of the exported image ends up with:
Error: failed to extract container: image.tar
Error: loading failed
After looking into udocker.py it turned out that issue is here:
tar: unrecognized option --delay-directory-restore' Try tar --help' or `tar --usage' for more information.

Unfortunately this option is needed for a normal user to properly extract container layers under some circunstances.
Example: https://superuser.com/questions/1219935/non-writable-dir-with-files-inside-of-tar-archive

As a practical example, the nixos/nix image requires --delay-directory-restore in order to work properly.

This has been fixed.


update issues when forked

Hi,
These days i see there are some great new updates, however with forked version we cant sync to the latest automatically anymore.
Please solve this issue,so when can sync the the latest version with no problem.

Could you please clarify what issue are you experiencing in more detail?
If I understand your problem correctly: in its default version, the CGPS GitHub Action doesn't use any files from your repository - instead, it automatically downloads the latest compatible version directly from this repo. This means that no matter how outdated your fork is, the GitHub Action will always be up to date.
However, it appears that your fork gets the script files from your own repo - this means that you are responsible for updating/syncing the fork to get the latest updates.

Hi,
Yes with own forked repo,when manualy  updating/syncing the the fork i had to discard all my commits.
When using the deafualt cgps version,can you tell how i can edit to set my own block and white lists? That's the only 2 files i want to edit.
Also please consider to add the following hagezi's block list;
https://raw.githubusercontent.com/hagezi/dns-blocklists/main/wildcard/tif.normal-onlydomains.txt
https://raw.githubusercontent.com/hagezi/dns-blocklists/main/wildcard/pro-onlydomains.txt

Hi,i cant sync the fork te the latest

 Hi,i cant sync the fork te the latest

Just delete your repo and fork a new one. Remember to save your lists.
Lists can now be defined is environment variables. Refer to README.

Hi,
Thanks for making this clear.
So this means the default blocklist and allow list will stay?
And the list i will add on variable will be added to default list?

Only your lists will be used if you add the variables.

Great feature.
How can we see or share recommended  block and allow lists.
Next featue request is to auto update ip in cloudflare for location using legacy dns on routers.
Like for home,office and parrents.
There is a script,but maybe you can make it better and advanced and integrate with cgps.
https://github.com/FiorenMas/Cloudflare-Gateway-Update-DDNS-For-DNS-Locations


Update 5.0 version in Migration Guide

Docs in en and de (in https://github.com/expressjs/expressjs.com/pull/1371) were updated, but all other langs need update as well to change:
$ npm install<EMAIL_ADDRESS>--save

to
$ npm install<EMAIL_ADDRESS>--save

Perhaps we should consider a better way to address this in the long run that wouldn't require touching so many files.  The _data/express.yml file has a current_version version for the latest 4.x release version.  We could add next_version for the 5.x latest version.  Of course, when 5.x is released, current_version would become 5.0.0 or whatever, and next_version would be something like 6.0.0-alpha.1 or the like.

Also I really hope Express 5 will be released anytime soon now..

Hi, I was working on this https://github.com/expressjs/discussions/issues/251, however, I think before that, we should sort this one out.
cc: @UlisesGascon

Hi, I was working on this https://github.com/expressjs/discussions/issues/251, however, I think before that, we should sort this one out.
cc: @UlisesGascon

Go ahead @IamLizu. I will assign this issue to you :)

Hi @UlisesGascon 👋
Do you think I should wait till #1552 is merged / rejected? I mean in case 1552 gets landed then a few conflicts might occur.


Fix compilation on FreeBSD 10.3 with default compiler

Given FreeBSD 10.3 with default compiler:

$ cc -v
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.3

Defining _XOPEN_SOURCE to 600 on the fixed line leads to the following errors:

cc -std=c99 -pedantic -c -O3 -fPIC  -Wall -W -Wstrict-prototypes -Wwrite-strings -g -ggdb  net.c
net.c:435:29: error: use of undeclared identifier 'AF_LOCAL'
if (redisCreateSocket(c,AF_LOCAL) < 0)
^
net.c:460:21: error: use of undeclared identifier 'AF_LOCAL'
sa.sun_family = AF_LOCAL;
^
2 errors generated.

AF_LOCAL is defined in sys/socket.h within ifdef __BSD_VISIBLE.
__BSD_VISIBLE could be defined in sys/cdefs.h, but it is never done if _XOPEN_SOURCE is defined.
So on FreeBSD _XOPEN_SOURCE shouldn't be defined.

I think this should be merged @badboy

bors r+


Theme support adds 200kb to the Nuxt bundle.

// nuxt.config.js
css: [
  { src: '~assets/style/app.styl', lang: 'styl' }
]

With
server-bundle.json  344 kB
...
nuxt.bundle.224f457c4d68af4f68a7.js     246 kB

vendor.bundle.fbef10f63661a32c5c8b.js     219 kB

Without
server-bundle.json  145 kB
...
nuxt.bundle.87c720560c249e74a551.js    47.3 kB

vendor.bundle.616fa214a1a7c12a664e.js     219 kB

Is there any way to include theming without this amount of bloating?

When you say theme support, you do mean the entire css of Vuetify correct? Because the theme specific features are nowhere near that size.

Long day, my bad.


Double entry in the lock file

When requiring django and djangorestframework the lock file generates double dependency for django.

Not only django with drf, confirmed

is this with the latest versions?

Proper casing should be used for older versions. The latest version should use proper casing automatically.

re-open if this is still an issue with the latest version

As far as I can see it is still a case, even with the latest versions. Pipfile has:
djangorestframework = "*" and django = "*"

Also elasticsearch-dsl creates a double entry of itself.

Proper casing is currently required in Pipfiles. I'll work on a fix :)
Sent from my iPhone

On Jan 25, 2017, at 3:18 PM, Kfir Breger<EMAIL_ADDRESS>wrote:
Also elasticsearch-dsl creates a double entry of itself.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.

this is now fixed!

Proper casing should always be used in Pipfiles. This tool now automatically corrects mistakes.

The latest version
This bug occurs with django-extensions

Ok, I think I see what's happening. The lock file generated from your Pipfile contains both
"django-extensions": "*"
and
"django_extensions": {
    "hash": "sha256:b79abdb0c9a0f6ba61701f299c7605830c4b2a8495d31461ac401d027bab2e10",
    "version": "==1.7.6"
}

The hash and version are correct for the module "django-extensions" but the wheel filename returned from PyPI is "django_extensions-1.7.6-py2.py3-none-any.whl". I haven't peaked at the changes from yesterday yet, but I'm betting pipenv is substringing a name from the wheel. Since the wheel name doesn't match the provided package name, we end up with two entries. I'll take a closer look.

@nateprewitt that's exactly it, just reproduced it. It seems that wheel replaces - with _. Should we have proper_case() use a none .whl link? I can put something together to fix it.

@jpadilla we're going to need to do that because PyPI doesn't seems to standardize naming on package links in the repo. The only place I'm seeing the name standardized is the  tag on the package page. Since we're already parsing a name out, that seems like an acceptable alternative solution.

So, what is the expected input and output here?

Also reported with django-cleanup.

I also experienced this with pytest-django.

fixed!

@kennethreitz curious to know how it was fixed?

It ended up being a few steps, @jpadilla. Apologies for not getting back to you about a PR, there ended up being some more nuance to it than expected.
Our original problem was parsing files downloaded from pip for the package name. In some cases the filename didn't exactly match the package name we wanted, which was leading to the bad Pipfile.lock entries.
The first step was fixing our proper_case function, which was returning bad data in certain cases. It relied on parsing a package's PyPI simple page for the last download link, which might not be identical to the actual package name (elasticsearch-dsl vs elasticseach_dsl). We modified the parser to instead retrieve the package name from the page header generated by PyPI itself. This now avoids issues with poorly named releases.
Once we had a way to get correct package names, we needed to map them to the files we downloaded for hashing. The problem here is we not only need to download the packages in the Pipfile, but all of their dependencies for hashing as well. Since we didn't have a list for those names, we had to parse pip's output to determine which packages we downloaded, and what their proper names were. Once we had that output, we simply kept track of the relation from a downloaded filename to its proper package name.
With the mapping, we were then able to solve the actual problem of generating the Pipfile.lock with duplicates. Since we previously hadn't known the names of the files pip was downloading (due to dependencies), we had to parse them all while hashing. This had been done the same way we'd handled links in proper_case, and was thus subject to the same flaw. We now just look up the filename before hashing, use the associated proper name, and everything seems to be grand.
Let us know if you're still encountering any issues with 3.2.8 and thanks for the interest :)

@nateprewitt bravo, thanks for the great recap!


Esversion normalization

This patch contains two refactoring commits followed by a bug fix that should
resolve both gh-2909 and gh-3051 gh-2902.

@jugglinmike just want to make sure you've seen this

Coverage decreased (-0.0005%) to 97.754% when pulling dbcc8501e0f5896a6213582df95f82971cff41a1 on jugglinmike:esversion-normalization into 78b79c099fc490d93cd7aef599a1528761e9498d on jshint:master.

@rwaldron You were right: somehow, I missed the build failure when I first
submitted this patch. I just had a chance to resolve it--see the fixup!
commit.
This is failing Coveralls because I removed a few branches that were covered
but are no longer necessary. Clicking through to the report, you'll see the
following:

Coverage
File
Lines
Relevant
Covered

v 97.07
src/jshint.js
5548 (+6)
2865 (-3)
2781 (-3)

Working the numbers out:
master:
2784 / 2868 = 0.9707112970711297

this branch:
2781 / 2865 = 0.9706806282722513

So the "coverage" statistic does decrease, but it doesn't actually reflect any
newly-uncovered branches.
If it looks good to you, say the word and I will be happy to perform
the fixup and force-push to this branch.

This patch contains two refactoring commits followed by a bug fix that should
resolve both gh-2909 and gh-3051.

Does that mean that this supersedes #3051?

Sorry, @rwaldron. gh-3501 is unrelated to this work--that reference was
incorrect. The final commit in this patch should resolve both gh-2909 and
gh-2902.

Coverage remained the same at 97.754% when pulling a0a238ecbb654a0532e956bd38e209fd78ab2dbc on jugglinmike:esversion-normalization into 78b79c099fc490d93cd7aef599a1528761e9498d on jshint:master.

@rwaldron I've changed that variable name as requested. Sorry for the delay!

Sorry Mike, I'm the absolutely worst.


Setting tab name with echo

I am trying to run a command to set a tab/pane name (not sure which is which atm) using echo.
windows:
  - name: Run-apps
    root: ~
    layout: tiled
    panes:
      - commands:
        - echo -e '\033];My tab name\007'
        - cd ~/my-app

When I run this I get:
200:201: syntax error: Expected “"” but found unknown token. (-2741)

Any way to make this work as I expect?
Rob
:)

Solved this with a script.
      - commands:
        - renameConsole.sh "New name"

The script is hacky because I noticed that sometimes the rename just doesn't work.. but like all good IT solutions clicking the button over and over solves everything:
#!/bin/bash

sleep 2
echo -e "\033];${1}\007"

sleep 2
echo -e "\033];${1} 2\007"


update images to use cello naming

 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.


Increment version for synapse releases

Increment package version after release of Azure.Analytics.Synapse.Spark

Covering for auto-merge as it seems to have ignored Chris's approval.


Remove null collection dates from SAR-CoV-2 sequence metadata

Closes #36
This corrects a regression introduced in #4c0728 and adds a test case for non-empty/bad-format dates in the metadata file.
Below is the query plan of the filtered Polars LazyFrame, which matches the one created by the above commit (i.e., all operations occur in the Polars streaming engine when streaming=True

Not strictly related to this PR, but if anyone is curious about the number of rows that get discarded due to missing or invalid collection dates, it's ~ .5% of sequences from 50 US states + DC/PR Homo sapiens (15,097 of 2,917,878)
*based on the most recent metadata file


New Device discovered in HA but no Entities

Hi,
I've managed to successfully upload the D1 mini.
Home Assistant discovers a new device but there are no entities to control the AC.
I must be doing something wrong but I don't know what.
Do I need to add something in my configuration.yaml as well??
INFO Connecting to <IP_ADDRESS>:6053 (<IP_ADDRESS>)
INFO Successfully connected to <IP_ADDRESS>
[21:53:29][I][app:105]: ESPHome version 1.19.4 compiled on Jun 28 2021, 21:52:31
[21:53:29][C][wifi:484]: WiFi:
[21:53:29][C][wifi:344]:   SSID: '***'[redacted]
[21:53:29][C][wifi:345]:   IP Address: <IP_ADDRESS>
[21:53:29][C][wifi:347]:   BSSID: 68:FF:7B:6F:6E:80[redacted]
[21:53:29][C][wifi:348]:   Hostname: 'airco'
[21:53:29][C][wifi:352]:   Signal strength: -62 dB ▂▄▆█
[21:53:29][C][wifi:356]:   Channel: 1
[21:53:29][C][wifi:357]:   Subnet: <IP_ADDRESS>
[21:53:29][C][wifi:358]:   Gateway: <IP_ADDRESS>
[21:53:29][C][wifi:359]:   DNS1: (IP unset)
[21:53:29][C][wifi:360]:   DNS2: (IP unset)
[21:53:29][C][logger:189]: Logger:
[21:53:29][C][logger:190]:   Level: DEBUG
[21:53:29][C][logger:191]:   Log Baud Rate: 0
[21:53:29][C][logger:192]:   Hardware UART: UART0
[21:53:29][C][mhi_ac_ctrl:043]: MHI-AC-Ctrl Climate 'MHI-AC-Ctrl'
[21:53:29][C][mhi_ac_ctrl:044]:   Min. Temperature: 16.0°C
[21:53:29][C][mhi_ac_ctrl:045]:   Max. Temperature: 36.0°C
[21:53:29][C][mhi_ac_ctrl:046]:   Supports HEAT: YES
[21:53:29][C][mhi_ac_ctrl:047]:   Supports COOL: YES
[21:53:29][C][ota:029]: Over-The-Air Updates:
[21:53:29][C][ota:030]:   Address: <IP_ADDRESS>:8266
[21:53:29][C][api:095]: API Server:
[21:53:29][C][api:096]:   Address: <IP_ADDRESS>:6053
[21:53:36][D][api.connection:630]: Client 'Home Assistant 2021.6.6 (<IP_ADDRESS>)' connected successfully!

Just a device with no entities

Hm, looks like you're right. I'll need to check if something has changed in ESPHome itself, they could've broken something...

I found a error in the HA logs:
Logger: homeassistant
Source: components/esphome/init.py:214
First occurred: 22:17:03 (1 occurrences)
Last logged: 22:17:03
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/esphome/init.py", line 214, in on_login
entity_infos, services = await cli.list_entities_services()
File "/usr/local/lib/python3.8/site-packages/aioesphomeapi/client.py", line 137, in list_entities_services
entities.append(cls(**kwargs))
File "", line 9, in init
self.supported_modes = __attr_converter_supported_modes(supported_modes)
File "/usr/local/lib/python3.8/site-packages/aioesphomeapi/model.py", line 245, in _convert_climate_modes
return [ClimateMode(val) for val in value]
File "/usr/local/lib/python3.8/site-packages/aioesphomeapi/model.py", line 245, in
return [ClimateMode(val) for val in value]
File "/usr/local/lib/python3.8/enum.py", line 339, in call
return cls.new(cls, value)
File "/usr/local/lib/python3.8/enum.py", line 662, in new
raise ve_exc
ValueError: 6 is not a valid ClimateMode

Interesting, it's definitely a valid mode: https://github.com/esphome/esphome/blob/dev/esphome/components/climate/climate_mode.h#L23
Gotta dig deeper.

1 was changed to 6 here: https://github.com/esphome/esphome/commit/ebadaa966016dd9cfbc7fbd3046883ade9be0214#diff-3cc17e2d884f227c82605ff7dae5e504ab117f46f087e32030690e5c5ce350cf
this is probably the breaking change...

...and the answer is probably: https://github.com/esphome/esphome/pull/1933
"the value for AUTO 6 was sent via protobuf but HA doesnt understand it yet"
Brilliant...

OK, I've pushed a new commit, could you check if that works, please?

It Works!!!
I have a entity and I can controll my AC.
Can't turn it off yet but I don't know if that is a known issue or not.
Will dive in to that when I'm home from work.

Oops. :)
That's what happens when you try to develop without a device to test on. I've added "off" to the list of supported modes, which might fix it.

Cool, thank you for testing!


JavaScript

#JavaScript
User Story
As a bootcamp student
I want the pre-work notes structured on a webpage
So I can easily find and read the documentation
Acceptance Criteria
GIVEN a pre-work study guide website
WHEN I view the study guide
THEN I can see the four topics I learned listed along with a suggestion on what I should study first

Successfully deployed changes.


Dataset preparation (camera pose)

HI!
Am I right that if I want to use camera pose extracted from the blender ( obj.matrix_world) I need to multiply it by diag(1 -1 -1 1) to follow the OpenCV convention?
Thank you!

I'm not sure what convention Blender uses, but you are right about DSAC* using the OpenCV convention. If Blender uses the OpenGL convention, you might have to flip twice: Flip second and third column, then flip second and third row. (Result of multiplying diag(1 -1 -1 1)  from left and from right.)
Let me know whether you solved the issue.
Best,
Eric

Thank you!
I solved this issue when I simply saw this picture.

So I did it like this

Best,
Yaroslav


Fix code scanning alert - Inclusion of functionality from an untrusted source

Tracking issue for:

[x] https://github.com/Astraxx04/LearnZ/security/code-scanning/8

Fixed by PR #44


Table 3. CPC comparision, ResNet 50 design choice

Thank you for sharing your code. I'm happy to try this seemingly attractive representation learning idea on a different backbone. e.g. ResNet50.
Gladly, you mentioned ResNet50 on Table3 in your paper, so I'm looking into it. Then I got several questions about it.
Table3. CIFAR10 (no data augmentation) DIM(L) single global

From the FoldedResNet code https://github.com/rdevon/DIM/blob/master/cortex_DIM/configs/resnets.py#L129
I was able to reproduce similar result (conv: 80, Y(64): 71) as it is on the paper(80.95) with following commmand
CUDA_VISIBLE_DEVICES=0 python scripts/main.py local classifier --d.source CIFAR10 --d.batch_size 128 --o.learning_rate 0.0002 --encoder_config foldresnet34_32x32 --local.mode nce --local.mi_units 1024 -n CIFAR10_DIM_L_NCE_foldresnet34 --t.epochs 500

CIFAR10_DIM_L_NCE_foldresnet34_final.t7_global_test_acc

I know you mentioned setting mi_units to be 2048 in Appendix 2, but it seems this change does not explain 9% performance difference. So I looked into the backbone.
While I was trying to fill the performance gap, I found that the ResNet used in this code is somewhat different from the one I usually use.

From the above image (from original ResNet Paper), 34-layer and 50-layer structure are only differ in use of bottleneck block instead of basic block.
In your code, even though the name shows resnet37, using bottleneck block make it resnet50 like encoder.
And I also considered using ResNet for CIFAR10 requires small modification from ImageNet 224x224 input version of ResNet (e.g. First conv kernel size become 3x3 from 7x7, no maxpooling after that)
However, there are a few more changes that have no explanation I can think of. Could you clarify what was the behind thought on these small changes?

Why did you change all conv_2,3,4x layers to have stride=1?
The only downsampling occurs at the first conv. But you could do the same thing by setting stride at following conv layers. Is there any advantage downsampling on the lowest level feature?
Why did you remove conv_5x layer completely from your _foldresnet37_32x32? I understand keeping all conv_xx layers make feature map to small (say, 1x1) but you can just set stride to be 1 as you did in previous layers. Does the insertion of conv_5x affect final results?
repeating blocks follow [3, 4, 6, 3] pattern. Considering you removed the final block. Then following [3, 4, 6] seems reasonable. But your code has a pattern of [2, 5, 2]. Is there any specific reason?

I was tried various modified ResNet structure based on your code, and most of the time classification accuracy rise and down again, but at the same time loss still decreases. (maybe goes to a degenerative solution or trivial solution) Have you experienced this phenomenon during your work? If the above changes don't matter much to the final result I wouldn't ask this question. It seems DIM training works on specific design choice, and I'm not sure what it is.

So one quick question: the results that you're focusing on are training DIM and the classifier together, correct?


remove obsolete information from print Coordinates

Changes proposed in this pull request:
change output from:
1D Coordinates object with 40 points of cshape (40,)
domain: cart, convention: right, unit: met
coordinates: x in meters, y in meters, z in meters
Does not contain sampling weights

to:
1D Coordinates object with 40 points of cshape (40,)
Does not contain sampling weights

Thanks, this looks clearner now. But I'm not sure if we consider it a bug and merge into main or merge into dev for later release.

+1 for bugfix in develop instead of hotfix in main

Yes, I also think this is a bugfix.

a bugfix is a bug on development and will be fixed in a patch release, a hotfix is a bug on main and should be fixes by a patch release. (even it's not that critical).
Every version, in this case 0.6.x, in itself should be as free from bugs as possible, so I would like to handle it as a hotfix.

Thanks for implementing, I'm all for more compact reprs
Since everyone accepted, I'll merge into main.


Support ILP32 on RV64 in psABI

This pull request adds a new e_flags X32. It occupies the sixth bit of e_flags layout.
We have initially implemented rv64 ilp32 on the gnu toolchain and kernel.
Details in this link.
@guoren83 @palmer-dabbelt  @kito-cheng

Regardless of whether we want it, x32 is completely the wrong name for it. x32 comes from the x86, x86_64 and (awful) x64 terminology specific to x86.

I'll also note that, normally, ILP32-on-64 ABIs use ELFCLASS32, not ELFCLASS64. This is complicated on RISC-V by the fact that there is a single EM_RISCV, not separate EM_RISCV32 and EM_RISCV64.

I'll also note that, normally, ILP32-on-64 ABIs use ELFCLASS32, not ELFCLASS64. This is complicated on RISC-V by the fact that there is a single EM_RISCV, not separate EM_RISCV32 and EM_RISCV64.

In ILP32-on-RV64, we used  ELFCLASS32 and EM_RISCV. X32（Let's temporarily call it this name) is added to distinguish between ilp32 on RV64 and ilp32 on RV32 . I think this e_flag is necessary.
This is the ELF Header which generated by ILP32-on-RV64
ELF Header:
Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class:                             ELF32
Data:                              2's complement, little endian
Version:                           1 (current)
OS/ABI:                            UNIX - System V
ABI Version:                       0
Type:                              REL (Relocatable file)
Machine:                           RISC-V
Version:                           0x1
Entry point address:               0x0
Start of program headers:          0 (bytes into file)
Start of section headers:          24620 (bytes into file)
Flags:                             0x21, RVC, X32, soft-float ABI

I would prefer using something like register a new e_machine value EM_RISCV64_X32 or EM_RISCV64_ILP32 rather than use a e_flags for two reason: the flags only used for ELFCLASS32, and it's a wast to ELFCLASS64, use new e_machine could prevent old tool interpreter that as a normal RISC-V 32 binary

I would prefer using something like register a new e_machine value EM_RISCV64_X32 or EM_RISCV64_ILP32 rather than use a e_flags for two reason: the flags only used for ELFCLASS32, and it's a wast to ELFCLASS64, use new e_machine could prevent old tool interpreter that as a normal RISC-V 32 binary

I could not agree with you.

There are not  EM_RISCV64 or EM_RISCV32 in RISC-V, using a new e_machine value EM_RISCV64_X32 means we have to add EM_RISCV64 and EM_RISCV32 . This is maybe a more serious waste than "it's a wast to ELFCLASS64”
In situations similar to mips-n32 and aarch64_ilp32,  them use the same e_machine value with N64 or LP64 ,LLP64. Unable to prove such a major flaw, I tend to follow them.

e_machine is 16 bit value, and use as sequence number, so we still have 2^16 - 248 = 65288 to use, but e_flags is use as bit vector, and reserved 8 bit for non-std use, and we also used 5 bit, so we have only 19 bit left.
So compared to e_flags, e_machine has much larger room to use (waste :P).

OK, you convinced me.
So do we need to set EM_RISCV32 and EM_RISCV64 as well? And what number should be chosen?

Seems like it should be happened here, we could send request to<EMAIL_ADDRESS>and https://groups.google.com/g/generic-abi , but I would like to pick an random value before we reach further consensus.
However I know a random value might be a bit too vague, maybe we could tentatively use 1243 (EM_RISCV + 1000), and update it in this PR after it's registered later.

OK, you convinced me. So do we need to set EM_RISCV32 and EM_RISCV64 as well? And what number should be chosen?

I don't have an overly strong view on EM_RISCV_X32 (though Kito makes a good point about eflags bits being scarce), but don't see why we'd need to introduce EM_RISCV32 and EM_RISCV64 as well at this point - it feels like it would cause confusion with no real gain.

The world would have been better if EM_RISCV had been split in two like that, but it wasn't, so we need to live with that, and trying to retroactively do it is a bad idea. So I agree with Alex.

This feature has already been adopted by upstream open-source RTOS projects, including NuttX and RT-Thread. During the 11.7 psABI meeting, it was agreed to include N32 in the psABI specification as an experimental feature.
@kito-cheng

I don’t think it was completely agreed, but it will receive less opposition than trying to make it non-experimental

Devboard:
BPI-CanMV-K230D-Zero: https://docs.banana-pi.org/en/BPI-CanMV-K230D/BananaPi_BPI-CanMV-K230D-Zero
Toolchains:
GCC: https://github.com/ruyisdk/riscv-gnu-toolchain-rv64ilp32
LLVM: https://github.com/ruyisdk/llvm-project/tree/rv64ilp32
Linux:
Linux Kernel: https://github.com/ruyisdk/linux-xuantie-kernel
RTOS:
EasyXem (AUTOSAR CP R19-11): https://atomgit.com/easyxmen/XMen/tree/rv64ilp32-dev
Nuttx: https://github.com/apache/nuttx
RT-Thread: https://github.com/RT-Thread/rt-thread/pull/9194
Due to the widespread adoption of N32 ABI, I support including N32 as an experimental feature in the psABI specification.

Has the design of the RV64 ILP32 ABI been thoroughly vetted, and have the inevitable performance wrinkles been worked out?
I don't want to be an impediment to adopting an RV64 ILP32 ABI, but this seems like a surprisingly small PR to that end.

I don’t see a change regarding ELFCLASS32/64, for one. I’m also concerned about the 2 GiB restriction making this of extremely limited use.

My other big concern as a quite separate issue is with the toolchain side. Our toolchain conventions dictate that cc -mabi=ilp32[fde]? for a 64-bit-targeting compiler gets you RV32. How then would you enable this ABI instead?

I’m also concerned about the 2 GiB restriction making this of extremely limited use.

Yeah. What is the exact nature of the restriction? We did design the virtual memory system so that a 4 GiB heap is possible. I would think that a 2 GiB relative limit in static addressing is a requirement, following the usual logic for RV64, but we should be able to provide the whole heap.

I’m also concerned about the 2 GiB restriction making this of extremely limited use.

Yeah. What is the exact nature of the restriction? We did design the virtual memory system so that addresses up to 4 GiB are usable. I would think that a 2 GiB relative limit in static addressing is a requirement, following the usual logic for RV64, but we should be able to provide the whole ~4 GiB heap.

It's there because the ISA and ABI like to sign-extend things and so sign-extending an address >= 2 GiB gives you something in the kernel's address space, so you'd have to make more changes to the ABI that may have a performance cost. Unlike using UXL=32 where you can actually use the full 32-bit address space, which seems like the wrong way round for the two configurations if anything. Combined that makes this quite a niche thing; you'd likely struggle to build a full distro with it, I know Debian struggled with 32-bit MIPS's (architectural) address space limitations for many years, so it would be for embedded use only, at which point why not just use RV32, that's what it's for.

I was conflating the UXL=32 story with the RV64 ILP32 situation. Sorry for that noise.

I was conflating the UXL=32 story with the RV64 ILP32 situation. Sorry for that noise.

Well, it is still somewhat relevant. As far as I understand, i386 and x32 can both use a 4 GiB address space (provided you're using a 64-bit kernel), and neither MIPS N32 nor MIPS O32 can use a 4 GiB address space as the various untranslated/kernel windows are architectural and the 32-bit regions still present in the 64-bit address space (though it wouldn't surprise me if R6 or another revision allows turning this off given it ditched a bunch of other historical baggage, my knowledge is dated). RISC-V, as far as I know, is unusual in its 32-bit ISA+ABI having a bigger usable address than this proposed 64-bit ISA + 32-bit ABI (or even different in any respect), so it's worth drawing attention to.

I’m also concerned about the 2 GiB restriction making this of extremely limited use.

Yeah. What is the exact nature of the restriction? We did design the virtual memory system so that addresses up to 4 GiB are usable. I would think that a 2 GiB relative limit in static addressing is a requirement, following the usual logic for RV64, but we should be able to provide the whole ~4 GiB heap.

It's there because the ISA and ABI like to sign-extend things and so sign-extending an address >= 2 GiB gives you something in the kernel's address space, so you'd have to make more changes to the ABI that may have a performance cost. Unlike using UXL=32 where you can actually use the full 32-bit address space, which seems like the wrong way round for the two configurations if anything. Combined that makes this quite a niche thing; you'd likely struggle to build a full distro with it, I know Debian struggled with 32-bit MIPS's (architectural) address space limitations for many years, so it would be for embedded use only, at which point why not just use RV32, that's what it's for.

The facts are:

Sophon-cv1800B 64MB (XuanTie C906)
Kendryte-k230d 128MB (XuanTie C908)
Renesas RZ/Five xxxMB (Andes AX45)
Allwinner D1s/F133 64MB (XuanTie C906)
...
Small memory rv64 ISA chips have widely come out; they need 64ILP32 ABI to solve the productization problem.

So, your question becomes, why did the above fact come out? Let me guess a little:

RV64 ISA is more scalable. For example, rv32 Linux only supports a maximum of 1GB of physical memory, but rv64 Linux supports 128+GB-sv39/64+TB-sv48 with almost no limitations.
RV64 ISA supports ld/sd instructions, which satisfies the vendor more than lw/sw.
RV64 ISA supports 64-bit atomic instructions, which satisfies the Linux & OS kernel design.

for a 64-bit-targeting compiler gets you RV32. How then would you enable this ABI instead?

Only when -march=rv64* && -mabi=ilp32* are specified, the rv64ilp32 ABI would be enabled. This will not affect the current default -mabi=ilp32* usage, which stays on the rv32ilp32 ABI.

I also see value in RV64 ILP32, since the wider registers, memory accesses, etc. will offer higher performance than UXL=32.
But I'd like to take a beat and see if we can somehow work around the 2 GiB heap addressing limitation.  As a strawman, we could consider the idea that pointers are unsigned and zero-extended.  Pointers would be loaded from memory using LWU instead of LW, which would hurt code size by a few %.  Some address computations would be performed using ADD instead of ADDW, which would improve code size a little bit.  It would be possible for buggy code to generate pointers greater than 2^32, since ADD[I] and load/store offset addressing don't wrap addresses mod 2^32, but this would correspond to UB anyway.  Is something like this workable?

I also see value in RV64 ILP32, since the wider registers, memory accesses, etc. will offer higher performance than UXL=32.
But I'd like to take a beat and see if we can somehow work around the 2 GiB heap addressing limitation. As a strawman, we could consider the idea that pointers are unsigned and zero-extended.

Pointers would be loaded from memory using LWU instead of LW, which would hurt code size by a few %.
Em... There is no C.LWU for LWU, so code size is greatly affected. I make a comparison for Linux kernel code size:
When ISA_C is on, rv32ilp32 is 8580K, and rv64ilp32 is 9041K.
When ISA_C is off, rv32ilp32 is 11838K, and rv64ilp32 is 12091K.
We found that losing C.LWU contributes a lot to code size.

Some address computations would be performed using ADD instead of ADDW, which would improve code size a little bit.
Yes, and compiler work is more complex than it sounded.

Some type-punning operations would result in explicit zero-/sign-extensions, increasing dynamic instruction count somewhat.
I agree.

It would be posible for buggy code to generate pointers greater than 2^32, since ADD[I] and load/store offset addressing don't wrap addresses mod 2^32, but this would correspond to UB anyway.
Is something like this workable?
Theoretically, this is possible. But we must pay the inevitable performance cost and face complex compiler issues. So, we choose the simplest and most effective way to deal with it. Limit the addressing to 2GiB in psabi-spec to minimize the modification of the spec and compiler. I want to give more explanation from the perspective of productization demand:

From practice, 2GiB is enough for the embedded scenario. Most small memory devices only need 1GB of physical address, and 2GiB address space is enough. RISC-V Linux 64-bit compat mode (UXL=32) only supports 2GiB address space, not 4GiB address space, because it's enough for the embedded scenarios in practice (e.g., k230/k230d productization).
In the end, rv64ilp32 is the supplement for rv64lp64. If you need more address space, go to rv64lp64 with a simple replacement.

Limiting the address space to just 2G may cause Asan to not work well. Asan
consumes a lot of virtual memory space, so having the full 4G available, if
possible, would be ideal. Asan is a very popular modern memory debugging
tool, and losing support for it would not be a good idea.

Back to zero-extension vs. sign-extension, I would prefer sign-extension
because both the ISA and psABI are sign-extension preferred. Here are some
concrete examples:

Arguments are sign-extended if their size is narrower than XLEN, so pointers
passed as arguments would always require an extra zero-extension IF we don't
change the calling convention.
The medlow memory model becomes useless, as address generation would require
an extra zero-extension (e.g., lui, addi → lui, addi, zext), and accessing
global objects would also need an extra code sequence (e.g., lui, lw →
lui, addi, zext, lw).
No C.LWU, as @guoren83 mentioned.

And one Linux-specific question for rv64ilp32 with a 2G restriction: Where is
the address range for placing the vDSO? Does it also go in the lower 2G?

It sounds like we might go down a path of doing the easier, and more code-size-efficient, 2 GiB thing.  We could always do the 4 GiB thing later as another ABI if we absolutely need to do so.

Limiting the address space to just 2G may cause Asan to not work well. Asan consumes a lot of virtual memory space, so having the full 4G available, if possible, would be ideal. Asan is a very popular modern memory debugging tool, and losing support for it would not be a good idea.

Linux user-mode rv32ilp32 only supports 2GiB with rv64lp64 Linux kernel (compat mode) and ~2.4GiB with rv32ilp32 Linux kernel (native mode). So, how did Asan support rv32ilp32, which only has 2~2.4 GiB address space?
ps:
Note the current rv64lp64 compat mode only supports (UXL=32 rv32ilp32 ABI) 2GiB address space, not 4GiB address space. AddressSanitizer (ASan) is relevant to all ILP32 ABIs, not just the 64ILP32 ABI.

Back to zero-extension vs. sign-extension, I would prefer sign-extension because both the ISA and psABI are sign-extension preferred. Here are some concrete examples:

Arguments are sign-extended if their size is narrower than XLEN, so pointers
passed as arguments would always require an extra zero-extension IF we don't
change the calling convention.
The medlow memory model becomes useless, as address generation would require
an extra zero-extension (e.g., lui, addi → lui, addi, zext), and accessing
global objects would also need an extra code sequence (e.g., lui, lw →
lui, addi, zext, lw).
No C.LWU, as @guoren83 mentioned.

And one Linux-specific question for rv64ilp32 with a 2G restriction: Where is the address range for placing the vDSO? Does it also go in the lower 2G?
It's the same as user-space rv32ilp32 ABI of rv64lp64 Linux kernel (compat mode with only 2GiB address space).

Limiting the address space to just 2G may cause Asan to not work well. Asan consumes a lot of virtual memory space, so having the full 4G available, if possible, would be ideal. Asan is a very popular modern memory debugging tool, and losing support for it would not be a good idea.

Linux user-mode rv32ilp32 only supports 2GiB with rv64lp64 Linux kernel (compat mode) and about 2.4GiB with rv32ilp32 Linux kernel (native mode). So, how did Asan support rv32ilp32, which only has 2~2.4 GiB address space?

It's never supported on upstream so honest I don't know, some T-head folks say they will upstream the support but I don't saw yet.
[1] https://lf-rise.atlassian.net/wiki/spaces/HOME/pages/8585550/DP_05_001+-+Address+Sanitizer

ps: Note the current rv64lp64 compat mode only supports (UXL=32 rv32ilp32 ABI) 2GiB address space, not 4GiB address space. AddressSanitizer (ASan) is relevant to all ILP32 ABIs, not just the 64ILP32 ABI.

I am not family with Linux kernel, so I am wondering does compat mode upstreamed?

Back to zero-extension vs. sign-extension, I would prefer sign-extension because both the ISA and psABI are sign-extension preferred. Here are some concrete examples:

Arguments are sign-extended if their size is narrower than XLEN, so pointers
passed as arguments would always require an extra zero-extension IF we don't
change the calling convention.
The medlow memory model becomes useless, as address generation would require
an extra zero-extension (e.g., lui, addi → lui, addi, zext), and accessing
global objects would also need an extra code sequence (e.g., lui, lw →
lui, addi, zext, lw).
No C.LWU, as @guoren83 mentioned.

And one Linux-specific question for rv64ilp32 with a 2G restriction: Where is the address range for placing the vDSO? Does it also go in the lower 2G?

It's the same as user-space rv32ilp32 ABI of rv64lp64 Linux kernel (compat mode with only 2GiB address space).

Could you explicitly explain that since I believe not every one is family with Linux kernel here including me.

Limiting the address space to just 2G may cause Asan to not work well. Asan consumes a lot of virtual memory space, so having the full 4G available, if possible, would be ideal. Asan is a very popular modern memory debugging tool, and losing support for it would not be a good idea.

Linux user-mode rv32ilp32 only supports 2GiB with rv64lp64 Linux kernel (compat mode) and about 2.4GiB with rv32ilp32 Linux kernel (native mode). So, how did Asan support rv32ilp32, which only has 2~2.4 GiB address space?

It's never supported on upstream so honest I don't know, some T-head folks say they will upstream the support but I don't saw yet.
[1] https://lf-rise.atlassian.net/wiki/spaces/HOME/pages/8585550/DP_05_001+-+Address+Sanitizer
Thx for mentioning. @joshua-arch1 has contributed a 64-bit Asan riscv porting, and he will continue the work of a 32-bit Asan riscv port. As far as I know, @joshua-arch1 would use a 2GiB address space layout, which leaves the target program with 1.7GiB of address space because 64-bit Linux kernel compat mode only supports user 2GiB address space.

ps: Note the current rv64lp64 compat mode only supports (UXL=32 rv32ilp32 ABI) 2GiB address space, not 4GiB address space. AddressSanitizer (ASan) is relevant to all ILP32 ABIs, not just the 64ILP32 ABI.

I am not family with Linux kernel, so I am wondering does compat mode upstreamed?
Yes, compat mode has been upstreamed for two years.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/riscv/include/asm/compat.h

Back to zero-extension vs. sign-extension, I would prefer sign-extension because both the ISA and psABI are sign-extension preferred. Here are some concrete examples:

Arguments are sign-extended if their size is narrower than XLEN, so pointers
passed as arguments would always require an extra zero-extension IF we don't
change the calling convention.
The medlow memory model becomes useless, as address generation would require
an extra zero-extension (e.g., lui, addi → lui, addi, zext), and accessing
global objects would also need an extra code sequence (e.g., lui, lw →
lui, addi, zext, lw).
No C.LWU, as @guoren83 mentioned.

And one Linux-specific question for rv64ilp32 with a 2G restriction: Where is the address range for placing the vDSO? Does it also go in the lower 2G?

It's the same as user-space rv32ilp32 ABI of rv64lp64 Linux kernel (compat mode with only 2GiB address space).

Could you explicitly explain that since I believe not every one is family with Linux kernel here including me.

Here is the patch:
<EMAIL_ADDRESS>

This is generally LGTM as an experimental proposal, but I would like to defer the final approval to the next psABI meeting (time for next psABI meeting is not decide yet, will update once confirmed)

Although it’s experimental, as it’s a big enough feature that could be hard to change later down the line I’d like to comb through it myself after the holidays and wait for others to give more feedback.


Zooming in or out is affecting custom title bar too.

VSCode Version: 1.28.1
OS Version: Windows 7 x64

Steps to Reproduce:

Zoom in or out
=> Problem : the title bar is affected.

Does this issue occur when all extensions are disabled?: Yes
It's probably not exactly a bug as i suppose it's the default behavior of Chromium zoom.
Perhaps it is working as intended, but, it's making custom title bar design inconsistent with other Windows app, and also with native title-bar mode, maybe on Linux and MacOS too.
In the other hand it certainly can be useful to zoom title-bar from an accessibility perspective. However , maybe it could be more consistent to make the zoom of the title bar managed by the OS accessibility options.

@Guema this is the intended behavior. the menu bar should be zoomable for accessibility reasons and so we zoom the titlebar. similar to scaling windows in the system display options. if you, however, do not use the menu bar and don't want it to zoom the titlebar, you can set window.menuBarVisibility to hidden and the title bar will not zoom with the rest of the UI.


Support Local Health Checks for OPAL Server

The issue:
When deploying permitio/opal-server container in ECS Fargate as a service, the task definition provides the abillity to set up a health check. The simplist way to do this would be: curl -f http://localhost:7002/healthcheck || exit 1.  When I run this command in the container I get: /bin/sh: 1: curl: Permission denied.  When I do the exact same setup for the permitio/opal-client container (with the change in port to 7000) and run it, the curl command works as expected.
The proposed solution:
Add the curl package to the permitio/opal-server image.
Testing

made the change to the docker file
ran make docker-build-server
ran make docker-run-server
In the shell for the container run curl http://localhost:7002/healthcheck and verify a 200 status code is returned

@asafc @orishavit can you take a look here :)


xds: add flag for istio_authn

Signed-off-by: Kuat Yessenov<EMAIL_ADDRESS>This supports custom Envoy builds without Istio filters.

@kyessenov: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
6bd72cf4486fbb17bb7dad451c618c02ece8d958
link
true
/test release-notes

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@hzxuzhonghu I'd agree but we already do for MX, ALPN, etc. It's not easy to modify control plane at source level without a top level flag like this.

What about:

1 env var with a CSV list of "optional filters". Default is none
parse node.Extensions
When we insert filters, replace filter = append(... with filters = proxy.AppendFilter(... which checks if it is present+optional

Obviously we cannot make all filters optional but most should be ok. This would be minimal maintaince overhead and maximize flexibility. WDYT?
Since I am scope creeping this a lot, I'd be happy to take on some of the work if you want

Closing for more internal discussions. I don't think this is really about complex scenarios, intended users are aware of theissues caused by lack of filters and are OK with it.

I don't think you should close it - it is a very good and useful change.
Just not 'pilot-wide' - instead should be based on a setting in the node
meta ( not negotiation,
but explicit user intent to not generate the filters )
On Fri, Jan 20, 2023 at 10:21 AM Kuat @.***> wrote:

Closing for more internal discussions. I don't think this is really about
complex scenarios, intended users are aware of the issues caused by the
lack of filters and are OK with it.
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/42904#issuecomment-1398770445, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAUR2TV4RJSCASGCKKYQEDWTLJS3ANCNFSM6AAAAAAUA2AT5I
.
You are receiving this because your review was requested.Message ID:
@.***>

Is ther a use where a client will want to have the filter compiled in but not use it? If not, then using Node.Extensions seems to be the "client" part of it? If there is a use case, its not clear to me

Not sure about use case - my concern is that 'node extension' is a pretty
poor API and too envoy specific.
Authn is an Istio feature - we have a lot of other Istio features that may
be turned on or off, some may be envoy specifc and others may work with
ztunnel or other
implementations, the Istio API is not tied to envoy.
And envoy has a mechanism to report its compile options and filters on
every connection. That may be useful for an envoy-specific API and control
plane, we may
check if the filter is there - but I don't think "Image happens to be
compiled in a specific way" is the right way to express user intent about
enabling or not an Istio feature.
As for use case - I think we should start to give users ability to control
which Istio features are enabled in their mesh. Starting with EnvoyFilter,
of course - but also
'permissive', non-beta APIs, etc. In this case 'upstream envoy' feature
would allow non-istio build of envoy to be used in the mesh - which seems
reasonable as long
as user confirms somehow it's by intent and not accident.
On Fri, Jan 20, 2023 at 12:34 PM John Howard @.***>
wrote:

Is ther a use where a client will want to have the filter compiled in but
not use it? If not, then using Node.Extensions seems to be the "client"
part of it? If there is a use case, its not clear to me
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/42904#issuecomment-1398904486, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAUR2VPTL4YW4FAPJM3RYLWTLZFLANCNFSM6AAAAAAUA2AT5I
.
You are receiving this because your review was requested.Message ID:
@.***>

@kyessenov: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-ambient_istio
6bd72cf4486fbb17bb7dad451c618c02ece8d958
link
true
/test integ-ambient

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@kyessenov: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-ambient_istio
6bd72cf4486fbb17bb7dad451c618c02ece8d958
link
true
/test integ-ambient

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Use %USERPROFILE% instead of $HOME for windows setup

Closes #58

Just to let you know, you can always directly merge in minor changes. Different reviews and opinions are needed only for major/core changes.

Afaik this repository still requires PRs to be review-approved before I can merge them.

Thanks for the reviews btw.
I also thought that it would okay to not take up so much of your time you with the minor changes, but since permissions changed before I thought it's the way it should be.

All repos settings are updated now.


fix(jsregexp): fix install_jsregexp on Windows

Users on Windows may install neovim by many means:

scoop install neovim: which nvim shows ~/scoop/shims/nvim
winget install neovim or manually download Windows installer and set env: which nvim shows C:/Program Files/Neovim/bin/nvim

Either way, we can use lua51.dll in the original nvim directory ($(scoop prefix neovim)/bin or C:/Program Files/Neovim/bin/nvim)
Care must be taken when path contains spaces. Quotes are needed to let gcc understand L"C:/Program Files/..." such directories.

[!NOTE]
Users may also need to set:
SHELL=C:/path/to/Git/usr/bin/sh.exe # if git sh.exe is not in PATH
.SHELLFLAGS=-c # if git sh.exe is not in PATH
CC=gcc # if default cc is not set to any compiler
NEOVIM_BIN_PATH=C:/path/to/Neovim/bin # if Neovim/bin is not detected by the Makefile

Related: #759 #986 #1130 #1190 #1220

I am not sure if the failing test was due to timeout or snippet file not being saved before running the test case. Those failed snippets work on my local machine.

-------- Global test environment teardown.
======== 422 tests from 32 test files ran. (39879.00 ms total)
PASSED   417 tests.
FAILED   2 tests, listed below:
FAILED   ../../../tests/integration/session_spec.lua @ 1468: session All operations work as expected in a longer session.
../../../tests/integration/session_spec.lua:1857: Row 2 did not match.
Expected:
  |/**                                               |
  |* * A /**                                          |
  |*  * A short Description                           |
  |*  */                                              |
  |* ^public void myFunc() { {4:●}                         |
  |*                                                  |
  |* }short Description                               |
  | /**                                              |
  |  * A short Description                           |
  |  */                                              |
  | public void myFunc() {                           |
  |                                                  |
  | }*/                                              |
  |public void myFunc() {                            |
  |                                                  |
  |}                                                 |
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |*{2:-- INSERT --}                                      |
Actual:
  |/**                                               |
  |* * ^A{3: /**}                                          |
  |*{3:  * A short Description}                           |
  |*{3:  */}                                              |
  |*{3: public void myFunc() {} {4:●}                         |
  |*{3:        }                                          |
  |*{3: }short Description}                               |
  | /**                                              |
  |  * A short Description                           |
  |  */                                              |
  | public void myFunc() {                           |
  |                                                  |
  | }*/                                              |
  |public void myFunc() {                            |
  |                                                  |
  |}                                                 |
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |{0:~                                                 }|
  |*{2:-- SELECT --}                                      |
To print the expect() call that would assert the current screen state, use
screen:snapshot_util(). In case of non-deterministic failures, use
screen:redraw_debug() to show all intermediate screen states.
Snapshot:
screen:expect({
  grid = [[
    /**                                               |
     * ^A{3: /**}                                          |
    {3:  * A short Description}                           |
    {3:  */}                                              |
    {3: public void myFunc() {} {4:●}                         |
    {3:        }                                          |
    {3: }short Description}                               |
     /**                                              |
      * A short Description                           |
      */                                              |
     public void myFunc() {                           |
                                                      |
     }*/                                              |
    public void myFunc() {                            |
                                                      |
    }                                                 |
    {0:~                                                 }|*13
    {2:-- SELECT --}                                      |
  ]]
})
stack traceback:
	test/functional/ui/screen.lua:851: in function '_wait'
	test/functional/ui/screen.lua:527: in function 'expect'
	../../../tests/integration/session_spec.lua:1857: in function <../../../tests/integration/session_spec.lua:1468>
FAILED   ../../../tests/integration/source_spec.lua @ 61: loaders: vscode: error-message when parser not installed.
../../../tests/integration/source_spec.lua:85: Row 8 did not match.
Expected:
  |^{                                                 |
  |        "snip1": {                                |
  |                "prefix": "all1",                 |
  |                "body": [                         |
  |                        "expands? jumps? $1 $2 !" |
  |                ]                                 |
  |        },                                        |
  |*Could not determine ran...help treesitter-parsers |
Actual:
  |^{                                                 |
  |        "snip1": {                                |
  |                "prefix": "all1",                 |
  |                "body": [                         |
  |                        "expands? jumps? $1 $2 !" |
  |                ]                                 |
  |        },                                        |
  |*Could not determine ran...r 2 and language "json" |
To print the expect() call that would assert the current screen state, use
screen:snapshot_util(). In case of non-deterministic failures, use
screen:redraw_debug() to show all intermediate screen states.
Snapshot:
screen:expect({
  grid = [[
    ^{                                                 |
            "snip1": {                                |
                    "prefix": "all1",                 |
                    "body": [                         |
                            "expands? jumps? $1 $2 !" |
                    ]                                 |
            },                                        |
    Could not determine ran...r 2 and language "json" |
  ]]
})
stack traceback:
	test/functional/ui/screen.lua:851: in function '_wait'
	test/functional/ui/screen.lua:527: in function 'expect'
	../../../tests/integration/source_spec.lua:85: in function <../../../tests/integration/source_spec.lua:61>
ERROR    3 errors, listed below:
ERROR    ../../../tests/integration/treesitter_postfix_spec.lua @ 27: treesitter-postfix Default-case works ["live"]
test/functional/testnvim.lua:126: Error executing lua: .../work/LuaSnip/LuaSnip/lua/luasnip/extras/_treesitter.lua:333: attempt to call method 'range' (a nil value)
stack traceback:
	.../work/LuaSnip/LuaSnip/lua/luasnip/extras/_treesitter.lua:333: in function 'match_tsnode'
	...uaSnip/LuaSnip/lua/luasnip/extras/treesitter_postfix.lua:155: in function 'real_resolver'
	...uaSnip/LuaSnip/lua/luasnip/extras/treesitter_postfix.lua:111: in function 'user_resolve'
	...unner/work/LuaSnip/LuaSnip/lua/luasnip/nodes/snippet.lua:38: in function 'resolveExpandParams'
	...unner/work/LuaSnip/LuaSnip/lua/luasnip/nodes/snippet.lua:814: in function 'matches'
	.../LuaSnip/lua/luasnip/session/snippet_collection/init.lua:158: in function 'match_snippet'
	/home/runner/work/LuaSnip/LuaSnip/lua/luasnip/init.lua:334: in function 'expand'
	[string "<nvim>"]:1: in main chunk
stack traceback:
	test/functional/testnvim.lua:126: in function 'exec_lua'
	../../../tests/integration/treesitter_postfix_spec.lua:92: in function <../../../tests/integration/treesitter_postfix_spec.lua:27>
ERROR    ../../../tests/integration/treesitter_postfix_spec.lua @ 27: treesitter-postfix Default-case works ["copy"]
test/functional/testnvim.lua:126: Error executing lua: .../work/LuaSnip/LuaSnip/lua/luasnip/extras/_treesitter.lua:333: attempt to call method 'range' (a nil value)
stack traceback:
	.../work/LuaSnip/LuaSnip/lua/luasnip/extras/_treesitter.lua:333: in function 'match_tsnode'
	...uaSnip/LuaSnip/lua/luasnip/extras/treesitter_postfix.lua:155: in function 'real_resolver'
	...uaSnip/LuaSnip/lua/luasnip/extras/treesitter_postfix.lua:111: in function 'user_resolve'
	...unner/work/LuaSnip/LuaSnip/lua/luasnip/nodes/snippet.lua:38: in function 'resolveExpandParams'
	...unner/work/LuaSnip/LuaSnip/lua/luasnip/nodes/snippet.lua:814: in function 'matches'
	.../LuaSnip/lua/luasnip/session/snippet_collection/init.lua:158: in function 'match_snippet'
	/home/runner/work/LuaSnip/LuaSnip/lua/luasnip/init.lua:334: in function 'expand'
	[string "<nvim>"]:1: in main chunk
stack traceback:
	test/functional/testnvim.lua:126: in function 'exec_lua'
	../../../tests/integration/treesitter_postfix_spec.lua:92: in function <../../../tests/integration/treesitter_postfix_spec.lua:27>
ERROR    ../../../tests/integration/treesitter_postfix_spec.lua @ 27: treesitter-postfix Default-case works [nil]
test/functional/testnvim.lua:126: Error executing lua: .../work/LuaSnip/LuaSnip/lua/luasnip/extras/_treesitter.lua:333: attempt to call method 'range' (a nil value)
stack traceback:
	.../work/LuaSnip/LuaSnip/lua/luasnip/extras/_treesitter.lua:333: in function 'match_tsnode'
	...uaSnip/LuaSnip/lua/luasnip/extras/treesitter_postfix.lua:155: in function 'real_resolver'
	...uaSnip/LuaSnip/lua/luasnip/extras/treesitter_postfix.lua:111: in function 'user_resolve'
	...unner/work/LuaSnip/LuaSnip/lua/luasnip/nodes/snippet.lua:38: in function 'resolveExpandParams'
	...unner/work/LuaSnip/LuaSnip/lua/luasnip/nodes/snippet.lua:814: in function 'matches'
	.../LuaSnip/lua/luasnip/session/snippet_collection/init.lua:158: in function 'match_snippet'
	/home/runner/work/LuaSnip/LuaSnip/lua/luasnip/init.lua:334: in function 'expand'
	[string "<nvim>"]:1: in main chunk
stack traceback:
	test/functional/testnvim.lua:126: in function 'exec_lua'
	../../../tests/integration/treesitter_postfix_spec.lua:92: in function <../../../tests/integration/treesitter_postfix_spec.lua:27>
 2 FAILED TESTS
 3 ERRORS
------------------------------------------------------------------------------
$NVIM_LOG_FILE: /home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/build/.nvimlog
(last 100 lines)
DBG 2024-11-10T19:24:25.822 nvim.41508.0 log_request:46: RPC <- 1: [request]   id=1: nvim_exec_lua
DBG 2024-11-10T19:24:25.822 nvim.41508.0 handle_request:346: RPC: scheduled nvim_exec_lua
DBG 2024-11-10T19:24:25.822 nvim.41508.0 state_enter:99: input: K_EVENT
DBG 2024-11-10T19:24:25.822 nvim.41508.0 handle_nvim_exec_lua:7203: RPC: ch 1: invoke nvim_exec_lua
DBG 2024-11-10T19:24:25.823 nvim.41508.0 log_response:51: RPC -> 1: [response]  id=1
DBG 2024-11-10T19:24:25.823 nvim.41508.0 may_trigger_safestate:301: SafeState: Start triggering
DBG 2024-11-10T19:24:25.823 nvim.41508.0 inbuf_poll:512: blocking... events=false
DBG 2024-11-10T19:24:25.823 nvim.41508.0 inbuf_poll:512: blocking... events=true
DBG 2024-11-10T19:24:25.823 nvim.41508.0 receive_msgpack:206: ch 1: parsing 210 bytes from msgpack Stream: 0x5634c4183540
DBG 2024-11-10T19:24:25.823 nvim.41508.0 log_request:46: RPC <- 1: [request]   id=2: nvim_exec_lua
DBG 2024-11-10T19:24:25.823 nvim.41508.0 handle_request:346: RPC: scheduled nvim_exec_lua
DBG 2024-11-10T19:24:25.823 nvim.41508.0 state_enter:99: input: K_EVENT
DBG 2024-11-10T19:24:25.823 nvim.41508.0 handle_nvim_exec_lua:7203: RPC: ch 1: invoke nvim_exec_lua
DBG 2024-11-10T19:24:25.823 nvim.41508.0 log_response:51: RPC -> 1: [response]  id=2
DBG 2024-11-10T19:24:25.823 nvim.41508.0 may_trigger_safestate:301: SafeState: Start triggering
DBG 2024-11-10T19:24:25.823 nvim.41508.0 inbuf_poll:512: blocking... events=false
DBG 2024-11-10T19:24:25.823 nvim.41508.0 inbuf_poll:512: blocking... events=true
DBG 2024-11-10T19:24:25.824 nvim.41508.0 receive_msgpack:206: ch 1: parsing 194 bytes from msgpack Stream: 0x5634c4183540
DBG 2024-11-10T19:24:25.824 nvim.41508.0 log_request:46: RPC <- 1: [request]   id=3: nvim_exec_lua
DBG 2024-11-10T19:24:25.824 nvim.41508.0 handle_request:346: RPC: scheduled nvim_exec_lua
DBG 2024-11-10T19:24:25.824 nvim.41508.0 state_enter:99: input: K_EVENT
DBG 2024-11-10T19:24:25.824 nvim.41508.0 handle_nvim_exec_lua:7203: RPC: ch 1: invoke nvim_exec_lua
DBG 2024-11-10T19:24:25.824 nvim.41508.0 log_response:51: RPC -> 1: [response]  id=3
DBG 2024-11-10T19:24:25.824 nvim.41508.0 may_trigger_safestate:301: SafeState: Start triggering
DBG 2024-11-10T19:24:25.824 nvim.41508.0 inbuf_poll:512: blocking... events=false
DBG 2024-11-10T19:24:25.824 nvim.41508.0 inbuf_poll:512: blocking... events=true
DBG 2024-11-10T19:24:25.824 nvim.41508.0 receive_msgpack:206: ch 1: parsing 199 bytes from msgpack Stream: 0x5634c4183540
DBG 2024-11-10T19:24:25.824 nvim.41508.0 log_request:46: RPC <- 1: [request]   id=4: nvim_exec_lua
DBG 2024-11-10T19:24:25.824 nvim.41508.0 handle_request:346: RPC: scheduled nvim_exec_lua
DBG 2024-11-10T19:24:25.824 nvim.41508.0 state_enter:99: input: K_EVENT
DBG 2024-11-10T19:24:25.824 nvim.41508.0 handle_nvim_exec_lua:7203: RPC: ch 1: invoke nvim_exec_lua
DBG 2024-11-10T19:24:25.824 nvim.41508.0 log_response:51: RPC -> 1: [response]  id=4
DBG 2024-11-10T19:24:25.824 nvim.41508.0 may_trigger_safestate:301: SafeState: Start triggering
DBG 2024-11-10T19:24:25.824 nvim.41508.0 inbuf_poll:512: blocking... events=false
DBG 2024-11-10T19:24:25.824 nvim.41508.0 inbuf_poll:512: blocking... events=true
DBG 2024-11-10T19:24:25.824 nvim.41508.0 receive_msgpack:206: ch 1: parsing 201 bytes from msgpack Stream: 0x5634c4183540
DBG 2024-11-10T19:24:25.824 nvim.41508.0 log_request:46: RPC <- 1: [request]   id=5: nvim_exec_lua
DBG 2024-11-10T19:24:25.824 nvim.41508.0 handle_request:346: RPC: scheduled nvim_exec_lua
DBG 2024-11-10T19:24:25.824 nvim.41508.0 state_enter:99: input: K_EVENT
DBG 2024-11-10T19:24:25.824 nvim.41508.0 handle_nvim_exec_lua:7203: RPC: ch 1: invoke nvim_exec_lua
DBG 2024-11-10T19:24:25.824 nvim.41508.0 log_response:51: RPC -> 1: [response]  id=5
DBG 2024-11-10T19:24:25.824 nvim.41508.0 may_trigger_safestate:301: SafeState: Start triggering
DBG 2024-11-10T19:24:25.824 nvim.41508.0 inbuf_poll:512: blocking... events=false
DBG 2024-11-10T19:24:25.825 nvim.41508.0 inbuf_poll:512: blocking... events=true
DBG 2024-11-10T19:24:25.826 nvim.41508.0 read_cb:121: closing Stream (0x5634c4183540): EOF (end of file)
DBG 2024-11-10T19:24:25.826 nvim.41508.0 receive_msgpack:206: ch 1: parsing 0 bytes from msgpack Stream: 0x5634c4183540
DBG 2024-11-10T19:24:25.826 nvim.41508.0 stream_may_close:107: closing Stream: 0x5634c4183540
DBG 2024-11-10T19:24:25.826 nvim.41508.0 stream_may_close:107: closing Stream: 0x5634c41836f8
INF 2024-11-10T19:24:25.826 nvim.41508.0 chan_close_with_error:508: RPC: ch 1 was closed by the client
INF 2024-11-10T19:24:25.826 nvim.41508.0 os_exit:693: Nvim exit: 1
DBG 2024-11-10T19:24:25.829 ?.41509    rpc_start:90: rpc ch 1 in-stream=0x55872688d6f8 out-stream=0x55872688d540
INF 2024-11-10T19:24:25.829 nvim.41509.0 set_init_2:595: startup runtimepath/packpath value: /home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/build/Xtest_xdg/config/nvim,/etc/xdg/nvim,/home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/build/Xtest_xdg/share/nvim/site,/usr/local/share/nvim/site,/usr/share/nvim/site,/home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/runtime,/home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/build/lib/nvim,/usr/share/nvim/site/after,/usr/local/share/nvim/site/after,/home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/build/Xtest_xdg/share/nvim/site/after,/etc/xdg/nvim/after,/home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/build/Xtest_xdg/config/nvim/after
DBG 2024-11-10T19:24:25.832 nvim.41509.0 receive_msgpack:206: ch 1: parsing 60 bytes from msgpack Stream: 0x55872688d540
DBG 2024-11-10T19:24:25.832 nvim.41509.0 log_request:46: RPC <- 1: [request]   id=0: nvim_exec2
DBG 2024-11-10T19:24:25.832 nvim.41509.0 handle_request:346: RPC: scheduled nvim_exec2
INF 2024-11-10T19:24:25.832 nvim.41509.0 main:657: starting main loop
DBG 2024-11-10T19:24:25.832 nvim.41509.0 may_trigger_safestate:301: SafeState: Start triggering
DBG 2024-11-10T19:24:25.832 nvim.41509.0 inbuf_poll:512: blocking... events=false
DBG 2024-11-10T19:24:25.832 nvim.41509.0 state_enter:99: input: K_EVENT
DBG 2024-11-10T19:24:25.832 nvim.41509.0 handle_nvim_exec2:9583: RPC: ch 1: invoke nvim_exec2
DBG 2024-11-10T19:24:25.832 nvim.41509.0 log_response:51: RPC -> 1: [response]  id=0
DBG 2024-11-10T19:24:25.832 nvim.41509.0 may_trigger_safestate:301: SafeState: Start triggering
DBG 2024-11-10T19:24:25.832 nvim.41509.0 inbuf_poll:512: blocking... events=false
DBG 2024-11-10T19:24:25.832 nvim.41509.0 inbuf_poll:512: blocking... events=true
DBG 2024-11-10T19:24:25.833 nvim.41509.0 receive_msgpack:206: ch 1: parsing 74 bytes from msgpack Stream: 0x55872688d540
DBG 2024-11-10T19:24:25.833 nvim.41509.0 log_request:46: RPC <- 1: [request]   id=1: nvim_exec_lua
DBG 2024-11-10T19:24:25.833 nvim.41509.0 handle_request:346: RPC: scheduled nvim_exec_lua
DBG 2024-11-10T19:24:25.833 nvim.41509.0 state_enter:99: input: K_EVENT
DBG 2024-11-10T19:24:25.833 nvim.41509.0 handle_nvim_exec_lua:7203: RPC: ch 1: invoke nvim_exec_lua
DBG 2024-11-10T19:24:25.833 nvim.41509.0 log_response:51: RPC -> 1: [response]  id=1
DBG 2024-11-10T19:24:25.833 nvim.41509.0 may_trigger_safestate:301: SafeState: Start triggering
DBG 2024-11-10T19:24:25.833 nvim.41509.0 inbuf_poll:512: blocking... events=false
DBG 2024-11-10T19:24:25.833 nvim.41509.0 inbuf_poll:512: blocking... events=true
DBG 2024-11-10T19:24:25.834 nvim.41509.0 receive_msgpack:206: ch 1: parsing 77 bytes from msgpack Stream: 0x55872688d540
DBG 2024-11-10T19:24:25.834 nvim.41509.0 log_request:46: RPC <- 1: [request]   id=2: nvim_exec_lua
DBG 2024-11-10T19:24:25.834 nvim.41509.0 handle_request:346: RPC: scheduled nvim_exec_lua
DBG 2024-11-10T19:24:25.834 nvim.41509.0 state_enter:99: input: K_EVENT
DBG 2024-11-10T19:24:25.834 nvim.41509.0 handle_nvim_exec_lua:7203: RPC: ch 1: invoke nvim_exec_lua
DBG 2024-11-10T19:24:25.834 nvim.41509.0 log_response:51: RPC -> 1: [response]  id=2
DBG 2024-11-10T19:24:25.834 nvim.41509.0 may_trigger_safestate:301: SafeState: Start triggering
DBG 2024-11-10T19:24:25.834 nvim.41509.0 inbuf_poll:512: blocking... events=false
DBG 2024-11-10T19:24:25.834 nvim.41509.0 inbuf_poll:512: blocking... events=true
DBG 2024-11-10T19:24:25.834 nvim.41509.0 receive_msgpack:206: ch 1: parsing 78 bytes from msgpack Stream: 0x55872688d540
DBG 2024-11-10T19:24:25.834 nvim.41509.0 log_request:46: RPC <- 1: [request]   id=3: nvim_exec_lua
DBG 2024-11-10T19:24:25.834 nvim.41509.0 handle_request:346: RPC: scheduled nvim_exec_lua
DBG 2024-11-10T19:24:25.834 nvim.41509.0 state_enter:99: input: K_EVENT
DBG 2024-11-10T19:24:25.834 nvim.41509.0 handle_nvim_exec_lua:7203: RPC: ch 1: invoke nvim_exec_lua
DBG 2024-11-10T19:24:25.834 nvim.41509.0 log_response:51: RPC -> 1: [response]  id=3
DBG 2024-11-10T19:24:25.834 nvim.41509.0 may_trigger_safestate:301: SafeState: Start triggering
DBG 2024-11-10T19:24:25.834 nvim.41509.0 inbuf_poll:512: blocking... events=false
DBG 2024-11-10T19:24:25.834 nvim.41509.0 inbuf_poll:512: blocking... events=true
DBG 2024-11-10T19:24:25.834 nvim.41509.0 receive_msgpack:206: ch 1: parsing 79 bytes from msgpack Stream: 0x55872688d540
DBG 2024-11-10T19:24:25.834 nvim.41509.0 log_request:46: RPC <- 1: [request]   id=4: nvim_exec_lua
DBG 2024-11-10T19:24:25.834 nvim.41509.0 handle_request:346: RPC: scheduled nvim_exec_lua
DBG 2024-11-10T19:24:25.834 nvim.41509.0 state_enter:99: input: K_EVENT
DBG 2024-11-10T19:24:25.834 nvim.41509.0 handle_nvim_exec_lua:7203: RPC: ch 1: invoke nvim_exec_lua
DBG 2024-11-10T19:24:25.834 nvim.41509.0 log_response:51: RPC -> 1: [response]  id=4
DBG 2024-11-10T19:24:25.834 nvim.41509.0 may_trigger_safestate:301: SafeState: Start triggering
DBG 2024-11-10T19:24:25.835 nvim.41509.0 inbuf_poll:512: blocking... events=false
DBG 2024-11-10T19:24:25.835 nvim.41509.0 inbuf_poll:512: blocking... events=true
------------------------------------------------------------------------------
CMake Error at /home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/cmake/RunTests.cmake:103 (message):
  functional tests failed with error: 1
make[1]: *** [Makefile:132: functionaltest] Error 1
make: *** [Makefile:98: test] Error 2
-- Tests exited non-zero: 1
-- Output to stderr:
E5113: Error while calling lua chunk:
FAILED: test/CMakeFiles/functionaltest /home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/build/test/CMakeFiles/functionaltest
cd /home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/build/test && /usr/local/bin/cmake -D TEST_TYPE=functional -D BUILD_DIR=/home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/build -D CIRRUS_CI= -D CI_BUILD=OFF -D DEPS_INSTALL_DIR=/home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/build/usr -D NVIM_PRG=/home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/build/bin/nvim -D TEST_DIR=/home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/test -D WORKING_DIR=/home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master -P /home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master/cmake/RunTests.cmake
ninja: build stopped: subcommand failed.
make[1]: Leaving directory '/home/runner/work/LuaSnip/LuaSnip/deps/nvim_multiversion/worktree_master'
Error: Process completed with exit code 2.

Hey, thanks for this PR, I don't have Windows currently, so that's a great help :)
The failing tests should be largely fixed by commits to luasnip-master that are missing in your branch, could you rebase?

Hey, thanks for this PR, I don't have Windows currently, so that's a great help :) The failing tests should be largely fixed by commits to luasnip-master that are missing in your branch, could you rebase?

Oh, I forgot that my origin master was too old. Thanks for pointing that out.

@L3MON4D3 tests passes after rebasing.

These changes look really good (shell pwd -> $(PROJECT_ROOT) :ok_hand:), and TY for mentioning the necessary steps for windows-users in the README :ok_hand:
If you could satisfy my curiosity regarding the && false (just so I understand that quirk :D), I'll be happy to merge :)

These changes look really good (shell pwd -> $(PROJECT_ROOT) 👌), and TY for mentioning the necessary steps for windows-users in the README 👌
If you could satisfy my curiosity regarding the && false (just so I understand that quirk :D), I'll be happy to merge :)

I took the && false trick from a stackoverflow comment. I also encountered empty outputs from LUASNIP_DETECTED_OS?=$(shell uname) and PROJECT_ROOT:=$(shell pwd). Running make outputs:
process_begin: CreateProcess(NULL, uname, ...) failed.
Makefile:45: pipe: Bad file descriptor
...

Initially, I thought this is a make's bug on non-bash shells (powershell fails, but git bash works). I also tested with $(shell uname 2>/dev/null), which works on both like the trick.
I believe it's better to use 2>/dev/null to redirect stderr, which also outputs $(shell command) successfully.

@xudyang1 I don't know why my windows machine still builds fail. Here's the building log from Lazy
make: *** No rule to make target 'install_jsregexp'.  Stop.

My Lazy config
{
  "L3MON4D3/LuaSnip",
  dependencies = "rafamadriz/friendly-snippets",
  build = vim.g.os == "Windows" and "make install_jsregexp CC=gcc.exe SHELL=sh.exe .SHELLFLAGS=-c"
    or "make install_jsregexp",
}

LazyNvim support luarocks and jsregexp is installed via luarocks. I guess we can config like this (just guessing...)
{
  "L3MON4D3/LuaSnip",
  dependencies = {
    "rafamadriz/friendly-snippets",
    "kmarius/jsregexp",
  },
}

@KevinNitroG It did not work for me, LuaSnip still complains that jsregexp is not installed, even though lazy installed jsregexp successfully.

@KevinNitroG It did not work for me, LuaSnip still complains that jsregexp is not installed, even though lazy installed jsregexp successfully.

I don't know how to check have LuaSnip recognized jsregexp installed... How can we do that?

@KevinNitroG just execute :checkhealth in neovim and go to luaSnip.

@xudyang1 sh.exe (git) doesn't recognize uname command when the build happens.


"Achieve an S- rank on all levels" achievements are unlocking prematurely

After completing a single level with the grade "AA", the "Truly Lemondary" achievement unlocked.

I investigated the achievement but it appears to be working properly, and the achievements for later chapters show "88%/95%" as would be expected
I'll follow up with other playtesters to see if I can get a lead on it, but for now as this only seems to affect a single person, I'm downgrading this to a priority 4. ...Maybe their CPU is just really bad at division?

They sent me some game logs which have these messages:
[STEAM] Setting Steam stat: CHAPTER_3_RANK_S_PERCENT -> 6.25
[STEAM] Getting Steam stat: CHAPTER_3_RANK_S_PERCENT
[STEAM] get_stat_float(CHAPTER_3_RANK_S_PERCENT) response:<PHONE_NUMBER>32960332447744
[STEAM] setStatFloat(CHAPTER_3_RANK_S_PERCENT, 6.25) response: False

https://github.com/Poobslag/turbofat/pull/2724
I've added a sanity check for the set_stat Steam call, although this seems tangentially related to this bug. Regardless of what Steam thinks their percent complete is, we divide two numbers and check whether the result is equal to 1.0. Even if we did something boneheaded like divide by zero, the result wouldn't be equal to 1.0, and the achievement would not be set. I'm still unsure what could cause this bug.

godot(1).log
Here is a log file from someone's game where this bug happened. The achievement is unset, we set the CHAPTER_1_RANK_S_PERCENT to True, and then the achievement is mysteriously set.

godot(1).log
This is still happening, even with the standalone GodotSteam.
[STEAM] getAchievement(BASIC_TUTORIAL) response: {achieved:True, ret:True}
[STEAM] Getting Steam achievement: CHAPTER_1_RANK_S
[STEAM] getAchievement(CHAPTER_1_RANK_S) response: {achieved:False, ret:True}
[STEAM] Getting Steam achievement: CHAPTER_2_RANK_S
[STEAM] getAchievement(CHAPTER_2_RANK_S) response: {achieved:False, ret:True}
[STEAM] Getting Steam achievement: CHAPTER_3_RANK_S
[STEAM] getAchievement(CHAPTER_3_RANK_S) response: {achieved:False, ret:True}
[STEAM] Getting Steam achievement: CHAPTER_4_RANK_S
[STEAM] getAchievement(CHAPTER_4_RANK_S) response: {achieved:False, ret:True}
[STEAM] Getting Steam achievement: CHAPTER_5_RANK_S
[STEAM] getAchievement(CHAPTER_5_RANK_S) response: {achieved:False, ret:True}
[STEAM] Getting Steam achievement: CHAPTER_6_RANK_S
[STEAM] getAchievement(CHAPTER_6_RANK_S) response: {achieved:False, ret:True}
[STEAM] Getting Steam stat: CHAPTER_1_RANK_S_PERCENT
[STEAM] getStatFloat(CHAPTER_1_RANK_S_PERCENT) response: 0
[STEAM] Setting Steam stat: CHAPTER_1_RANK_S_PERCENT -> 7.142857
[STEAM] setStatFloat(CHAPTER_1_RANK_S_PERCENT, 7.142857) response: True
[STEAM] Storing stats
[STEAM] storeStats response: True
[STEAM] Getting Steam achievement: CREATE_CREATURE
[STEAM] getAchievement(CREATE_CREATURE) response: {achieved:True, ret:True}
[STEAM] Getting Steam stat: CHAPTER_1_STORY_PERCENT
[STEAM] getStatFloat(CHAPTER_1_STORY_PERCENT) response: 0
[STEAM] Setting Steam stat: CHAPTER_1_STORY_PERCENT -> 10
[STEAM] setStatFloat(CHAPTER_1_STORY_PERCENT, 10) response: True
[STEAM] Storing stats
[STEAM] storeStats response: True
[STEAM] Getting Steam achievement: BASIC_TUTORIAL
[STEAM] getAchievement(BASIC_TUTORIAL) response: {achieved:True, ret:True}
[STEAM] Getting Steam achievement: CHAPTER_1_RANK_S

We never call set_achievement; so it is some sort of unusual conflict between setStatFloat, getStatFloat, storeStats and getAchievement which causes the achievement to be set.

I've tried duplicating this on my PC both with the exported .exe and through the Steam client. I've also tried duplicating it on my Lenovo laptop. In all cases, the achievements unlock correctly. This issue appears to only affect some users.

https://forums.unrealengine.com/t/how-to-update-steam-achievement-progress/366901/4
This appears to be a known issue with Steam, where setting progress stats randomly unlocks the associated achievements. There is no workaround.

I've disabled all progress stats through Steam. The stats still exist, but are not linked to any achievements.
It's possible replacing them with ints would work around the issue, we can experiment with that after the release when we have more time.


ENTSWM-220 + Arquillian testing for WFS

As we include the information about the users having to include commons-logging in the Release Notes, we should have it in the main docs as well. In the upstream, the warning is included in the Testing in container chapter. I believe the chapter in question is ready style-wise, but please check the entire file for factual aspects. Thank you.

So this is essentially upstream sync + one line to include some content in the WF Swarm guide? That LGTM :-)

merged: f5d0af7e176d450c4db9b873e52c164b6e5f9d5c