Refactor virt controller template machine container spec

What this PR does / why we need it:
This PR refactors the virt-controller templating service. It is barely understandable.
It focuses explicitly in generating the specification of containers. It replaces the ad-hoc generation of containers in the virt-launcher pod by using a builder pattern, allowing the customization of the spec via options. It is working for the following containers:

compute
sidecars
init container

Follow up PRs will re-use this approach for the following resources:

env vars
volumes
resources (this one will be tricky ... that code is all over the place)
compute container command
...

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

NONE

/cc @iholder-redhat
Hey; I remember we discussed somewhere in the past refactoring the virt-controller template machine.
Here's my attempt; early feedback is welcome.

@acardace let me know if you feel this PR deserves to unit test this new structure. I actually think it might, but have avoided doing it so far since the templating service is actually unit tested pretty well.

/test pull-kubevirt-unit-test

Awesome! Great to see this, thank you.
Just one suggestion - basically there are two builder styles. The first one being something like:
NewRenderer(name, WithVolumeDevices(volumeDevices), WithVolumeMounts(volumeMounts)).Render()

And the other one being something like:
NewRenderer(name).WithVolumeDevices(volumeDevices).WithVolumeMounts(volumeMounts).Render()

I've always preferred the later, I find it to be more readable and straight forward, and it also eliminates the need of constructing an Option slice (this can be done automatically and internally by the builder behind the scenes). Implementation-wise, the renderer can have another unexposed field, something like options. Then each call to an option method such as WithVolumeDevices() would append the option to the internal slice instead of returning it. Finally, Render() can do the same logic but with the internal slice.
Instead of
if nonRoot {
  options = append(options, WithNonRoot(...))
}

We would have
if nonRoot {
  builder.WithNonRoot(...)
}

WDYT?

Awesome! Great to see this, thank you.
Just one suggestion - basically there are two builder styles. The first one being something like:
NewRenderer(name, WithVolumeDevices(volumeDevices), WithVolumeMounts(volumeMounts)).Render()

And the other one being something like:
NewRenderer(name).WithVolumeDevices(volumeDevices).WithVolumeMounts(volumeMounts).Render()

I've always preferred the later, I find it to be more readable and straight forward, and it also eliminates the need of constructing an Option slice (this can be done automatically and internally by the builder behind the scenes). Implementation-wise, the renderer can have another unexposed field, something like options. Then each call to an option method such as WithVolumeDevices() would append the option to the internal slice instead of returning it. Finally, Render() can do the same logic but with the internal slice.
Instead of
if nonRoot {
  options = append(options, WithNonRoot(...))
}

We would have
if nonRoot {
  builder.WithNonRoot(...)
}

WDYT?

I disagree. I'd rather build the options once, then have them applied at constructor time, rather than allowing the structure to be mutated afterwards. Mutatos are evil.

Awesome! Great to see this, thank you.
Just one suggestion - basically there are two builder styles. The first one being something like:
NewRenderer(name, WithVolumeDevices(volumeDevices), WithVolumeMounts(volumeMounts)).Render()

And the other one being something like:
NewRenderer(name).WithVolumeDevices(volumeDevices).WithVolumeMounts(volumeMounts).Render()

I've always preferred the later, I find it to be more readable and straight forward, and it also eliminates the need of constructing an Option slice (this can be done automatically and internally by the builder behind the scenes). Implementation-wise, the renderer can have another unexposed field, something like options. Then each call to an option method such as WithVolumeDevices() would append the option to the internal slice instead of returning it. Finally, Render() can do the same logic but with the internal slice.
Instead of
if nonRoot {
  options = append(options, WithNonRoot(...))
}

We would have
if nonRoot {
  builder.WithNonRoot(...)
}

WDYT?

I disagree. I'd rather build the options once, then have them applied at constructor time, rather than allowing the structure to be mutated afterwards. Mutatos are evil.

I'm with @maiqueb here, even if in practice for this case there's probably no harm in letting the object mutate before we actually create the VMI allowing the object to mutate afterward makes correctness harder.
If we are to adopt a builder pattern (which would be great) I prefer @maiqueb 's one.

I disagree. I'd rather build the options once, then have them applied at constructor time, rather than allowing the structure to be mutated afterwards. Mutatos are evil.

I'm with @maiqueb here, even if in practice for this case there's probably no harm in letting the object mutate before we actually create the VMI allowing the object to mutate afterward makes correctness harder.
If we are to adopt a builder pattern (which would be great) I prefer @maiqueb 's one.

@maiqueb @acardace
Just to clarify - I do want to mutate only at construction time. It's all a matter of implementation.
I'll try to clarify me idea again - we can add a []Option field to ContainerSpecRenderer struct.
When doing something like that:
if nonRoot {
  builder.WithNonRoot(...)
}

It will, behind the scenes, simply do something like:
func (ccr *ContainerSpecRenderer) WithNonRoot(userID int64) {
    ccr.internalOptionSlice = append(ccr.internalOptionSlice, func(renderer *ContainerSpecRenderer) {
		renderer.userID = userID
	})
}

Meaning no mutation happened yet, only added to a slice. This is exactly what's being done now, the difference being that now the user has to prepare a slice, append new options to it, etc while it can occur automatically behind the scenes. Only at Render() (=construction) time we can iterate through the slice and mutate.
When debugging we would still be able breakpoint at render time and see the mutation happening in a single place, but the code feels nicer when you don't have to worry about constructing a slice of options, which adds burden and makes the code look worse IMO.

/sig code-quality

I disagree. I'd rather build the options once, then have them applied at constructor time, rather than allowing the structure to be mutated afterwards. Mutatos are evil.

I'm with @maiqueb here, even if in practice for this case there's probably no harm in letting the object mutate before we actually create the VMI allowing the object to mutate afterward makes correctness harder.
If we are to adopt a builder pattern (which would be great) I prefer @maiqueb 's one.

@maiqueb @acardace Just to clarify - I do want to mutate only at construction time. It's all a matter of implementation.
I'll try to clarify my idea again - we can add a []Option field to ContainerSpecRenderer struct. When doing something like that:
if nonRoot {
  builder.WithNonRoot(...)
}

It will, behind the scenes, simply do something like:
func (ccr *ContainerSpecRenderer) WithNonRoot(userID int64) {
    ccr.internalOptionSlice = append(ccr.internalOptionSlice, func(renderer *ContainerSpecRenderer) {
		renderer.userID = userID
	})
}

Meaning no mutation happened yet, only added to a slice. This is exactly what's being done now, the difference being that now the user has to prepare a slice, append new options to it, etc while it can occur automatically behind the scenes. Only at Render() (=construction) time we can iterate through the slice and mutate.

You make a good point.

When debugging we would still be able breakpoint at render time and see the mutation happening in a single place, but the code feels nicer when you don't have to worry about constructing a slice of options, which adds burden and makes the code look worse IMO.

While I understand your point, I still prefer the other approach, that clearly communicates to the reader that the options are something only applicable when the builder is created without having to check the builder pattern implementation. Your approach, imo, has that hidden under the hood - which, I understand is exactly why you prefer it.

I disagree. I'd rather build the options once, then have them applied at constructor time, rather than allowing the structure to be mutated afterwards. Mutatos are evil.

I'm with @maiqueb here, even if in practice for this case there's probably no harm in letting the object mutate before we actually create the VMI allowing the object to mutate afterward makes correctness harder.
If we are to adopt a builder pattern (which would be great) I prefer @maiqueb 's one.

@maiqueb @acardace Just to clarify - I do want to mutate only at construction time. It's all a matter of implementation.
I'll try to clarify my idea again - we can add a []Option field to ContainerSpecRenderer struct. When doing something like that:
if nonRoot {
  builder.WithNonRoot(...)
}

It will, behind the scenes, simply do something like:
func (ccr *ContainerSpecRenderer) WithNonRoot(userID int64) {
    ccr.internalOptionSlice = append(ccr.internalOptionSlice, func(renderer *ContainerSpecRenderer) {
		renderer.userID = userID
	})
}

Meaning no mutation happened yet, only added to a slice. This is exactly what's being done now, the difference being that now the user has to prepare a slice, append new options to it, etc while it can occur automatically behind the scenes. Only at Render() (=construction) time we can iterate through the slice and mutate.

You make a good point.

When debugging we would still be able breakpoint at render time and see the mutation happening in a single place, but the code feels nicer when you don't have to worry about constructing a slice of options, which adds burden and makes the code look worse IMO.

While I understand your point, I still prefer the other approach, that clearly communicates to the reader that the options are something only applicable when the builder is created without having to check the builder pattern implementation. Your approach, imo, has that hidden under the hood - which, I understand is exactly why you prefer it.

Your point is valid and I understand your position.
Well, now that we understand each other - we can agree to disagree :smile:

/retest

/test pull-kubevirt-generate

/retest

/retest

/retest

/lgtm
Great work @maiqueb!

/test pull-kubevirt-e2e-k8s-1.23-sig-compute-migrations-nonroot

/test pull-kubevirt-e2e-kind-1.23-vgpu-nonroot

/test pull-kubevirt-e2e-k8s-1.21-operator
/test pull-kubevirt-e2e-k8s-1.21-sig-storage


How to add webpack to an existing HTML project and package it?

I didn't pay much attention to webpack before, but now I encountered an html project that had to be packaged.
Since the official document only introduces configuration examples, it is difficult to have a sense of substitution. I carefully read 1/3 of the official document and took notes. I still have no idea about packaging existing projects.
I configured webpack myself, but I can only package the contents of the leaked files:

How does it package complex project structure dependencies?
For example, I have a project with the following directory structure:

you need different loaders to package your images, CSS, fonts and stuff. Read the docs for more info.

you need different loaders to package your images, CSS, fonts and stuff. Read the docs for more info.

Answer above, and please prefer to use discussions or stackoverflow for questions,  you can copy files using copy-webpack-plugin, maybe you can setup the right publicPath, please provide configuration, otherwise it is hard to say what is wrong, closed because it is question without enough information (it doesn't mean that we don't want to help you), feel free to feedback and we will help

Answer above, and please prefer to use discussions or stackoverflow for questions,  you can copy files using copy-webpack-plugin, maybe you can setup the right publicPath, please provide configuration, otherwise it is hard to say what is wrong, closed because it is question without enough information (it doesn't mean that we don't want to help you), feel free to feedback and we will help


