Add blocking notification to EditPage

This PR contributes towards Issue #3326.
This PR adds a notification to the EditPage which must be acknowledged before the brew itself will become editable.
EditPage:

MongoDB entry:

This covers the case of initially loading /edit/:id .. but what happens when an author has opened a non-locked brew, but that brew has since had the lock applied?

This can happen as authors do have a habit of opening a brew to edit and leaving it open in their browser for long periods of time (e.g. weeks).

Does this click-to-acknowledge persist? That is, having obtained edit access for this session, if they close the brew and later go to edit it again will they see this message again? Or does click-to-acknowledge update the mongo record for the brew (e.g. editor-ack: <some-date> .. I would recommend a  rather than simply true, btw).

That said, I'm not really sure how lax or strict we should be in this type of situation.

I think the question here is what is the locking function here to prevent? what type of content are we expecting to lock? confidential doc leaks? an alien cult manifesto? communist propaganda? (its a joke but you get what i mean).
It is a locking function, for content the user can rewrite or already has in their system. If the content of the brew is so bad it is deserving to lock the document, why not delete it entirely?
I understand the idea behind the locking, not so sure of its usefulness. Better to have it and not use it than need it and not have it, for sure.

I don't think we have any way to push notifications out like that without creating a live socket connection for every editing session, which adds some complexity. Something like that would be a whole separate project, but eventually that might be something we add.

We could throw the notification upon the first (auto)save of that brew, based on info received then.

That's a good point. Autosave creates regular periodic requests which could be used this way.

It is a locking function, for content the user can rewrite or already has in their system. If the content of the brew is so bad it is deserving to lock the document, why not delete it entirely?

There might be a copyright claim against an image in a brew. Deleting the entire brew would be an overreaction.

It is a locking function, for content the user can rewrite or already has in their system. If the content of the brew is so bad it is deserving to lock the document, why not delete it entirely?

There might be a copyright claim against an image in a brew. Deleting the entire brew would be an overreaction.

locking the brew for a copyright claim seems too much for me, however, the "get that image out or we will lock it" would seem more appropiate to me. IDK

In response to a DMCA claim we are required by law to remove the offending content from public access until the issue is resolved. Otherwise we as the hosting service can be liable for the copyright infringement.

1. Seeing this popup in action, it occurs to me that it behaves as kind of a mini error page. Would it make more sense to use the common "Error Page" for this message? And put the "click to unlock" button on there?

Rather than creating a new LockNotification component, we could instead throw, and include in that error some function to disable the lock temporarily.

2. The error should probably explain what being "locked" means. I.e. the brew is not visible via the share page, etc.

Currently the only fixed text is "BREW LOCKED", everything else comes from the lock.message field. It should be trivial to add some explanatory text.

3. So "Click to unlock" just takes you to the editor as normal, but doesn't actually lift the lock. Is there a better name for that button, like "CLICK TO CONTINUE TO THE EDITOR".

Should be a fairly simple change.

4. I think a better use for this kind of "popup" thing might be for a "submit to admins" thing. I'm picturing this:

* User tries to open their edit page, and hits the error page instead. This is where all the details are. "your brew is locked. Here are all the details, and what this means for you. etc. Click here to continue to the editor"

* User enters the editor, where this popup now appears with a smaller message: "Your brew is locked. (locking message). Once you have resolved this issue, click here to notify the administrators for review. (BUTTON "REQUEST UNLOCK"). Click (OTHER BUTTON) to temporarily hide this notification (will reappear when the page is next reloaded).

A method for requesting locks be removed will need to be created, which is intended to be added in a later PR, once functionality to actually add/remove/otherwise update locks has been created.

5. It might make sense to reuse (and maybe update) the "notificationPopup.jsx" component we already have instead of making a separate component element.

As NotificationPopup is a non-blocking and permanently clearable message, it has a different purpose to this notification; although I suspect it might work with some modifications.

"This is a test message from the database." is the lock.message property. All other text in the notification is currently fixed text and will appear in every lock notification.
The "REQUEST LOCK REMOVAL" button is currently attached to a stub function.

It occurs to me that we may want two messages - one for the ErrorPage, and one for the LockNotification. The general public needs only to know that the brew is locked, while the author needs to know the specifics of why it is locked... As such, an editMessage and a shareMessage might be appropriate.

Fixed the typo in the NOT YET IMPLEMENTED message:

Current state of this PR:
Attempting to access a locked brew by any method other than edit results in an error.
The error code (1001) and message (THIS IS THE TEST SHAREMESSAGE) are set on the lock object. Internally, it uses a HBErrorCode value of 100.

Attempting to access a locked brew via edit results in the LOCKED notification.
The message (This is the test EditMessage.) is set on the lock object. It is a different message to that displayed on the Error page.

Clicking CONTINUE TO EDITOR bypasses the lock notification and allows access to the Editor. The notification will return the next time the getBrew function is called - in this usage scenario, typically on the next page refresh.
Clicking REQUEST LOCK REMOVAL currently pops a NOT YET IMPLEMENTED message box, which reports the ShareID of the locked brew. It is intended to pass this ID to the /api/lock/review/request/:id route from PR #3421 once that PR is finished and merged.

The lock object on the MongoDB entry is as follows:

Just one question. is there a scenario where these need a custom, per-lock message?

I think custom messages are a good idea, for the same reason as @5e-Cleric --- rather than them coming to reddit to ask why their brew is unlocked, we can anticipate the question and put the answer right in the error screen especially since we don't expect this to be super common (hopefully).
Also, we could have perhaps a code that corresponds to the type of lock, if we ever expect to lock things for reasons beyond DMCA.  I assume the 1001 error code is just a generic code, so this would be in addition to that (or appended to that as 1001-1 1001-2 etc).  If we ever wanted to find out the quantity of types of locks, this would make it easier.   But perhaps that is just not worthwhile for a tool such as this.

I assume the 1001 error code is just a generic code, so this would be in addition to that (or appended to that as 1001-1 1001-2 etc).

I believe there are plenty unused http error codes for us to use some, 452 - 499 are unused, so we could create some, here some suggestions:

HTTP Code
Suggested Use

455
Generic Block

456
Copyright issues

457
Confidential Information Leakage

458
Sensitive Personal Information

459
Defamation or Libel

460
Hate Speech or Discrimination

461
Illegal Activities

462
Malware or Phishing

463
Plagiarism

465
Misrepresentation

466
Inappropriate Content

Currently, the message and code can be set to anything - I used 1001 in my test lock simply because it doesn't get used anywhere else, so I could be sure it was coming from my code.
I anticipate that we will be able to build in some suggested entries at the UI stage.

As a template:

Dear User,
We regret to inform you that your document titled [Document Title] has been locked and is no longer accessible due to a violation of our content guidelines. This action was necessary because the document Violates copyright laws || Contains offensive content || Includes illegal material.
We take these matters very seriously to ensure the safety and integrity of our platform for all users.
We ask you to remove any offending content, once you have, you can submit a request for us to remove the lock; once removed, users will be able to access the share page of this brew once again.
If you believe this action was taken in error, or if you have any questions or concerns, please contact our team at reddit for further assistance.
Thank you for your understanding and cooperation.
Sincerely,
NaturalCrit

We should also specify what is the offending content as well as what is the specific issue.

We should also specify what is the offending content as well as what is the specific issue.

IMHO there is no point to the notification message if it doesn't identify what needs to changed.

It is my intention that any template message should still be fully editable by the person applying the lock; most likely, selecting a template would only populate the field and still require the case-specific details be entered manually.
I would tend towards a shorter template message, something more like this:

This document has been locked and is no longer accessible due to reason.
Before it can be unlocked, the following issues must be corrected:

specific issue

Once you have corrected the above issue(s), click "REQUEST REVIEW". Once an Administrator confirms that all issues have been corrected, the lock will be removed.
If you have any questions about the process, you may contact our team via Reddit.
Sincerely,
Homebrewery Admin Team

@G-Ambatte Is this one ready for another review pass or are you still working on it?

@G-Ambatte Is this one ready for another review pass or are you still working on it?

It's almost there, I'll try to finish this one up today/tomorrow.

It might make sense to reuse (and maybe update) the "notificationPopup.jsx" component we already have instead of making a separate component element.

I've just pushed some changes now that creates a new Dialog component, which the existing notificationPopup.jsx has been modified to use. However, the new Dialog component uses <dialog> instead of <div>, which allows it to include an option to effectively block the entire page until it is acknowledged.
As this is not how the existing NotificationPopup has worked, this option is not enabled for those messages in the current build, but this should allow us to use the blocking version for the initial LockNotification on the EditPage, and the non-blocking version for an "on auto-save" reminder message.

State of the PR:

Dialog components:

[x] LockNotification
[x] NotificationPopup
[ ] RenderWarning

To do:

[ ] Shift RenderWarning to use Dialog
[ ] Shift dialog[open] styling to new dialog.less file
[ ] Tweak NotificationPopup styling to better match pre-PR layout

These are pretty minimal changes and I don't anticipate them taking much longer.

I believe that's all of the outstanding items now!

I manually added a lock object to a brew so that the operation can be seen on the deployment; of course I realized after the fact that this does not help a great deal unless anyone who wants to test it is able to log in on an author account.
https://homebrewery-pr-3382.herokuapp.com/edit/69po5z2nejuq

Looks good to me.

FYI the Lock Notification has both onClick and onCancel methods, so it can be cleared by pressing the ESC key. This calls the same function as clicking the "CONTINUE TO EDITOR" button.

Final state of the PR:
When a modal (blocking notification) is shown, the rest of the page dims to indicate that it cannot be interacted with.

Regular pop ups (like Render Warning or Notification Popup) do not cause this dimming.
Currently, clicking "REQUEST LOCK REMOVAL" pops a "NYI" alert. Implementing this functionality is work for a future PR.
Clicking "CONTINUE TO EDITOR" removes the modal pop up and allows normal access to the editor. However, this pop up will return every time the page is refreshed.
Possible work for a future PR: cause the Lock notification to reappear as a non-blocking notification on a relatively long timer (30 minutes, 60 minutes)

Possible work for a future PR: cause the Lock notification to reappear as a non-blocking notification on a relatively long timer (30 minutes, 60 minutes)

