feat: Add support for Draft 6 in NumberConstraint

I am opening this PR because I first encountered it as reported in https://github.com/api-platform/core/issues/6041. I have read and seen either via commit history or issues (such as #699) that this repository has very limited people capabilities.
I tried to keep this as short as possible to offer a Draft 4 and Draft 6 compliance for Numbers->Range case without changing too much. Ref: Draft 6 Backward-incompatible changes.
I don't know if an is_bool is fine vs filter_var, I am more than happy to apply changes as per your feedback.

Thank you very much for this PR! As you've noticed, we are indeed extremely short on people with available time.
A few points:

Could you please set this PR against the master branch, not 5.x.x. The 5.x.x branch is draft-04 only, and draft-06 stuff goes in master.
Draft-06 and draft-04 are mutually exclusive regarding the exclusiveMinimum and exclusiveMaximum keywords unfortunately, as both versions of the spec mandate a type, but the type differs.
I appreciate what you are trying to do with the version inference thing (detecting draft-4 vs draft-06 behaviour by looking at the type). It's not really appropriate (because it results in things passing validation which shouldn't), but given that we do this elsewhere already with other keywords, I'm inclined to say that we should just accept it here too. Users that want strict validation of the type against the spec version can enable CHECK_MODE_VALIDATE_SCHEMA. With that said, this behaviour does need to be documented in the README, as it's clearly not spec-compliant.
I'm unsure whether we should also backport this into 5.x.x, and currently leaning towards not, particularly noting that the master branch is essentially feature-complete for draft-06 - it can be (and is) used in production now for most use-cases. My primary concern is that backporting this could result in validation behaviour changing for existing deployments in violation of the v4 spec, and I really don't want to risk that on something as widely-used as this library is. Happy to be convinced otherwise if you have a good argument for why we should backport it regardless.