fix discord link in README

jeez, i'm stupid.. :D

no you aren't, you just forgot or haven't tested!

I tested it – by copying the invite code over to Discord. Which probably isn't what most users do.. Thanks for spotting and fixing this. c:

^ unintentional. I'm tired and clicked the wrong thing. ,_,


Don't run slow clang-tidy checks

misc-const-correctness shows an extreme slowdown on large files, causing a >10x regression of clangd reparse time when enabled. Checks are often inadventently enabled e.g. by misc-* globs, as much as we wish this weren't the case. I blocked this check in e78165f0ba1e2fbf72b36a36c8560645b69a168a, but a more systematic approach is needed.
Goals:

don't let slow checks into releases. We can't assume check authors care about clangd.
minimize feature churn between releases
minimize maintenance toil
document some fairly objective standard of "fast" that users and check authors can understand

Plan:

only run "fast checks" by default, as an additional filter applied to checks specified in .clang-tidy etc
keep a static "fast check" list, not a "slow check" list, per goal 1.
maintain this list by benchmarking on a known complex file (suggest clang/lib/SemaExpr.cpp) - addresses goal 4
"fast" means "regresses ParsedAST::build()" by less than 10%
benchmarking is done by a new mode in clangd --check, precise within <5%. Script updates the fast list (goal 3).
avoid noise by using some debounce: add a check to fast list if measurement <8%, remove it if measurement >13%. Addresses goal 2

cc @kadircet as we've been discussing this offline

've been trying to get some checks to work in clangd such as misc-const-correctness but after some debugging  I found this commit:
https://github.com/llvm/llvm-project/commit/e78165f0ba1e2fbf72b36a36c8560645b69a168a
which seems to disable the check completely.
The main issue seems to be that the slow check is automatically enabled by the glob which can be a surprise to users that don't explicitly check all the options.
Is there a way to get the check moved to a non-glob group or something like that, to allow for users that want the check (and the downside) to opt-in to it?
For now I've made a script that runs clang-tidy externally and posts the results, but it would be nice for the developers to not get surprised by the CI when they submit patches.

The main issue seems to be that the slow check is automatically enabled by the glob which can be a surprise to users that don't explicitly check all the options. Is there a way to get the check moved to a non-glob group or something like that, to allow for users that want the check (and the downside) to opt-in to it?

Perhaps this could take the form of a new Allowlist subkey under ClangTidy in the clangd config file, which does not allow globs, and explicitly enables the listed checks, overriding the performance section of the built-in blocklist.

@sam-mccall would you be alright with the suggestion from @HighCommander4 ?
If so I'll take a stab at implementing this over the weekend.

@sam-mccall @kadircet I'd like to pick this up in the next weeks, do you agree with the following plan (from @HighCommander4 )?

Add a AllowList subkey to the ClangTidy configuration group in the clangd config file

Explicitly disallow globs in this key

Any check in this AllowList will override matching keys in the built-in blocklist

I could also add a warning to the clangd logging that lists the blocked keys that were re-enabled to make sure that the users have an easy way to check that the key was really re-enabled.
I'l wait for your approval for a while before starting :)
Since I'm not too familiar with clangd/llvm, I may be missing something so if you can think of any edge cases or problems with the proposed solution, let me know :)

Sorry for leaving this thread unattended for a long while. We iterated over this with @sam-mccall couple times offline, but forgot to leave any artifacts.
Our final conclusions were towards:

Only let people to enable slow checks, and never the crashy checks.
Do this by having a new config option ClangTidy.EnableSlowChecks boolean, that defaults to False. (if need be we can have an orthogonal option to enable crashing-checks).

The rationale for never enabling crashy checks is, in practice that just causes support requests on clangd side that we can't maintain and degrades experience for average user to the point of having an unusable clangd until they do a through investigation (or ask for support).
This still needs us to have a separate list of "slow" checks, @sam-mccall is going to be working on getting that piece landed this week.
What do you folks think about this?

What do you folks think about this?