I disagree with this, if we lock a brew, the user first priority should be removing such content. This encourages that behaviour. Making it wait longer times gives 0 advantages.

Possible work for a future PR: cause the Lock notification to reappear as a non-blocking notification on a relatively long timer (30 minutes, 60 minutes)

I disagree with this, if we lock a brew, the user first priority should be removing such content. This encourages that behaviour. Making it wait longer a longer time gives 0 advantages.

This would be in addition to the existing blocking notification, so authors cann't just clear the message and then never refresh the Edit page, and thus never be presented with the notification again. The timed notification would serve as an additional reminder, and potentially also provide an easier way to access the "REQUEST REVIEW" button once the required changes have been made.

I've run this through the Linter now, the only thing it picked up from these changes is an unused useState, which I have corrected in the latest commit.

This would be in addition to the existing blocking notification, so authors can't just clear the message and then never refresh the Edit page, and thus never be presented with the notification again. The timed notification would serve as an additional reminder, and potentially also provide an easier way to access the "REQUEST REVIEW" button once the required changes have been made.

Oh, then yeah, sure, great

Thanks @G-Ambatte ! 💯 ⭐ 🎉


Handle unpriviledged user role creation

Possibly fixes #807
It might need some polishing as my sql is a bit rusty :smiley:

@paulfantom mind updating this one so we can merge it in?
Run go generate on the project so the SQL changes are included properly.

Catch only the duplicate_object exception, and no other

I am closing this PR since we want to catch what we already catch in the SQL scripts. I also don't have enough expertise to continue with this PR and implement check-create-catchduplicates logic.
If anyone wants to follow up on this, feel free to. If not, I will circle back to the issue and implement the logic after finishing with more pressing tasks.

@paulfantom don't give up! I think you were basically done. As I understand it, all you need to do is delete the two lines below from each exception block you added.
             I think you were basically done.

Or if you'd rather me take it over, I could do that too, @paulfantom


Raspberrypi wic

Purpose of pull request
For wic support of raspberry pi3
Test
How to test
Build core-image-minimal by following the steps in doc / raspberrypi3.md.
# bitbake core-image-minimal

After the construction is completed, write the wic image to the SD card and start it with raspberry pi3.
$ sudo dd if=core-image-minimal-raspberrypi3-64.wic of=/dev/sde bs=1G

Test result
I was able to confirm the startup.
root@raspberrypi3-64:~# uname -a
Linux raspberrypi3-64 4.19.175-cip43 #1 SMP PREEMPT Fri Mar 5 02:02:36 UTC 2021x

According to meta-raspberrypi, it would be nice to install LICENCE.broadcom_bcm43xx to rootfs.
linux-firmware-rpidistro_git.bb  installs LICENCE.broadcom_bcm43xx .


Make server_urls dynamically reloadable

closes #723
PropertyFileConfigurationSource now reloads changes done to the config file(currently every minute).
Checklist

[x] Implement code
[x] Add tests
[x] Update documentation
[x] Update CHANGELOG.md

Hi and thanks for the PR!
The agent already supports reloading the configuration file:
https://github.com/elastic/apm-agent-java/blob/35f13a95fef02f3daf8d9c1c2bf26b7cc8027218/apm-agent-core/src/main/java/co/elastic/apm/agent/impl/ElasticApmTracerBuilder.java#L119
So refreshing the values for server_urls is not the problem here. It's rather that after initialization, it's not read from the configuration anymore. One of the reasons is that we shuffle the list in order to achieve load balancing. Another reason is that we have explicitly set the dynamic flag to false which signals users (this is also gets rendered in the configuration docs) that this is an option which is not reloadable at runtime:
https://github.com/elastic/apm-agent-java/blob/35f13a95fef02f3daf8d9c1c2bf26b7cc8027218/apm-agent-core/src/main/java/co/elastic/apm/agent/report/ReporterConfiguration.java#L57-L72
In a PR which is currently in review, I have also refactored a lot in that area and created an ApmServerClient.
So it makes sense to wait for that PR to land until we tackle the challenge of reading the updated configuration. We can either do this inside of the ApmServerClient or we can swap out the references to the client for all users with a new instance of the client when the configuration changes. I haven't really made up my mind yet on which option is better. Probably the first is a bit easier. The configuration option allows us to add a change listener via org.stagemonitor.configuration.ConfigurationOption#addChangeListener.

sorry for not providing more detail earlier 🙈


What determines vertical stack order for events?

I have a requirement to display events, and one requirement is to have "similar" events from one source drawn in the same row.
For example:

These are all events from "Node 1". We want all "TX" events to be drawn on the same row, and all "RCV" events to be drawn on the same row. So for this example I want the two "TX" events to be in the 'second row' of Node 1, and the two "RCV" events to be on the 'third row' of Node 1.
The backing data is not currently defined so I have total freedom there. Is there any current support for determining the vertical sort order of events within the same group?
codesandbox of above

I've had a quick look through the code and there is very little science to the overlapping. From what I understand is that the items are placed on the timeline in the order they come in from the items array.
If the item overlaps with an item with a lower index, it will be moved down a level.
To better control how the items render could you use multiple groups and styling?

@JaredDiCioccio I dont think this would work in the current implementation.
you are welcome though to submit a PR to support the needed behaviour but it is not in our current plans to do so


Problem loading a camera

Hello,
I am facing an error initialize a thorlabs camera. The Camera is correctly detected
...
[datetime] pymodaq.pymodaq.daq_viewer_main.Testing - INFO - Ready
[datetime] pymodaq.pymodaq.daq_viewer_main.Testing - INFO -   File "C:\Users\admin\.conda\envs\sp_dev\lib\site-packages
\pymodaq_plugins_thorlabs\daq_viewer_plugins\plugins_2D\daq_2Dviewer_Thorlabs_DCx.py", line 91, in ini_detector
    self.settings.child('exposure').setValue(self.controller.exposure.m_as('ms'))
'UC480_Camera' object has no attribute 'exposure'
[datetime]pymodaq.pymodaq.daq_viewer_main.Testing - INFO - detector initialized: False

I think the fix might be as easy as replacing
https://github.com/CEMES-CNRS/pymodaq_plugins_thorlabs/blob/5df60c9fea7b6f41546dd1b3ea8d3732d351e3e0/src/pymodaq_plugins_thorlabs/daq_viewer_plugins/plugins_2D/daq_2Dviewer_Thorlabs_DCx.py#L91
and other similar instances such as
https://github.com/CEMES-CNRS/pymodaq_plugins_thorlabs/blob/5df60c9fea7b6f41546dd1b3ea8d3732d351e3e0/src/pymodaq_plugins_thorlabs/daq_viewer_plugins/plugins_2D/daq_2Dviewer_Thorlabs_DCx.py#L54
by self.controller._get_exposure() and self.controller._set_exposure(Q_(...))
I am unable to submit a PR right now since I don't manage to get this plugin installed from source, see
CEMES-CNRS/PyMoDAQ#71 but I hope to get it right at some point lol

Hello,
for this plugin I'm using the package Instrumental that at the time was missing some functionalities. I did a PR from my fork but it seems it is not yet included in the official branch. You can therefore try to install Instrumental from :
https://github.com/CEMES-CNRS/Instrumental
see pip documentation on how to install from a git url!
However Instrumental also requires the thorlabs library to be processed once for the python code to work. If you cannot find how to do it, you can try to execute the module _build_uc480.py:

Let me know if it works

Hello,
Did you have success controlling the camera exposure time with your implementation?
I have checked mabuchilab/Instrumental#144 and in my opinion there is something broken beyond the missing exposure  facet.
See mabuchilab/Instrumental#150

Well I got that camera only for a short time to produce the new PID module and the video on it. I don't remember if I made it finally working but I think so. @quantumm is the owner of the camera, so maybe he can do some testing?

If he can, that'd be great!
In any case, I've opened #5 on the topic. For me it currently works so if @quantumm finds some time to test it'd be great

Hello,
I will try to do those tests but unfortunately for now it is difficult to find some time :/

Hi,
I tried again to install the plugin to use a DCC camera with a fresh install of pymodaq (3.5.6).
I was surprised to see that this issue is still not solved.
It seems like something wrong happened during the merge of the PR #5 .
Such call like controller.exposure should have been removed, which is not the case if you look at lign 91 in the current version of this file : https://github.com/CEMES-CNRS/pymodaq_plugins_thorlabs/blob/0.1.2/src/pymodaq_plugins_thorlabs/daq_viewer_plugins/plugins_2D/daq_2Dviewer_Thorlabs_DCx.py

Hi
The merge is fine, the changes have just not been released in a new version of the plugin yet.
For now, you should still install from source the main branch of this PR to obtain theses fixes.

Ah ok. Think I got it ;) Thanks.

I only tested the camera, not the other instruments, but it is fine for that part yes.

I think this can be achieved directly from the install_requires if you have a clone of instrumental_lib on github that will reliably work for an extended period of time:
https://stackoverflow.com/questions/32688688/how-to-write-setup-py-to-include-a-git-repository-as-a-dependency
Cheers
Nicolas

FOUND IT !!!
You have to put this in the requirements (in your plugin toml file):
[plugin-install]
#packages required for your plugin:
packages-required = ["pythonnet", "pywin32", "nicelib", "instrumental-lib @ https://github.com/CEMES-CNRS/Instrumental/archive/refs/tags/cemes.0.6.tar.gz"]
so you can point directly to an archive file without need of git. You could also do it for your dependencies on pylablib also

I will therefore publish a new version of thorlabs plugin including this requirement!

Hi guys,
Just wanted to note that the new release of the plugin didn't get uploaded to pypi
( error in upload workflow)
" Invalid value for requires_dist. Error: Can't have direct dependency:
         'instrumental-lib @ https://github.com/CEMES-CNRS/Instrumental/archive/
         refs/tags/cemes.0.6.tar.gz'

so at the moment, it cannot be installed by the plugin manager.
I was running into the camera exposure issue and it kind of drove me crazy until I noticed that I wasn't on the last release :-)

Ok I reverted the requirements on instrumental-lib for the moment and published v 0.2.0 on pypi manually. I'm in the process of a push release on instrumental so should have the next release soon to make it all work.