@Seldaek Do you have an opinion on (4)? If this violation would trouble composer (or if you aren't sure), then I won't backport it. You're too important to break ;-)

Hey! Thank you for looking at this so soon. Since you used numbers, I will use numbers too 😄

I first encountered this issue in API Platform, their schema generator moved on to greener pastures and suddenly my regression tests started breaking. The tests broke in a dependabot PR and that had me look deeper. I don't know if you read the linked issue or not, but I can also just override my property to Draft 4 and be done with it. That did not feel like the right solution.
The reason I sent it to 5.x.x is because API Platform does not require master. To add I have been working with Symfony for 10+ years now so my first instinct was to make it backward compatible and forward compatible but as I am writing this I am noticing that I did not trigger any deprecation for Draft 4 checks. I have no strong opinion where this should go and I will do whatever is your final decision 👌
I can open a different PR for CHECK_MODE_VALIDATE_SCHEMA too.

From @erayd comment above it looks like it is safe to require master as a version rather than ^5, would this be too much for API Platform @soyuka ?

I'm really not familiar enough with the draft 04 vs 06 changes, but I doubt this impacts Composer. We only have a few integer types defined and none of them have additional restrictions.
From a "requiring master" perspective, it'd be good if we changed https://github.com/justinrainbow/json-schema/blob/master/composer.json#L41 to be 6.x-dev @erayd - that way projects requiring the draft 06 could require this package as ^6@dev which is much better than pinning to dev-master, as dev-master will eventually become v7. ^6@dev will require dependents of dependents to also allow this project in a dev version until there is stable release, so it's also not super convenient, but at least it's semantically correct from a versioning point of view.

@erayd I can update this PR against master now. Do you want to keep both Draft 4 and 6 or just move to 6 and never look back?

Do you want to keep both Draft 4 and 6 or just move to 6 and never look back?

Both, please. Many people use v4 still.

Requiring PHP 8 as a minimum version for the v6 branch will never happen; it would break too many dependent projects.

@erayd I am sure this is about more than Composer, but from my/Composer perspective, PHP 7.2+ is alright now, as long as v5 is kept maintained for critical fixes (but I really don't expect much of that, and I can do it myself if needed), and most likely the next jump we would do would be PHP 8.1+ to be able to use Symfony components in v6. I don't expect this to happen for another year or so tho as it would leave too many people stranded right now, there's quite a bit of PHP 7.4 usage still :/

My opinion on this is that the Draft 6 version of this package should move on at least php 7 or 8 version, I don't understand why supporting older versions would be a benefit (as it's a maintenance burden anyway). You could always use the 4.x version of this package with older php versions right?
To follow @llupa's enhancement here, you should target master for this patch, where master would be implementing Draft 6. If you want Draft 4, just install 4.x or 5.x version of this package right?

You could always use the 4.x version of this package with older php versions right?

v4 of this library has been unmaintained for many years. It should be avoided; there are a number of known significant problems with it. For users who require an older version of PHP, and for whom draft-04 is acceptable, then the v5.x.x release branch is usually the right choice.
For users who require draft-06, regardless of PHP version, v6.x.x (master branch) is currently their only option.

@erayd I moved the PR to master, but GitHub Actions did not pick up my force push. I wanted to have Continuous Integration at least run once. Should I close this PR and open a new one to trigger it? Add a fake commit?

@llupa thanks for your efforts and sticking strong with all the rebasing and other comments. In an attempt to revive this library I'm doing some triage on the issues and pull requests.  That should do the trick for the workflow.
@erayd I see you mentioning:

The master branch already implements draft-06, and should be essentially feature-complete. This PR caught something that both we and the unit tests missed, but is an exception rather than the rule.

Does this perhaps mean that the json schema test suite is really do for some updating? Also since the version 1.2.0 which is set in composer.json explains that is has full coverage on draft3 and draft 4. Version 2.0.0 mentions draft 6 and 7 as well.

@DannyvdSluijs funny you wrote today. I was thinking about this PR over the weekend 😅
Workflows waiting to be started 👍


[Linear] Only the last 50 teams are shown when creating an issue

Extension
https://www.raycast.com/linear/linear
Description
The teams GraphQL API call is not paginated: https://github.com/raycast/extensions/blob/c286c7bf40e6263bfc9100513e92a11b3a568def/extensions/linear/src/api/getTeams.ts#L24-L53
resulting in only the latest 50 teams being fetched from linear
Linear doc: https://developers.linear.app/docs/graphql/working-with-the-graphql-api/pagination

The first 50 results are returned by default without query arguments.

If there are more than 50 teams some will be missing from the dropdown when creating a linear issue

Steps To Reproduce

create more than 50 teams in linear
trigger the "Create issue" linear raycast action
list the teams in the "Team" dropdown

Current Behaviour
only the last 50 teams created are shown
Expected Behaviour
all available teams are shown

Thanks for opening up an issue. It can be fixed by adding typeahead search support to this field.

@raycastbot assign me

@raycastbot assign me


Remove callsite

Stack:

#2283
#2282
#2254
#2257
#2281 ⬅
#2253
#2252
#2245

⚠ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.


Correctly handle failed migrations

There is a bug in handling failed migrations whereby the migration task gets decoupled
from the migration repository. This leads to a failure of the task to get deleted with
the repository and also leads to the migration failed page resulting in a ISE.
This PR removes the zeroing out of the task id from the migration but also makes
the migration handler tolerate missing tasks much nicer.
Fix #17571
Signed-off-by: Andrew Thornton<EMAIL_ADDRESS>

Now - this has the result that the reason for the failed migration may never get shown to the user.
To that end we could remove the auto repository delete from the failed migration handler.

Codecov Report

Merging #17575 (af3f195) into main (bd613c7) will increase coverage by 0.04%.
The diff coverage is 12.50%.

@@            Coverage Diff             @@
##             main   #17575      +/-   ##
==========================================
+ Coverage   45.49%   45.53%   +0.04%
==========================================
  Files         793      793
  Lines       88811    88822      +11
==========================================
+ Hits        40401    40449      +48
+ Misses      41897    41857      -40
- Partials     6513     6516       +3

Impacted Files
Coverage Δ

modules/task/migrate.go
36.84% <0.00%> (ø)

routers/web/repo/view.go
39.79% <0.00%> (-0.41%)
:arrow_down:

routers/web/user/task.go
0.00% <0.00%> (ø)

modules/task/task.go
59.70% <66.66%> (ø)

modules/git/repo_base_nogogit.go
82.85% <0.00%> (-2.86%)
:arrow_down:

modules/git/utils.go
68.05% <0.00%> (-2.78%)
:arrow_down:

modules/process/manager.go
72.83% <0.00%> (-2.47%)
:arrow_down:

models/issue_comment.go
51.31% <0.00%> (-0.59%)
:arrow_down:

models/webhook.go
71.50% <0.00%> (+0.53%)
:arrow_up:

modules/queue/queue_bytefifo.go
59.88% <0.00%> (+0.59%)
:arrow_up:

... and 7 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 bd613c7...af3f195. Read the comment docs.

Now as a follow-up to this we need to make the UI for the user to view their tasks.


Update for Example-1

Example-1 contained incorrect parameter -Url. Fixed it to -OriginUrl.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-pnp/Remove-PnPTenantCdnOrigin.md
:white_check_mark:Succeeded
View (sharepoint-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Hi Juha,
as this in PnP PowerShell, we can't, unfortunately, merge this in as it has a special publishing process where we auto-generate the documentation directly from the source code. This means that the right place to submit this edit would be the following file in the PnP PowerShell GitHub repository.
https://github.com/SharePoint/PnP-PowerShell/blob/107734fe24891d3a5744c8a8ce2e03dd1db4e540/Commands/Admin/RemoveTenantCdnOrigin.cs#L21
Due this automation process, we won't be merging this, but feel free to submit a PR to the PnP-PowerShell repository, so that we get the changes included in next monthly release. Thx.


ResolveNames operation parsing error

I'm trying to get the primary smtp address of a user.
One, or probably the best way, I found was to use the ResolveNames operation.
But trying to do so, using search_scope::active_directory crashes on parsing the response.
I do get a mailbox but I also get contact information about the user. And those contact information do not include a DirectoryId, which is expected by the parse function.
Following the request:
<m:ResolveNames ReturnFullContactData="true" SearchScope="ActiveDirectory" >
	<m:UnresolvedEntry>sebastian.becker</m:UnresolvedEntry>
</m:ResolveNames>

And the response:
<m:ResolveNamesResponse xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
	<m:ResponseMessages>
		<m:ResolveNamesResponseMessage ResponseClass="Success">
			<m:ResponseCode>NoError</m:ResponseCode>
			<m:ResolutionSet TotalItemsInView="1" IncludesLastItemInRange="true">
				<t:Resolution>
					<t:Mailbox>
						<t:Name>Sebastian Becker</t:Name>
						<t:EmailAddress>sebastian.becker@regisafe.rocks</t:EmailAddress>
						<t:RoutingType>SMTP</t:RoutingType>
						<t:MailboxType>Mailbox</t:MailboxType>
					</t:Mailbox>
					<t:Contact>
						<t:Culture>de-DE</t:Culture>
						<t:DisplayName>Sebastian Becker</t:DisplayName>
						<t:GivenName>Sebastian</t:GivenName>
						<t:Initials/>
						<t:CompanyName/>
						<t:EmailAddresses>
							<t:Entry Key="EmailAddress1">SMTP:sebastian.becker@regisafe.rocks</t:Entry>
						</t:EmailAddresses>
						<t:PhysicalAddresses>
							<t:Entry Key="Business">
								<t:Street/>
								<t:City/>
								<t:State/>
								<t:CountryOrRegion/>
								<t:PostalCode/>
							</t:Entry>
						</t:PhysicalAddresses>
						<t:PhoneNumbers>
							<t:Entry Key="AssistantPhone"/>
							<t:Entry Key="BusinessFax"/>
							<t:Entry Key="BusinessPhone"/>
							<t:Entry Key="HomePhone"/>
							<t:Entry Key="MobilePhone"/>
							<t:Entry Key="Pager"/>
						</t:PhoneNumbers>
						<t:AssistantName/>
						<t:ContactSource>ActiveDirectory</t:ContactSource>
						<t:Department/>
						<t:JobTitle/>
						<t:OfficeLocation/>
						<t:Surname>Becker</t:Surname>
					</t:Contact>
				</t:Resolution>
			</m:ResolutionSet>
		</m:ResolveNamesResponseMessage>
	</m:ResponseMessages>
</m:ResolveNamesResponse>

As you can see, the contact element does contain information. but those are not an actual contact from a contact list. But contact information from a ContactSource.
My idea was to replace the DirectoryId in the resolve_names_response_message with the actual contact. Using ews::contact::from_xml(...) to parse the contact from the response.
Problem is, from_xml(...) expects an item_id. Which is not available as well. And which, I assume, is the same as the DirectoryId. Though not 100% on that.
Anyone have any ideas on how to solve this properly? Why was the DirectoryId assumed to be available? I guess it's always there when the name is found in a contact list!?
Changing ews::contact to not require an item_id? That might proof to be more extensive than it sounds.

I think it is a bug. According to the XSD DirectoryId is an optional element. So, the resolve_names_response_message::parse() should handle the case of a missing DirectoryId.
And I also think that DirectoryId and ItemId are something different. It depends where the contact information comes from. If comes from Exchange then it is an item within Exchange and has an ItemId.  If it comes from a third-party ressource like the AD, then it does not have an ItemId, but might have an DirectoryId.
At least, this how I understood the ressources that I found on this topic, e.g. on the  the FindPeople [1] operation and the summary of how contact information is provided in Exchange [2].
[1] https://docs.microsoft.com/en-us/exchange/client-developer/web-service-reference/findpeople-operation
[2] https://docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/people-and-contacts-in-ews-in-exchange


Add common files for cypress test

The files common and store are added to cypress/views
These files are needed for other test execution.
Signed-off-by: Timothy Asir Jeyasingh<EMAIL_ADDRESS>

@bipuladh , @vbnrh , Please review


Updated the version of cloudposse/ssm-tls-self-signed-cert/aws" to 1.3.0

what
Updated the version of referenced module cloudposse/ssm-tls-self-signed-cert/aws to 1.3.0
why
The current versions referenced in this module use an older version that does not allow the more recently released tls provider to be used. This causes conflicts if trying to add this module to an environment were a 4.0.x version of the tls provider was already used, which would happen easily since that is the current version.
references
closes #79

This is happening to me today after upgrading cloudposse/ec2-client-vpn module to 0.18.0 from 0.16.0.
Here's the error I got:
module.self_signed_cert_ca.tls_private_key.default[0] was created by a newer provider version than is currently selected. Upgrade the tls provider to work with this state.


Transparant facades showing conduits

Issue Description:
There are two conflicting thoughts about transparant facades. There are those who want to view conduits inside a transparant facade (#2737), and there are those who don't (#3226). As those issues describe the matter quite clearly I'm not going to repeat it here :)
Closing the latter as invalid is, in my point of view, closing your eyes to what a part of your user base wants. For two years (or however long conduit facades have been part of EnderIO) they behaved in one way (consistent with their description: they hide the conduit. There was no need to open a ticket as it did not need fixing: It was working as expected), and the you change them and mark issues pleading to change it back as invalid?
To quote HenryLoenwind from #3226: "great now we get reports telling us that we fixed a bug people liked...", yeah, that's what you get when you "fix" something that wasn't broken in the eyes of (at least some of) your users.
To quote MindForger on that same issue: "i prefere to see the cable through the glass... either way it would be unrealistic!", I prefer NOT to see the cable, I want that block to be glass, not conduit. If I wanted to see the conduit (or didn't care to see it) I wouldn't put a facade on it...
And while there may be ways to build around that in some situations (like, go 10 blocks left, go up, come back 10 block, to go around a window), this is not always possible (and a bit expensive, though that's the least of my worries).
As for realism, most wires and pipes in real life are not 1 by 1 by 1 meter (and if they are, their looks don't matter all that much), so there are loads more options to hide them properly.
If you want to see a conduit, don't put a facade on it... Conduit facades are used specifically (and pretty much ONLY, as water, lava or mobs are already blocked by the conduit itself) to HIDE conduits, and now they're not hidden, so from my point of view the current situation is most definitely a bug.

It is called a design decision - and I like transparent facades.

As you pointed out, either way some people will be unhappy.
As of 1.9 things like torches and anvils can be used to paint facades which makes hiding the conduits silly

Why not have both? Why do we have to have one or the other?

@CrazyPants : I haven't played 1.9 yet so I'm not quite sure I follow.
There is no longer a need for a painting machine as its function has been superseded by torches and anvils? As much as I try to see the logic behind that, it doesn't tell me what that has to do with how a facade behaves?
On the other hand, if you mean you can paint a facade to look like a torch or an anvil, well, torches are special anyway so I'm not sire what my opinion is, but an anvil is opaque so you couldn't see the conduit anyway (outside of its hitbox or whatever it's called).
@MatthiasMann : I like transparant facades too, but now they're only partially transparant :) I am curious why you would want to facade a conduit if not to hide it though? Is it for consistency when you have a line of conduits going perpendicular through a window?
@bookerthegeek : Though more work for the devs, it would address the issue brilliantly. For instance the current recipe for a facade but with an ender pearl in the center spot to have the conduit take a short hop through "somewhere else" so you don't see it in that block?

to me its HOW i want it to look.
I WANT to hide the cables.. I don't WANT to HAVE to use a wireless light.. since there is LITERLLAY no way to not charge EVERYTHING and only power the lights.
so please put it back.. or make wireless ligths need to LINK to the power source and not just charge everything.
I literally had a issue where I had my based wired up with wireless lights and somehow was charging EVERYTHING on the server..
seriously.. someone 5k blocks away was getting there jetpack charged by me..
and i had gone 60k away and was being recharged by a bug..
Since then i don't WANT wireless lights..
so again its the asthetics..
and if its as"

mindforger commented on Mar 15

sorry to say that, but not beeing able to hide cable properly and using glass to make them invisible is very cheap thinking

if its "CHEAP THINKING" then wireless would not be a issue at all..
maybe have it both ways.. the painter has a option to hide or not.. this way we can have both options and both of us be happy?

We understand what you want - but as you said yourself there are just as many (if not more) people who like it the way it is now. And logically - it makes more sense. Why would glass make conduits invisible?
As for the reason WHY you would use a transparent facade, perhaps on a floor, to make it smooth? Or just for aesthetics to give a "see-through" view into your wiring? There are tons of reasons. In the end, if you don't like it, use an opaque block as your facade, or use wireless lights. If there is a bug with those then report/confirm it, it is not relevant here.
In the end it is just a design decision that we have made, and we don't plan to undo it.

No, it doesn't make sense. Why would a block designed to hide something not hide something?
Where did I say something about lights? And an opaque block in the middle of a glass windows isn't very aesthetic...
So, basically, you've taken away functionality that has been part of the mod since the beginning, what was working as designed, which bothered nobody for three years, and you don't give an alternative, making the description of the block inaccurate (to the least) in the process. From your very own wiki: "The conduit facade allows you to hide conduits behind a block". Well, they don't... And yes, of course you can update the wiki, but you are just fundamentally changing what the block does. It's like you change the SAG mill to smelt ore to ingots instead of dusts and call it a day...

"Cover" not necessarily means "hide".

Indeed it does not (though that is by far the most common use), so it's a good thing we're discussing something designed to hide instead of to cover :P

Since topic is closed already, I see no point in dragging this… discussion.
The only possible followup is topic lock, and I really don't want to get that kind of attention.

Why would a block designed to hide something not hide something?

Because the block is transparent? Because you painted it as such?

I'm done discussing this. The decision is final, the behavior will not be reversed. All devs are in agreement. You are welcome to suggest alternatives in a separate issue, but "transparent facades show conduits" is not a bug.


Bug: Fix pagination design issues.

update left and right arrows to the correct version.

remove hover effect from "..."

@LeoT7508 feel free to add any other issues that you see.

Slim chevron being updated under #1038


VS Code not opening from terminal.

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

VS Code Version: 1.64.0
OS Version: Windows 10 - 20H2 (OS Build 19042.1466)

Extra VSCode information:
Version: 1.64.0 (user setup)
Commit: 5554b12acf27056905806867f251c859323ff7e9
Date: 2022-02-03T04:22:20.678Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.19042

Steps to Reproduce:

Open the terminal and cd to a directory
Use the command code . to open the entire directory in VS Code

Expected Result:
Open the directory in VS Code.
Bug:

code : The term 'code' is not recognized as the name of a cmdlet, function, script file, or operable program. Check
the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ code .
+ ~~~~
    + CategoryInfo          : ObjectNotFound: (code:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Extra Information:
Previously, I was able to open VS Code from the terminal using the code . command.
But all of a sudden, without making any changes, this command has stopped working and displaying the error.

Update
I was able to fix this issue by re-installing VS Code.

But, I would still like to know the reason behind VS Code not opening from terminal even when it previously worked.

I got the same issue. Got it working by copying the .vscode-server-server/bin/5554b12acf27056905806867f251c859323ff7e9/bin/remote-cli/code to .vscode-server-server/bin/5554b12acf27056905806867f251c859323ff7e9/bin/code.

I got the same issue. Got it working by copying the .vscode-server-server/bin/5554b12acf27056905806867f251c859323ff7e9/bin/remote-cli/code to .vscode-server-server/bin/5554b12acf27056905806867f251c859323ff7e9/bin/code.

I tried that, now it's complaining about .vscode-server-server/bin/node: not found 😅

I confirm the issue. I have a working setup of macOS laptop connecting to remote ubuntu desktop. After I have updated today to 1.64, I'm no longer able to open anything from the terminal using code <file> or code <folder>.

I confirm the issue. I have a working setup of macOS laptop connecting to remote ubuntu desktop. After I have updated today to 1.64, I'm no longer able to open anything from the terminal using code <file> or code <folder>.
Though I did not try reinstalling code yet.

Yes, the bug seems to occur after updating to 1.64.
The only fix that seems to be working is just reinstalling VSCode.

I've tried reinstalling VS code both host and client, but it did not work for me. It only worked when I installed older (1.63) release of the VS code client version.
My client OS is MacOS Monterrey (M1), host is Ubuntu 18.04 x64.

Here's what happened:
Setup:  Windows 10 21H1, WSL 2 running Ubuntu 20.04 LTS

VSCode auto-updated when I closed it (Windows UI).
running code . from WSL2 lead to it downloading + extracting version 5554b12acf27056905806867f251c859323ff7e9 of the remote, then failed with ~/.vscode-server-server/bin/code: not found
Then I copied ~/.vscode-server-server/bin/5554b12acf27056905806867f251c859323ff7e9/bin/remote-cli/code to ~/.vscode-server-server/bin/5554b12acf27056905806867f251c859323ff7e9/bin/code, after which it failed with ~/.vscode-server-server/bin/node: not found
Then I opened VSCode regularly through Windows, and opening WSL directories/files from there works fine
After that, opening directories from the cli via code  works again

After the update it's important that users also update to the matching Remote-WSL extension: v0.64.2.
This happens automatically but might require a restart of VS Code.
.vscode-server-server is caused by running an old version of Remote-WSL with VS code 1.64.
It can be deleted.

@morkovka1337 Can you explain more what your setup is? Are you using the Remote SSH extension?

same issue here. I access remote ubuntu 20.04 container in ubuntu 20.04 desktop via vscode remote-ssh and encounter this issue after upgrade vscode to 1.64. the Remote-SSH plugin version is 0.70.0.

@morkovka1337 Can you explain more what your setup is? Are you using the Remote SSH extension?

Yes, I'm using remote-SSH extension v 0.70.0.

The issue with Remote-SSH is https://github.com/microsoft/vscode-remote-release/issues/6289.
The restored integrated terminal does not contain the new PATH.
The workaround is to close the integrated terminal (use the trashcan in the view toolbar) and open a new one.
env | grep remote-cli should then return the PATH.

@morkovka1337 I think the problem is that you have "terminal.integrated.inheritEnv"; false configured. That doesn't go well together with the code command in the integrated terminal in remote windows. Can you set it to true?

@morkovka1337 I think the problem is that you have "terminal.integrated.inheritEnv"; false configured. That doesn't go well together with the code command in the integrated terminal in remote windows. Can you set it to true?

@aeschli Yes, seems like this solves the problem, thank you!

VS code isn't in path.


[CLEANUP] JSON Input Step Sonar Cleanup

:white_check_mark: Build finished in 2m 39s
Build command:
mvn clean verify -B -e -Daudit -amd -pl plugins/json/core

:ok_hand: All tests passed!
Tests run: 80, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message


broken link to documentation

on this page:
https://github.com/Microsoft/vsts-rm-extensions/tree/master/Extensions/IISWebAppDeploy/Src
WinRM: IIS Web App Management: Create or update IIS websites and app pools. The task's detailed documentation is in the source repo.
link is broken

Hey!
I would like to take up this issue, please. :smile:

Done. :+1:
(Also, thanks for clarifying which Version we have to link it there beforehand - I had added links to both versions' README in my commit earlier) :smile:


Patelchandni/ziptoperror

Only for function app with run from package setup, if we get "Offset to Central Directory cannot be held in an Int64" error, then adding a retry to download zip file again and extract triggers.

please rebase and squash to one commit once ready for review.

Adding @eliaslopezgt for review as well.


"There's not a page or function yet at /search"

With the Gatsby 4.x update for this starter, the application now 404's in development mode if you press the back button in your browser after having submitted filters on the search archive page.
This is reproduced by:
1: Running gatsby develop
2: Selecting any method of filtering (so anything that adds URL parameters) on the archive at "/search".
3: Visiting a product page that is a result of this filtering.
4: Navigating back to the search archive with the browser back button.
This now gives you the Gatsby development 404 error message, which looks like this:

I noticed this, since I was trying to migrate a Gatsby 3.x.x Shopify application to v4 - and I can therefore confirm that this wasn't happening before the v4 update.
Tested with a clean clone of the main repo, with my own access tokens.

My understanding is that '/search' is now server-side rendered. I'm curious to know how this should be deployed on a manual deployment and not using Gatsby cloud!

Maybe gatsby serve

My understanding is that '/search' is now server-side rendered.

Yes, I see that the approach towards fetching products has changed from the 3.x version (Understandably). I think the bug I describe, is somehow Gatsby related, though. If you simply resubmit a URL which makes your development server 404 under the conditions that I describe above - the correct view is actually rendered. So, if you simply hit enter after clicking in the address bar when you get this error, you are taken to the correct state of the application.
Whether or not this is related to the SSR that has been implemented - that I don't know enough about Gatsby to speak on.
I'm hoping that there are brighter minds here, who can provide some insight into why this might happen when a browser "back" button is clicked only. Could it perhaps be 'Back/forward cache' related?

I will also just note, that the exact same thing happened in the application that I was trying to migrate, which was how I noticed. No SSR on any page there. Upgrading from Gatsby v3 to v4 seems to have caused this issue.

I'm not having this issue with the back button (when using gatsby serve).  However I've noticed that I can't use a frontend proxy (like nginx) it always returns a 404 when attempting to reach /search. If I run gatsby serve by itself and access via port 9000 in the browser the search page functions as it should.

If I do a gatsby build and deploy those files then /search still 404s.

If I do a gatsby build and deploy those files then /search still 404s.

Keep in mind, if you aren't deploying to Gatsby Cloud, you are going to need to either deploy to a provider that supports Gatsby's runtime SSR functionality that was introduced in v4 such as Netlify with the plugin @netlify/plugin-gatsby and gatsby-plugin-netlify. Make sure to get the beta version of each.
If you are deploying to a VPS, you'll need to run a node process via gatsby serve, which has been re-worked in v4 so now it is designed for production use.

Before this issue gets derailed, I'd just like to reiterate that the 404 issues i describe in my OP occur even though SSR functionality isn't implemented. Updating this starter to Gatsby V4, without implementing the SSR changes that were made to search.jsx in conjuction with the v4 update, still produces this behavior.
The question is, if this is actually a framework issue?

If I do a gatsby build and deploy those files then /search still 404s.

Keep in mind, if you aren't deploying to Gatsby Cloud, you are going to need to either deploy to a provider that supports Gatsby's runtime SSR functionality that was introduced in v4 such as Netlify with the plugin @netlify/plugin-gatsby and gatsby-plugin-netlify. Make sure to get the beta version of each.
If you are deploying to a VPS, you'll need to run a node process via gatsby serve, which has been re-worked in v4 so now it is designed for production use.

thanks. It took a while to get that clarified regarding VPS use!

I am also having the same issue. search page works locally but gives me 404 page on Netlify.

@yohdev-von in my case, The server side rendered pages that use getServerData works fine locally. it only gives me 404 page on Netlify. I was able to address this issue by installing @netlify/plugin-gatsby (this one will be installed automatically for Gatsby sites on Netlify) and gatsby-plugin-netlify plugins.
The reason why you get 404 on production is that for Server side rendering you need to have running NodeJS server(gatsby serve).
FYI - https://github.com/netlify/netlify-plugin-gatsby/#readme


Update Github Action: generate-counter.yml

Changing the workflow to be triggered on changes to main as this repo doesn't have a master branch

Thanks @josehelps


Add unit test support

Description
This pull request adds a unit testing API.
New helpers:
InteractorTestHelper
NodeTestHelper
ParentNodeTestHelper
To make testing easier you can use:
FeatureStub
NodeViewStub
instead of relying on mocks.
Check list

[ ] I have updated CHANGELOG.md if required.
[ ] I have updated documentation if required.

Would you mind going through the PR and adding new lines where you see the red circle icon that shows there is a missing new line? I will be introducing detekt in the future so hopefully we won't need to worry about mentioning this on a PR.

Done

Can you also update documentation/setup/downloads.md?

Updated docs as well, thank you!


mantlui: update to 0.4

update to 0.4, which adds health checks
visual diff: https://github.com/CiscoCloud/mantl-ui-frontend/commit/37ea0e74ccd879d58aea08c486670134a12546dd

Tested on openstack. :+1:


A note about auto-openning NERDTree

In the readme FAQ, you have the following Q:

How can I open a NERDTree automatically when vim starts up if no files were specified?

and the answer:
autocmd StdinReadPre * let s:std_in=1
autocmd VimEnter * if argc() == 0 && !exists("s:std_in") | NERDTree | endif

Which interfere with session. If there is a session, opened with gvim -S x.vim, for example, the NERDTree will automaticly openup, which is not needed 99% my bet. So, this:
autocmd StdinReadPre * let s:std_in=1
autocmd VimEnter * if argc() == 0 && !exists("s:std_in") && v:this_session == "" | NERDTree | endif

..may suit better. Or, maybe, wrap it into function and use setting, like:
let g:NERDTreeOpenWhenNoFile=1

This is in the realm of user customization, to be done only in the .vimrc. No new function or setting. I will update the readme.

Roger that :+1:


ansible_default_ipv4.address cant detect public ip for build-scaleway-ubuntu1604-armv7-1 and -2

Ansible isnt able to detect the public ip address for the machines build-scaleway-ubuntu1604-armv7-1 and -2.
On other machines, the ansible variable ansible_default_ipv4.address is equal to the public/external ip address, but for these two machines, it is equal to the private ip adresses
On -1 for example
"ansible_default_ipv4.address: <IP_ADDRESS>",
This causes hosts_file tasks in the adopt_etc role to enter this address in /etc/hosts, causing an improper entry, causing errors such as https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues/1907

ansible_ssh_host is another ansible variable for a machine's public ip. Could use this instead of ansible_default_ipv4.address, but would like to better understand why these ansible isnt able to detect the public up using ansible_default_ipv4.address

build-alibaba-ubuntu1804-armv8-1 and build-scaleway-ubuntu1604-x64-1 are experiencing the same issue

Closed as https://github.com/AdoptOpenJDK/openjdk-infrastructure/pull/1996 is merged


calculon console throws: AttributeError: 'NoneType' object has no attribute 'core'

Fresh git pull, calculon display works fine, but console fails with:
$ calculon console
Traceback (most recent call last):
  File "/usr/local/bin/calculon", line 9, in <module>
    load_entry_point('calculon==0.1', 'console_scripts', 'calculon')()
  File "/Library/Python/2.7/site-packages/calculon-0.1-py2.7.egg/calculon/main.py", line 78, in main
    args.func()
  File "/Library/Python/2.7/site-packages/calculon-0.1-py2.7.egg/calculon/main.py", line 50, in console
    calculon.V = VoltronProxy()
  File "/Library/Python/2.7/site-packages/calculon-0.1-py2.7.egg/calculon/voltron_integration.py", line 45, in __init__
    self.connect()
  File "/Library/Python/2.7/site-packages/calculon-0.1-py2.7.egg/calculon/voltron_integration.py", line 103, in connect
    raise e
AttributeError: 'NoneType' object has no attribute 'core'

Should be fixed in deed0886ea6e49cae1fb51a7ebfd0ef5dc70e3ca

Should be fixed in deed0886ea6e49cae1fb51a7ebfd0ef5dc70e3ca

Confirmed working.

Confirmed working.

Great thanks.

Great thanks.


Update for Senses

Closes #84
This update seems to always capture the senses on a statblock across multiple imports in a session
It also supports multiple special senses
Tested with importing Chimeron and Durixaviinox back and forth

ahh yes, I didn't account for my own tunnelvision haha, totally forgot those were there I will make sure to test against them, and good to know about the autoDebug


CAMEL-20237: camel-platform-http-main - Make it possible to configure http auth

Description
Authentication is configured similar to session management in camel-platform-http-vertx.
In vert.x order of adding AuthenticationHandler matters (see https://groups.google.com/g/vertx/c/6lSKBWzK2pE).
Handlers for routes farther in the url path should be added first, that's why we are sorting AuthenticationConfigEntries by path length.
Tracking
https://issues.apache.org/jira/browse/CAMEL-20237

/component-test camel-platform-http-vertx camel-platform-http-main

/component-test camel-platform-http-vertx camel-platform-http-main

Can you add a bit of docs into the doc file inside src/main/docs folder

Can you add a bit of docs into the doc file inside src/main/docs folder

added some description of how default auth works and how to set up custom auth


Can not handle 204 no content for updating resources.

http://jsonapi.org/format/#crud-updating-responses-204
204 no content is a valid response, but it does not trigger any update on the Resource that was updated (since deserialize has nothing to do).

This is mostly an issue in https://github.com/pixelhandler/ember-fetchjax. Which decides that a 204 response should have it's own handler that returns an empty string. The regular success handler is not called, and the resolved promise shows no sign of a 204 response (an empty string as response is not a good way to check if this was a 204).
Which means there is no way to single out these requests and handle the updates/state on the just-updated-resource.
To fix this, I have sent in this PR on ember-fetchjax.
That PR will break EJR however. I have some EJR changes/patches coming up to (hopefully) completely fix relationship tracking which rely on that ember-fetchjax PR though.

@aars If I recall, I added the special "No Content" handler to accommodate behavior from JSONAPI::Resources gem in the Rails app I worked on while developing the library. Which should be based on this part of the spec:

http://jsonapi.org/format/#crud-creating-responses-204

Note: If a 204 response is received the client should consider the resource object sent in the request to be accepted by the server, as if the server had returned it back in a 201 response.

@aars If I recall, I added the special "No Content" handler to accommodate behavior from JSONAPI::Resources gem in the Rails app I worked on while developing the library. Which should be based on this part of the spec:

http://jsonapi.org/format/#crud-creating-responses-204

Note: If a 204 response is received the client should consider the resource object sent in the request to be accepted by the server, as if the server had returned it back in a 201 response.

I guess I figured an empty String '', was better then an undefined or null response. But yeah sounds like we should revisit that.


User should see progress of faceverification

In the past we showed the user progress since it takes time to finish all steps

checking duplicates
checking liveness
enrolling
whitelisting

can we use zoom current UI to change the label with current step?

Most probably, we can’t do it.
We have to listen Gun then update some label
But during the http call new Zoom UI shows only the progress bar with label. We have setOverrideResultScreenSuccessMessage but i'm not sure it could change 'uploading' label too. If there are no possibility to change ‘uploading’ label in the ZoomCustomization - then it’s impossible
To make own overlay over Zoom progress bar is a bad idea, from my point of view:

we’ll have to research Zoom’s styles & HTML to understand how to do it
we’ll have write own styles for our overlay. We’ll have to render it some way, so it will be direct DOM access - another dirty hack in the React app
As Zoom provides full UI and provides list of the customizations could be applied, there probably are some limitations what we could change. And probably if we’ll render something over their’s UI we could have our account locked
Anyway we could add the workaround on the Web only as Gun exists for browser & node only. And we can’t expose RN code to be used in the native (only opposite).

If setOverrideResultScreenSuccessMessage could update ‘uploading’ message - we could listen session changes via Gun and update label (Web Only)

I've checked - setOverrideResultScreenSuccessMessage() couldn't update label on  overlay with the progressbar
By Zoom's design, we could change this text in the scope of localization. But localization and other customization could be performed before initialize ZooM only. During session running, providing custom i18n string form zoom_result_facemap_upload_message key don't have any effect.
I found a simple hack -
document
            .querySelector('#zoom-upload-progress-message p')
            .innerHTML = `any html here`

but as i've mentioned above
a) it will work web-only as it's direct DOM manipulating
b) not designed by Zoom and not a React-way
c) we don't know how does Zoom react on this hack. They have commented some params of ZoomCustomization as removed, because "they are frequently misconfigured by developers". They don't like when we're expecting their DOM tree - on active manipulations with Chrome Developer Tools Zoom terminates FR session immediately. So, here's a probability that out accounts could be locked
I don't recommend to use the hack found but the final solution  will be yours of course

ok thanks.
i think we will return response before whitelisting and add another screen
for waiting for whitelisting.
the message for failure can be customized right?

@tomerGD @LiavGut
do we show another screen when waiting for whitelisting?
or just keep it as is?

@sirpy Keep it as is, for now.


[feat] Remove client

Client logic has been extracted to https://github.com/neogeek/websocket-game-lobby-client

Codecov Report

Merging #30 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #30   +/-   ##
=======================================
  Coverage   87.17%   87.17%
=======================================
  Files           2        2
  Lines         156      156
  Branches       36       36
=======================================
  Hits          136      136
  Misses         20       20

Impacted Files
Coverage Δ

src/datastore/ephemeral.ts
83.33% <ø> (ø)

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 03a05bc...0e55b49. Read the comment docs.


Update RJSF styling for tooltip.

Description
This PR fixes RJSF styling for tooltip.

reduce font size
improve header

Notes for Reviewers
Signed commits

[ ] Yes, I signed my commits.

Still draft?


Cannot install .NET Core on debian

sudo apt-get install dotnet-sdk-2.2
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package dotnet-sdk-2.2
E: Couldn't find any package by glob 'dotnet-sdk-2.2'
E: Couldn't find any package by regex 'dotnet-sdk-2.2'

What instructions did you use? What OS release are you running? This error is unfortunately very general. The most common cause is using instructions that don't match your distro or distro version.

Have you already done this: https://dotnet.microsoft.com/download/linux-package-manager/debian9/sdk-2.2.300 ?

Closing due to lack of response from OP.


Added hybrid parallel ViLT

An MPI-backended Colossal-AI implementation of Vision-and-Language Transformer using 1D tensor parallel and data parallel.

Thank you for reviewing. The commit is edited as requested.

Hi @ExtremeViscent  Could you cancel the review request for FrankLeeeee? This prevents other reviewers' action.


iOS devices not getting push ID

Home Assistant release with the issue:

0.87.1
Last working Home Assistant release (if known):
0.87
Operating environment (Hass.io/Docker/Windows/etc.):

Ubuntu 16.04
Virtual environment
Component/platform:
iOS

Description of problem:
iOS component fails to get push ID.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
ios:

Traceback (if applicable):
The notify.ios platform was loaded but no devices exist! Please check the documentation at https://home-assistant.io/ecosystem/ios/notifications/ for more information

Additional information:
I've attempted the steps described here twice as a method of troubleshooting but had no success.
Here's what my app looks like:
Screenshot 1
Screenshot 2

Same issue.  My iPhone which I registered when running 0.84 has a push notification ID.
However, my wife's iPhone that I setup today while running 0.87 does not get a push notification ID.

Same situation here, followed the same steps.  Running 0.87.1 in docker.  2 iPhones, 3 iPads all same.

Same issue here. Running 0.87.1 in Docker. 2 iPhones.

Same, Docker with 1 iPhone working and 2 not.

same, 0.87.1, iPhone.

dito. iPhone 6s with iOS 12.1.4 and Home Assistant 0.87.1 on Raspberry

ios 12.1.2 iphone xr ,HA 0.87.1, I also reproduce this issue.

Same here, Iphone X HA 0.871
Wife is on Iphone 6 plus and works perfectly.


[DIR-652] Instances Filter

Preview link: https://direktiv-ui-refs-heads-sebastianarmbrust-dir-652-inst-fltr.direktiv.dev/sebxian/instances
Description

Adds filters to instances. Where the old UI had input fields that were always visible, the new UI only has an "Add filter" button that opens a menu. In the menu, users can in two steps (1) select the field to be filtered and (2) enter a value.
Filters that have been set appear as buttons above the instances table. The value in these buttons can be clicked, which opens a menu to edit the respective filter value.
Filters can be removed by clicking the "x". When filtering by name, deleting the query also removes that filter.
When filtering by date, the workflow is different from the old UI. When a filter by date is first created, only a date picker is shown but no time of day can be specified. Once a date filter has been added, the filter button can be clicked to refine the time.
Filters that use Inputs do not update the filters as soon as the value is changed by typing. The new value has to submitted by hitting enter. A follow-up issue (DIR-705) has been created to add a submit button to the input as soon as the respective UI component has been implemented.

To do

Investigate why Playwright tests often fail in the CI for this branch. May or may not be related to my changes.

Notes / Feedback requested

Note: There is a bug in the API. Before and after do the opposite of what you would expect. This should already be fixed, but not in the version on the frontend test server.

Here are some specific things I would like to receive feedback:

When filtering by status and trigger, the value displayed on a defined filter button is not translated, but the string that is actually used in the query is rendered. This is apparent when the option "cloud event" (translated) is clicked, which is displayed as "cloudevent". It should be possible to translate this value (with some extra code required due to typescript), but it could be argued that it is actually better to show the exact value to users that they would also find in other places (for example, in the logs, or when using a cli tool). In that case, one could even argue some of the other labels in the menus shouldn't be translated either.
Filter field "Trigger" was "Invoker" in the old UI, but is "TRIGGER" in the API. I think trigger is easier to understand in any case and we shouldn't use different labels to avoid confusion.
I thought about componentizing the filter buttons further to make the code drier. But did not see easy ways to do so (without leading to problems with TypeScript due to merged types in JSX return blocks).
The Filters component has gotten a bit long for my taste. It might be possible to separate the code into smaller components (for example, the filter buttons for existing filters could be separated from the main menu), but I hesitated to do this as it would involve a lot of prop drilling (or maybe introducing useContext()). The reason for this is that all the popover menus need to be handled in the main component's scope. Any suggestions on how to approach this are welcome (or maybe the code is acceptable for now).

@stefan-kracht regarding consistent terms, I updated the table header "invoker" to "trigger" in bf2d4aabe243c1d4181e77367334bb82218b1178
I didn't update variable names in the backend because I realized that the inconsistent naming is actually in the API. The property in the "instances" model is called "invoker", but the filter param is called "TRIGGER".
In 5ef0729c6a5165ef667dec29c7997a201110567e, I removed the translations for the enum filter values in the dropdown menu (those are used under trigger and status). Now they are 100% identical with what will be shown on the filter button (but there were only whitespace differences anyway). It did look a bit better before and we could always revert this if that's a problem.

@stefan-kracht I reset the offset when updating filters here: 03974c148ee89ddebd4e66f629a8421ce956e2a0
Good catch, that's something I normally do, but forgot this time.

@stefan-kracht I followed all your suggestions (except one noted below), please go through my commits and let me know what you think!
As discussed in person, I didn't update the styling for the filter buttons to leave that for a separate issue.
Also, I'm not sure I like removing the filters from the menu when they have been defined. If they are always (and redundantly) in the + button menu, some users may find it easier to find a filter via this menu and change the value than find the correct filter button. I think I prefer the redundant version (but I don't feel strongly about it).


Improve multithreading support

Last year Paradox developer Mathieu Ropert published a blog entry pointing to some potential enhancements in PhysFS regarding multithreading ( https://mropert.github.io/2020/07/26/threading_with_physfs/ ).
We are unaffiliated with Paradox or any Paradox products, but we encounter comparable performance problems in one of our projects when loading resources through PhysicsFS. Since modern APIs like Vulcan support multithreaded model-loading and since many machines now feature four, eight or even more cores and with ever-increasing SSD speeds, it is unfortunate that when using PhysicsFS, loading can effectively only be done on one thread at a time.
Is there any chance to see this bottleneck in PhysicsFS addressed in the future?

I've had that blog post open in a tab for months, but haven't had a chance to work on this yet. But yes, I'd like to resolve this issue and will try to find time to do so soon.

waiting for it

Okay, so I looked at this, and reading from a PHYSFS_File does not hold the state lock as far as I can tell, which is where most of your time would be spent (either waiting on file i/o or decompressing). We've always said that it was safe to read from handles from any thread, as long as you don't read from the same handle on two threads at the same time, and this still seems to be the case: PHYSFS_read() and friends don't grab the big global lock when you call into them.
However, PHYSFS_enumerate() does, which is to say: if you've set up your threaded loader to look like...
void myloader_on_a_thread(const char *dir_to_read_from)
{
    PHYSFS_enumerate(dir_to_read_from, load_an_enumerated_file, NULL);
}

...each thread is going to block all the others until the entire directory is enumerated, because that does hold the state lock, and if the app's enumeration callback actually loads each file during enumeration, that will effectively serialize the whole effort. While this can be worked around by the app, what I'm describing is definitely a PhysicsFS deficiency.
Going to look further into this; we can very likely make the locking more fine-grained and solve this problem without changing the API or changing thread safety guarantees in unreasonable ways.

Confirmed with Mathieu that this is happening during enumeration, so I'll figure out how to fix that.


Upgrade to Python 3 (or introduce bilingual compatibility)

As per subject.

Triggered by https://github.com/gavanderhoorn/ktransw_py/issues/15#issuecomment-476335996.

Closing as #22 was merged.
Seems rossum is compatible with both Python 2 and 3 (right now at least), so this was less work than expected.


In fmt.Errorf, should we use %w replace %v?

(This is used to request new product features, please visit https://discuss.istio.io for questions on using Istio)
Describe the feature request
In fmt.Errorf, use %w replace %v.
Such as:
diff --git a/tools/docker-builder/docker.go b/tools/docker-builder/docker.go
index 9fc6a9a1d5..c13d8e921c 100644
--- a/tools/docker-builder/docker.go
+++ b/tools/docker-builder/docker.go
@@ -112,7 +112,7 @@ func CopyInputs(a Args) error {
                        args := bp.Dependencies()
                        args = append(args, filepath.Join(testenv.LocalOut, "dockerx_build", fmt.Sprintf("build.docker.%s", target)))
                        if err := RunCommand(a, "tools/docker-copy.sh", args...); err != nil {
-                               return fmt.Errorf("copy: %v", err)
+                               return fmt.Errorf("copy: %w", err)
                        }
                }
        }

Or, Is there any particular reason why we use %v?
Describe alternatives you've considered
Affected product area (please put an X in all that apply)
[ ] Ambient
[ ] Docs
[ ] Dual Stack
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Additional context

This doesnot matter. Please keep away from https://github.com/istio/istio/wiki/Development-Conventions#superfluous-changes


Memory Leak in EFM Plugin

Describe the bug
In our application we've two aurora databases each with an own jdbc connection. Through our monitoring we found that our pods randomly restarted due to out of memory. After some investigation we found out that the software.amazon.jdbc.plugin.efm.MonitorImpl of one of our jdbc connections stopped working and we don't saw any exceptions. In this case it collects software.amazon.jdbc.plugin.efm.MonitorConnectionContext objects in the newContexts queue. In one of our heap dumps we found out that in the newContexts queue were over 4000000 objects.
This screenshot from one of our heap show that the first instance is stopped=true with over 411MB of objects in the newContexts queue. The second one is the one which is working it no objects in the newContexts queue.

Expected Behavior
No memory leak.
What plugins are used? What other connection properties were set?
auroraConnectionTracker,failover,efm,iam
Current Behavior
Randomly the Monitor stopps and objects are stored in newContexts but they won't ever be removed.
Reproduction Steps
We couldn't find any reproducer as we just observed this behavior randomly without any pattern.
Possible Solution
At least catch and log RuntimeException and return an appropriate ConnectionStatus object in software.amazon.jdbc.plugin.efm.MonitorImpl#checkConnectionStatus to avoid that uncaught runtime exceptions stop the monitoring thread without shutting down the monitor completly.
Additional Information/Context
No response
The AWS Advanced JDBC Driver version used
2.2.2
JDK version used
zulu 11.0.17
Operating System and version
Distroless Docker Image at AWS EKS

Hi @chr-fritz,
Thanks for reaching out and raising this issue.
We'll take a look at this and keep you updated as we investigate.
Thank you for your patience!

Hi @chr-fritz,
We've recently merged some changes (PR #676) that updated our monitoring implementation and added additional logging. I understand that you aren't able to reproduce this consistently, but would you be able to check out our snapshot build with driver logs enabled (logs can be enabled as seen here) and let us know how that goes?
Thank you!

Hey @crystall-bitquill,
I'm also experiencing the same issue reported here. I've using a snapshot build and getting the following log line (identifying details removed). I'm thinking we need to include the exception type in the log line.
WARNING: Continuing monitoring after unhandled exception was thrown in monitoring thread for node <clustername>-02.<removed>.us-west-2.rds.amazonaws.com: null
Nov 14, 2023 9:23:23 PM software.amazon.jdbc.plugin.efm.MonitorImpl run

Hi @andrecloutier-pd,
Thanks for trying out the snapshot build and for letting us know about the logs. There were some changes merged recently (PR #718) that make the logger message include the entire exception. Could you kindly check out the latest snapshot build and let us know how that goes?
Thank you!

I wonder if this is the same issue? Two days ago we got a budget warning from AWS. Something had generated a few gigabytes (or hundreds of dollars depending on how you want to measure it) of cloudwatch log entries. The CPU was spinning on 100% generating the output in the image as fast as it could.
No wonder AWS is big business for Amazon

Hi @kimble, thank you for reaching out with this information.
The driver logs thrown by the monitoring thread are necessary to inform the user of potential monitoring problems. This info can help the user and team diagnose and address issues that may arise. However, we understand that the volume of logs generated by this particular scenario was greater than you expected. To address this, we have created PR #751, which lowers the logging level for the particular messages you are seeing to avoid potential surprises for other customers. Thank you for raising your concern. Please note that you can also filter the logs using the properties file. For example, to filter out the logs in the posted image you can add the following line to your .properties file:
software.amazon.jdbc.plugin.efm.MonitorImpl.level=OFF

Regarding the memory leaks issue, we have made improvements to the monitoring objects to ensure they are synchronized and the driver does not cache references to them in PR #718.
We will keep you updated for when we create an official release containing this fix.
In the meantime, could you please help us further improve our driver by checking out our snapshot build containing changes from PR #751 and PR #718, and send us the unhandled exceptions your application is throwing so we can triage it?

Hi @kimble, thank you for reaching out with this information.
The driver logs thrown by the monitoring thread are necessary to inform the user of potential monitoring problems. This info can help the user and team diagnose and address issues that may arise. However, we understand that the volume of logs generated by this particular scenario was greater than you expected. To address this, we have created PR #751, which lowers the logging level for the particular messages you are seeing to avoid potential surprises for other customers. Thank you for raising your concern. Please note that you can also filter the logs using the properties file. For example, to filter out the logs in the posted image you can add the following line to your .properties file:
software.amazon.jdbc.plugin.efm.MonitorImpl.level=OFF

Regarding the memory leaks issue, we have made improvements to the monitoring objects to ensure they are synchronized and the driver does not cache references to them in PR #718. We will keep you updated for when we create an official release containing this fix.
In the meantime, could you please help us further improve our driver by checking out our snapshot build containing changes from PR #751 and PR #718, and send us the unhandled exceptions your application is throwing so we can triage it?

Reducing the log level will probably just hide the problem that there is a thread consuming 100% printing the lines from my screenshot over and over as fast as it can.

and send us the unhandled exceptions your application is throwing

Not sure what you mean by this?

Hi @kimble,

The logs will only be printed if you choose to enable FINEST/DEBUG level logs. You can also disable logging for that particular thread.
We have released v2.3.1 containing fixes from #751 and #718. Could you please give it a try? If the issue persists can you please send us the driver logs related to the issue?

Hi all,
We've recently added an experimental Host Monitoring Plugin (PR #764) to the driver, called the Host Monitoring Plugin v2. More information can be found here. The Host Monitoring Plugin v2 is functionally equivalent to the Host Monitoring Plugin and they are configured using the same parameters. The Host Monitoring Plugin v2 was created to address the issues that you all have been experiencing, and it is meant to be a more stable version of the Host Monitoring Plugin.
As it is currently an experimental plugin, please note that it should be tested before being used in a production environment. This plugin can be tried out by using the snapshot build aws-advanced-jdbc-wrapper-2.3.2-20231213.213138-10.jar. For more information on using a snapshot build, see this page. If you are able to test out the plugin, please let us know if you encounter any errors or if this plugin was able to resolve the issues you've encountered.
Thank you!

Hi all,
Heads up that the aforementioned experimental Host Monitoring Plugin is now available on our latest release of the driver.
Also wanted to reiterate that it is currently an experimental plugin that should be tested before being used in a production environment.
If you are able to test out the plugin, please let us know if it resolves these issues or if there are any other issues encountered.
Thank you

Hi all,
Heads up that the aforementioned experimental Host Monitoring Plugin is now available on our latest release of the driver.
Also wanted to reiterate that it is currently an experimental plugin that should be tested before being used in a production environment.
If you are able to test out the plugin, please let us know if it resolves these issues or if there are any other issues encountered.
Thank you


:sparkles: convert genotypes from top to forward

Description

SNPconvert.py was modified to convert data into forward coordinates
Related Issue

closes #111
Motivation and Context

These changes are required if we need to convert data to forward coordinates, for example to create a VCF file
How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Refactoring (non-breaking change which improve code itself)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

coverage: 94.311% (+0.003%) from 94.308%
when pulling 7ac8fa63c7de447ff4f9e63a543d6b58b0e2d12c on issue-111
into bd0c5e6375a79287db2109cbec7fe8886ae24107 on devel.


Add dark mode for better eye comfort

Implemented dark mode color scheme
Added dark mode toggle functionality
Improves accessibility and reduces eye strain

@Bilalkamal  Hi and thank you for this PR
It is something I wanted to do for a while and I simply lacked the time so your work is very valuable
That being said, there's a few things to consider before merging this:

First, there has been many refactors and the merge looks pretty tricky

While this is a good start, the general looks of the darkmode should be polished a bit before pushed to production
Here's an example of a design I had in mind

There's a little fade-in animation when switching mode (on the github icon and some of the footer text) I don't know if it's intentional but I think it's a bit distracting

Let me know if you want to keep working on this PR or if I should take it from here, anyway thank you very much

Hey @cyclotruc!
Thanks for the feedback! I'll simplify the changes to make merging easier. Regarding the design - while the blue looks great, a darker shade would be gentler on the eyes when viewing larger result boxes. Would you be open to exploring a darker shade?
I love using Gitingest and dark mode felt like a natural addition. Happy to continue refining the PR, though!
Keep up the good work!

@Bilalkamal You're right it should probably be a darker shade for the main menu element since the goal is to reduce eye strain
You are very welcome to keep working on this PR if you'd like
Or start a new one to avoid the current merge conflicts
Feel free to pick colors that seem fitting to you we can always adjust later
And you can also give me access to your branch so I can help you
Thank you again!


Numbered links stay on after switching apps

Steps to reproduce:

Switch from Lagrange to another app via Alt+Tab.
Switch back to Lagrange.

Result:
The links are now numbered.
They stay numbered, no matter how you switch back (both Alt+Tab and via other methods).
They stay numbered between page reloads and navigating to pages in the same tab.
They disappear on scroll or switching tabs.
They disappear on pressing and releasing Alt.
Expected result:

Numbered links do not stay on after switching out of the app.
Numbered links do not stay on after navigating to a different URL.
Numbered links do not stay on after reloading the page.

I think this bug is one of the reasons I was so confused by the variety of the link icons -- they were unexpectedly changed for me when returning to the app :laughing:

Fixed in dev branch

3b0e44c should take care of all three of the expected cases.


V2.7 branch timing related fixes

Pull in changes from several related backports
#52867
#53183
#52832
Fixes https://github.com/zephyrproject-rtos/zephyr/issues/41111
Related https://github.com/zephyrproject-rtos/zephyr/issues/53605
To address the issue above, we have dropped commit 662f37d9066402d1532eb98f17d65c98f578c09d (consistent with main).

I'm unable to reproduce this locally in v2.7-branch or the pull request
twister -i -p qemu_x86_nopae            -s tests/kernel/mem_protect/userspace/kernel.memory_protection.userspace

@andyross - setting this to high priority because we're aiming to release v2.7.5 in a few days.

Also, it looks as though the Backport Issue Check is a false positive - if you click through to the actual check, it seems to have passed, but the status was not updated in the PR.
CC @stephanosio

Removing high-priority here. The more pressing high priority backport is for mbedTLS


Can we upgrade the version of the arrow?

I use connector-x and datafusion got this error.
mismatched types
expected reference `&Vec<datafusion::arrow::record_batch::RecordBatch>`
   found reference `&Vec<arrow::record_batch::RecordBatch>`
perhaps two different versions of crate `arrow` are being used?rustc[E0308](https://doc.rust-lang.org/error-index.html#E0308)

Detail info: https://github.com/apache/arrow-datafusion/issues/2090

@zemelLeong the upgrade should be pretty straight forward, let me know if you need any help with this.

@zemelLeong the upgrade should be pretty straight forward, let me know if you need any help with this.

I'll try it today.

Hi @zemelLeong  sorry for the late reply. I just upgraded the arrow version to 9.0.0 (the same with with current datafusion release).
I also found that the main branch of datafusion is 11 so this version might need to be upgraded again. Please feel free to submit a PR if you need it later. Basically you need to set up the version at both here and here.


Use a well-behaved default target_transform for default_collate

Use a default target_transform which is well-behaved for the default_collate function (i.e. which converts class augmentations to integers)
Addresses #27 @tesfaldet

Just tried it and it works perfectly for me!


Skewed textures on IE11

On IE11, textures get skewed if they are not on the first texture slot.

if only one texture is set per StateSet : everything works fine
if additional textures are set on the same StateSet, the new textures will get deformed. The first texture will still have a correct mapping thought.

On Firefox 49 :

On Internet Explorer 11, you can see the first texture (small checkerboard) still being rendered correctly, but other textures that are above it are skewed :

Test case :
IE11-multi-texture-bug.zip

Not sure we can do something to fix it, Do you have the same issue with edge from MS ?

No, it works fine with Edge.

Ok so probably it will be never fixed in ie11. I close it.


Gabor/nixpkgs 23.05

This is needed for tracking ic-hs which did the jump recently. nixpkgs-22.11 got deprecated too.
Wasmtime generates different errors on trapping now.
Remains to be debugged:

[ ] why is shell failing in CI, but not on the M1 Mac?
[ ] why is the hash updater failing?

Would be good to have the shell built though

Sure, I'll debug, but if it remains mysterious then I'll leave an issue. Also I wonder if @crusso can enter nix-shell on this branch.

Would be good to have the shell built though

Yep this is fixed now. unit tests now use the .so-toolset for OCaml. Do you think there is a catch?


Use fixHtmlCmdFunc to ensure event-handlers are installed after the DOM is updated

Use fixHtmlCmdFunc to ensure event-handlers are installed after the DOM is updated

Fixes #1801

So, I'm actually not sure if this will work… In the delta bit, I think it's fine. But, in the case of the JqAppend and friends, these are JsExps. That means it can stand in wherever a value is expected, except using fixHtmlCmdFunc would emit JS that wouldn't allow that, I think? That's why there's a distinction between fixHtmlFunc and fixHtmlCmdFunc to begin with—fixHtmlFunc wraps everything in a JS IIFE with a final value of the original JsExp.
I wonder if the right way to fix this issue isn't to rewrite fixHtmlFunc to do this:
((function() { var result = <original JsExp>; <extracted commands>; return result; })())

I think this is incidentally also more in line with what would be the expected behavior of invoking this JS with an HTML block that contained a script block—executing it before the block has been acted on could yield some pretty funky results, including exactly the one we ran into here where the JS expects the content to already be in the DOM.
To be clear, I think the conversion of the things inside new JsCmd to use fixHtmlCmdFunc was correct no matter what we do with the rest.

Actually I'm still not sure if that'll work either… Because these are designed to be chained with ~>, so the result of the overall expression would go after a ., I think. If that's the case, then we would end up with something like $('#id').((function() { ... })()), which isn't valid JS.
The solution in this PR is valid only as long as you do a single method call—e.g. $('#id').append('one thing')—but the API is designed to take multiple—e.g., $('#id').append('one thing').append('another thing'). This approach would fall down because we'd get:
$('#id')
  .append('updated thing'); extractedJS;
  .append('another thing'); extractedJS;

Once again, invalid JS... Oof, this is a tough one 😞
Could be that fixHtmlFunc just calls appendJs. Basically runs through, extracts the JS from the content, runs S.appendJs with that JS, and returns the updated content. No IIFE, no extra JsCmds, etc.

Are there extra changes in this PR that don't deal with the core bug? I'm a bit confused at how all of this relates to the bug as described in the original issue.
That said, revisiting the original issue:

installing eventhandlers on elements which has not yet been inserted into the DOM

Am I crazy or does this sound like more of an ordering issue than a JsExp or JsCmd issue?

This is an ordering issue, but it's an ordering issue that gets at the fundamental underlying way that JsExp and JsCmd are designed to differ—JsExp as a vehicle for pieces of a JS expression, and JsCmd as a vehicle for a whole JS expression. Both can potentially reference HTML, and the HTML can in turn potentially contain event handlers, which need to be separated out for execution as separate commands. So the ordering issue blossoms in complexity because we are worried about two orderings: one, making sure event handlers are installed after an expression's HTML attaches to the DOM, and two, making sure that event handler attachment happens after a JsExp's chained form has been put into a command, i.e., making sure they are appended as JS after whatever final containing JsCmd is built from the JsExp.
We can also manage this on the client via a lift.nextTick or direct call to setTimeout.
Lastly, no matter what we do, we'll need unit tests for this so we're not tripped up by it in the future.

@Shadowfiend Will those unit tests need to run JS in a browser environment?

No, that would pretty much be an integration test by definition. We just need to basically confirm that the JS looks like what we expect it to.

Ok, understood. I asked because in my vdom branch, @blmeadows and I have used HtmlUnit to accomplish this. I agree that it's integration testing at that point, but I rarely take time to split those hairs. :)

Ok, just looked at this again. I was wrong about this:

these are designed to be chained with ~>, so the result of the overall expression would go after a .

If we look at the invocations in the code base, we see patterns like this:
  case class JqAppend(content: NodeSeq) extends JsExp with JsMember {
    override val toJsCmd =
      "append("+fixHtmlFunc("inline", content){a => a}+")"
  }

Here, we apply fixHtmlFunc to the passed content, but then we pass the result itself to the append function, so that doesn't go after append.
However! This brings up a very interesting note: if there were ever a script element in content that referred to other stuff in that same NodeSeq, the above approach, which is the current one, would not work! This is because we wouldn't actually run the append until after the IIFE is invoked, therefore after the script that expected the element in question to already be in the DOM ran.
Net-net, my concern with the initial suggestion for fixing fixHtmlFunc is really maintaining “bug-parity” with the current Lift 2.6… Except the framework now triggers that bug consistently heh. I think for Lift 3.0.0, I'm going to rewrite fixHtmlFunc to use setTimeout (rather than add to the public API of lift.js) and then we can see if there's a better way after we get the initial release out the door.

@andreak can you try the branch shadowfiend-changes-to-fixhtmlfunc and tell me if that fixes your issue? And if not, any chance you can put up a sample project that exhibits the problem? I'd like to get this knocked out soon.

First; I think this is a serious issue that needs to be fixed before 3.0 goes final.
Second; We need to make this work with potential script-elements in content, and have them evaluated before a potential chained call to another JqSomething. If not it will require at least us (Visena) to still have our custom version of these JqAppend-like classes.
I really don't like the approach with setTimeout, I'm sorry but it is a code-smell and it seems hacky. We should find a better way, although I'm not sure what that is. I'm sure we can figure this out though.
I see that my proposed solution using fixHtmlCmdFunc does not work with chaining so that needs to be fixed as well.
I'm in Bulgaria with my 9-year old daughter  this week (training camp) so I'm not able to be too creative here, but will try to give it some thoughts.

Hmmm… When you get back from vacation, can you lay out why the JS needs to be executed pre-DOM-append? The problem for me is that having that JS evaluated before a chained call is an actively broken model, IMO. The simplest example of this is the following construction:
Jq("#my-element") ~>
  JqAppend(
    Group(

Show me!

    )
  )

It is incorrect to execute that script until after the new element has been appended (and won't work otherwise anyway). Now, when it's laid out as above it's easy to fix. But imagine you had a snippet that included JS like the above that could be rendered in a regular snippet or could be rendered as a JQuery append expression. The execution of that script is no longer the same in the two cases.

Btw, I do agree that using setTimeout is in general dirty and a smell. However, we're at this point deep in the RC cycle for Lift 3, and Lift 3's been on the docket for a while. Moreover, using setTimeout is an internal implementation detail (i.e., not part of public API).
I think the correct solution to this is to have JsExp track its internal JS and the HTML-extracted JS independently and only combine them when it is converted into a JsCmd—at which point no further chaining is possible. This also allows a custom JsExp at the end of the chain to change the way/order that the extracted JS is executed. But, this is an invasive change, and I suggest that we could implement this more correct version in Lift 3.1, transparently to most framework users.

Another option is really to just provide a flag to disable event extraction, or disable event extraction automatically when inline scripts are allowed in the SecurityRules ContentSecurityPolicy.

Note that I'm not advocating that the embeded JS needs to be executed pre-DOM-append, but before a potential chained call.
Take this:
JqId(JE.Str(uid)) ~> Append(content) ~> JqSlideDown(600)

What I mean is that if content contains script-elements, they must be evaluated before the call to JqSlideDown()

So, all JS (both the event-extraction code and in script-elements) from content must be evaluated before the chained call to JqSlideDown. My point is that we'll be having a hard time doing that with the setTimeout-approach, unless I'm missing something?

You're right… Unfortunately I think we have to choose either before inserting the content, or after any chained calls. Each case has its own problems, and neither is strictly correct. Only the latter works for extracted DOM event handlers.
I don't think we can execute any JS after the current chained function actually executes, but before the next one does… Will keep thinking on it though.

@andreak any updated thoughts on this? Thinking of opening a PR to allow for disabling event extraction and perhaps disable it by default in Lift 3…

How should we proceed on this PR given that we've shipped @Shadowfiend's fix?

I think we'll need to decide which path is the “correct” one—probably best done on the ML. The ultimate solution will have to be different than what's here, as it will be more core—would be down for closing this PR. While we wait on what @andreak thinks, I'll drop the milestone on the PR.

@Shadowfiend @andreak Ping, this has been here for awhile now.

Posted this ML thread to pick up the question of what to do. Closing this PR as the code here can produce invalid JS; we'll pick it back up in issue #1801 once we see what happens on the ML.


[ConstraintSolver] Extend position tracking to SubtypeOf constraints

While trying to find potential bindings for type variable mark if it's
located on the right-hand side of the subtype-of constraint, so it could
be de-prioritized in favor of bindings found for the left-hand side,
with all else equal.
Resolves: rdar://problem/22898292

@swift-ci please smoke test

@swift-ci please test source compatibility

@rudkx looks like that didn't work either :(

@swift-ci please smoke test

@rudkx Looks like putting the check at the end of the tuple make it better - only 1 test failure where before stdlib couldn't compile, i'll figure out what is going on. But since tuple comparison is lexicographical it's better to keep the flag at the end so if there are better bindings for the right-hand side they are attempted.

Ok, so it looks like subtype-of (and most likely bind-param too) is not going to work as just a boolean flag, because it is very contextual, it need to be applied to disambiguate situation between two type variables associated by the same bind-param or subtype-of constraint otherwise it just pushes incorrect bindings to the top which then produces no solutions like in the example of test/Migrator/tuple_arguments.swift...

It doesn't happen currently because 99% of the BindParam are contracted away by contractEdges so that flag is never set, otherwise test/Migrator/tuple_arguments.swift would have failed too.

I've opened PR with alternative approach which makes type variable selection for contextual https://github.com/apple/swift/pull/11747.


working with multiple folders from Metrichor

Probably not an issue but more of a question. Will poretools recursively work through the "batch" folders that are now spit out by Metrichor for 1D reads? The new Metrichor output puts called reads into separate folders of 4000 reads.
I tried poretools stats pass/batch_1487*/*fast5 but receive an "Argument list too long" error. Do all the reads need to be in a single folder for poretools to function?
Thanks!
Jarrod

One problem with that command is that it will retrieve all of the files and tries to pass it on the command line, which obviously does not work because there are tons.  You might be able to get it working with poretools stats pass/batch_1487* (i.e. just the folder names), but even that will fail with a sufficient number of reads.  As a short fix you could either move all the reads into one folder, or link them symbolically.
@nickloman maybe it would be reasonable to provide a recursive search for fast5 files

The current version in github conducts a recursive search. If you build from the repo, the following command should work:
poretools stats pass/batch_1487*/

Hmm. I don't think it is actually doing anything recursively...
`$ poretools fastq  --group 001 workspace/pass/*/ > reads_001.fastq
WARNING:poretools:Cannot open file: workspace/pass/0/. Perhaps it is corrupt? Moving on.
WARNING:poretools:Cannot open file: workspace/pass/1/. Perhaps it is corrupt? Moving on.
WARNING:poretools:Cannot open file: workspace/pass/10/. Perhaps it is corrupt? Moving on.
...Am I missing something? Ideally, I want to pull all the fastq files from the albacore/workspace directory, but as far as I can tell, poretools fastq  --group 001 workspace///.fast5 > reads_001.fastq
`
is choking due to the '' expansions on the command line.

Just try
poretools fastq --group 001 workspace/pass

Yes, that works much better :+1:

I'm having this same problem with Albacore produced batch folders - when I give the path to the workspace directory containing the batch folders, I get this error: WARNING:poretools:Directory is empty!
When I use workspace/*/, I get the same error as above, WARNING:poretools:Cannot open file: workspace/0/. Perhaps it is corrupt? Moving on.
Thanks!

@joshualoving as @arq5x  mentioned you should pull in the latest version from the git repo (the recursive subfolder code was fixed here). Then you can just run  poretools fasta workspace/ and it will parse all the subfolders inthere as well.

I cloned and built from the repository and still had the problem. Do I need to clone a particular commit/branch?
Thanks!

Hi @joshualoving I don't know if you got it to work or not however I was having the same problem and I was able to get it to work. First I deleted the poretools folder and reinstalled from the repo using the following command
git clone --recursive https://github.com/arq5x/poretools
I don't know if recursive is needed or not I just didn't want to lose a package.
Hope you got your question answered!
Sean

poretools fasta barcode03.fastq > barcode03.fasta
WARNING:poretools:Cannot open file: barcode03.fastq. Perhaps it is corrupt? Moving on.
i m getting this error after running above command. Please help

Poretools works on the fast5 file not the fastq file. You would want.to run poretools fasta barcode03/ > extract_fasta.fasta if you are working with the fastq files you could use seqtk


Redis pub/sub: delete entry on successful ACK

With Redis pub/sub, entries aren't automatically evicted from the server after an XACK command, which can lead to an ever-growing memory usage.
We should either perform XDEL on an entry after a successful XACK automatically or opt in for it with a metadata option like deleteEntryAfterAck: true/false.

Whoever works on this: Please base your work on top of this PR: https://github.com/dapr/components-contrib/pull/2228
Do not merge your PR until 2228 is complete. Thanks!

What happens if Dapr crashes after the XACK but before the XDEL?

I have a question, how to make sure this message has acked by all consumer groups?
I don’t know in current situation our redis pub sub component whether has multiple consumer groups. If does, should we use some extra efforts to make sure this message has also confirmed by other consumer groups before we delete it.  As I know, currently redis hasn’t provided an api to check the message consuming progress.
https://github.com/redis/redis/issues/8392

If the Redis entry isn't scoped to a consumer group then we can't use XDEL because there isn't a way to guarantee an ACK from all consumer groups.

If the Redis entry isn't scoped to a consumer group then we can't use XDEL because there isn't a way to guarantee an ACK from all consumer groups.

So what do you mean entry scoped to a consumer group? Is that mean this is only one consume group that will consume the entry/topic?
Is there any api/way to get this information?

Closing as there isn't an API in Redis to support getting ack info for consumer groups.


Generating bipolar signals

We've been running WaveDrom happily on Windows 10 for generating digital signal timing diagrams. However, in a new project, we need to document bipolar waveforms. Is it possible to do this with WaveDrom? While multiple analog voltage levels would be great, just three levels would be something we could get away with.

Could you add a drawing of the bipolar waveform? Is it a trinary signal, or some sort of differential?

I think the two biggest cases would be bipolar encodings like AMI in the example below:

The other use case is return-to-zero encodings like in this example:

It would also be useful for diagramming states of outputs from H-bridges, e.g. voltage to motors. However, I think that too much feature creep could lead to trying to graph analog voltages, which is probably beyond the scope of WaveDrom.

Yes, this seems like useful feature, but lay aside of current tool.
It can be implemented as part of analog waveforming story, once we decide what is the best way to represent analog descriptions.
Related to: https://github.com/drom/wavedrom/issues/68

You can sort of get this by using the 'z' element:
For the AMI signal in your example:
{ name: "AMI", wave: '1z0z.101z.0z'}

or we can introduce a new character - fro 0.5 level ?

@superlou My apologies for resurrecting a very old thread.
We are working on creating an extensible framework for WaveDrom, and I believe that we should be able to address the 'bipolar signals' requirement now with reasonable effort. We have already got trigonometric waveforms and 'async' waveforms (similar to what is supported by SchemDraw) working with the new framework, and would like to add bipolar signals support also.
Can you please let us know how you might want to specify the diagram ? Something on the lines of:
{
  name: 'AMI', wave: [ 'bipolar',
    { 'seq' : '01101', 'type': ('ami' | 'rtz'), ... ??? }
  ]
}

What other attributes do you envisage being necessary for the bipolar waveforms? Do you want the colors to be configurable? If so, how would you like to specify that?


Re-render datetimepicker

I have one datetimepicker that depends on another one, so depending on the date that is chosen on the first one, the selectable dates should change on the second one.
on the first time that happens because of the beforeRender function, but how to re-render second datepicker after a change in the first one?

Did you ever find a solution for this?

Cool, looking forward to it.

Why did you close? is it not an issue anymore?

You said you were gonna do a PR so I can wait for the PR.


The default frame setting question

Why the first_frame is default to be 5 and last_frame to be 260 , is there any reason or consideration to set the default value.

Yes, you're right. But there might be some issues in the first/last frame due to indexing problems. Feel free to create PRs.


Add documentation working group notes from 06-12-2020, 06-19-2020

Signed-off-by: Michael Dolan<EMAIL_ADDRESS>

I'll merge this tomorrow if there is no additional feedback.


Hey,
I didn’t add this feature, but you can enable and modify it in the swift.py code.
It's not my priority right now, but I’ll add it to my list.

Hey,
I didn’t add this feature, but you can enable and modify it in the swift.py code.
It's not my priority right now, but I’ll add it to my list.

I will try. Thanks


James/vib 814

What/Why?
Text on add to cart button should be localized inside of the ProductDetail component.
Testing

enable a secondary local in /core/i18n/routing.ts like 'es'
Navigate to a PDP and prefix the URL /es/
button text should change

https://github.com/user-attachments/assets/deb14f7b-a666-4d26-9a47-d51436b9f9fd

Looks good @jamesqquick. You'll have to rebase ad resolve the conflict, though.

@migueloller done! I don't know if I'm allowed to merge or not lol I'll wait for you. If I need to rebase again in the morning I will

@migueloller done! I don't know if I'm allowed to merge or not lol I'll wait for you. If I need to rebase again in the morning I will

If it’s all green, go for it!


Fixed affinity CLI parameter.

The line threadAffinity = getParam("setAffinity", threadAffinity);
evaluates to 0 or 1 if the parameter exists, which is not a valid enum (AFFINITIZE is 1, DEAFFINITIZE is 2).
It is set as a boolean in OSPCommon.cpp line 119.

Thanks for finding this bug! I ended up fixing it in a slightly different way (see c50e5ddef), but this PR made it dead simple to spot. The fix is on both release-1.6.x and devel. Thanks again!


[transformers snippet] Support pipeline VLMs

Description
Rn, if you go to conversational VLM like Llama-3.2-11B-Vision-Instruct, you would not receive high-level pipeline snippet.
On the contrary, if you go to conversational LLM like Llama-3.1-8B-Instruct, you will receive high-level pipeline snippet.
https://github.com/huggingface/transformers/pull/34170 was merged. Therefore, now we can add pipeline snippet for VLM.
Here is an example snippet, one would get
# Use a pipeline as a high-level helper
from transformers import pipeline

image_ny = "https://cdn.britannica.com/61/93061-050-99147DCE/Statue-of-Liberty-Island-New-York-Bay.jpg"
image_chicago = "https://cdn.britannica.com/59/94459-050-DBA42467/Skyline-Chicago.jpg"

pipe = pipeline("image-text-to-text", model="meta-llama/Llama-3.2-11B-Vision-Instruct")
pipe(
    images=[image_ny, image_chicago],
    text="<image> <image> Are these the same cities? If not what cities are these?",
)

The example is super nice, but not all image-text-to-text models support multiple images reliably. I'd go for a simpler single-image example for now.

Agreed with this! another problem is that although most models use the <image> token, some models use a different token. For example, Pixtral uses [IMG], and mllama uses <|image|>, so this snippet would not work with these models.
However since you have this check:
if (model.tags.includes("conversational") && model.config?.tokenizer_config?.chat_template) {

It would be even better and simpler to also use chat template for vlms also, with something like this:
image_ny = "https://cdn.britannica.com/61/93061-050-99147DCE/Statue-of-Liberty-Island-New-York-Bay.jpg"
image_chicago = "https://cdn.britannica.com/59/94459-050-DBA42467/Skyline-Chicago.jpg"
messages = [
    {
        "role": "user",
        "content": [
            {"type": "text", "text": "What’s the difference between these two images?"},
            {"type": "image"},
            {"type": "image"},
        ],
    }
]
outputs = pipe([image_ny, image_chicago], text=messages)

I completely agree with @yonigozlan best to have chat template


Additional model fields

Hi
Great library. Worked first time. Just wondering if there is a way to add additional model fields to the upload form which can then be accessed via the signal. e.g. I have a file description and checkbox that need sending along with the file.
Thanks

Closing this since it's working with fineuploader, and that's the recommended js library!


Latest version not available via Homebrew

Question
0.4.48 was released one month ago but multiple colleagues have reported that installing shopware-cli via Homebrew installs version 0.4.47

Related to https://github.com/FriendsOfShopware/homebrew-tap/issues/1

Is fixed https://github.com/FriendsOfShopware/homebrew-tap/commit/01ab15135e4944964f090994cd43c894038d70ef


Added Install Instructions for Other Distros

Since I had to look a little to find the Gentoo equivalent of libxdo-dev, I just added the installation instructions for some other distros.
I'm unsure if libx11-devel is necessary for Fedora, though I included it just in case. I only tested the Gentoo one, though I'm confident the others will work.

Thank you for merging it!


Component failure in case there is more than one installation

In my account, there are 2 alarms registered, one active, the other no long in use.
This causes the API to fail
Logger: custom_components.securitas.securitas_direct_new_api.apimanager
Source: custom_components/securitas/securitas_direct_new_api/apimanager.py:102
Integration: Securitas Direct (documentation, issues)
First occurred: 7:56:49 AM (1 occurrences)
Last logged: 7:56:49 AM
Lo sentimos. No se ha podido realizar la acción solicitada.

Proposing a possible solution, adding installid optional parameter to the component configuration:
securitas:
username: !secret securitas_user
password: !secret securitas_password
init.py.zip
code:  !secret securitas_pin
country: ES
installid: "123456"
Code changes to handle it attached here...
With this, the component can log and get alarm status after restart, but it seems it is not refreshing status on regular basis (it pulls on start, but then no errors nor information updates)