This approach is nice is simple, and it sounds like  it will handle the issues that have come up so far, such as users wanting to enable misc-const-correctness (which will be in the "slow" list), and users suffering from the hang-prone bugprone-unchecked-optional-access (which is being added to the "crashy" list in https://github.com/llvm/llvm-project/pull/69427).
It wouldn't terribly surprise me if we subsequently get reports about users wanting to enable bugprone-unchecked-optional-access, and in such cases I tend to lean towards letting users shoot themselves in the foot if they really want to :) But we can leave that discussion to later if/when we get such a request.
The only other thing that occurs to me is: might users want to enable e.g. only one check on the "slow" list that they really care about, and not all of them? That would be facilitated by the more granular AllowList configuration. But that can also be considered later, I think it's fine to keep things simple for now.

The only other thing that occurs to me is: might users want to enable e.g. only one check on the "slow" list that they really care about, and not all of them? That would be facilitated by the more granular AllowList configuration. But that can also be considered later, I think it's fine to keep things simple for now.

We pick up rest of the configuration from check-list provided through regular means. I think if the users already got their hands dirty with clangd-config, they can also Add/Remove tidy checks while at it. That way we can avoid yet-another-way to mention checks :D

Ah, good point, they can use EnableSlowChecks: true while disabling the slow checks with ClangTidy: Remove:. Seems like that use case is covered then!

Ah, good point, they can use EnableSlowChecks: true while disabling the slow checks with ClangTidy: Remove:. Seems like that use case is covered then!

How will user know which checks are considered slow/crashy? Figuring them out and removing one by one does not sound very fun. I wish there was a "collective alias" for them, so I could do something like:
Diagnostics:
  ClangTidy:
    Add:
    - '*'
    Remove:
    - slow
    - crashy

It would make sense to support these aliases on clang-tidy side as well, would be handy for .clang-tidy configs.

https://github.com/clangd/clangd/issues/1337#issuecomment-1770214885

Ah, good point, they can use EnableSlowChecks: true while disabling the ones they don't want with ClangTidy: Remove:. Seems like that use case is covered then!

That would require users to have a list available of which checks are slow. Maybe the documentation in https://clang.llvm.org/extra/clang-tidy/checks/list.html could have an extra column added for Good, Slow or Unstable (crashes)

I run clang-tidy on cpp files manually inside CI, but running it is very slow. I'd like to know which checks are slowing down the check. Is there a list or way to do that?

@5chmidti --enable-check-profile is very helpful! I noticed that cert-dcl37-c and cert-dcl51-cpp  as the alises of  bugprone-reserved-identifieris also pretty slow. I disabled it for clang-tidy, but added it back forclangd`.
.clangd
Diagnostics:
  ClangTidy:
    Add: bugprone-reserved-identifier

I wonder if clang-tidy automatically deduplicates the fixes before checking as it seems the aliases are checked twice! They appear twice in --enable-check-profile

@sam-mccall If clangd has FastCheckFilter now, shouldn't -misc-const-correctness be removed from disableUnusableChecks?

@dpar39 could you file a new issue for that please? It's less likely to be forgotten about that way, than a comment on a closed issue.

I already opened one, though not in this repo, but in llvm-project: https://github.com/llvm/llvm-project/issues/89758 (not sure how these two repos are related)

I already opened one, though not in this repo, but in llvm-project: llvm/llvm-project#89758 (not sure how these two repos are related)

Thanks, that works.
(Either issue tracker is fine. This one predates the entire LLVM project moving from Bugzilla to Github.)


Provider should force prepare after setModels call

Q
A

Is bugfix?
yes/no

New feature?
yes/no

Breaks BC?
yes/no

Tests pass?
yes/no

Fixed issues
comma-separated list of tickets # fixed by the PR, if any

Provider should force prepare after setModels call

Why?

$provider = new ArrayDataProvider(['allModels'=>[1, 2]);
$provider->getKeys(); // 0,1
$provider->setModels([1,2,3]);
$provider->getKeys(); // 0,1 but not 0,1,2
because nobody call prepareModels && prepareKeys (from ArrayDataProvider)

It was not intended to use data providers in this way. If you want to change providers' context (pass another set of models) - you must re-create DataProvider object.

forcing prepare on set is against the lazy loading principle. If you change models you have to call prepare() manually afterwards.


Adding moveToFront & moveToBack functions

Hey!
What do you think about adding those functions to the lib ? http://stackoverflow.com/a/14426477/649896

d3-selection now includes moveToFront and moveToBack as raise and lower: https://github.com/d3/d3-selection#selection_raise


Proposal: Adding support for deploying

I've been considering adding support for deploying a project that uses this SDK to a SQL Server as part of a dotnet publish. I have experimented with this and it is fairly easy to extend the publishing pipeline by adding a Publish target to the Sdk.targets file and do something from there. But before I go and implement this I was wondering if this would be considered useful for other folks using this package.
I do see a couple of challenges. First of all, we will need to have sqlpackage.exe to do the actual publishing. On Windows you get this as part of the SSDT tools, but on Linux and Mac there isn't an easy way to acquire it. You would need to download it and then make it available on the path for this package to use it. Or we could include it in this package, but I'm not sure if we're even allowed to redistribute it. Ideally sqlpackage.exe would be available as a .NET Core Global Tool so we could run dotnet tool install SqlPackage but that is not how it has been implemented today. Maybe @dzsquared knows if this is changing at some point?
Of course we'd also need to know the server and database name to deploy to. We could probably use localhost and the name of the project as sane defaults, but allow these to be overridden through properties in the project file.
So basically I'm looking for some feedback on this idea. @ErikEJ What do you think?

Why do we need sqlpackage(.exe) ?
https://docs.microsoft.com/en-us/dotnet/api/microsoft.sqlserver.dac.dacservices.deploy?view=sql-dacfx-150
(Not claiming it will be simple to support all options)

Hmm, yeah, you're right, we don't need to use SqlPackage.exe to deploy it, we could just build a tool ourselves that does it and then run that. Would be quite a bit of work to support all options yes, but maybe we don't need to support them all since it will be mostly used for local development I think.
Maybe we need to rename the current BuildDacpac tool and add the support there, or have a separate tool. They have a different purpose of course, but maybe including yet another tool in the same package is a bit too much overhead. We would be duplicating dependencies in that case.

This has been implemented in #33 and should be released soon as 1.2.0. I'll leave this open until that version is out.

1.2.0 is out on NuGet.org which has support for this. Thanks @ErikEJ for reviewing the change.


getting-started-placeholder

We need this file to exist in order for the clusterctl integration in the capi repo to work.
The PR to capi to allow "clusterctl init --provider kubevirt" fails the tests because the lack of this file.
https://github.com/kubernetes-sigs/cluster-api/pull/6457
What this PR does / why we need it:
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Release notes:

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 45.93%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
711

Relevant Lines:
1548

💛  - Coveralls


Resources don't displayed.

Does this occur consistently? / Yes
Repro steps:

To open App Service resources with Azure extensions - APP SERVICE or FUNCTIONS tab on VSCode.

Even if some app service resources are deployed in my subscription but any resource doesn't see.

I repeated log-out and log-in from Azure but this behavior didn't change. And I can see all STORAGEs under my subscription.

Next I opened VS and I can see app service resources under my subscription.

So I think this problem comes from extension App Service or Functions.
Version: 1.3.0
OS: win32
OS Release: 10.0.19043
Product: Visual Studio Code
Product Version: 1.56.2
Language: ja

A few questions

Can you give more information about your function apps? For example - how did you create them and what options did you choose when creating?
Is there anything you can think of that may be unique about your subscription?
I assume you can see these function apps listed in the portal?

Hi @ejizba
Thank you for your help.
ANSWER

Can you give more information about your function apps? For example - how did you create them and what options did you choose when creating?

I created functions on Azure portal not from Azure CLI or something. And SKUs are different, Consumption, EP or App Service. I think all resource is healthy and stable.

Is there anything you can think of that may be unique about your subscription?

I don't think my subscription is unique.

I assume you can see these function apps listed in the portal?

Yes. All functions can see on Azure portal.
UPDATE
I deleted some resources then it started to display FUNCTIONS on my VSCode. I'm not sure which resource affected. I think some resource returned error then VSCode can't display resources...

I'll try to find out the cause. If you have findings please give comment.

I deleted some resources then it started to display FUNCTIONS on my VSCode. I'm not sure which resource affected. I think some resource returned error then VSCode can't display resources...

Interesting - yeah let us know if you figure out which type of resource may have been causing an error.
Note to self: This may be fixed if we use a Resource Graph query to get sites instead of the Microsoft.Web list api

Asked MS support desk. We can't resolve this issue by ourselves.


Added vtx offset handling to the renderer

I was playing with the new features/additional libraries from https://github.com/TillAlex/ImGui.NET-nativebuild/tree/additional_libraries and had some issues with the ImPlot benchmark (visual glitches).
This PR adds ImGuiBackendFlags.RendererHasVtxOffset to account for larger meshes generated by the benchmark.

^ This is included in the OpenTK example of ImGui.Net and I was wondering why the examples here omitted it.
https://github.com/NogginBops/ImGui.NET_OpenTK_Sample

Thanks @sneusse , merged this in.


Rename module aliasing terms to avoid confusion

The term 'real' and 'alias' cause confusion so rename them to clarify as follows:
s/real/binary
s/alias/syntaxName

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

I like the idea of clarifying the logical/physical split here, I'm just not sure that syntax name is the right term to apply here. I can offer some other suggestions, but I think ultimately I don't object to what you've got here.
-module-alias LHS=RHS

LHS
RHS

Syntax Name
Binary Name

Surface Name
ABI Name

Logical Name
Physical Name

I like the idea of clarifying the logical/physical split here, I'm just not sure that syntax name is the right term to apply. I can offer some other suggestions, but I think ultimately I don't object to what you've got here.
-module-alias LHS=RHS
LHS RHS
Syntax Name	Binary Name
Surface Name	ABI Name
Logical Name	Physical Name

I'm not sure if Syntax name is less clear than Surface name or Logical name. I'm trying go convey that it's the name as written in the source code, which. may or may not be the same as the binary name. I've gotten feedback that the current naming is too confusing and "Syntax" makes it clearer.


#208 make STJ conditional so only included for < net 6

This will make System.Text.Json only necessary on frameworks older than net 6 and hence improve mantainability
Closes #208

@andrueastman all done. I will do the license expression as well now

Agree, we should also ensure license expression is set on abstractions.


chore: use the fixture block_context in transaction_test

This change is

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#1790  👈
#1789
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ArniStarkware and the rest of your teammates on  Graphite

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 75.71%. Comparing base (b8f70b3) to head (aed9142).

Additional details and impacted files
@@                                 Coverage Diff                                 @@
##           arni/chore/test/readablity/parametrize_with_values    #1790   +/-   ##
===================================================================================
  Coverage                                               75.71%   75.71%
===================================================================================
  Files                                                      61       61
  Lines                                                    8675     8675
  Branches                                                 8675     8675
===================================================================================
  Hits                                                     6568     6568
  Misses                                                   1675     1675
  Partials                                                  432      432

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

crates/blockifier/src/transaction/transactions_test.rs line 1375 at r1 (raw file):
Previously, dorimedini-starkware wrote…
are these lines still required?
can you change the fixture to be block_context: &BlockContext?
seems redundant
ditto on the other bc = &bc; assignments

About changing the type of fixture block_context: BlockContext to &BlockContext, I can try doing it in another PR.
About the assignments let bc = &bc. I tried deleting this assignment on each of the 12 instances. Indeed, not required on one of those 12 instances! On the other 11 times - the execute method requires a reference (a &BlockContext).

Merge activity

Apr 14, 11:23 AM EDT: @ArniStarkware started a stack merge that includes this pull request via Graphite.


C script fails to compile with fatal error "__debug not found"

Every time I try to run my program it keeps saying this, can someone help?
In file included from <built-in>:326:
In file included from <command line>:2:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/iostream:38:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/ios:216:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/__locale:15:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/string:439:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/algorithm:628:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/memory:604:
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/iterator:341:10: fatal error: '__debug' file not found
#include <__debug>
         ^
1 error generated.
[Finished in 0.31s]

@artym26 This doesn't look like an error in atom-script actually. Can you provide a simple hello world that reproduces this issue for you? Once we have that we can execute it locally.
The error seems to be that the __debug library isn't in your include path. After googling a bit I found this StackOverflow question.


Add PHP 8.2

Tool name
PHP 8.2
Tool license
PHP-3.01
Add or update?

[X] Add
[ ] Update

Desired version
8.2.0
Approximate size
No response
Brief description of tool
PHP is a popular general-purpose scripting language
URL for tool's homepage
https://php.net/
Provide a basic test case to validate the tool's functionality.
php -v

Platforms where you need the tool

[ ] Azure DevOps
[X] GitHub Actions

Runner images where you need the tool

[X] Ubuntu 18.04
[X] Ubuntu 20.04
[X] Ubuntu 22.04
[ ] macOS 10.15
[ ] macOS 11
[ ] macOS 12
[X] Windows Server 2019
[X] Windows Server 2022

Can this tool be installed during the build?
Yes

Tool installation time in runtime
~2 min
Are you willing to submit a PR?
Yes

Hi @mikhailkoliada
Any update on this?

It has been released.

Will this be available for 22.04 as well?

@igorboskovic3 Is there a reason that Ubuntu 22 does not have PHP8.2? (And is currently supported an outdated version of PHP8.1?)
Meanwhile, Ubuntu 20 supports PHP 7.4, 8.0, 8.1, and 8.2


Add support for premium_tier on guilds (once we know what it is)

Example of a guild object containing this value:
{
  "voice_states" : [],
  "verification_level" : 0,
  "vanity_url_code" : null,
  "unavailable" : false,
  "system_channel_id" : "###",
  "splash" : null,
  "roles" : [],
  // Well would you look at that!
  "premium_tier" : 0,
  "owner_id" : "128316294742147072",
  "name" : "###",
  "mfa_level" : 0,
  "members" : [],
  "member_count" : 11,
  "lazy" : true,
  "large" : false,
  "joined_at" : "###",
  "id" : "###",
  "icon" : null,
  "features" : [],
  "explicit_content_filter" : 0,
  "emojis" : [],
  "description" : null,
  "default_message_notifications" : 0,
  "channels" : [],
  "banner" : null,
  "application_id" : null,
  "afk_timeout" : 300,
  "afk_channel_id" : null
}

Note the premium_tier field above owner_id.

Note that this does NOT mean "immediately open a PR," but rather "we should PR this once we know what it's for / that it won't be removed"

Closed in favour of #329


Implicit int cast to BigInteger during interscore calls isn't supported

In the current goloop version, a method with an int return type from a foreign SCORE is implicitely converted to BigInteger through an interscore call.
Related issue talking about this behavior : https://github.com/icon-project/goloop/issues/65
However, that behavior isn't implemented in javaee-unittest and make the tests fail with a ClassCastException:
this.decimals = ((BigInteger) Context.call(token_addr, "decimals")).intValue();

Such line fails to run because the "decimals" method from IRC2 returns an int natively. The unittest package uses the int return type instead of the BigInteger one.
How hard would it be to fix javaee-unittest in order to copy the goloop engine behavior ?

You might have noticed, I have modified the IRC2 javaee-tokens RI for decimals to have a return type of BigInteger.
https://github.com/sink772/javaee-tokens/commit/a4cad6c4c98a5307fd5a0b7e12e5e032cf64146e
This is just a workaround solution, but I believe you don't need to use int type here if you want to get the value via inter-call.
I think it's better to use BigInterger in all cases for external readonly methods.


Remove debug sections by default

The changes on master Rust insert debug sections now (yay!) but this means that
wasm binaries by default pick up debug sections from the standard library, so
let's remove them by default in wasm-bindgen unless --debug is passed

@fitzgen they're dwarf indeed!

Are they generated even when we don't have debug = true in Cargo.toml etc? It seems strange to me that we should be removing this stuff.

Yes, the standard library comes with debug information and, like Linux, final binaries have debuginfo sections by default in release mode for this reason

Ok. We probably want to separate the idea of debug info and debug assertions at some point in time, but happy to move forward with this for now.


docs: code contribution guidelines point to 404 wiki

The links to the wiki on CONTRIBUTING.rst are broken, i.e.:

sign your commits (http://invenio-software.org/wiki/Tools/Git/Workflow#R2.Remarksoncommitlogmessages)
logically separate commits (http://invenio-software.org/wiki/Tools/Git/Workflow#R1.Remarksoncommithistory)

I failed to find an issue for this until I submitted this one. Closing


Guide for the backend primitives

URL, if applicable
No response
Describe the new content you are requesting.
@ElePT suggested creating a guide for the backend primitives.  This can probably wait until the V2 backend primitives are out. For now, the content has been pulled from https://docs.quantum.ibm.com/verify/simulate-with-qiskit-primitives into https://docs.quantum.ibm.com/run/primitives-get-started
If this new content request is accepted, do you want to write the content?
no

do we have enough content to fill a whole page for this? Or is the small section in the primitives page basically it?

Done


Separated TimeZone core logic from the webservice

I've created a new class to store the core logic (TimeZoneReader) and separated the logic from the webservice so I can have a crack at writing a solution for https://github.com/graphhopper/graphhopper/issues/1259

HOWEVER: I have not compiled the new Jar files or touched anything to do with the Maven files.
I really have no experience working with Maven and would be happier if someone else took charge of that bit if possible? (Or explained to me how to do it properly in Eclipse..)

Thanks a lot!

Or explained to me how to do it properly in Eclipse

You can always verify if the settings work via command line and finally here at github via travis. See this build which is green and is about your current changes. Creating maven sub modules should not be that hard as you create a parent pom linking to all sub modules like core and web and the submodules link back to the parent inside the pom.xml. See e.g. here and here. (Please keep the version at 1.0-SNAPSHOT)

I'm having trouble getting the POM configuration to create a basic .jar file after splitting the project into submodules, as explained on this SO post.. https://stackoverflow.com/questions/21021485/how-to-configure-maven-shade-plugin-in-a-multi-module-project
Is what I've uploaded ok (which creates a timezone-release module as suggested in the SO post), or should I just revert it back to being a single module??

Thanks for your contribution. Would you mind to revert it to the single module? I can setup the modules.

Would you mind to send us an email (https://www.graphhopper.com/imprint/) so that we can send you a CLA? Thanks.

@oblonski - No problem, I've reverted it back! :+1:


Add biweekly option to the repeat interval

Would be useful for people who get their paycheck every two weeks

Duplicate of #8

https://github.com/nlogozzo/NickvisionMoney/releases/tag/2023.1.0-beta3


Thousands of sleeping threads due to restarting service task

We've an application which consists of two container (php, redis). While running it dozens of time upon docker/swarm we some problems running it with swarm mode.
Due to a misconfiguration we had some containers restarting over and over, we have no restart: policy btw., but the php container is recreated every few seconds, tries to connect to a database, which fails and the setup process is stopped.
The issue we are facing is, that on the node on which this is happening, we currently have over 3700 sleeping threads, which won't go away even after removing everything with docker service rm.
Output of ps -eLf
[...]
root     15531     1 11907  0 3605 06:48 ?        00:00:01 /usr/bin/dockerd -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label node=1 --label provider=generic
root     15531     1 12769  0 3605 06:50 ?        00:00:02 /usr/bin/dockerd -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label node=1 --label provider=generic
root     15531     1 12783  0 3605 06:50 ?        00:00:04 /usr/bin/dockerd -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label node=1 --label provider=generic
root     15531     1 12784  0 3605 06:50 ?        00:00:00 /usr/bin/dockerd -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label node=1 --label provider=generic
root     15531     1 14874  0 3605 06:52 ?        00:00:01 /usr/bin/dockerd -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label node=1 --label provider=generic
root     15531     1 15083  0 3605 06:52 ?        00:00:06 /usr/bin/dockerd -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label node=1 --label provider=generic
root     15531     1 15216  0 3605 06:52 ?        00:00:10 /usr/bin/dockerd -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label node=1 --label provider=generic
root     15531     1 15237  0 3605 06:52 ?        00:00:09 /usr/bin/dockerd -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label node=1 --label provider=generic
root     15531     1 15942  0 3605 06:52 ?        00:00:06 /usr/bin/dockerd -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label node=1 --label provider=generic
root     15531     1 17144  0 3605 06:54 ?        00:00:08 /usr/bin/dockerd -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label node=1 --label provider=generic
root     15531     1 17773  0 3605 06:56 ?        00:00:02 /usr/bin/dockerd -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label node=1 --label provider=generic
[...]

Is this a bug or some option we are missing? Engine version 17.07.0-ce

Possibly related: https://github.com/docker/libnetwork/issues/1113
CC: @handcode

Some more information on this...
A: Swarm-cluster created
B: Broken application stack created (restarting due to config errors)
C: Broken application stack removed; broken nginx (see below) stack created for testing
D: Engine restart (due to too many threads?)
E: Recreated swarm-cluster and deployed broken-nginx stack on vanilla setup to verify the issue

Detailed view

Broken nginx stack configuration, deployed with docker stack deploy
version: '3'
services:
  nginx:
    image: nginx
    depends_on:
      - redis
    volumes:
      - /tmp:/etc/nginx
  redis:
    image: redis

We're also verifying this with the same stack running on a single node with docker-compose, but with additional restart options to simulate a similar behavior, seems not to happen here (threads stay on a "reasonable" number)
This is looking pretty serious, since one broken configuration will kill your node within a few hours.

Some more info...
This is how a pstree looks like:
systemd-+-agetty
        |-auditd---{auditd}
        |-cron
        |-dbus-daemon
        |-dhclient
        |-dockerd-+-docker-containe-+-docker-containe-+-redis-server---3*[{redis-server}]
        |         |                 |                 `-9*[{docker-containe}]
        |         |                 |-2*[docker-containe-+-redis-server---3*[{redis-server}]]
        |         |                 |                    `-8*[{docker-containe}]]
        |         |                 `-16*[{docker-containe}]
        |         `-128*[{dockerd}]
        |-fail2ban-server---2*[{fail2ban-server}]
        |-packagekitd-+-{gdbus}
        |             `-{gmain}
        |-polkitd-+-{gdbus}
        |         `-{gmain}
        |-rsyslogd-+-{in:imklog}
        |          |-{in:imuxsock}
        |          `-{rs:main Q:Reg}
        |-sshd-+-sshd---sshd---bash---sudo---bash---watch---watch---sh---pstree
        |      `-sshd---sshd---bash---top
        |-systemd---(sd-pam)
        |-systemd-journal
        |-systemd-logind
        |-systemd-timesyn---{sd-resolve}
        `-systemd-udevd

This line shows the processes/threads getting accumulated:
    |         `-128*[{dockerd}]

other counts stay the same

Ping @thaJeztah - sorry to bug you here, but usually you're the person who knows who can shed some light on such issues :) This is completely keeping us from progressing with swarm mode

Can you add the output of docker version and docker info as well, to give some context about the version that's running, platform, and configuration? Other than the flags set on the daemon (shown in the top comment), do you have any configuration options set (such as a specific logging driver, etc?)

Also, it may be good to get a stack dump from the daemon; you can obtain that by sending dockerd a SIGUSR1 signal, which will produce a stack dump in the daemon logs (or mention a file that it saved the dump in)

System

Docker Swarm (swarm mode)
2 nodes in Debian 9 in VirtualBox VM
Host is Debian 8.7

docker version
Client:
 Version:      17.09.0-ce-rc3
 API version:  1.31 (downgraded from 1.32)
 Go version:   go1.8.3
 Git commit:   2357fb2
 Built:        Thu Sep 21 02:30:17 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.07.0-ce
 API version:  1.31 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   8784753
 Built:        Tue Aug 29 17:41:44 2017
 OS/Arch:      linux/amd64
 Experimental: false

docker info
Containers: 5
 Running: 1
 Paused: 0
 Stopped: 4
Images: 3
Server Version: 17.07.0-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 22
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: active
 NodeID: mag1ux9hbpu4ht3m7hw9y2k82
 Is Manager: true
 ClusterID: n8udy3doioh76n0nahd0f7n21
 Managers: 1
 Nodes: 3
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
  Force Rotate: 0
 Autolock Managers: false
 Root Rotation In Progress: false
 Node Address: <IP_ADDRESS>
 Manager Addresses:
  <IP_ADDRESS>:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 3addd840653146c90a254301d6c3a663c7fd6429
runc version: 2d41c047c83e09a6d61d464906feb2a2f3c52aa4
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.0-3-amd64
Operating System: Debian GNU/Linux 9 (stretch)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 996.5MiB
Name: 49.hz-3.ci20.de
ID: TK43:Z7UR:7KCT:OGQQ:ZSQJ:NDVC:SBAM:JEG7:H2WZ:TUDT:PNW6:P54Z
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
 master=1
 provider=generic
Experimental: false
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

WARNING: No swap limit support

syslog, daemon.log
Last lines of logs - there are literally 10.000s of lines like:
Oct 18 06:41:15 49 dockerd[16012]: time="2017-10-18T06:41:15.413061421Z" level=warning msg="rmServiceBinding handleEpTableEvent a1000_nginx c0b470da70bdb19458b71739ad8ba25b1b2138ce29d3cb60a79f54e86eeb2b2d aborted c.serviceBindings[skey] !ok"

or
Oct 18 07:30:15 49 dockerd[16012]: time="2017-10-18T07:30:15.794025337Z" level=error msg="failed removing service binding for ff251e3002c4d142200bb9d5d777c007c3108e032dc4bd085aca34ee90c117c6 epRec:{a1000_nginx.1.8mg9zapesvy3pjq5qudl9h0jp a1000_nginx pdtkw7qm533i785xpxsortwcl <IP_ADDRESS> <IP_ADDRESS> [] [nginx] [a39bb7ea080b]} err:network y2n9z1cvzyvnu7dtmc7k8uehh not found"

Are you able to reproduce on a 17.09 daemon? Or perhaps better; 17.10, as I see the patch for https://github.com/docker/libnetwork/issues/1934 was included in 17.10, but not (yet) back ported to 17.09; https://github.com/docker/docker-ce/pull/264
/cc @fcrisciani

Yes, I tried it with 17.10 (upgraded all nodes), see this gist for some logs.
On the two workers one gets filled with threads, around 2900 in 24h, while the other gets filled with logs ~7GB in 24h. Both machines close to dying, just because of the one broken config from the initial example.
Can you reproduce that?

@schmunk42 can you attach the go routine stack trace? You just have to send the signal SIGUSR1 to the dockerd.

@fcrisciani This is the log generated by SIGUSR1
https://gist.github.com/schmunk42/2c131c972f95f74ba96cdd38aca34ded
These are entries in daemon.log popping up every few seconds without any trigger, just by running the broken stack
Nov 28 12:54:57 60 systemd-udevd[8706]: Could not generate persistent MAC address for vx-001003-txlxs: No such file or directory
Nov 28 12:54:57 60 systemd-udevd[8723]: Could not generate persistent MAC address for veth65e1074: No such file or directory
Nov 28 12:54:57 60 systemd-udevd[8727]: Could not generate persistent MAC address for veth9b931b0: No such file or directory
Nov 28 12:54:57 60 systemd-udevd[8741]: Could not generate persistent MAC address for veth03f4d2e: No such file or directory
Nov 28 12:54:57 60 systemd-udevd[8744]: Could not generate persistent MAC address for veth7240c7b: No such file or directory
Nov 28 12:54:58 60 systemd-udevd[8873]: Could not generate persistent MAC address for vx-001003-txlxs: No such file or directory
Nov 28 12:54:58 60 systemd-udevd[8880]: Could not generate persistent MAC address for veth9b931b0: No such file or directory
Nov 28 12:54:58 60 dockerd[11717]: time="2017-11-28T12:54:58.477791086Z" level=error msg="fatal task error" error="task: non-zero exit (1)" module=node/agent/taskmanager node.id=joew8i91uii2jxxrg4rf5huvc service.id=yc2k69nxb0e93klatluyo68fm task.id=ehw9fz9p90mzscnanw7x35k78
Nov 28 12:55:10 60 systemd-udevd[8956]: Could not generate persistent MAC address for vx-001003-txlxs: No such file or directory
Nov 28 12:55:10 60 systemd-udevd[8972]: Could not generate persistent MAC address for veth3664dfc: No such file or directory
Nov 28 12:55:10 60 systemd-udevd[8975]: Could not generate persistent MAC address for veth78ca53a: No such file or directory
Nov 28 12:55:10 60 systemd-udevd[8990]: Could not generate persistent MAC address for vetha9bbb84: No such file or directory
Nov 28 12:55:10 60 systemd-udevd[8993]: Could not generate persistent MAC address for veth7c1b114: No such file or directory
Nov 28 12:55:11 60 systemd-udevd[9122]: Could not generate persistent MAC address for veth78ca53a: No such file or directory
Nov 28 12:55:11 60 dockerd[11717]: time="2017-11-28T12:55:11.469510925Z" level=error msg="fatal task error" error="task: non-zero exit (1)" module=node/agent/taskmanager node.id=joew8i91uii2jxxrg4rf5huvc service.id=yc2k69nxb0e93klatluyo68fm task.id=e4t55oeef4xgxdhpc6luuuk86
Nov 28 12:55:12 60 dockerd[11717]: time="2017-11-28T12:55:12.617012600Z" level=info msg="Node join event for 389fba4fb358/XXX.XXX.114.243"
Nov 28 12:55:16 60 dockerd[11717]: time="2017-11-28T12:55:16.710447099Z" level=error msg="fatal task error" error="starting container failed: No such network: a1000_default" module=node/agent/taskmanager node.id=joew8i91uii2jxxrg4rf5huvc service.id=yc2k69nxb0e93klatluyo68fm task.id=has8nrdkx1n6s0vyx29vjtjvq
Nov 28 12:55:19 60 dockerd[11717]: time="2017-11-28T12:55:19.339634446Z" level=error msg="network a1000_default remove failed: No such network: a1000_default" module=node/agent node.id=joew8i91uii2jxxrg4rf5huvc
Nov 28 12:55:19 60 dockerd[11717]: time="2017-11-28T12:55:19.339734351Z" level=error msg="remove task failed" error="No such network: a1000_default" module=node/agent node.id=joew8i91uii2jxxrg4rf5huvc task.id=has8nrdkx1n6s0vyx29vjtjvq

@schmunk42 found the issue, working on a fix, this is the PR that introduced the regression https://github.com/moby/moby/pull/34188
In particular the line: https://github.com/moby/moby/pull/34188/files#diff-470d751551967a09e51effadaf1d5cf4R59
There is some logic in https://github.com/moby/moby/blob/master/daemon/cluster/executor/container/controller.go#L186 that expects the type ErrNoSuchNetwork in order to retry to create the network as managed. In that PR the error type is changed and so the issue start popping up. This is currently affecting all releases starting from 17.09.
What you are seeing is a result of that failure and the containers are remaining in Created state. This is something else that will have to be checked
^ @dperny

hi @fcrisciani I got a problem which I think quite similar to this, below is the messages in syslog, do you think this is the same issue or should I file another ticket?
Jun 11 02:35:31 staging-swarm-02 dockerd: time="2018-06-11T02:35:31.847866588Z" level=info msg="Node join event for staging-swarm-01-010eb502ed1d/<IP_ADDRESS>"
Jun 11 02:35:32 staging-swarm-02 dockerd: time="2018-06-11T02:35:32.357947221Z" level=error msg="logs call failed" error="failed to publish log message: EOF" module="node/agent/taskmanager" node.id=qqt7nrh49j98fizne4i641cml
Jun 11 02:35:32 staging-swarm-02 dockerd: time="2018-06-11T02:35:32.357963363Z" level=error msg="logs call failed" error="failed to publish log message: EOF" module="node/agent/taskmanager" node.id=qqt7nrh49j98fizne4i641cml
Jun 11 02:35:37 staging-swarm-02 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethafc0bc1: link becomes ready
Jun 11 02:35:37 staging-swarm-02 kernel: docker_gwbridge: port 6(vethafc0bc1) entered blocking state
Jun 11 02:35:37 staging-swarm-02 kernel: docker_gwbridge: port 6(vethafc0bc1) entered forwarding state
Jun 11 02:35:37 staging-swarm-02 kernel: br0: port 4(veth14) entered disabled state
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: docker_gwbridge: port 6(vethafc0bc1) entered disabled state
Jun 11 02:35:37 staging-swarm-02 kernel: docker_gwbridge: port 6(vethafc0bc1) entered disabled state
Jun 11 02:35:37 staging-swarm-02 kernel: device vethafc0bc1 left promiscuous mode
Jun 11 02:35:37 staging-swarm-02 kernel: docker_gwbridge: port 6(vethafc0bc1) entered disabled state
Jun 11 02:35:37 staging-swarm-02 kernel: br0: port 4(veth14) entered disabled state
Jun 11 02:35:37 staging-swarm-02 kernel: device veth14 left promiscuous mode
Jun 11 02:35:37 staging-swarm-02 kernel: br0: port 4(veth14) entered disabled state
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 kernel: IPVS: __ip_vs_del_service: enter
Jun 11 02:35:37 staging-swarm-02 dockerd: time="2018-06-11T02:35:37.915850487Z" level=error msg="fatal task error" error="task: non-zero exit (2)" module="node/agent/taskmanager" node.id=qqt7nrh49j98fizne4i641cml service.id=l1ghb9jrb7czjtbd5obqcbhmv task.id=66ww07onuzte510sfkh7t3muk

output of docker info:
docker info
Containers: 138
 Running: 4
 Paused: 0
 Stopped: 134
Images: 65
Server Version: 17.09.1-ce
Storage Driver: overlay
 Backing Filesystem: xfs
 Supports d_type: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: active
 NodeID: qqt7nrh49j98fizne4i641cml
 Is Manager: false
 Node Address: <IP_ADDRESS>
 Manager Addresses:
  <IP_ADDRESS>:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 06b9cb35161009dcb7123345749fef02f7cea8e0
runc version: 3f2f8b84a77f73d38244dd690525642a72156c64
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 3.10.0-693.11.6.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.639GiB
Name: staging-swarm-02
ID: W7UX:N2GT:PKF2:62VT:TZZP:LKQR:Q5YF:CCCS:L4RQ:NMXH:I6BC:7TBN
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

thanks

@cuongnv23 the issue being discussed here was resolved in Docker 18.01, and you're running an older version than that (17.09); it's worth testing it you're still able to reproduce on a current version of Docker


about Demo

hello, thank you for sharing your code. Would you please provide a demo or a pre_trained model for test? thanks!

hello, thank you for sharing your code. Would you please provide a demo or a pre_trained model for test? thanks!

Thanks for your interest. You can download the pre-trained model from Baidu online drive (https://pan.baidu.com/s/1a1VXZ6sBEibLMp88cU8tnQ#list/path=%2F)

@YirongMao  Thank you very much. I will have a try.

hello, thank you for sharing your code. Would you please provide a demo or a pre_trained model for test? thanks!

Moreover, the source code of resnet-34 is provided in my another project, please refer to https://github.com/YirongMao/COSONet/blob/master/resnet.py. The link of Baidu online drive includes images of WebFace and IJB-A datasets, and the resnet-34 pre-trained model this project used.


Update installation instructions

Pending @ravenac95 on

[x] https://github.com/oasislabs/toolstate/issues/4
[x] add https://get.oasis.dev -> https://raw.githubusercontent.com/oasislabs/toolstate/master/installer.py

@nhynes you're good to go


Mesh display: no visual available, can't draw mesh! (maybe no data has been received yet?)

Hello, it's my honor to learn about your work. when I put this project on my device, I find that there is something wrong about "roslaunch sel_map spot_sel.launch"
[ INFO] [1667551188.586010063]: Mesh Display: Update
[ERROR] [1667551188.586152061]: Mesh display: no visual available, can't draw mesh! (maybe no data has been received yet?)
[MeshDisplay] onEnable-------------------------------->
[ INFO] [1667551188.586368137]: Mesh Display: Update
[ERROR] [1667551188.586400533]: Mesh display: no visual available, can't draw mesh! (maybe no data has been received yet?)
[ INFO] [1667551188.589839548]: No initial data available, waiting for callback to trigger ...
[ INFO] [1667551188.589980674]: Mesh Display: Update
[ERROR] [1667551188.590021492]: Mesh display: no visual available, can't draw mesh! (maybe no data has been received yet?)
[ INFO] [1667551188.590136463]: Mesh Display: Update
[ERROR] [1667551188.590174442]: Mesh display: no visual available, can't draw mesh! (maybe no data has been received yet?)
[ INFO] [1667551188.592721792]: Mesh Display: Update
[ERROR] [1667551188.592792062]: Mesh display: no visual available, can't draw mesh! (maybe no data has been received yet?)
after that, I check it out, and I think that, this problem is happened about "void MeshDisplay::initialServiceCall()", because:
ros::NodeHandle n;
 m_uuidClient = n.serviceClient<mesh_msgs::GetUUIDs>("get_uuid");
mesh_msgs::GetUUIDs srv_uuids;
  if (m_uuidClient.call(srv_uuids))
  {
    std::vector<std::string> uuids = srv_uuids.response.uuids;
   if (uuids.size() > 0)
the value of "m_uuidClient.call(srv_uuids)" is none, so that,  "[ INFO] [1667551188.589839548]: No initial data available, waiting for callback to trigger ..." is output on screen, but I can't find the reason, maybe it's related to ros package:mesh_tools?
and then, I really don't know how to continue, could you give me some advice, thanks a lot.

Hi sevenzero70, thanks for checking out our work!
Have you tried running any data through ROS? The initial mesh that is created for the map is treated as an empty mesh, so nothing will be sent to nor will show up inside of rviz until the map has data to process and the mesh begins to have valid points.
If you'd like to try with one of the rosbags we used for our paper, issue #3 includes the following link to spot_comp3.bag which corresponds to figure 5b in our paper along with some extra info. As liuxiao916 mentioned in that issue, you'll want to launch with spot_bag_sel.launch instead. We'll be updating our readme with this additional information eventually.
In case you are running data and nothing is showing, do you mind adding open_rviz:=false as another roslaunch argument and then opening rviz separately? Then could you send the output of the roslaunch window? In other words, in one terminal could you launch roslaunch sel_map spot_sel.launch open_rviz:=false and in another launch rviz, then share the output of the first terminal?

Thanks for your reply! I found that, the problem is my device performs so poorly that it takes a particularly long time to read the .bag message, and I set the frequency to 0.1 to build a complete elevation map barely. And then, I have some other questions:1、if I want to process some images from realsense, which topic should I provide to the node: sel_map. 2、when the bag has finished, I found that the robot is suspending in mid-air, maybe is lack of odometry information? Sorry to take up so much of your time, waiting for your answer, thanks!
------------------ 原始邮件 ------------------
发件人:                                                                                "roahmlab/sel_map"                                                                                @.>;
发送时间: 2022年11月4日(星期五) 晚上10:19
@.>;
<EMAIL_ADDRESS>主题: Re: [roahmlab/sel_map] Mesh display: no visual available, can't draw mesh! (maybe no data has been received yet?) (Issue #4)
Hi sevenzero70, thanks for checking out our work!
Have you tried running any data through ROS? The initial mesh that is created for the map is treated as an empty mesh, so nothing will be sent to nor will show up inside of rviz until the map has data to process and the mesh begins to have valid points.
If you'd like to try with one of the rosbags we used for our paper, issue #3 includes the following link to spot_comp3.bag which corresponds to figure 5b in our paper along with some extra info. As liuxiao916 mentioned in that issue, you'll want to launch with spot_bag_sel.launch instead. We'll be updating our readme with this additional information eventually.
In case you are running data and nothing is showing, do you mind adding open_rviz:=false as another roslaunch argument and then opening rviz separately? Then could you send the output of the roslaunch window? In other words, in one terminal could you launch roslaunch sel_map spot_sel.launch open_rviz:=false and in another launch rviz, then share the output of the first terminal?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Due to inactivity, I'll be marking this issue as closed.

Sorry to bother you after a long time, I get part of the mapping effect when running “spot-comp8.bag” under the default configuration as shown in the figure, but the colors shown in the figure I can't correspond well to the type, I don't know the meaning of each color, whether it is the terrain category or the attribute value. Besides I want to get an image similar to the  second row of Figure 5 in your paper to represent the image of the coefficient of friction,and what should I do？ Waiting for your reply, thanks.
------------------ 原始邮件 ------------------
发件人:                                                                                "roahmlab/sel_map"                                                                                @.>;
发送时间: 2023年1月20日(星期五) 凌晨4:28
@.>;
<EMAIL_ADDRESS>主题: Re: [roahmlab/sel_map] Mesh display: no visual available, can't draw mesh! (maybe no data has been received yet?) (Issue #4)
Due to inactivity, I'll be marking this issue as closed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Hi @sevenzero70, sorry for the delay. I would use spot_comp3.bag as that corresponds to a figure in our paper. spot_comp8.bag works, but it doesn't directly correspond to any figures.
When running with the default configuration, it'll use the colorscale defined in sel_map/sel_map/config/colorscales/default.yaml.
With this default colorscale, unknown values are mapped to gray while values between 0 and 1 are mapped according to the 7-stop pink-purple colorscale. Lower values are pinker, while higher values are more purple. The measured terrain values can be found in sel_map/sel_map/config/terrain_properties/csail_semseg_properties.yaml. If you want to use the colors defined by the terrain_properties files, you can add colorscale:=use_properties.yaml to the launch command.
If you want an image similar to Figure 5 and your hardware may be running slower, you may want to consider replaying the rosbag with the extra --rate option: rosbag play spot_comp3.bag --clock --pause --rate 0.5. Since the node is designed to run in realtime, it will skip ahead in the processing of frames if it falls too far behind. Since the method relies on projected areas being processed multiple times as part of the Bayesian estimation, this probably won't yield reasonable results.
We pause our rosbag around at around the 50 second timestamp to get the mesh shown in figure 5b.


Can not install current version HAOS

I just purchased a Toshiba portable AC with wifi - RAC-PT1412JVWRU connected to wi-fi with the Toshiba NA app.
Attempting to install integration receive error " This integration does not support configuration via the UI.  If you followed this link from the Home Assistant website, make sure you run the latest version of Home Assistant."

No pending updates:
Home Assistant 2023.4.4
Supervisor 2023.04.0
Operating System 9.5
Frontend 20230411.1 - latest

Same issue

I have the same problem. Will try to install manually, but if anyone found a solution, please share.

Added it manually by searching for it in HACS, and worked well.


Refactor carbon-components-react imports to relative imports

We shouldn't be importing components from carbon-components-react in the components. If a component in this library relies on another component in this library (Carbon proxy or not), it should be imported from a relative path, not carbon-components-react.
We need to have a ./src/components/ComponentName/index.js for each component instead of importing and reexporting directly from carbon-components-react in ./src/index.js.
Then, all existing imports from carbon-componets-react need to be refactored to use the new relative locations.
Basically looking to mirror the strategy that ibm-security has put forth in their addons repo. Their Checkbox export is a good example because it's a component that only deviates in style, not in function (js).

Hello, this looks like it would be a good first issue to get an understanding of the code base. Could I claim this issue? @tay1orjones @scottdickerson

I began editting a few of the components and have run into an odd issue. When converting the Card component's SkeletonText to use the relative path, the component fails to render with
type is undefined

updateMemoComponent@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:14291:28
beginWork@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:15485:16
performUnitOfWork@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:19108:12
workLoop@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:19148:24
renderRoot@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:19231:7
performWorkOnRoot@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:20138:7
performWork@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:20050:7
performSyncWork@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:20024:3
requestWork@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:19893:5
scheduleWork@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:19707:5
scheduleRootUpdate@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:20368:3
updateContainerAtExpirationTime@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:20396:10
updateContainer@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:20453:10
ReactRoot.prototype.render@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:20749:3
legacyRenderSubtreeIntoContainer/<@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:20886:14
unbatchedUpdates@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:20255:10
legacyRenderSubtreeIntoContainer@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:20882:5
render@webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:20951:12
render@webpack-internal:///./node_modules/@storybook/react/dist/client/preview/render.js:55:24
renderMain@webpack-internal:///./node_modules/@storybook/react/dist/client/preview/render.js:93:3
renderMain@webpack-internal:///./node_modules/@storybook/core/dist/client/preview/start.js:205:7
renderUI@webpack-internal:///./node_modules/@storybook/core/dist/client/preview/start.js:231:9
emit@webpack-internal:///./node_modules/eventemitter3/index.js:180:35
StoryStore/_this.setSelection/<@webpack-internal:///./node_modul/@storybook/client-api/dist/story_store.js:239:22

I have limited knowledge in the React.memo() function, but it seems that its blowing up because of that function.
When I attempt to import the SkeletonText without the memo, it renders correctly.

@sstone2423 I agree, this is a good spot to get an understanding of the codebase. You'll touch probably every file 😄
You found a bug with our usage of .memo! I did some debugging, seems we can fix by changing one line in Card.
- const OptimizedSkeletonText = React.memo(SkeletonText);
+ const OptimizedSkeletonText = React.memo(props => <SkeletonText {...props} />);

Feel free to deliver this in pieces over time, instead of one huge PR. We can link the PR's to the issue and keep it open until all items are finished.

Oh wow good catch! This bug was really throwing me off.
I'll go ahead and break them up every few components

Ran into a similar issue in https://github.com/IBM/carbon-addons-iot-react/blob/master/src/components/ComposedModal/ComposedModal.jsx#L60
The styled(InlineNotification) function is giving the same undefined error as the memo function was. When InlineNotification or ModalFooter are changed to relative import, the components are undefined and the app blows up. I've tried the same ...props fix and double-checked the styled-components docs, but it looks like its being used correctly.

Tracking for completed components:
[ ] - Accordian
[ ] - AddCard
[ ] - Breadcrumb
[ ] - Button
[ ] - Card
[ ] - Checkbox
[ ] - CodeSnippet
[ ] - ComboBox
[ ] - ComposedModal
[ ] - ComposedStructured
[ ] - ContentSwitcher
[ ] - CopyButton
[ ] - Dashboard
[ ] - Datatable
[ ] - Datepicker
[ ] - Dropdown
[ ] - FileDrop
[ ] - FileUploader
[ ] - Form
[ ] - FormItem
[ ] - FormLabel
[ ] - Header
[ ] - Hero
[ ] - Icon
[ ] - ImageCard
[ ] - Inlineloading
[ ] - Link
[ ] - List
[ ] - ListBox
[ ] - Loading
[ ] - Modal
[ ] - ModalWrapper
[ ] - Multiselect
[ ] - Navbar
[ ] - notification
[ ] - Numberinput
[ ] - Orderedlist
[ ] - Overflowmenu
[ ] - Page
[ ] - PageTitlebar
[ ] - PageWizard
[ ] - Pagination
[ ] - Paginationnav
[ ] - ProgressIndicator

All PRs are open with the exception of the components that have import bugs listed above

After some thought on how best to break this issue up, I have divided the work into 2 PR's. The first PR will be adding the index.js files to each carbon component, and changing the import paths in the main src/index.js. The second PR will change each component's import paths to use relative instead of carbon-components-react.
My reasoning is that if I were to split this task into more PRs, 5 components per PR for example, there would be a mismatch of how components are being imported across the library which could lead to confusion. By changing ALL components at once, per subtask, it helps to keep consistency. I'll add further descriptions in each PR

It was decided this wasn't needed

@scottdickerson @davidicus @sstone2423 I'd like to revisit this... I was out when the related PRs came through.
Unfortunately this has left us in a very less than ideal situation. The first PR was merged, second was not, so we have many unused index.js files now for each component. There is no consistency of our imports across the codebase.
While importing from carbon-components-react in components and stories might make it easier to discern at a glance which components come directly from Carbon, we now have situations where stories are importing from the index.js and in other places vice versa importing directly from carbon-components-react.
This inconsistency hasn't bitten us yet, but it's very easy to have a mismatch between what's shown in storybook and what we're exporting. Worst case scenario is that bugs can very easily slip through snapshots due to a simple import error.

This estimate could go high depending on if we choose to continue proxying Carbon components as being discussed here: https://github.com/carbon-design-system/carbon-addons-iot-react/issues/2445.


Feature request: README specifically for the examples/ folder

Is your feature request related to a problem? Please describe.
A way of running the specs in examples/ isn't detailed in the README.
Describe the solution you'd like
Add a new README.md inside examples/ that talks about TodoApp.spec.js and
TodoApp.vue from the point of view of serving and running the tests.  Sure there's a tutorial online, but the repo would be even better if it had advice on how to run the specs.  Running yarn test from the root folder does not include the todo app specs, yet it does run (and all those tests pass).
Describe alternatives you've considered
I tried cd-ing to the examples folder and running yarn test there but it collects tests for execution as if it were in the root folder.

Hi @paul-hammant
The way to run the example is explained at the top of the test, see https://github.com/vuejs/test-utils/blob/main/examples/TodoApp.spec.js
Adding a README could be nice: do you want to make a PR? Or if the explanation at the top of the test is enough, then we can close this.

I'd missed that of course .. so used to just seeing copyright/left there.
I'm readying a pull request for y'all, but I'm seeing something else picked up by that command:
 ✓ tests/docs-examples/teleport.spec.ts (1)

 Test Files  1 passed (1)
      Tests  1 passed (1)
   Start at  08:22:59
   Duration  1.24s (transform 307ms, setup 21ms, collect 375ms, tests 31ms, environment 454ms, prepare 99ms)

 PASS  Waiting for file changes...
       press h to show help, press q to quit
✨  Done in 29.19s.

This was one of the first files I added to this repo - I had totally forgotten about it. We can definitely include more "real" examples, if that's something people would find useful.
There's some other repos with examples, if you'd like to see more, for example:

https://github.com/lmiller1990/vue-testing-handbook/tree/master/demo-app-vue-3

Taking a look, @lmiller1990, but there's errors while running tests after yarn install
demo-app-vue-3 paul$ yarn test:unit
yarn run v1.22.19
$ vue-cli-service test:unit
 PASS  tests/unit/ComponentWithVuex.spec.js
 PASS  tests/unit/ComponentWithButtons.spec.js
 PASS  tests/unit/FormSubmitter.spec.js

  ●  Cannot log after tests are done. Did you forget to wait for something async in your test?
    Attempted to log "[Vue Router warn]: Unexpected error when starting the router: TypeError: Cannot read properties of null (reading '_history')
        at Window.get history [as history] (/vcs/vue-testing-handbook/demo-app-vue-3/node_modules/jsdom/lib/jsdom/browser/Window.js:207:79)
        at finalizeNavigation (/vcs/vue-testing-handbook/demo-app-vue-3/node_modules/vue-router/dist/vue-router.cjs.js:2439:41)
        at /vcs/vue-testing-handbook/demo-app-vue-3/node_modules/vue-router/dist/vue-router.cjs.js:2326:27
        at processTicksAndRejections (node:internal/process/task_queues:96:5)".

      at Window.get history [as history] (node_modules/jsdom/lib/jsdom/browser/Window.js:207:79)
      at finalizeNavigation (node_modules/vue-router/dist/vue-router.cjs.js:2439:41)
      at node_modules/vue-router/dist/vue-router.cjs.js:2326:27
      at processTicksAndRejections (node:internal/process/task_queues:96:5)".
      at console.warn (node_modules/@jest/console/build/BufferedConsole.js:224:10)
      at warn (node_modules/vue-router/dist/vue-router.cjs.js:46:18)
      at node_modules/vue-router/dist/vue-router.cjs.js:2618:21
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

  ●  Cannot log after tests are done. Did you forget to wait for something async in your test?
    Attempted to log "[Vue Router warn]: Unexpected error when starting the router: TypeError: Cannot read properties of null (reading '_history')
        at Window.get history [as history] (/vcs/vue-testing-handbook/demo-app-vue-3/node_modules/jsdom/lib/jsdom/browser/Window.js:207:79)
        at finalizeNavigation (/vcs/vue-testing-handbook/demo-app-vue-3/node_modules/vue-router/dist/vue-router.cjs.js:2439:41)
        at /vcs/vue-testing-handbook/demo-app-vue-3/node_modules/vue-router/dist/vue-router.cjs.js:2326:27
        at processTicksAndRejections (node:internal/process/task_queues:96:5)".

      at Window.get history [as history] (node_modules/jsdom/lib/jsdom/browser/Window.js:207:79)
      at finalizeNavigation (node_modules/vue-router/dist/vue-router.cjs.js:2439:41)
      at node_modules/vue-router/dist/vue-router.cjs.js:2326:27
      at processTicksAndRejections (node:internal/process/task_queues:96:5)".
      at console.warn (node_modules/@jest/console/build/BufferedConsole.js:224:10)
      at warn (node_modules/vue-router/dist/vue-router.cjs.js:46:18)
      at node_modules/vue-router/dist/vue-router.cjs.js:2618:21
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

 PASS  tests/unit/Posts.spec.js
  ● Console

    console.warn node_modules/vue-router/dist/vue-router.cjs.js:46
      [Vue Router warn]: No match found for location with path ""
    console.warn node_modules/vue-router/dist/vue-router.cjs.js:46
      [Vue Router warn]: No match found for location with path ""
    console.warn node_modules/vue-router/dist/vue-router.cjs.js:46
      [Vue Router warn]: No match found for location with path "/posts/1"
    console.warn node_modules/vue-router/dist/vue-router.cjs.js:46
      [Vue Router warn]: No match found for location with path ""
    console.warn node_modules/vue-router/dist/vue-router.cjs.js:46
      [Vue Router warn]: No match found for location with path "/posts/new"
    console.warn node_modules/vue-router/dist/vue-router.cjs.js:46
      [Vue Router warn]: No match found for location with path ""
    console.warn node_modules/vue-router/dist/vue-router.cjs.js:46
      [Vue Router warn]: No match found for location with path "/posts/1"

 PASS  tests/unit/router-hooks.spec.js
 PASS  tests/unit/NestedRoute.spec.js
 PASS  tests/unit/SubmitButton.spec.js
 FAIL  tests/unit/Parent.spec.js
  ● Parent › does not render a span

    TypeError: wrapper.find(...).isVisible is not a function

       9 |     const wrapper = mount(Parent)
      10 |
    > 11 |     expect(wrapper.find("span").isVisible()).toBe(false)
         |                                 ^
      12 |   })
      13 |
      14 |   it("does render a span", () => {

      at Object.<anonymous> (tests/unit/Parent.spec.js:11:33)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

  ● Parent › does render a span

    TypeError: wrapper.find(...).isVisible is not a function

      19 |     })
      20 |
    > 21 |     expect(wrapper.find("span").isVisible()).toBe(true)
         |                                 ^
      22 |   })
      23 |
      24 |   it("does not render a Child component", () => {

      at Object.<anonymous> (tests/unit/Parent.spec.js:21:33)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

 PASS  tests/unit/CompositionApi.spec.js
 PASS  tests/unit/Bilingual.spec.js
 PASS  tests/unit/Emitter.spec.js
 PASS  tests/unit/example.spec.js
 PASS  tests/unit/mutations.spec.js
 PASS  tests/unit/App.spec.js
 PASS  tests/unit/getters.spec.js
 PASS  tests/unit/Greeting.spec.js
 PASS  tests/unit/NumberRenderer.spec.js
 FAIL  tests/unit/ParentWithAPICallChild.spec.js
  ● Test suite failed to run

    Cannot find module 'axios' from 'ComponentWithAsyncCall.vue'

      1 | <template>
    > 2 |

        | ^
      3 | </template>
      4 |
      5 |


FindKey includes label

Hi,
on my card private key and public key of the certificate are not found. I dug into it and found that your search for keys in FindKeys in Pkcs11X509Certificate includes CKA_ID and also CKA_Label. On my card however Label is only set on the certificate - not on either of the keys - when importing the certificate using the provider tool (Thales SafeNet). Do you think it is a good idea to exclude label search not only for me but everyone?
BR and thanks for your work.
Edit: Tested with another type of card (ACOS). When putting a certificate on that card label is not set for either certificate, private key or public key. All empty.

Yes, excluding CKA_LABEL from search template sounds like a good idea. I'll remove it in next version.

Thanks

This feature will be published today in Pkcs11Interop.X509Store 0.4.0.


update to spec 9200

Hi there! I list you our changes in this PR:

Add some methods from democracy pallet
Update s2 flag from 0x200 to 0x000
Migrate to main branch (CAUTION: just before merging this PR, the default branch has to be changed from master to main. You can check how to do it here.
Update to spec 9200
Improve zemu tests

Thanks!

Crowdloan pallet support was added! Included also in nanos light version

Hi! We also added the upgrade to spec 9220, and also other small changes. Thanks!


Expose port 8888 for remote debugging

We need to expose a port for remote debugging purpose

Fix included in v1.0.3


Update PR Meta Issue

I copy and paste Matthias' suggestions here. Let's keep track of it and coordinate the work in this issue.

[x] APIs and interfaces:
Unfortunately, you've put already effort into API extensions. I would recommend to remove the modifications of MLOutput and MLContext because MLOutput is not maintained and MLContext is about to get a major refactoring. Let's use the command line interface for now and extend the APIs once the backend is ready.
[x] Isolation of Flink dependencies: We need to be very careful about introducing Flink API dependencies into shared classes in order to ensure that Spark and Flink backends can be used without dependency on the other. For example, there are (1) references to Flink in runtime/controlprogram/Program, and (2) references to the SparkExecutionContext in Flink execution modes. Could you please systematically go over shared classes and double check for isolation?
[ ] Bufferpool integration: I agree that the duplication of RDDObject and DataSetObject creates unnecessary redundancy in a core place like our bufferpool (CacheableData and ExecutionContext). Let's abstract this to something like DistDataObject with two implementations RDDObject and DataSetObject. Just let me know, I'd be happy to prepare this for you guys.
[x] Broadcast memory budget: Currently, the broadcast memory budget is obtained from the SparkExecutionContext. It would be good to automatically obtain this size (e.g., size for user objects) to remove the dependency and because it is really important for operator selection.
[x] Checkpointing: I see a CheckpointFLInstruction which always does a pass-through. Let's remove this instruction (until Flink supports distributed caching) and simply do not apply the rewrites for injecting these checkpoints (RewriteInjectSparkLoopCheckpointing, RewriteInjectSparkPReadCheckpointing).
[x] Instructions w/ broadcasts: There seem to be some inconsistencies wrt when and how we broadcast data (e.g., join vs join w/ hint vs withBroadcastSet). I understand that Flink offers optimization capabilities in that regard. However, from a SystemML perspective I would recommend to stick to physical operator semantics (e.g., MAPMM with broadcast, CPMM/RMM with join). If experiments show that Flink actually does better than our operator selection, we could simply compile earlier (for smaller data sizes) CPMM/RMM. Btw, is there a way to pin the broadcast in distributed memory and reuse it across multiple invocations?
[x] Advanced operations: You already added compiler support for advanced operations like weighted squared loss and cumulative aggregates. Let's put these aside for now and get a narrow prototype running well first before we broaden the scope.
[x] Tests: It would be good if we could add a few tests for flink mapmm and tsmm to ensure they are producing correct results as this is the precondition for any experiments. Please have a look into FullMatrixMultiplicationTransposeSelfTest and FullDistributedMatrixMultiplicationTest.
[x] Exception handling: There are a couple of instances where exceptions are simply put to stderr. Could you please double check that all caught exceptions are rethrown in order to simplify debugging. Also, please replace the assertions for dimensions mismatch checks with exceptions as these checks need to happen even if assertions are disabled (by default).
[x] Formatting: Well, we don't have a style guide defined yet but the project-wide convention is to use tabs instead of spaces (e.g., issues in DMLScript). Furthermore, you've also done some code cleanups of formatting existing code. Could we separate these changes out of this PR to simplify the review? Feel free to submit them as an individual PR though.

I am working on AggBinary problem and try to make the linear test run on "FLINK" mode

I'll have a look at the Instructions w/ broadcasts issue. I will replace the general implementation with the one given by the name. That is replace Flink's join operator with BroadcastSets.

I am having a look at the unnecessary API changes and Flink dependencies. The removal of the Flink dependency from Program.java touches the question of where to put the env.execute() parts ( #15 )

I think for the CheckpointFLInstruction, we can just remove it since it was not generated during optimization anyways...

I went over the Flink/Spark interdependencies but we should double check before we check this off the list.

Hi @fschueler !
May be can we have fresh look this flink integration status and relist what are the current bottlenecks or things to be taken care off. I think this integration is important for engineering applications.


Messaging: Support subsetting on arbitrary labels

Currently Messaging supports subsetting based on name, keyspace, shard and/or keyrange. I propose adding another standard field that would support subsetting based on arbitrary labels. The most flexible would be to allow for a list of key/value labels, but I think even just supporting an array of string labels would be sufficient.
Use Cases

State management - Generally we like to process messages 3-5 times to account for intermittent failures. At that point, we consider them "failed", meaning that a developer needs to investigate the root cause. These messages should no longer be queued, but also should not be purged.
Prioritization - We have two queue types, standard and priority, which dictates the order that they are processed. In some cases the consumer orders by high priority, and in some cases we have separate priority and standard consumers.
High cardinality - It could be useful for subscribing to messages based on a user or tenant id for websocket-like updates.

Alternate Solutions
Without digging into the internals, it's hard to say whether or not general label filtering would be feasible from a technical standpoint.

Dedicated failure state - I am currently participating in the Google Cloud Tasks Alpha, and the number one requested feature is for dead/buried tasks, and a similar concept exists in many other queue libraries. I think this makes a lot of sense to natively support. I think it could be added as a single api, identical to MessageAck, called MessageFailed or something, that would set a timestamp in the table. Requeuing messages would be left to the user, similar to running an update on the next_time column to reschedule.
Multiple queues / epoch: For our use case, just having a priority and a standard queue solves the issue. I think epoch helps somewhat, but based on the index in the docs, Messaging sorts by time and then epoch, where we are essentially looking for epoch and then time.
Update stream - This high cardinality piece isn't something we need immediately, and for the use case mentioned, using the update stream or potentially adding streaming query support would likely be more useful.

@sougou What are your thoughts?

Permanently failing messages sounds like a valid use case. However, the current design has no elegant way to accommodate it: An acked message essentially sets the time_acked field to non-null. We could introduce a new state column, but that would break backward compatibility. An alternate approach would be to set a time_next far away into the future and a huge epoch, which will amount to the same thing because the message will never be resent. As for scanning for these rows, the queries should be infrequent enough that a full table scan may be acceptable.
For priority queues, we can look at starting the lower priority messages with epoch 1, and higher ones with epoch 0. Although the time seems to participate in the prioritization, it's not the case in reality. It's mainly used to decide if a message has come due. However, the problem with epoch is that the message is high priority only for first send. It then becomes epoch=1, which will then be on par with lower priority messages.
Filtering of messages is something we should definitely look at doing as an advanced feature.


Aligned permissions examples with rule 255

The rule 255 ({MUST} follow naming convention for permissions) states that pattern for resource part of permission should follow [a-z][a-z0-9-]* pattern, but resource scopes in example are not aligned to this pattern.

👍

:+1:


Build failure: python312Packages.spectral-cube

Steps To Reproduce
Steps to reproduce the behavior:

nix-build -I . -A python312Packages.spectral-cube

Build log
Check whether the following modules can be imported: spectral_cube
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<string>", line 1, in <lambda>
  File "/nix/store/lgymkqydhhmf88rvbq6hagq8lcpfr52w-python3-3.12.3/lib/python3.12/importlib/__init__.py", line 90, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 995, in exec_module
  File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
  File "/nix/store/i2hynyk2qz4bhdrmmxqm0bmqy9bbwfza-python3.12-spectral-cube-0.6.5/lib/python3.12/site-packages/spectral_cube/__init__.py", line 5, in <module>
    from .spectral_cube import (SpectralCube, VaryingResolutionSpectralCube)
  File "/nix/store/i2hynyk2qz4bhdrmmxqm0bmqy9bbwfza-python3.12-spectral-cube-0.6.5/lib/python3.12/site-packages/spectral_cube/spectral_cube.py", line 60, in <module>
    from distutils.version import LooseVersion
ModuleNotFoundError: No module named 'distutils'
error: builder for '/nix/store/5xsrhx6an0ybcys9vysdh1b8vl61h8xi-python3.12-spectral-cube-0.6.5.drv' failed with exit code 1;

Notify maintainers

@smaret
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"aarch64-darwin"`
 - host os: `Darwin 23.4.0, macOS 14.4.1`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.21.0`
 - channels(root): `"nixpkgs"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

Add a :+1: reaction to issues you find important.

Fixed with #320017.


Sort dask array

Unless I missed it, there is no way to sort or argsort dask arrays, is it a current work in progress ?

cc @jrbourbeau (for awareness)

A k-way merge may be appropriate for the implementation: https://stackoverflow.com/questions/50907949/k-way-merge-sort-divided-on-multiple-hosts

Sorting would be good to have for SciPy! Of the ~575 failures so far for pushing dask.array through SciPy's test suite, ~150 are for missing argsort, and ~75 are for missing sort. So this is one of the biggest pieces of the array API standard that Dask is missing, with most of the other failures due to boolean indexing.

The easy version of this would be to sort along single dimensions only when they use a single chunk, and otherwise error. The hard version would be to support sorting even in the multiple chunk case. I'd be glad to see either of these in dask.array.

The easy version sounds in scope for array-api-compat, but the hard version would probably have to be implemented in dask.array itself.


feat: upgrade to polkadot-v0.9.43

This PR upgrades the dependencies to v0.9.43

Closing, as the pallet was already migrated to 1.0.0 in https://github.com/SubstrateChess/pallet-chess/pull/34


Unexplained file size increase

Hello,
My input html file is 75kb (2178 lines)
I combine several css and js lines into one.
<!-- build:css css/imb.min.css -->
    ...
<!-- /build -->

<!-- build:js js/imb.min.js -->
    ...
<!-- /build -->

The output html file is 114kb (2154 lines)
How come?
No text was added, only removed.
Maybe the encoding changed?

i don't think changing the encoding could add 39kb to your file.
grunt-processhtml doesn't add anything to your files, it just process them.
doesn't look like an issue of the plugin please review your code


Recycle bin bugs

Sometimes right-clicking an item will show menu items for a regular folder
Deleting files doesn't work always
After unpinning the recycle bin from the sidebar, you can no longer access the recycle bin by entering Shell:RecycleBinFolder in the path box since it turns off recycle bin support. Unpinning shouldn't disable recycle bin support.

Merging with #1089.


Z-Index/Layer level for note on board

Due to the nature of RelativeLayout, there is no z-index to be store. However, we can store notes object as a stack, so on initialization, it will render it the correct order. A clicked note object should be put on the front of the stack for this system to work.

Solve on PR #13