Reopen issue #1668

Issue #1668 was closed automatically, even though it is clearly a problem with the proptype definition. Read to the end, and you will see that right should be a valid enum as the component does not render properly without it when using children.

Possible that it's different because of an update to SUI?

This issue was invalid and anyone doesn't read that SUI doesn't have definitions for right. To display correctly an icon with children API just pass the icon prop:
<Input icon>
  <input className="custom" />
  <Icon name="calendar" />
</Input>

https://codesandbox.io/s/8k14k8rp30

@layershifter Ok, so your latest reply on https://github.com/Semantic-Org/Semantic-UI-React/issues/1668#issuecomment-409877369 makes it much clearer. You have to keep the icon prop as a bool prop for it to work properly. Thanks!


AirCurve 10 ST 401 firmware

Does anyone have this stock firmware?

There are no rights to redistribute vendor firmware, please do not ask or use this repository to do so, it is very likely to cause the project to be scrubbed from github if you so.


update dependencies

@react-native-community/async-storage is replaced (fixes #45)
Some dependencies are updated
bump minimum deployment target on iOS

see here


docs: Update links and comments for realSwipe function

Summary
This PR focuses on updating the comments related to the realSwipe function in the TypeScript type definitions. Specifically, it corrects the documentation link and enhances the clarity of existing comments
Changes

Corrected the @see URL for the realSwipe function to accurately direct users to the correct section of the GitHub README, ensuring developers have access to relevant and detailed usage instructions.
Refined comments within the type definitions to improve clarity and provide better guidance on using the realSwipe function.

Motivation
The primary goal of these updates is to make the documentation more user-friendly and accurate, thereby enhancing the developer experience. Clear documentation supports developers in utilizing the realSwipe function more effectively, fostering a more intuitive and productive development process.
Impact
These documentation and comment enhancements do not introduce changes to the functionality or API of the cypress-real-events library. They are focused solely on improving the quality of information provided in the codebase, making it easier for developers to understand and implement features correctly.
Thank you for considering this contribution. I believe these documentation improvements will greatly benefit the cypress-real-events community by providing clearer guidance and support. I am open to any feedback and further discussion on these changes.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Shell: source code cleanup

Minor style and formatting updates in shell source files.
Removed obsolete '\r' characters.
Static functions cleanup.

Codecov Report

Merging #11906 into master will decrease coverage by 1.2%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master   #11906      +/-   ##
==========================================
- Coverage   48.19%   46.98%   -1.21%
==========================================
  Files         280      280
  Lines       43259    43271      +12
  Branches    10364    10373       +9
==========================================
- Hits        20850    20333     -517
- Misses      18255    18856     +601
+ Partials     4154     4082      -72

Impacted Files
Coverage Δ

subsys/shell/shell.c
0.16% <0%> (-24.37%)
:arrow_down:

subsys/shell/shell_fprintf.c
0% <0%> (-90%)
:arrow_down:

subsys/shell/shell_utils.h
0% <0%> (-80%)
:arrow_down:

subsys/shell/shell_wildcard.c
0% <0%> (-78.67%)
:arrow_down:

subsys/shell/shell_history.c
0% <0%> (-75.44%)
:arrow_down:

subsys/shell/shell_help.c
0% <0%> (-74.4%)
:arrow_down:

subsys/shell/shell_ops.h
0% <0%> (-52.64%)
:arrow_down:

subsys/shell/shell_cmds.c
0% <0%> (-44.54%)
:arrow_down:

subsys/shell/shell_utils.c
0% <0%> (-44%)
:arrow_down:

subsys/shell/shell_dummy.c
5.71% <0%> (-31.43%)
:arrow_down:

... and 3 more

Continue to review full report at Codecov.

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

recheck


Sync reference  documentation for Spring Cloud Azure 4.1.0 of GitHub pages and Microsoft docs

Context
Now we have 2 places to hold Spring Cloud Azure Reference doc:

Spring Cloud Azure MS docs: https://docs.microsoft.com/en-us/azure/developer/java/spring-framework/
Spring Cloud Azure github.io: https://microsoft.github.io/spring-cloud-azure/current/reference/html/index.html

Problem
Changes to reference documents will first synchronize MS Docs, we need to keep the content of the above two reference documents consistent.
Goal
After the release of 4.1.0, the content of the documentation in both MS Docs and gitHub.io is consistent.

https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/3035

There is a new issue tracking this, close it now. https://github.com/Azure/azure-sdk-for-java/issues/29161


Is it legal to both enable and disable a flag, as in (?i-i:.)?

That seems potentially fraught; it's not obvious which should take precedence.

Precedent in other languages seems to be:

Modifiers before - are added, then
Modifiers after - are removed.

Which means (?i-i:.) is equivalent to (?-i:.), which is what the spec text should currently reflect.

Is there a reason to want this to be legal, other than precedent from other languages?

I’d expect this to be syntactically prevented, since it’s confusing as to whether the two cancel out, or whether i is already there and it’s a -i, or whether it’s not already there and it’s a noop.

@waldemarhorwat asked about this during the December 2021 Plenary. My response was the same, and I have since verified the behavior in other engines. I had assumed consensus had already been reached on the behavior of (?i-i:.) at that time.

The extent of the discussion in the notes is

WH: And if it's the same flag on both sides of the -?
RBN: I would have check. That's either an error or a no op right now, I believe what the current specification text that I've written has is that it would first set the flag and then unset the flag, so it's essentially unsetting it. But again, I'll have to clarify that.

which I at least did not understand as the committee agreeing to permitting this.

I can add it to the slides for discussion in June. I would be fine with making it an error if necessary, it just seems needlessly pedantic.


editor.hover.delay doesn't affect debugger hovering, only language server hovering

Type: Bug
Set editor.hover.delay to 3000 (3 seconds). While debugging, hold Alt and hover over a keyword. It will correctly take 3 seconds to display the hover information from the language server. Then, release Alt and hover over a variable. It always takes about 3/4 of a second to evaluate the value regardless of the setting.
(This is frustratingly slow for me.)
VS Code version: Code 1.77.3 (704ed70d4fd1c6bd6342c436f1ede30d1cff4710, 2023-04-12T09:16:02.548Z)
OS version: Windows_NT x64 10.0.19042
Modes:
Sandboxed: No

System Info

Item
Value

CPUs
AMD Ryzen 9 5950X 16-Core Processor             (32 x 3394)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
undefined

Memory (System)
63.94GB (27.65GB free)

Process Argv
--crash-reporter-id bbc83cb3-8859-43b9-93a1-5337a381d19f

Screen Reader
no

VM
0%

Extensions: none
A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
vscorecescf:30445987
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30410667
cppdebug:30492333
vsclangdc:30486549
c4g48928:30535728
dsvsc012:30540252
pynewext54:30695312
azure-dev_surveyone:30548225
nodejswelcome1:30587005
282f8724:30602487
pyind779:30671433
89544117:30613380
pythonsymbol12:30671437
vsccsb:30705552
azdwalk:30721579
pythonms35:30701012
pythonfmttext:30716742

We do look at that setting, but we multiply by 2, I didn't realize that. @isidorn do you remember why you made this change, is it just that the debug hover can be very large and you don't want it to be too touchy?
https://github.com/microsoft/vscode/commit/5e5ae15b22c6617f22923edce6e359897cac0f83

Multiplying by 2 doesn't explain why it's still less than a second when I set it to 3000 though.

@roblourens yes, the idea was that debug hover can be very large and requires user interaction. So we make it as twice as slow as the editor hover.
Just a naive heuristic, feel free to change :)

No, I didn't do that, so maybe that's it. If that can't easily be changed, the description of the setting should probably explain that a restart is necessary.

Can you let me know whether the general delay behavior is ok with you after a reload? I think I would like to leave the heuristic, it seems fine to me and adding a new setting for the debug hover delay would be overkill to me.
The restart only applies to where this setting is used for debug, so I wouldn't describe it in the setting description, but maybe that can be resolved.

Looks like it's correctly 6 seconds after a reload.
Would you consider making the 2x heuristic itself into a setting? I'd really just like to make it responsive for myself. I'd also think a better heuristic might be a fixed additional length of time, like an additional 100ms or something, but it doesn't matter to me if I can discover it and turn it off. Is it common for users to hover their mouse over an identifier for a length of time between, say, 100 and 1000 milliseconds? I figure once the mouse stops it's probably not gonna start moving again for a while, and at that point it's just a question of how responsive the program feels. But this is just my opinion and I don't have any real data to back it up of course.
My only problem with the restart being required is that it prevented me from realizing this setting even has any effect in debug, so it makes the setting just seem like it doesn't work. I was lucky to even think of the idea that it might be different between the debugger and language server; my initial impression was that the setting had no effect at all. Now that I know how it works it doesn't matter for me personally, of course.

I was having the same issue - the value evaluation in debug felt very slow to me. I tried everything, including modifying the hover delay. However it felt like it had no effect so I returned it back to its original value - I would have never thought about needing to restart. Good thing I found this thread.
Maybe the need to restart should be clearly specified in some way?

Is it possible to avoid/configure this factor of 3 in the delay for those who would want to see the variable content quickly while hovering?

Made some changes here to:

Let the delay be changed without a reload
Improve the heuristic by basing the factor on the setting. Now the *2 factor is applied for a hover delay between 0 and 300ms (the default hover value, so default behavior is unchanged), after which it reduces to *1 by 900ms.


Fix "hostname needed" detection

Hello !
This PR fixes #33 at least for zsh, seems to work in bash too but dunno in fish.
If someone could test it in fish to ensure compatibility...

@nekonyuu: The script does generaly not work with an fish shell:
Expected end of the statement, but instead found a string
.shell_prompt (line 8):     if [[ -n ${ZSH_VERSION-} ]]; then print %m; elif [[ -n ${FISH_VERSION-} ]]; then hostname -s; else printf "%s" \\h; fi
                                                                                ^

But this is not the problem of your change, it is in my eyes that "fish" doesn't understand the "elif" statement, it is "else if" in "fish" i think.
I've done another quick check:
if [ $blub ]; then print a; elif [ $blah ]; then print b; else print test; fi
Expected end of the statement, but instead found a string
fish: if [ $blub ]; then print a; elif [ $blah ]; then print b; else print test; fi
                                                                     ^

So the change should be merged and maybe if this is realy an bug with fish handling a new issue should opened.

BTW, the PR works in BASH (daily use).

Thank you for the PR!


update time estimate

[Enter feedback here]
If possible, including an estimate of how long the update process will take would be helpful. That allows the CX to have an idea of how long the maintenance period needs to be, particularly if there is a one-node system.

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

ID: a451efca-ca52-6a0f-3063-400c217b183f
Version Independent ID: cb8266b5-1651-c0e4-c540-1796ecb9a50c
Content: Install Update on Azure Stack Edge Pro GPU device
Content Source: articles/databox-online/azure-stack-edge-gpu-install-update.md
Service: databox
Sub-service: edge
GitHub Login: @alkohli
Microsoft Alias: alkohli

@cchapin2020
Glad to know you have self-resolved the issue. If there are further questions regarding this topic, please do let us know and we will gladly continue the discussion.


Add missing router methods

This PR mostly adds sync and async router fns for the missing HTTP methods HEAD, PUT, PATCH, DELETE, OPTIONS, CONNECT and TRACE.
I originally added a with_status_code setter to Response in my fork, but later saw that you have since added a nearly identical method, so I merged the two commits and kept with_status as the name from the main branch (though perhaps with_status_code should be used to be consistent with the existing getter). Let me know if you would prefer to have a separate PR for the with_status return value type change.

Thanks @fkettelhoit - I've merged this into a testing branch and will get back to you if there are any changes needed. I think it's a great addition and appreciate the help! This will likely be out with the next release.


binutils: make patches unconditional

The Darwin patch was always supposed to be unconditional, and neither of these patches should have any effect when applied to other targets. Conditional application should be avoided where possible as it makes it very easy to miss when a patch needs to be updated.

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

There’s Darwin‐conditional autoreconf stuff that should maybe be unconditional too now?

I was worried about the bootstrapping impact of doing that.  We don't need an autoreconf except for Darwin, so I think maybe it's better not to, even though it's a bit weird that the patch gets applied with no autoreconf on other platforms?

I think it’s okay for bootstrapping to do it, although I never worked out exactly why, just saw it being done elsewhere and that it’s apparently fine. I could be wrong though. I guess I feel like applying the patch unconditionally but only actually having it do anything conditionally isn’t ideal, though it should still have marginally better anti‐bitrot properties than the status quo.
Personally I want us to autoreconf all the things all the time, so I’m biased to doing it if it’s possible. But if it’s not then yeah I guess the current state of the PR is the best we can do under the circumstances. (But I must lodge despair into the aether that generated autoconf output is a bootstrapping problem by itself!)

avr-size.patch adds an additional option that's not standard behaviour. I'm split on whether I would do this conditionally, so I leave it up to your judgement.
-  -A|-B|-G  --format={sysv|berkeley|gnu}  Select output style (default is %s)\n\
+  -A|-B|-G|-C  --format={sysv|berkeley|gnu|avr}  Select output style (default is %s)\n\
+            --mcu=<avrmcu>            MCU name for AVR format only\n\

I don't think there's a compelling reason not to given that it won't do anything if it's not given.
OOC do you know why this patch isn't upstream if all these distros are using it?


A few chapters won't download.

Well, as the title says...they won't...it's because the internal count of the code will get messed up if you change to a different chapter during the sleep time. This can be a pain, because then you will have to first run the whole code for that particular "missing" chapter and then close it to then again make better changes in the database.

This will be fixed in later releases.

This will be fixed in later releases. I'll close this issue when that happens, while informing here what version the enhancement has been on.

I guess I'll drop this project in favor of something else. Maybe I'll pick up once python gets more efficient and fast. Anyways, it was nice working with it. I got to learn a lot. I probably won't archive my repo. Closing now.


Print error to console and don't spam notify.

So you can actually see the error.

Looks good to me; fix the code style and I'll merge it in.

Put the newline variable inline if it's not used anywhere else. Then I'm happy.

It is used twice, inlining it wouldn't look too good...

Okay I fixed it and squashed it.

By the way, instead of committing and squashing, you can use git commit --amend to edit the latest commit. (It will prompt for the commit message again, you can just leave it as-is)

Thanks for the tip.

It screwed up my tabs for some reason though.

Never mind, it was because some of the file was tabs and some was spaces. I replaced all the spaces with tabs.

It's making the difference comparison act weird but I only changed the spaces into tabs.

I'm closing this branch.


After cpu_start during device startup and after deep sleep, ESP32 stops executing function and prints out garbage (IDFGH-3999)

Environment

Development Kit:     none
Module or chip used:  ESP32-WROOM-32D
IDF version (run git describe --tags to find it):
v4.1-beta2-141-g84b51781c
Build System:         idf.py
Compiler version (run xtensa-esp32-elf-gcc --version to find it):
xtensa-esp32-elf-gcc (crosstool-NG esp-2019r2) 8.2.0
Operating System:     Linux
Using an IDE?: VS code
Power Supply: Battery

Problem Description
I have several boards running my firmware (about 10). Occasionally (once a week) these boards stop executing their code. I can diagnose this because the board will connect to wifi and push data to our backend. We take a timestamp each time this handshake occurs (every five minutes) so we can get a sense of what our units are doing. When the ESP32 is not polling wifi it sleeps for 5 minutes.
However, sometimes they just drop out infinitely and stop executing their code. We have set up several monitored units to catch the output when this occurs and this is what we caught. It occurred after a sleep period during startup.
Has anyone seen something like this before? Is there anyway I can diagnose further to understand what is happening?
Debug Logs
I (12) boot: ESP-IDF v4.1-dirty 2nd stage bootloader
I (12) boot: compile time 09:05:57
I (12) boot: chip revision: 1
I (14) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (21) boot.esp32: SPI Speed      : 40MHz
I (26) boot.esp32: SPI Mode       : DIO
I (30) boot.esp32: SPI Flash Size : 4MB
I (35) boot: Enabling RNG early entropy source...
I (40) boot: Partition Table:
I (44) boot: ## Label            Usage          Type ST Offset   Length
I (51) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (58) boot:  1 otadata          OTA data         01 00 0000f000 00002000
I (66) boot:  2 phy_init         RF data          01 01 00011000 00001000
I (73) boot:  3 ota_0            OTA app          00 10 00020000 00150000
I (81) boot:  4 ota_1            OTA app          00 11 00170000 00150000
I (88) boot: End of partition table
I (92) boot_comm: chip revision: 1, min. application chip revision: 0
I (99) esp_image: segment 0: paddr=0x00170020 vaddr=0x3f400020 size=0x384b0 (230576) map
I (196) esp_image: segment 1: paddr=0x001a84d8 vaddr=0x3ffbdb60 size=0x042e4 ( 17124) load
I (204) esp_image: segment 2: paddr=0x001ac7c4 vaddr=0x40080000 size=0x00404 (  1028) load
0x40080000: _WindowOverflow4 at C:/Users/TonyWu/Desktop/esp-idf/components/freertos/xtensa_vectors.S:1778

I (204) esp_image: segment 3: paddr=0x001acbd0 vaddr=0x40080404 size=0x03448 ( 13384) load
I (218) esp_image: segment 4: paddr=0x001b0020 vaddr=0x400d0020 size=0xef52c (980268) map
0x400d0020: _stext at ??:?

I (594) esp_image: segment 5: paddr=0x0029f554 vaddr=0x4008384c size=0x1a878 (108664) load
0x4008384c: r_ea_alarm_set at ??:?

I (641) esp_image: segment 6: paddr=0x002b9dd4 vaddr=0x400c0000 size=0x00064 (   100)
I (658) boot: Loaded app from partition at offset 0x170000
I (658) boot: Disabling RNG early entropy source...
I (658) cpu_start: Pro cpu up.
I (662) cpu_start: Application information:
I (667) cpu_start: Project name:     oto-template
I (672) cpu_start: App version:      f8f79036
I (677) cpu_start: Compile time:     Sep 16 2020 17:07:27
I (683) cpu_start: ELF file SHA256:  6971aecc21d58d35...
I (689) cpu_start: ESP-IDF:          v4.1-beta2-141-g84b51781c
I (696) cpu_start: Starting app cpu, entry point is 0x400814b4
0x400814b4: call_start_cpu1 at C:/Users/TonyWu/Desktop/esp-idf/components/esp32/cpu_start.c:271

I (0) cpu_start: App cpu up.
I (706) heap_init: Initializing. RAM available for dynamic allocation:
I (713) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (719) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM
I (725) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM
I (731) heap_init: At 3FFBDB5C len 00000004 (0 KiB): DRAM
I (737) heap_init: At 3FFCEB18 len 000114E8 (69 KiB): DRAM
I (744) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (750) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (756) heap_init: At 4009E0C4 len 00001F3C (7 KiB): IRAM
I (762) cpu_start: Pro cpu start user code
I (781) spi_flash: detected chip: generic
I (781) spi_flash: flash io: dio
I (782) cpu_start: S�`���~����f` �����~��������� �~������f~`�~���f�������~��~���`�~��x��`��~�f�~�xf��fx`�� �f��f��x������~f���~��~���������x��`�����`���fx�fx`��~��f��~��~���`�~����� �~���f�~�`����f����`���~����f` �����~��������� �~������f~`�~���������`�f������ff�������f��f����`���~����f` �����~���������

Hi @jonhunterking66,
Thanks for a clear description of the problem you're seeing.
This looks like it's most likely a hardware issue rather than a software issue. I noticed that your power source is a battery and you're using a module on a custom device, does the design follow the ESP32 Hardware Design Guidelines closely? Is it possible the main power supply is unstable, or has insufficient capacitance to maintain a stable voltage during high bursts of current draw?
Suggest also checking the brownout detector configuration. The default level is the minimum (level 0, ~2.43V) but you should be able to increase this and you may find that a BOD reset is triggered rather than unexpected behaviour:
https://docs.espressif.com/projects/esp-idf/en/v4.1/api-reference/kconfig.html#config-esp32-brownout-det
(The long term fix for this probably still a hardware fix, though.)
Finally, if you can then it's strongly recommended to update the ESP-IDF v4.1 final release now that it's available. Although I don't expect this will fix the problem, it's possible that the particular release branch commit you're using has some kind of bug.

@projectgus thank you for the feedback!
I will update to 4.1 and review the documents you have supplied.
Could you explain a little bit more about why unstable power could cause this problem? Since we are not seeing brownout warnings in the debug output I would expect it to be something else.

@projectgus I also wanted to clarify that we are using a WROOM-32D on our custom board. This makes me feel like its unlikely a layout issue. Unless you expect it is circuitry unrelated to the module. Most of the ESP32 Hardware design guidelines relate to layouts of standalone SoCs.

@projectgus I have updated to v4.1-273-g94cb7e8b8

@projectgus any chance this could be a memory issue?

Hi @jonhunterking66,

Could you explain a little bit more about why unstable power could cause this problem? Since we are not seeing brownout warnings in the debug output I would expect it to be something else.

Of course. Some key things include:

The default brownout detector level is very conservative, so it is possible that a short voltage drop caused by power supply instability will push the voltage below the specified range but not trigger the detector. Increasing the level should help rule this out.
It is also possible for short power supply faults to occur that don't trigger the brownout detector.
Electrical noise in general can cause interference in other components inside the module, for example the communication lines between the flash chip and the ESP32.

I also wanted to clarify that we are using a WROOM-32D on our custom board. This makes me feel like its unlikely a layout issue. Unless you expect it is circuitry unrelated to the module. Most of the ESP32 Hardware design guidelines relate to layouts of standalone SoCs.

Apologies, I should have linked you to the WROOM datasheet which has some layout & supporting hardware guidelines.
It is still possible for supporting hardware to cause issues - particularly if power supply ever drops below 3.0V, or if there's not enough power supply capacitance (and/or layout issues with placement of capacitors), and/or electrical noise and EMI.

I have updated to v4.1-273-g94cb7e8b8

Were you able to reproduce the problem with this version?
FWIW, this is a still a "release branch" - specifically it has 273 commits made after v4.1 which will be included in v4.1.1. To get the exact stable release you would run git checkout v4.1. I know the versioning is a bit complex to understand, and some of the names are conterintuitive - there is a longer explanation here.

any chance this could be a memory issue?

It's not impossible, however I'd expect more consistent failures in this case.
It looks like the UART baud rate goes bad just about the time that the app_main() routine in the firmware is scheduled to run. (The UART has a hardware FIFO buffer and a software buffer so execution is usually a short time ahead of where the UART log is.)

What does your firmware do in the app_main() routine? Is there anything there which might cause an intermittent issue if it does corrupt memory or similar?
Which peripheral(s) and/or peripheral drivers does your firmware enable/use?
Do you have any power management features enabled, apart from using deep sleep? Are you able to share the project sdkconfig file, please?

Thanks.

@projectgus
We ran several boards with our firmware over the weekend all based on 4.1. Several boards repeated the same issue. I also ran the code on a dev board to see if I could recreate the problem. It did occur on the dev board so I feel like we can rule out a hardware issue.
To answer your follow up questions:

What does your firmware do in the app_main() routine? Is there anything there which might cause an intermittent issue if it does corrupt memory or similar?

void app_main(void)
{
  xTaskCreate(&read_task, "read", 1024*6, NULL, 1, &read_handle);
  vTaskSuspend(read_handle);
  xTaskCreate(&main_task, "MAIN", 1024 *40, NULL, 2, &main_handle);
}

The read task reads an adc value and performs two i2c reads. The main task is huge. It runs a state machine that performs several functions that relate to BLE, wifi and motor control. There are several places that I could imagine memory issues. The Wifi and BLE stack are both fairly complex and its possible there is memory issues there.

Which peripheral(s) and/or peripheral drivers does your firmware enable/use?

ADC, BLE, Flash, GPIOs, I2C, PWM, OTA, sleep, and WiFi

Do you have any power management features enabled, apart from using deep sleep? Are you able to share the project sdkconfig file, please?

Nothing that I can note. I will add the sdkconfig to this comment.
sdkconfig.txt

@projectgus Is there any other information I can give to help with this?

I have caught more instances of this occurring. These took place after sleep started:

@projectgus we have video of the error happening, it does not sleep for the 5 minutes as I expected but starts printing out garbage ~10 seconds after entering sleep.

Hi @jonhunterking66,
Thanks for the extra info and for being patient while I got back to you.
I agree that if you can reproduce on a dev board then it's probably not hardware related.
Do I understand correctly that there are two slightly different failure patterns that you are seeing:

Device goes to deep sleep, wakes up (after an unknown amount of time?), normal boot log is printed until some time during startup but before booting finishes the UART output becomes corrupt. (This is the failure shown in the first post.)
Device appears to go into 5 minute deep sleep but spontaneously prints corrupted UART output 10 seconds later. (This is the failure shown two posts above.)

Do you have access to a logic analyzer that you can use to capture the UART output? The corrupted output may be output at baudrate/2 (as the APB clock is halved when going into deep sleep), or it may be at some other random baud rate. Capturing it and seeing if there is anything decipherable there may give additional clues as to where it's getting stuck.
Otherwise, the best possible next step would be if we can reproduce this ourselves. Do you think it would it be possible for you to remove parts of your firmware iteratively by trial and error to try and come up with a minimal test case that you could send us? Or are the failures too infrequent for this?

@projectgus no worries. I really appreciate you getting back to me.
Yes, there are two different instances where we have seen this:

The device sleeps for 5 minutes, normal boot log is printed until cpu_start in which case it becomes corrupted
The device goes into the 5 minute deep sleep, but starts printing out garbage 10 seconds after entering deep sleep.

The most confusing part for me is that if it is just UART corruption then why does the code stop executing properly?
I will capture the baud rate to see if we can get any clues from there. In addition I will simplify the code to try and see if I can recreate this. Maybe I can start by taking out the WiFi related stuff? Not sure if you have any suggestions about simplifications.
I might be able to get you a code copy as well but I would have to speak to my manager about that as this code is being used on a product.

@projectgus I can also confirm that the baud rate during the garbage outputting state is half. 57000 during garbage output, 115200 during normal operation

Hi @jonhunterking66 ,

I can also confirm that the baud rate during the garbage outputting state is half. 57000 during garbage output, 115200 during normal operation

OK, this is very useful as it confirms the APB clock rate is somehow being set back to the XTAL value during the boot (it should be 80MHz but it's being set to 40MHz). Does the same also during the "false sleep" state?
If you look at this half-rate UART output do you see anything useful like a crash log, or does it look like normal execution apart from the bad baud rate?

 The most confusing part for me is that if it is just UART corruption then why does the code stop executing properly?

If the APB clock is reverting to 40MHZ instead of 80MHz then a lot of things may be trying to work but failing (for example Wi-Fi will fail to initialize the RF subsystem properly and you'll probably get a Wi-Fi error, other peripherals may also be working but at half the configured speed.) The UART is probably just one symptom.

Maybe I can start by taking out the WiFi related stuff? Not sure if you have any suggestions about simplifications.

This is a bit of a guessing game to be honest, as we've not seen this behaviour before and we don't know how to reproduce it except that you can reproduce it on your firmware. My guess is that some combination of things that are running when going to deep sleep (maybe drivers, especially drivers which are processing data in ISRs, plus possibly also Wi-Fi) are not fully resetting like they should and this is causing the bug somehow.
If you're confident enough about reproducing on your current firmware that you can disable Wi-Fi entirely and see if the problem goes away or not, this would be a very useful piece of information. And/or one by one not initialising certain drivers and seeing if the problem goes away?

@projectgus

OK, this is very useful as it confirms the APB clock rate is somehow being set back to the XTAL value during the boot (it should be 80MHz but it's being set to 40MHz)

So just to be clear the 40Mhz clock speed is not expected during sleep?

If you look at this half-rate UART output do you see anything useful like a crash log, or does it look like normal execution apart from the bad baud rate

Do you mean if I was able to read the baud rate at 40Mhz? I have not tried to convert the garbage output to logs. Any suggestion on how I could do that?
I can definitely try remove part of the code. Wifi is a big one that is used a lot. The code would pretty drastically change however.
Would there be value for you seeing the code? I would need you to sign an NDA. Not sure if this ever happens but if that would be helpful let me know.
I will try removing the Wifi stack.

So just to be clear the 40Mhz clock speed is not expected during sleep?

When the chip is actually going into deep sleep the APB clock is set to 40MHz. This is half the usual value during normal operation. So this part is expected.
The unexpected part is that the chip shouldn't be doing anything externally visible at this time. If you're seeing UART output at half the configured  baud rate then the most likely direct cause is that the UART is outputting while the APB clock is set to 40MHz not the normal 80MHz (the UART baud rate is divided from the APB clock.)

 Do you mean if I was able to read the baud rate at 40Mhz? I have not tried to convert the garbage output to logs. Any suggestion on how I could do that?

If the "garbage" output is output at 57600bps (ie half the configured 115200) then you should be able to use a logic analyzer capture to do this, or run a serial program at 57600bps while the program is running. The already-captured serial logs probably can't be decoded,

I can definitely try remove part of the code. Wifi is a big one that is used a lot. The code would pretty drastically change however.
Would there be value for you seeing the code? I would need you to sign an NDA. Not sure if this ever happens but if that would be helpful let me know.
I will try removing the Wifi stack.

Normally we try to find a more minimal test case to reproduce, and work from this. So if you are able to try removing parts of the firmware to narrow it down then this is ideal, thanks.

To clarify further, a APB clock speed of 40Mhz corresponds to a 57600bps on UART?
We determined that the UART was outputting at 57600bps using an oscilloscope.
I will try removing wifi from the firmware to test this further.

@jonhunterking66 Can you check what exactly UART is outputting? You can do that by running e.g. miniterm.py PORT_NAME 57600 — the output printed at 115200 will be shown as garbage, but the output printed at 57600 will be visible.

@igrr Could I get a little more guidance on this?

Thanks for getting involved and helping out!

@igrr just started messing around with miniterm.py. Its awesome. The idf.py monitor call resets the unit but this just picks up where the unit is running.
I feel like this is going to be very useful. I will let you guys know what I find.

To clarify further, a APB clock speed of 40Mhz corresponds to a 57600bps on UART?

I'll explain this connection in detail, as there are a few different variables here:

The UART baudrate is calculated as (clock source / divider) where both the clock source and the exact divider value are configured from registers (more details in ESP32 Technical Reference Manual).
When power management is disabled (as it is in your sdkconfig), the clock source is the APB clock
The APB clock runs at 80MHz during normal app execution
So the divider value will be approx 694.4 (80MHz/115200)
If the baud rate spontaneously changes from 115200 to 57600 then there are two plausible root causes: the clock source has halved in frequency, or the UART divider register has doubled in value.

We know that when we head into deep sleep the APB clock goes from 80MHz to 40MHz as we disable the internal PLL and revert the APB to the bare crystal frequency (40MHz). When the system resets out of deep sleep it should reconfigure the PLL and the APB clock goes back to 80MHz (side note: this also happens on first boot, the bootloader starts off running at the crystal frequency and then configures the clocks during startup.)
So although we can't say for sure that this is why the UART baud rate is spontaneously half the normal value, or what is triggering the bug, it's the most likely internal behaviour that's responsible for what you're seeing.
Hopefully capturing the "garbage" output with miniterm gives some clues.

@igrr thank you for the clarification. I will try and capture a failure again while using miniterm.py

@projectgus @igrr I have not been able to recreate the issue. I recently restructured my WiFi library to deal with some heap losses. I did not think this would fix the problem as I deep sleep between every WiFi poll, and it seems the heap was back to full size at the start of every cycle.
Not convinced yet that it is entirely fixed until I have run it for about a week. Let me know if any of this information helps lead to a conclusion.

@jonhunterking66 How did you go running your updated firmware?

Its been going great. I have not seen it since I restructured my WiFi library to deal with heap losses. I have no idea if they were related but I have not seen it since.

Thanks for the update. In that case I'm going to close this as unreproducible, but if you come across this issue again then please let us know.


refs/tags/v0.20.7 Changelog Update

Update changelog

Auto-generated by create-pull-request

@ctrombley would you know what we should do with this PR? It seems outdated now


fix: do not overwrite user's guicursor shape

fixes #54. removed the cursor shape options (e.g. block, ver25. hor20) from being set in the guicursor. now this plugin only handles the highlighting.
for example, the following line:
vim.opt.guicursor:append('v-sm:block-ModesVisual')

was changed to:
vim.opt.guicursor:append('v-sm:ModesVisual')

Oo excited to test this. Thanks for contributions, I'll be able to review soon 💜

Been testing millow's fork/branch with no issues. Works as advertised 👍

Appreciate the feedback :) I just got back from a trip last night so still playing catch up

This change breaks the current behavior
From the linked issue, what we want is for the guicursor shape to be configurable

This change breaks the current behavior
From the linked issue, what we want is for the guicursor shape to be configurable

I argue that this plugin has no need to be able to configure the guicursor shape when neovim literally provides you the ability set the cursor completely by yourself independent of this plugin in a very easy way.

Respect user's guicursor settings not Add guicursor shape configuration options

^^^ Agreed. This plugin makes it super-simple to customize colors per-mode which otherwise requires bespoke autocmds.  I can't think of a problem with the default guicursor implementation of cursor shapes that needs a plugin to solve.
:h guicursor has a clear examples that that even work in old versions of vanilla vim.

This new behaviour seems ideal, and is how I would have implemented initially if I had a better understanding of what I was actually doing.
I'm a little confuse about the debate going on now though, is there a disagreement on whether this plugin should change the cursor shape or not?

imho I can't think of a use case for a plugin to manage the cursor shape during mode switching (it's a single line option config), but of course that doesn't mean one doesn't exist.
I'm curious if @fitrh's issue is that users might rely on this bug to set their cursor shape to the ones hardcoded in the plugin.  I doubt this the case though, since the cursor shape isn't configurable and I think you just copied the default nvim cursor shape anyway (so shouldn't be a change even if they are) .
Either way, the ask seems out of scope from this issue (and OP confirmed this above).
If @fitrh has a use case for why the builtin option isn't sufficient, maybe they can open a new issue with their use case to discuss as a new feature request?


[Doc] Clean up docs

Fix some formatting, spelling, grammar, and punctuation mistakes.

This is great, thank you. Readable documentation is underrated 🙃


Short solution needed: "Hash passwords for usage with PHP PDO" (php-pdo)

Please help us write most modern and shortest code solution for this issue:
Hash passwords for usage with PHP PDO (technology: php-pdo)
Fast way
Just write the code solution in the comments.
Prefered way

Create pull request with a new code file inside inbox folder.
Don't forget to use comments to make solution explained.
Link to this issue in comments of pull request.

Hash passwords for usage with PHP PDO


in release checklist: update pinned version of vendored dependencies

make sure we're doing this every release. should go with #1366

@EverlastingBugstopper maybe  we should include this directive as a todo bullet in #1366 to ensure it doesn't get lost.

added as sub-task to #1366


Fix GPG email checking to be case insensitive

Fix #1986

A little performance remark but otherwise LGTM.

Fixed suggested changes and added unit test

LGTM


Wrap order clauses in Arel.sql()

These are marked as "dangerous SQL" since Rails 5.2 and will fail with
Rails 6.1.

The linked foreman PR is erroring in some katello tests, but I have no idea why...

The Katello tests in the linked Foreman PR fail, so maybe there's something missing regarding complete_value. However, in the scoped_search tests all the deprectation warnings are gone with this PR.

so maybe there's something missing

Do you want to keep this opened for a bit longer?

@adamruzicka If nobody else has an idea, I'd like to see it merged and released as I don't know if it's an Katello or scoped_search problem.

Hrm, scrap it... let's wait until a release with the other fix is out.

This is all green now with Foreman and Katello without deprecation supression :green_heart:.

Thank you @mmoll !


⚠ Bofrost.fr has degraded performance

In 1180043, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 958 ms

Resolved: Bofrost.fr performance has improved in 34a0feb.


Hyper CLI script fails to load HTML.

Observe:
C:\Users\cb2\Documents\hyper>hyper GET https://http2bin.org/html
Traceback (most recent call last):
  File "C:\Python34\Scripts\hyper-script.py", line 9, in <module>
    load_entry_point('hyper==0.2.0', 'console_scripts', 'hyper')()
  File "c:\users\cb2\documents\hyper\hyper\cli.py", line 227, in main
    print(request(args))
  File "C:\Python34\lib\encodings\cp850.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u2014' in position
1266: character maps to <undefined>

Note that this may be a Windows-only problem.

Yes. I could run the same command on OS X.

Cool, that makes narrowing this fix down easier. It's almost certainly because of this:
>>> locale.getpreferredencoding()
'cp1252'

The response data would be encoded with content-type charset. In this case, maybe utf-8, I guess your terminal (command prompt?) cannot output utf-8 encoded string?
def get_content_type_and_charset(response):
    charset = 'utf-8'
    content_type = response.getheader('content-type')
    if content_type is None:
        return 'unknown', charset

    content_type = content_type.lower()
    type_and_charset = content_type.split(';', 1)
    ctype = type_and_charset[0].strip()
    if len(type_and_charset) == 2:
        charset = type_and_charset[1].strip().split('=')[1]

    return ctype, charset

Correct, Windows cannot, at least not by default. See this bug.

Ah, sorry, I misunderstood reading the code. That's not encode, but decode with utf-8. So, the response data would be decoded as Unicode string. hmm,,,

issue 1602

I see. That's a print function bug.

Indeed. So the question becomes, how do we handle printing on Windows?

I guess we can handle using sys.stdout with encoded string, instead of print() function. Could you try this patch on your Windows?
diff --git a/hyper/cli.py b/hyper/cli.py
index 3dccfca..7727e21 100644
--- a/hyper/cli.py
+++ b/hyper/cli.py
@@ -6,6 +6,7 @@ hyper/cli
 Command line interface for Hyper inspired by Httpie.
 """
 import json
+import locale
 import logging
 import sys
 from argparse import ArgumentParser, RawTextHelpFormatter
@@ -224,7 +225,10 @@ def request(args):
 def main(argv=None):
     args = parse_argument(argv)
     log.debug('Commandline Argument: %s', args)
-    print(request(args))
+    data = request(args)
+    encoding = locale.getpreferredencoding()
+    sys.stdout.buffer.write(data.encode(encoding))
+    sys.stdout.buffer.flush()

I guess locale.getpreferredencoding() is the same as sys.getfilesystemencoding() in almost every case. However, I'm not sure which is appropriate.
FILESYSTEM_ENCODING = sys.getfilesystemencoding()

locale.getpreferredencoding() should be preferred, I think.

That patch works fine on Window for the /html endpoint. It does not work for /encoding/utf8, but updating the data.encode(encoding) call to read data.encode(encoding, errors='replace') fixes that too.

OK. If so, it's also better to use locale.getpreferredencoding() for request data, instead of FILESYSTEM_ENCODING.

Thank you for confirming. I'm going to fix and send PR.

Brilliant, thanks. =)

Resolved by #88.


Can't get Valheim to update

Hi,
I cant get Valheim to update. My local game is running the latest version 0.150.3. The server is stuck at 0.148.7
Iv'e tried pulling the image again and restarted the image.
Got the following error att startup.:
valheim_1  | [ODIN][INFO]  - Installing 896660 to /home/steam/valheim
valheim_1  | [ODIN][ERROR] - Failed to find steamcmd in path
valheim_1  | [ODIN][ERROR] - Checking for script under steam user.
valheim_1  | [ODIN][INFO]  - Executing: /home/steam/steamcmd/steamcmd.sh .....
valheim_1  | [ODIN][INFO]  - Using steamcmd script at /home/steam/steamcmd/steamcmd.sh

I tried going in the docker with exec-comand
steam@a0acd0cec62d:~/valheim$ odin update
[ODIN][INFO]  - Checking for updates
[ODIN][ERROR] - Failed to find steamcmd in path
[ODIN][ERROR] - Checking for script under steam user.
[ODIN][INFO]  - Executing: /home/steam/steamcmd/steamcmd.sh .....
[ODIN][INFO]  - Using steamcmd script at /home/steam/steamcmd/steamcmd.sh
[ODIN][INFO]  - No server updates found
steam@a0acd0cec62d:~/valheim$

Never mind. Its working now

Yee, sometimes you have to wait for the Valheim devs to push the new version. It takes a bit for the server edition because they always push them last.


wireguard UI should provide QR code for setup

The setup of an wireguard interface is a bit uneasy, as copying a public key from the cellphone is not that easy for most people, or manually typing it is error-prone. I hate doing either of it. There would be an easy way to add an Android setup, if LuCi would provide the user with a QR code that the Android App could easily scan.

Or at the very least a .conf file generator of sort so we can download a conf file from the router and use it on the android client without the need to manually type the keys wich is prone to errors with 0 and O (zero and cap o) and l and I (lower L, cap i) etc...the file format can be seen here https://git.zx2c4.com/WireGuard/about/src/tools/man/wg.8
Also the command to generate the code can be seen here:
https://wiki.debian.org/Wireguard#A3._Import_by_reading_a_QR_code_.28most_secure_method.29
but im pretty sure that is going to require an extra package, on the other side the conf file AFAIK dont need anything extra...

Ping luci-app-wireguard's current maintainer @danrl  ;)
If you just open LuCI in cellphone browser, the copy should be easy in both direction.  I can also think of many ways to transfer such info from desktop browser to cellphone, online qrcode generator, copy and send to IM.  There are also existing luci apps such as travelmate, fwknopd using qrencode to generate and embed svg qrcode.
But I cannot think of a better way to transfer public key from cellphone to desktop browser ;)  Usually I just send these literal strings, qrcode, encoded urls to IM then receive and use them in desktop system ;)

Sounds like a nice idea. I am open to pull requests implementing the functionality. It's open source, get involved :)

Im smart and good at googling but i know literally zero about coding, i posted the links to help the best i can with my """skills""" :D

I think it's not about only the key. It's also the IP address. I always have troubles finding the right settings, only after trying a bunch of netmasks.
<dream>I would be so a killer feature to just "hold" the phone camera onto the screen and have a working wireguard connection.</dream>

@danrl Should the QR code added to the wg status page?

Depending on what is in the QR code. I understand we can have one per peer (maybe not that helpful) and/or one per interface. It should appear on the right level, so that it is clear what the qr code is about. Please keep in mind that people are running crazy setups, not everyone has the road warrior setup. So we should not optimize for a single use case.
I am not so sure I like the idea of pulling in all the dependencies that go into generating QR codes, but I can see the demand for that feature. Minimalists might not like it too much. Can we make it an extra package maybe?

@danrl please see #2195 for QR code support

QR Code feature is now in master.


 New keyboard action can be added - after pressing "space" it can call "shot" method from "Tank".

I would like to start working on this issue, could you assign it to me? Additionally I have one question in order to clarify the task. The barrel means the tank gun?

Yes, tank gun. The goal is to spawn this sprite: shotOrange.png at the end of a tank gun for a period of time (50ms? 100ms? Choose what looks best for you!).
Don't spawn the new thread! Use some flag inside the class that will be set to true after shot & set it to false after some period of time. How to measure the time? How to store timestamp? I have some idea, but maybe you will find something better? Feel free to ask me on DM if you will have any problem!

I created a PR #19 which solves this issue.


ACMPCA: Adding validation and unittests for revocation configuration

Adding parameter validation for revocation configuration.
Adding unittests to improve unittest coverage for set_revocation_configuration method in moto/acmpca/models.py
Adding unittests for validation.

boto3 documentation: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/acm-pca/client/update_certificate_authority.html
aws api documentation: https://docs.aws.amazon.com/privateca/latest/APIReference/API_CrlConfiguration.html#privateca-Type-CrlConfiguration-S3ObjectAcl

@bblommers
I don't think the failure of this github action has anything to do with my changes.
https://github.com/getmoto/moto/actions/runs/8373118600/job/22925602827?pr=7503

If you can just resolve the conflict, I'd be happy to merge


False Positive on io.vertx:vertx-web and io.vertx:vertx-auth-common

After updating to version 5.2.1 of the Maven plugin, I am receving two false positives for Vert.X:
vertx-web-3.7.0.jar<EMAIL_ADDRESS>: CVE-2018-12542
vertx-auth-common-3.7.0.jar<EMAIL_ADDRESS>cpe:2.3:a:sonatype:nexus:3.7.0:*:*:*:*:*:*:*) : CVE-2019-7238

For the first issue, there is strangely no CPE given, but according to the CVE, only versions up to version 3.5.3 are affected.
For the second issue, there is clearly a mismatch betwen the Maven corrdinates and the CPE, only the version is identical.

On the first issue - I notified the OSS Index team.  This issue is being reported by the OSS Index Analyzer.
I have added a suppression rule for the other issue.


Create user video for basic use and one for advanced use

Advanced use one should go into more details of customizing season, etc.

Explain the need for dashboard--difficult to pull all the data from each of the various sources and do the formatting and summaries. Dashboard does spatially referenced imports and error checking, formatting, summaries, viz...


LaunchScreen: black box instead of the vector logo on startup

It's an intermittent bug observed by other developers (see https://forums.developer.apple.com/thread/17146).
No fix has been committed yet. Maybe we should remove the file extension of the image used in the launchScreen.xib (Icon-170.png), but not sure it will help...

Is this still happening?
I haven't had this.


Unable to change multiple options at once/in short time span

Describe the bug
Hi,
I'm using a script (pyscript, but same would also apply to builtin scripts I guess) to change how my storage works.
I.e. if energy is very cheap at night, and solar forecast predicts that I won't get enough PV tomorrow, I might buy from the grid.
Or it might decide to buy current usage from the grid, and keep a specific state of charge in the battery for later, when it is more expensive.
I used binsentu's integration before, where the script worked, but this seems much better maintained and much cleaner, so I tried to switch.
However, the script fails to work now.
This seems to be related to the fact that the script might change multiple parameters in a short time span:
    select.solaredge_i1_storage_default_mode.select_option(option=modestr)
    select.solaredge_i1_limit_control_mode.select_option(option=exportmode)
    if exportlimit is not None:
        number.solaredge_i1_site_limit.set_value(exportlimit)

(this is pyscript syntax. AFAIK, this will just result in service calls)
If I comment out some of the calls, e.g. to only select the storage_default_mode, it works.
However, as soon as multiple changes are done, none of them seem to work at all, nothing happens.
I also tried playing with the command delay parameter, but didn't seem to make a difference.
I'm using persistent connection with 15s polling interval.
Expected behavior
All changes should be applied/queued.
Logs
Nothing is logged by the integration.
Debug Logs
It does say this:
2023-02-18 10:27:33.591 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.select] set SE10K-RWS48BEN4_7E061DAC_storage_default_mode to Charge from Solar Power
2023-02-18 10:27:33.591 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.select] set SE10K-RWS48BEN4_7E061DAC_limit_control_mode bits<PHONE_NUMBER>000000
2023-02-18 10:27:35.035 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Sleeping 3 seconds after write.
2023-02-18 10:27:36.674 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Sleeping 3 seconds after write.
2023-02-18 10:27:38.036 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 30

or
2023-02-18 10:29:18.643 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.select] set SE10K-RWS48BEN4_7E061DAC_storage_default_mode to Charge from Solar Power and Grid
2023-02-18 10:29:18.643 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.select] set SE10K-RWS48BEN4_7E061DAC_limit_control_mode bits<PHONE_NUMBER>000000
2023-02-18 10:29:19.301 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 30
2023-02-18 10:29:22.188 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Sleeping 3 seconds after write.
2023-02-18 10:29:22.188 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Sleeping 3 seconds after write.

but nothing seems to be actually done.
If I change the parameters in the HA UI, it works just fine.
Home Assistant (please complete the following information):

Home Assistant Core Version: 2023.2.5
solaredge-modbus-multi Version: 2.2.11

EDIT:
As a workaround, I can put an await asyncio.sleep(1) in between the calls, and it seems to work again.
For the site-limit, I have to use asyncio.sleep(5) because the number only becomes available when a site limit mode is not "Disabled", so it will have to wait for a whole round-trip before I can set it, I suppose.
This somewhat works fine for me, but it really doesn't feel right.

So the difference with this integration is that every time a write command is sent, a read to refresh the status of the inverter follows every write so that the data set is consistent. Validation and availability of some commands is affected by the values of others. The delay between writing a command and reading for updates can be set in options (default 3 seconds) because during the time the inverter is processing a write, it usually doesn't respond to reads.
I'm not sure about the scripts aspect (I've never used scripts in HA) or how that interacts with the command response delay setting since it does work in the HA frontend. It seems like the script is not waiting for each command to finish execution with the command response delay before moving to the next step or something, so I would suggest adding sleep calls between every write command in the script as already suggested.

I'm not sure about the scripts aspect (I've never used scripts in HA) or how that interacts with the command response
delay setting since it does work in the HA frontend. It seems like the script is not waiting for each command to finish execution with the command response delay before moving to the next step or something

Yes, AFAIK these calls do not block. That's not unique to scripts, but also e.g. if you create an automation that does multiple things in sequence.
I assume the same would happen when doing it via the UI, but I can't really click fast enough to reproduce it.

so I would suggest adding sleep calls between every write command in the script as already suggested.

sure, that works for me. I'm fine with it - it just doesn't "feel right". I'd have expected the modbus writes to be queued by the integration if necessary.

As far as understand how HA works "queuing" is not a possibility. HA is supposed to be asynchronous where I tell HA to wait for something to complete but it can go do other things while the task is processing and come back later, which is how the frontend UI works. This is using Python asynchronous frameworks, not specific to the integration.
You can't duplicate it in the UI because the UI does wait for each command to complete (that's what the command execution delay option is) basically causing it to self-queue multiple actions based on asynchronous calls to the write functions and the "await" keyword which is built-in to Python. Why that doesn't translate to scripts I don't know since it's executing the same code.

Just quickly looking at scripts in the UI, there is a "wait for a trigger" step that maybe could be used after executing each command to verify the command has been updated in the device state before moving to the next step. To me that sounds similar to what the frontend is already doing when you click on things rapidly and they execute over time.

I assume your Inverter Command Delay is set to something other than zero, if it's not, try
The Inverter Command Delay option is actually just a call to asyncio.sleep() built into the integration.

I did try both, with and without delay, but it didn't seem to make a difference.
Interestingly, it's not only that the second and third command in my script fails to do anything:
    select.solaredge_i1_storage_default_mode.select_option(option=modestr)
    select.solaredge_i1_limit_control_mode.select_option(option=exportmode)
    if exportlimit is not None:
        number.solaredge_i1_site_limit.set_value(exportlimit)

In fact, if written like this, none of them do anything. Not even the first one. Once I add a sleep in between, they start to work.

It's interesting that asyncio.sleep() works if you put it in the script but it doesn't work it when it's built into the integration. Scripts must not follow the same rules as the frontend UI when executing commands.
Even if I made a dynamic internal verification that commands were processed replacing the inverter command delay option, it would still depend on "await" and calls to asyncio.sleep() internally (send command, wait to see if state is updated, wait more if not, repeat), which the scripts are already bypassing.
I can explore ideas for a queue but since it already works in the frontend UI, I can't do anything that would break that.

Does it support putting an await in front of each of the commands in the script? I'm not familiar with pyscript.

Unfortuantely no, that doesn't seem to change anything.

Oh, actually, I found a different solution to achive what you intended with the await:
I can add an additional parameter blocking=True, which will result in a blocking service call. With that, it seems to work almost correctly. Just the last one (setting site limit right after the entity becomes available) doesn't work. Have to sleep a bit longer for that.
See https://hacs-pyscript.readthedocs.io/en/latest/reference.html#calling-services

When making a service call, either using the service.call function or the service name as the function, you can optionally pass the keyword argument blocking=True if you would like to wait for the service to finish execution before continuing execution in your function.

Which explains why I haven't seen this issue because that's the only way the frontend UI works.

I made a simple 3 command script on one of my test systems using HA's built in scripting with an inverter command delay of 10 seconds, and my observation is that this is not a problem with HA's own scripting service.
alias: Test Script
sequence:
  - service: select.select_option
    data:
      option: Charge from Solar Power
    target:
      entity_id: select.solaredge_i1_storage_default_mode
  - service: select.select_option
    data:
      option: Export Control (Export/Import Meter)
    target:
      entity_id: select.solaredge_i1_limit_control_mode
  - service: number.set_value
    data:
      value: "20"
    target:
      entity_id: number.solaredge_i1_backup_reserve
mode: single

It executed as expected:

And checking debug logs you can see the async calls were awaited as it's written in the integration code:
2023-02-22 10:44:40.162 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.select] set simulated-inv_000001_storage_default_mode to Charge from Solar Power
2023-02-22 10:44:40.167 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Sleeping 10 seconds after write.
2023-02-22 10:44:50.163 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.select] set simulated-inv_000001_limit_control_mode bits<PHONE_NUMBER>000001
2023-02-22 10:44:50.168 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Sleeping 10 seconds after write.
2023-02-22 10:45:00.664 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.number] set simulated-inv_000001_storage_backup_reserve to 20.0
2023-02-22 10:45:00.669 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Sleeping 10 seconds after write.

So my conclusion would be that this is a problem with pyscript choosing to ship with a default of non-blocking when that's the opposite of how HA core and HA frontend work. Adding an option to disable blocking would be fine if you warn people that this isn't the default behavior for HA and doing it may cause problems, because then you get issues like this where I'm not able to duplicate the problem in HA until its discovered the real problem is a third party integration deciding to do opposite of how HA behaves and making opposite its default.
I don't really think this is my problem to solve when the integration works with HA's built in script service and UI, and nobody has reported this problem with HA automatons. I assume you use a third party scripting service because it can do more stuff that the built in scripting can't do. And sure, it worked with another integration that (if I'm being honest the reason I actually went to the trouble to learn how to make this integration) didn't follow HA's development standards as well as I seek to follow and I'm big on staying with how HA core works, they were both kinda doing stuff out of spec that happened to work by coincidence but then doesn't work with a different integration because pyscript decides it knows better and ignores await calls by default that were there for a reason.

I've added a note about using blocking=True for pyscript service calls in the wiki.

Yes, I agree, this is probably quite a niche application, so wiki note is appreciated, but that's enough.
Thank you anyway, and sorry for all the fuss. Great work you are doing here.

Honestly if pyscript's default for service calls was blocking like how HA's scripts run, you wouldn't have noticed.


Remove dependency on System.Web from main Cassette module

Andrew,
I've become a fan of the Nancy framework, but don't like the current way that static content is handled.  I have started working on an integration module to pull Cassette into the Nancy pipeline : https://github.com/ChrisMH/Nancy.Cassette
The first step was to remove any reference to System.Web and related namespaces from the main Cassette project.  The project in this pull request is now based on the .NET 4.0 client profile and does not use any reference to ASP.NET libraries.
I used some code from the Mono project (JSON Serialization, HttpUtility), and I replaced IHttpString/HttpString with string.  I didn't see a reason that interface/class was necessary, but perhaps I'm missing something.
Unit tests were updated and are passing (except for two which didn't pass before I made these changes).
Chris

Awesome work Chris, thank you! Andreas will be happy too :)
The IHtmlString was being used so that generated HTML elements were not html-encoded by razor when put into the page. However, it's seems reasonable to just add the HtmlString wrapper around the normal strings in the Cassette.Web's Render helper method.
I'll try to get this merged into my 1.0 branch asap. Thanks again!

I just realised that what I said doesn't make any sense!! The Assets helper is in the main Cassette assembly. We can perhaps move it to the Cassette.Web assembly. The Nancy assembly would then need it's own version of the helper.

When HTML rewriting is enabled (the default) then GUIDs are inserted into the page and replaced later with the actual HTML. When rewriting is disabled the actual HTML is inserted directly. So without the IHtmlString wrapper, Razor will HTML encode the generated HTML. So the in-page helpers still need to using IHtmlString.
An option I'm exploring now is moving the static in-page helper into Cassette.Web. This will mean Cassette's core public API can be free of any System.Web types. The core Cassette HTML generators can be converted to return raw strings (as per your commit). However, Cassette.Nancy will then require its own static helper class. Is this a problem?
I'm also a bit concerned about pulling in all that mono source. It means we have to track the original source and support it within Cassette (apply patches, etc). How about using Json.net instead? That works with the .net client profile and has a nuget package.
HttpUtility is only used in one place by Cassette (BundleCache) and I'm pretty sure that code path is actually never hit! Deleting that code then removes the final System.Web dependency.

Nancy.Cassette didn't turn into all that much code, so it should be fairly
easy.  I'll rebase this evening and see.
On Mon, Nov 7, 2011 at 3:51 PM, Andrew Davey <
<EMAIL_ADDRESS>
Cool, let's go with Json.net.
I've pushed the branch here
https://github.com/andrewdavey/cassette/tree/remove-system-web-dependency- it's based on the forthcoming 1.0 beta. I'm unsure how easy it'll be to
merge with your current Nancy.Cassette fork. Once 1.0 is done it may be
easier for us to go through your code and cherry pick for a new Nancy
integration library.

Reply to this email directly or view it on GitHub:
https://github.com/andrewdavey/cassette/pull/92#issuecomment-2659470


.net 8 preview support in isolated process

Hi,
I get the below error after changing TargetFramework to net8.0.
I am using Visual Studio 17.7.0 Preview 1.0.
-- Invalid combination of TargetFramework and AzureFunctionsVersion is set.
Also the .net 8 options is missing in the new project template.

@parmarnishant .NET 8 (preview) support is not available yet, but will be coming out shortly. We will share an announcement when it is ready. I will also post an update to this issue. Thanks!
What .net8 features are you excited to try with azure functions?

Hi @kshyju
Thanks for the update.
I initially require Timer, Http and Queue triggers.
We will be using isolated mode.
Do we have estimated time frame when this will be available, so I can plan the work accordingly and not want to avoid alternatives if its coming sooner.

Closing as answered.


Custom Log Message display for unsupported languages + Adding Example and Docs

Description
This PR adds a Custom Log Message display for unsupported languages on the MetaCall Jupyter Kernel. It also adds more examples and corresponding Docs for the same.
Fixes #15
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[X] This change requires a documentation update
[X] Documentation update

Hello @HarshCasper! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file metacall_jupyter/kernel.py:

Line 102:80: E501 line too long (97 > 79 characters)


Add

http://grasshopper3d.com
https://github.com/thearn/stl_tools
buyers guide on 3D hubs http://tf3dm.com/
http://3dkitbash.com - 3D-Printable Toys and 3D Printer Test Kits

Added in 559c8c98583a7e563c3d7ff1d3a78b6378546e47


domd: add block dependency for block-up-notification

Since meta-xt-prod-cockpit-rcar uses core-image-minimal,
it should add block dependency to support block-up-notification
systemd service.
Signed-off-by: Andrii Chepurnyi<EMAIL_ADDRESS>

added rb


Change default values for strategy and Image spec fields and fixed docs and examples.

do not merge yet, i just saw references in docs and example to old image that I want to fix.

/lgtm

/lgtm


[core] Upgrade react-transition-group

No benefit yet since react-transition-group/Transition is still not strict mode ready but not using legacy context is already a big plus.

Nice :)

Looks like an issue with webpack. No idea why it concatenates so many modules on the next branch but treats each module individually in this PR. The core has no transitive dependency on react-transition-group but our docs have it. Probably the reason we hit the deoptimization since our docs now include two different versions.


Simplify truncation in SVDWorker.

The parameters controlling truncation, namely minm_, maxm_ and cut_ within SVDWorker only have indirect control on the final number of states kept through the variable docut. Also the code for computing docut is pretty compliacated. It would be good to simplify this code for readability and maintainability, and to write some tests to ensure that guarantees about minm_ etc. are being enforced.
Make sure to test that the truncate_ flag works correctly (when set false) as well.

Addressed in 8c9e4439d786de87be0662135fef62ee35de9a77