Create new imagery provider for MapBox styles

This work intends to incorporate the new Mapbox styles API into Cesium.
Fixes #4015

Thanks for the pull request @bampakoa!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

Great, thanks @bampakoa!  We'll take a look at this after the release goes out

@hpinkos this is a draft PR yet. I plan to push some more code along with tests and README changes this week and then I can notify you for reviewing 😉, if that is ok for you.

Oh yes!  I missed that.  Yeah, let me know when its ready =)

@hpinkos this is ready for review now. You can check it directly in the Hello World app by selecting the Mapbox layers from the picker (I guess I should revert it back l8r to the old Mapbox 😃 ). I have not updated the CHANGES.md file yet since there is not any relevant entry for the next release 😟
@cesium-concierge I have updated the tests 😉

Thanks for making this pull request @bampakoa ! ❤

Thanks again for your contribution @bampakoa!
No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

@OmarShehata can you review?

Thanks for putting this together @bampakoa ! It seems to work pretty well. I do have some notes/questions:

Can you merge in master and push?
Why is it called MapboxStyleProvider instead of MapboxStyleImageryProvider? It is an imagery provider, so it should be consistent with the other imagery providers listed here https://cesiumjs.org/Cesium/Build/Documentation/ImageryProvider.html?classFilter=ImageryProvid
It should probably be added to that list too I think ^
Since the old Mapbox API is deprecated, is there a reason to keep around the old MapboxImageryProvider? Can this new class just replace the old one?

I think this would be a breaking change in that the user needs to change the parameters they pass to the constructor, to choose which style they want, right?

@OmarShehata Hey, to the last point, the old Mapbox API still works, so I wouldn't break it!

@OmarShehata thanks very much for your feedback 😃

Can you merge in master and push?

No, I do not have permissions to do that in the CesiumJS repository

Why is it called MapboxStyleProvider instead of MapboxStyleImageryProvider? It is an imagery provider, so it should be consistent with the other imagery providers listed here https://cesiumjs.org/Cesium/Build/Documentation/ImageryProvider.html?classFilter=ImageryProvid

You are right, I will update the PR

It should probably be added to that list too I think ^

Sounds good to me. I will update the PR

Since the old Mapbox API is deprecated, is there a reason to keep around the old MapboxImageryProvider? Can this new class just replace the old one?

I think that we shouldn't because as @mrlubos points out the old API has not been deprecated yet. See this comment for more info.

Do you mean to rebase to the master?

A rebase isn't necessary, you just need to pull the latest master from this repository into your branch here. See https://help.github.com/en/articles/merging-an-upstream-repository-into-your-fork

I think that we shouldn't because as @mrlubos points out the old API has not been deprecated yet. See this comment for more info.

Thanks for the explanation - I'm still a little bit confused about the difference between these two routes that both get raster tiles from Mapbox:

https://docs.mapbox.com/api/maps/#maps
https://docs.mapbox.com/api/maps/#retrieve-a-sprite-image-or-json

Is the idea that using the style API (the second one) you have more fine grained control over customizing the look of the map? If so, do you have an example of something you can do with this that you couldn't do before?
I'm worried it's still a little big confusing having 2 Mapbox imagery providers that seem like they do the same thing, but just pass different parameters/use a different route? Would it make sense to have one MapboxImageryProvider but have a constructor option to use the style API?

Is the idea that using the style API (the second one) you have more fine grained control over customizing the look of the map? If so, do you have an example of something you can do with this that you couldn't do before?

@OmarShehata Yes, that is right. You can create whatever style you want in Mapbox Studio (such as this one which is GoT based) and then render it inside the client. Here is a brief overview of the differences between them and here is an article that explains why Mapbox is going to deprecate the old map styles

Would it make sense to have one MapboxImageryProvider but have a constructor option to use the style API?

I think that it would be complicated to maintain such a code as the two implementations have different required properties in order to create an object for each (mapId vs styleId). If we have two different constructors we are giving our users the opportunity to use whichever method they have created their maps and are comfortable with.

I see what you mean now (that GoT inspired map is awesome!) Thanks for the explanation. I think that's a good reason to have two separate classes if they are different APIs as you describe.
I noticed that they never actually use the word "deprecate" in that blog post. It seems like it's still a supported way of getting map tiles. I would say go ahead and name the new provider MapboxStyleImageryProvider.
And then @tfili can you do a final review and merge after that?

@OmarShehata what about the base layer picker control? Should I leave it as is, to use the initial API of Mapbox?

Since they're functionally equivalent, I don't think it really matters, but perhaps switching to the newer API is a good idea, so if we did want to add any custom styles to the base layer picker in the future it would be easier to do that.

@OmarShehata @tfili this is ready

@tfili I updated the type of the parameter. I think the code already takes resource into account 😉

Thanks again for your contribution @bampakoa!
No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

@tfili this one would be nice to get in for release since it's already ready!

Thanks @bampakoa. Sorry it took so long. Everything seems to work great.

@tfili my change has been mistaken added to the 1.58 version release notes in CHANGES.md. Could you please correct it or do you want me to open a PR for this?

Oh, good catch @bampakoa ! I got it here https://github.com/AnalyticalGraphicsInc/cesium/pull/7973

I still don't understand why we need a 2 Mapbox providers in master?  Is there a good reason to use one over the other?

@mramato Mapbox has two different APIs for creating and serving imagery. See https://github.com/AnalyticalGraphicsInc/cesium/pull/7698#issuecomment-494514606
From what I understand, the newer one allows you to do customize more, but the old workflow isnt deprecated and removing it in Cesiumjs would be a breaking change.

@OmarShehata Yesss. Do you know if this new imagery will support vector tiles? (as opposed to the raster tiles served by the previous version)

@OmarShehata I understand that, so is there a reason there wasn't jut an in-place update or are the two incompatible?  If the latter, why wasn't the old one deprecated so that we can remove it 3 months from now?  Does the old version provide user-accessible functionality that the new one does not?

@mramato These are questions for Mapbox, not for Cesium. Mapbox released a new API with breaking changes.

@mramato

why wasn't the old one deprecated so that we can remove it 3 months from now

I think the initial confusion here was that the Mapbox static tiles API was deprecated in favor of the styles API. It looks like it is supported and will be supported for the foreseeable future. This is just supporting an additional workflow with different options. For example the raster (old) API lets you specify the image format: https://docs.mapbox.com/api/maps/#raster-tiles. The styles (new) API https://docs.mapbox.com/api/maps/#static-tiles doesn't have this option. I think deprecating and removing it in the CesiumJS side would be removing a feature that's still actively used by the community.
@mrlubos

Do you know if this new imagery will support vector tiles? (as opposed to the raster tiles served by the previous version)

@bampakoa can correct me if I'm wrong here, but it looks like the vector tiles are rasterized on the server, and that's what CesiumJS renders. We do have a feature request to support vector tiles directly in Cesium here: https://github.com/AnalyticalGraphicsInc/cesium/issues/2132

@OmarShehata I understand Mapbox supports vector tiles directly - https://docs.mapbox.com/api/maps/#retrieve-vector-tiles

I understand Mapbox supports vector tiles directly

Right, it's CesiumJS that doesn't support rendering these vector tiles.

Is this an issue for a separate pull request @OmarShehata @hpinkos? Anything on the roadmap?

@mrlubos yes this would be a separate feature from this pull request. You can see the full discussion here: https://github.com/AnalyticalGraphicsInc/cesium/issues/2132


chore: rework binaries

Description
Cleanup binaries.

📚 $\text{Stack Overview}$
Pulls submitted in this stack:

#115 👈
main

This comment was automatically generated by st.

Codecov Report
Attention: Patch coverage is 0% with 47 lines in your changes missing coverage. Please review.

Project coverage is 37.0%. Comparing base (aac595a) to head (f072a34).

:white_check_mark: All tests successful. No failed tests found.

Files with missing lines
Patch %
Lines

bin/node/src/main.rs
0.0%
23 Missing :warning:

bin/node/src/telemetry.rs
0.0%
22 Missing :warning:

bin/net/src/main.rs
0.0%
2 Missing :warning:

Additional details and impacted files

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


add license identification

This requires LicenseCheck v0.2.0 which will come shortly after LicenseCheck v0.1.0 passes its 3-day waiting period in General.
closes https://github.com/giordano/AnalyzeRegistry.jl/issues/4

LicenseCheck is registered now. I just added a commit to look for licenses in the Project.toml (or JuliaProject.toml, which I remembered is an allowed alternate name) too, based on https://github.com/JuliaRegistries/RegistryCI.jl/pull/344#issuecomment-778682269 (sounds like we are likely to add that as a way to pass the RegistryCI check, so I'd expect the key to become more common once that comes into effect).
In an earlier version of the PR, I stored is_osi_approved in the Package struct. That was always a kind of bad idea because it's a fast 1-line function call, so no need to pollute the struct fields with it, and now with 2 sources of licenses, I'd need two separate such fields. I did like having it in the show method though, so I just added that by doing the function call at show time.
I also now always parse the Project (to look for a license), so I took out the functionality from #7 that avoided parsing when we got the info from the registry. Hopefully the parsing code is robust enough though that that doesn't matter.


build/automated-releases

Setups automated releases using NX plugin.
How it works:

every push on the main branch will trigger release (after the repository is made public we will use the env to require additional approval before running)
release notes and version is determined based on commits for both of our libs (vue 2 and vue 3)
only affected libs will be released

If the "shared" directory was affected, both libs will be released
Otherwise only affected libs will be released

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


"Ghost" Items Appear on Benches

Sometimes, I see benches and bins built by the plugin that look like this:

I haven't noticed this display having an effect on whether the peeps will use them. From what I've seen people just treat them like regular benches and bins, they just look odd.

I can reproduce this bug.

At first I thought it was a texture error which is fixed after a restart of the game. But when I load the savegame, the same benches and bins are "ghosted". But the same b&b's are ghosted after a restart and reload.
If I reproduce this error in a scenario (in my case the "woodstock" scenario) and start the scenario new again, the ghosted textures will be seen in the same places. But I don't know why.

@tubbo

I haven't noticed this display having an effect on whether the peeps will use them. From what I've seen people just treat them like regular benches and bins, they just look odd.

I used the woodstock scenario again and added 1000 visitors via the "cheat-module" from OpenRCT2. I set the energy of the visitors to the lowest and noticed, that the guests will not use any of the benches. I assume, that this behaviour is the same with the bins.

I also noticed, that I can place a new bench over the ghosted one, but not over a correct one.

I don't know, if it is useful:
The problem occurs regardless of which benches or bins you use.


请问下有空可以更新一个ios版吗

请问下有空可以更新一个ios版吗？感激不尽

@wz1228556153  didn't quite understand what you meant but the
Plugin only supports Android OS for now.

@wz1228556153 hey do you have the ios implementation for this plugin?


pull access denied for registry.baidubce.com/easyfaas-public/runner-runtime

According to "getting-started-docker-compose.md",
When I use the command "sh app_control.sh start"
I get the information as:
Pulling runtime (registry.baidubce.com/easyfaas-public/runner-runtime:demo1.0)...
ERROR: The image for the service you're trying to recreate has been removed. If you continue, volume data could be lost. Consider backing up your data before continuing.
Continue with the new image? [yN]y
Pulling runtime (registry.baidubce.com/easyfaas-public/runner-runtime:demo1.0)...
ERROR: pull access denied for registry.baidubce.com/easyfaas-public/runner-runtime, repository does not exist or may require 'docker login': denied: requested accessto the resource is denied

Thank you for your feedback. I have resolved the problem. Please try it again.

still not work
[root@KSSHUAT00850 /opt/EasyFaaS/scripts/docker-compose/compose-local]# sh app_control.sh start
Pulling funclet (registry.baidubce.com/easyfaas-public/mini-funclet:demo1.0)...
ERROR: manifest for registry.baidubce.com/easyfaas-public/mini-funclet:demo1.0 not found: manifest unknown: manifest unknown

Thank you for your feedback. I have resolved the problem. Please try it again.

still not work,what is the correct image tag?
demo1.0 is not correct
[root@KSSHUAT00850 /opt/EasyFaaS/scripts/docker-compose/compose-local]# sh app_control.sh start
Pulling funclet (registry.baidubce.com/easyfaas-public/mini-funclet:demo1.0)...
ERROR: manifest for registry.baidubce.com/easyfaas-public/mini-funclet:demo1.0 not found: manifest unknown: manifest unknown

Thank you for your feedback. I have resolved the problem. Please try it again.

still not work,what is the correct image tag?
demo1.0 is not correct
[root@KSSHUAT00850 /opt/EasyFaaS/scripts/docker-compose/compose-local]# sh app_control.sh start
Pulling funclet (registry.baidubce.com/easyfaas-public/mini-funclet:demo1.0)...
ERROR: manifest for registry.baidubce.com/easyfaas-public/mini-funclet:demo1.0 not found: manifest unknown: manifest unknown

Sorry for trouble you. I have verified the tag. Give it a try later.


remove 'providers' option for melspec and embedding InferenceSession

Ty for this very interesting open-source wake-word project! I've done some experiments for SEPIA open assistant framework and it looks like it could finally become a real alternative to Porcupine 🙂 (with the exception of custom ww creation for now ^^).
Just a small comment. I'm getting warnings because of 'CUDAExecutionProvider' ('CUDAExecutionProvider' is not in available provider names).
I think you can simply remove the providers option in the utils class because ONNX runtime will set this to the available providers automatically.
Cu,
Florian

Looking forward to it 👍.
I spent some time to try and find out if I could transport the runtime over to ONNX web, but stopped for now when I realized there are actually 3 ONNX models involved ^^. I'll keep this on my to-do list though since my SEPIA clients are mostly running as web-apps (even the headless one).
Do you have any plans to work on that as well? :-)

This issue will be fixed when #31 is merged, so closing.
And yes, there are three separate models, which I admit is a bit unwieldy when porting to other deployment environments. I have considered making a javascript library before, but it would take some time as much of the functionality in the Python library would need to be ported as well.
Feel free to open a Discussion topic for this though, happy to continue the conversation there.


C# GetIndexed/SetIndexed don't work with nodes from other projects

Godot version
v4.0.beta4.mono.official.e6751549c
System information
Macbook OS Monterey
Issue description
The C# methods GetIndexed and SetIndexed don't work with object/nodes from other projects. Only the objects/nodes located inside the main project in the Godot solution work.
So, this node in your main project/solution works:
public partial class node_2d : Node2D {
	public string property;
	// Called when the node enters the scene tree for the first time.
	public override void _Ready() {
		SetIndexed(nameof(property), "hello");
		Console.WriteLine(GetIndexed(nameof(property)));
	}
}

But if you have this class in another project:
public class ClassLibraryNode : Node {
    public string otherProperty;
}

Then this code doesn't have any effect from your main project (it always return Nil)
public partial class node_2d : Node2D {
	public string property;

	// Called when the node enters the scene tree for the first time.
	public override void _Ready() {
		var x = new ClassLibraryNode();
		x.SetIndexed(nameof(ClassLibraryNode.otherProperty), "hello");
		Console.WriteLine(x.GetIndexed(nameof(ClassLibraryNode.otherProperty)));
	}
}

Steps to reproduce

Create a second project with a new class inherit from Node and a regular C# field.
Try to to update this field with SetIndexed(), the action is ignored.
Try to read thie field with GetIndexed(), it always return Variant.Nil

Minimal reproduction project
get-indexed-doesnt-work-is-nodes-from-other-projects.zip

This affects to Tween.TweenProperty() too because it can't get the current value to start the tween:
ERROR: Type mismatch between property and final value: Nil and float

Fixed adding this to the csproj:
   <PackageReference Include="Godot.SourceGenerators" Version="4.0.0-beta.4" />

It will be awesome if this is documented in a kind of C# guide for Godot 4 for another users facing the same issue.


Compile error: undefined reference to symbol 'krb5_free_context@@krb5_3_MIT'

When I try to compile I get an error
objs/ngx_modules.o \
-lpthread -lcrypt -lspnegohelp -lgssapi_krb5 -lpcre -lssl -lcrypto -ldl -lz
/usr/bin/ld: objs/addon/nginx-mod-auth-kerb/ngx_http_auth_sso_module.o: undefined reference to symbol 'krb5_free_context@@krb5_3_MIT'
/usr/bin/ld: note: 'krb5_free_context@@krb5_3_MIT' is defined in DSO /usr/lib/libkrb5.so.3 so try adding it to the linker command line
/usr/lib/libkrb5.so.3: could not read symbols: Invalid operation

I fix this error by getting krb5-config flags.
P.S. By the way I fix README viewing error.

Sweet. Thanks for the patch!


Fix the 500 error stacktrace for PUTing ACL with bad RDF content

Fix the 500 error stacktrace while PUTing ACL with bad RDF content
JIRA Ticket: https://jira.duraspace.org/browse/FCREPO-2844
What does this Pull Request do?
PUTing ACL with bad RDF content will produce a stacktrace with 500 error. The PR will fix it to return status 400 bad request.
How should this be tested?
1. Create resource:
$ curl -i -ufedoraAdmin:fedoraAdmin http://localhost:8080/rest/test -XPUT

2. Create ACL with bad RDF and verify status 400 returned:
$ echo -e '<> a junk:Object ;' | curl -i -ufedoraAdmin:fedoraAdmin http://localhost:8080/rest/test/fcr:acl -XPUT -H"Content-Type: text/turtle" --data-binary @-
HTTP/1.1 400 Bad Request
Date: Wed, 29 Aug 2018 18:04:23 GMT
Set-Cookie: JSESSIONID=9qlvnhmcfpyz1by05yixj2ols;Path=/
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: rememberMe=deleteMe; Path=/; Max-Age=0; Expires=Tue, 28-Aug-2018 18:04:23 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 63
Server: Jetty(9.3.1.v20150714)

RDF was not parsable: [line: 1, col: 6 ] Undefined prefix: junk

Interested parties
Tag (@ mention) interested parties or, if unsure, @fcrepo4/committers

👍 Looks good to me


(PUP-10509) Drop support for Ruby < 2.5

Drop distinction between Bignum and Fixnum (they were unified as Integer in 2.4), remove some monkey patches and conditional spec logic.

Apparently jruby <IP_ADDRESS> does not know about OpenSSL::X509::Name#to_utf8.
Should we keep the monkey patch only for jruby? @joshcooper
I see the method was added in https://github.com/ruby/openssl/pull/143 for MRI, but the jruby-openssl still doesn't have it (https://github.com/jruby/jruby-openssl).

Some background context, requiring 'openssl' in fips-enabled puppetserver will raise, so we do https://github.com/puppetlabs/puppet/blob/3b720e6e2ebbbffd73e7e4ecd6b12746c162cfbb/lib/puppet/ssl/openssl_loader.rb#L8
When running non-fips puppetserver, we still require 'openssl' but I don't believe we ever execute code paths that call Name#to_utf8. For example puppetserver installs its own HTTP client via Puppet::Network::HttpPool.http_client_class=, which bypasses the SSLProvider, CertProvider, Verifier, etc.
To answer your question, I have a slight preference to keep the monkey patch so that we get additional test coverage, even if the code doesn't execute on puppetserver.

CLA signed by all contributors.

Travis sometimes gets confused about build status so I'm going to ignore that.
I want to get PE CI green again before merging this, so probably will be next Monday.

jenkins please test this on redhat7-64a,ubuntu1804-64a,windows2019-64a with servertests


[netcore][07.adaptive cards] Edit Readme

Proposed Changes

Improve formatting
Fix some typos

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: dfavretto sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


EcoBase

Fit in EcoBase as a supertype, implement interface and test it all.

Also:

[ ] Remove old deprecations and testing
[ ] Update testing for new Phylo update
[ ] Remove RecipesBase REQUIRE and ext/EcoBase assuming that has been registered with METADATA


Fix method signature after change in IRB

We override IRB::Irb::output_value in awesome_print/custom_defaults.rb.
IRB Introduced a default argument for this method in https://github.com/ruby/irb/commit/c5ea79d5cecea9cae6ad0c1f31703a98cd329431. When overriding this changed signature an ArgumentError is raised.
To fix, we capture any parameters. They are discarded anyway in our case.
Closes #389

The build failure is some conditional check for old versions which is off base imo.
See https://travis-ci.org/github/awesome-print/awesome_print/jobs/747933000#L370

amazing-print/amazing_print#57 contains this exact change; no need to duplicate here.

Anxiously waiting for this to be released 😂   @BryanH

Anxiously waiting for this to be released 😂   @BryanH

@letiesperon Done! Have a few more to work through and then will see about releasing a new version!

@letiesperon Done! Have a few more to work through and then will see about releasing a new version!


How to run tests

First of all, thank you for the wonderful package.
I know this is not a feature request, but rather than just a question. I forked this package to add some new features for my project, then did'nt get how to run tests.
Could you please tell me how to run tests for this package?

Where do you want to run tests, local or GitHub actions?

Thanks for you reply. On local. Actually I've just found the way to run GitHub Actions on my local. Is this the right way supposed to be?

On local.

Fork the zingimmick/laravel-scout-opensearch repository and clone it

git clone git@github.com:<your-name>/laravel-scout-opensearch.git
cd laravel-scout-opensearch

Install dependencies and verify your local environment

composer update
composer check-platform-reqs

Add new features and test cases

Start the OpenSearch service via docker

docker run -d -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" -e "plugins.security.disabled=true" opensearchproject/opensearch:latest

Run tests using phpunit

./vendor/bin/phpunit

run GitHub Actions on my local. Is this the right way supposed to be?

I haven't used GitHub's self-hosted runners before, so it's hard to say it's the right way or not.

Thank you it works perfectly!
Maybe that would be great if you put those test steps on README.md.

I see, I will put those test steps on README.md as soon as possible.


Add proposal for an optional preflight check in kapp for validating safety of CRD upgrades

Note: I will squash all the commits once this is in an approved state and ready to merge.

[thought, non-blocking]: Have you considered use-cases where the CRD author/user would like to control the behaviour from the annotations on the CRD itself, say to bypass them all? Following the precedence of kapp's configuration and annotations I think one could argue for both. Maybe annotations are a potential footgun.

[thought, non-blocking]: Have you considered use-cases where the CRD author/user would like to control the behaviour from the annotations on the CRD itself, say to bypass them all? Following the precedence of kapp's configuration and annotations I think one could argue for both. Maybe annotations are a potential footgun.

@mamachanko Are you referring to a case where a user wants the preflight check enabled, but wants to ignore a specific CRD or which validations to run against a CRD?

Exactly.

[thought, non-blocking]: Have you considered use-cases where the CRD author/user would like to control the behaviour from the annotations on the CRD itself, say to bypass them all? Following the precedence of kapp's configuration and annotations I think one could argue for both. Maybe annotations are a potential footgun.

@mamachanko Are you referring to a case where a user wants the preflight check enabled, but wants to ignore a specific CRD or which validations to run against a CRD?

Exactly.

So for ignoring a specific CRD, I don't think that is unreasonable but IMO isn't necessary for the base implementation and is something that can be added in the future.
For annotations regarding what validations to run against the CRD, I think that is a bit more nuanced and likely opens up for a wealth of footguns. I think if there is a strong use case for that then I don't see why it couldn't be added, but I think for the initial implementation it makes the most sense to have either all the validations run or none of them (i.e check is enabled/disabled).

Is this ready to merge?

I believe this has now passed the lazy consensus period. I think it is good to merge.
cc @praveenrewar

Please change the status to Approved in a separate commit and we will be able to merge it

@joaopapereira should be done now in 1d187a56b0a1d11e248a89b668f24061d611b730


refactor(ci/build): make LoadRegistryFromFile function reusable across commands

…s commands
Signed-off-by: Aldo Lacuku<EMAIL_ADDRESS>
What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area plugins

/area registry

/area build

/area documentation

What this PR does / why we need it:
Make LoadRegistryFromFile() function reusable and remove duplicated code from oci command.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: alacuku
Once this PR has been reviewed and has the lgtm label, please assign jasondellaluce for approval by writing /assign @jasondellaluce in a comment. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: alacuku, jasondellaluce
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [jasondellaluce]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 847a6282d5ac75d7b9a185f734337e8eb841be08


[rst] changed to react-syntax-tree and improved createComponentChildr…

…en to not use mutation

Pull Request Test Coverage Report for Build 379

102 of 102 (100.0%) changed or added relevant lines in 19 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 376:
0.0%

Covered Lines:
421

Relevant Lines:
421

💛  - Coveralls


Problem with pagination rendering

Hi!
I have issue with rendering pagination bullets. As soon as i refresh my page, only one swiper pagination bullet will appear. If i resize the screen just a bit, all bullets will come back.
I'm stuck a bit. Maybe you can help?
Check the gif, please.

I have a similar issue.
When loading the page for the first time, I can drag the first slide but it won't go the the next one and ignore any given parameter ("centeredSlides", "slidesPerView", "spaceBetween"...) , but as soon as I resize the screen (even juste one pixel), everything works fine.

Hi @aimarjs , it will be really helpful if u can share ur code :)


DDC SDK v2 (DHT)

It is a base branch for the migration to new storage architecture. All PRs will be created to this branch until the migration is finalized.

All these changes were merged from these PR


Add type-inferring constructors

Convention: /i denotes a type-inferring version of something.
Allows you to do something like (some/i (some/i (some/i T))) with no type annotations

Would prefer to have a version of data that can generate such macros, but for now this is useful and a good demonstration.

Yeah this is a step in that direction.


How it relates to "Requests limits and allocations" article

How this article, and the described limits, relate to what described in the following one?
https://docs.microsoft.com/en-us/power-platform/admin/api-request-limits-allocations#non-licensed-usersapplication-users

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

ID: 3fd657fb-b2cb-a85a-7243-41d7cc30dc87
Version Independent ID: 4ed6833a-668b-ff05-97da-286fb6d68394
Content: API Limits (Common Data Service) - PowerApps
Content Source: powerapps-docs/developer/common-data-service/api-limits.md
Service: powerapps
GitHub Login: @JimDaly
Microsoft Alias: bsimons

The link you mention is about Entitlement limits and how they apply to Non-licensed users/application users/Users with special free licenses.
This topic is specifically about how Service Protection limits are applied and how developers writing code can deal with them.  I've re-titled this topic to make that clearer.
I also added this new topic Power Platform / PowerApps / Create apps / Common Data Service / API limits overview

This new topic should help clarify how Entitlement and Service Protection limits are different.
Service Protection limits apply to all users regardless of the request allocation entitlement.
One analogy could be that Entitlement describes how many miles you can drive in a rented car. Service Protection describes how fast you can drive. I hope this helps.

Hi Jim, thanks for clarification!


For the default UK grid intensity API - 'very high' needs to be supported

This library when querying the UK grid intensity API assumes the value can be low, medium or high.
This looks like an assumption we need to update, based on the figure here:
{
  "data": [
    {
      "from": "2024-01-12T12:00Z",
      "to": "2024-01-12T12:30Z",
      "intensity": {
        "forecast": 284,
        "actual": 279,
        "index": "very high"
      }
    }
  ]
}

Why did we not see this before? It might be that it hasn't been this cold in a while, or that we just didn't see it before on branch.
The code in question is at the link below.
https://github.com/thegreenwebfoundation/grid-intensity/blob/main/src/index.test.js#L108-L145
The quickest fix would be to 'cast' a very high result to high.
The longer term fix would probably be to include this functionality in CO2.js, because only querying the UK grid intensity API has plent of shortcomings if you are not in the UK.

LOL, now later in the year on a day where it's been particularly windy and sunny in the uk, we've had 'very low' which we need to cast to 'low' for the purposes of any branch-y designs using this libary.


Use new (non-deprecated) protocol buffer bindings

As a user of Fabric
I want Fabric v3 to use fabric-protos Go bindings based on protocol buffer APIv2
So that Fabric is using actively maintained and non-deprecated protobuf APIs
In early 2020, a new Go API for protocol buffers was released, and the older protocol buffer API was deprecated.

https://go.dev/blog/protobuf-apiv2
Deprecated API: https://pkg.go.dev/github.com/golang/protobuf
New API: https://pkg.go.dev/google.golang.org/protobuf

The two API versions produce 100% wire-level compatible protobuf messages so they can be used interchangeably with no compatibility implications for client applications, SDKs or other Fabric components. This has already been proven in the Fabric Gateway client API, which migrated seamlessly from the old to new protocol buffer API and maintained complete compatibility with Fabric.
Pre-built Go language bindings for the Fabric protobufs are already published based on both the old (fabric-protos-go) and new (fabric-protos-go-apiv2). The only work required is to change Fabric code to use the new protos package.

Per https://github.com/hyperledger/fabric-protos/blob/main/RELEASING.md fabric-protos-go-apiv2 v0.3.0 is ready for use by fabric main branch.

I briefly looked at this and it seems more involved than I'd hoped, particularly since migrating fabric-gateway was very easy (see commit). Other Fabric packages like fabric-config expose the older/deprecated protobuf package in their public API, which is a headache and likely a breaking change.
Since the old protobuf package got reimplemented using the newer protobuf package internally, you can translate between V1 and V2 protobuf Message structs, which might allow at least some changes to be made without breaking any public APIs. See this utility that used to be in fabric-gateway before it was migrated over entirely, which provided a few utility functions that can operate on both V1 and V2 messages by using the GeneratedMessage interface:
hyperledger/fabric-gateway/pkg/internal/util/protobuf.go
Ideally it would be good to entirely replace usage of the old protobuf API with the new one, and avoid juggling between the two message types, but taking advantage of the ability to transform message types might make it easier to migrate step-by-step instead of in one big bang.

Getting everything on APIv2 for Fabric v3 would be great, although none of the modules involved follow the main Fabric versioning! :)
Working out what to do about versions for fabric-chaincode-go (currently pseudo-version numbers) and fabric-contract-api-go (currently v1.2.2) would be good. It seems like these would be breaking changes, so in theory v1 and v2 respectively would make sense...
https://go.dev/doc/modules/version-numbers

fabric-chaincode-go

I can help on fabric-chaincode-go v1 change dev.

The sync.Mutex that was dragged into the apiV2 is the problem... function that takes it type and return it... are being flagged by go vet as copy of locked values.

The solution was to introduce pointers (on such functions signatures, 2 of 'em actually, if I remember correctly), the effect cascaded and some other function signatures had to take pointers too (no internal logic was touched) ... everything was well in the patch(PR) I included...test passed, go vet laid to bed... BUT... it broke an Interface definition.

@denyeart mentioned once a solution... I didn't quite figure it... Buh I'll try take another look at it again this work, hopefully it clicks.

While I also see the sync.Mutex warning issue, I guess it is inevitable to change some interface definition. I am fine with that since it will only affects v3 and onwards versions

@davidkhala this would require a large community vote... maybe maintainers like @denyeart @bestbeforetoday @ryjones can shed light to that better.

@tobigiwa Can you provide more details of the Interface definition that gets broken? If it impacts interoperability between v2 and v3 components then it would be a no-go.

Sorry it took this long to respond, I'll get on it including a solution I have in mind. Pardon me again.

@tobigiwa Any update?

@denyeart Sincerely speaking, I thought I have responded to this already, Please pardon me.
So to the problem at hand, the correction would have to take place in fabric-chaincode-go itself, which then can be cascaded to fabric-contract-api-go then to fabric. I have updated my fix on fabric-chaincode-go to meetup with main.
Regarding the changes to the interfaces, here there are:
So it breaks to two interface, 3 method signature in total, by introduction of a pointer to the pb.Response (in the shim/interface.go file).
// Chaincode interface must be implemented by all chaincodes. The fabric runs
// the transactions by calling these functions as specified.
type Chaincode interface {
	// Init is called during Instantiate transaction after the chaincode container
	// has been established for the first time, allowing the chaincode to
	// initialize its internal data
	Init(stub ChaincodeStubInterface) *pb.Response

	// Invoke is called to update or query the ledger in a proposal transaction.
	// Updated state variables are not committed to the ledger until the
	// transaction is committed.
	Invoke(stub ChaincodeStubInterface) *pb.Response
}

type ChaincodeStubInterface interface {
InvokeChaincode(chaincodeName string, args [][]byte, channel string) *pb.Response
}

This alongside some function signatures too, I should add.

It seems like this might have highlighted an underlying issue with how protobuf messages are handled. There are cases where they are passed by value, whereas the protobuf packages are designed for message to be referred to with pointers, and are not safe to pass by value. Perhaps the right thing to do is bite the bullet and make the breaking API change for Fabric v3.
There were some good observations on breaking changes and versioning above. However, although fabric-contract-api-go already has a v1.x version and so seems like a more obvious problem, I'm not sure these changes significantly impact the public API of that module. Typically smart contract implementors are embedding the Contract type, which is not impacted. It does impact ContractChaincode, but this is typically just created with NewChaincode() and then has its Start() method called, neither of which are changed. People should generally be using this higher level API and not the lower level fabric-chaincode-go API so hopefully the end-user impact is minimised. Even so, I'm not against creating a v2 module. I don't think it's a lot of work and it's certainly the safest approach for both the chaincode APIs since it avoids anyone accidentally updating module dependencies and pulling in breaking changes.

I was waiting for other comments, buh I'll just go ahead, you are very correct with this, it is the only way forward. Also, as you've highlighted, the changes are quite minimal.
What the way forward now? I'll like to do a little part in this.

The last few comments have actually made me more concerned about a move to apiv2.
Since the apiv2 announcement at https://go.dev/blog/protobuf-apiv2 mentions that existing consumers can stay on apiv1 indefinitely, I haven't seen much motivation to move up with breaking changes that may impact fabric users.

At the wire level the change is 100% compatible. It makes no difference to the client or server whether the other is using apiv1 or apiv2. The incompatibilities come when either:

Code is using the protobuf APIs, which are largely similar but do have some key differences.
The namespace conflict that occurs in the Go protobuf implementation when multiple bindings for the exactly the same protobuf messages are mixed in the same application.

The first is contained to the application code so is resolved by making any changes necessary changes to (Fabric) code.
The second impacts users where their application code depends on both fabric-protos and on Fabric (core, chaincode or client API) code, which in turn depends on a specific fabric-protos version. To make certain the protobuf API version used doesn't catch out the application developer, I took the approach of a major version change for fabric-chaincode-go. For users who are making use of fabric-protos in their application code, they can chose which version implementation they want to use and migrate when they are ready.
The major version change for fabric-chaincode-go is also required to fix the problematic pass-by-value of protobuf messages in the public API.

For reference, Go chaincodes are updated to use fabric-protos-go-apiv2:

fabric-chaincode-go v2 is delivered in hyperledger/fabric-chaincode-go#108
fabric-contract-api-go v2 is delivered in hyperledger/fabric-contract-api-go#137

What motivated me?
I was unable to update the fabric-chaincode-go/v2 package in fabric. I really didn't like it.
My plan.
I decided to try an update. And then thought about how to break that upgrade into smaller more manageable pieces.

update the parts of the code that won't work in the new versions of protobuf, protos-apiv2 and fabric-chaincode-go/v2. (https://github.com/hyperledger/fabric/pull/4962 https://github.com/hyperledger/fabric/pull/4963 and https://github.com/hyperledger/fabric/pull/4964)
update the old protobuf library to the new one (No new fabric-chaincode-go/v2 added yet and github.com/hyperledger/fabric-protos-go-apiv2)
The hardest and biggest one. Replacing fabric-protos-go with fabric-protos-go-apiv2. Here you will have to replace 4 libraries that depend on protos-go at the same time. These are github.com/hyperledger/fabric-chaincode-go/v2 , github.com/hyperledger/fabric-protos-go-apiv2 , github.com/IBM/idemix and github.com/hyperledger/fabric-config. Hence here, preferably there should only be package renames and imports. And a minimum of code changes.

My versions of github.com/IBM/idemix and github.com/hyperledger/fabric-config are ready. But I don't offer them for changes yet, I want to build the whole thing and make sure it works.
As soon as the version with the new protobuf is ready I will post it here.

https://github.com/hyperledger/fabric/pull/4970
I present to you my version of the changes to the fabric.
I'm not sure it's finished.
But I suggest you consider it and continue the discussion.

@pfi79 from my perspective, this is a great piece of work. I really like the way you tackled some of the sub-/pre-work in separate PRs, like avoiding pass-by-value for protobuf messages. All versions of the v1 protobuf APIs from the last few years are actually implemented on top of the v2 protobuf API, so it is possible to adopt some v2-specific functions in advance of a full switch by converting v1 proto.Message to v2 proto.Message structs.
One of the tricky aspects is that the protobuf change impacts not only the core Fabric codebase but also dependencies such as fabric-config and idemix. For cases where the public API of those libraries cannot remain unchanged, perhaps the right approach is to deliver v2 implementations of those dependencies (similar to fabric-chaincode-go/v2) in advance of the critical change in the Fabric codebase that would switch to those v2 dependencies. I think you've essentially proved out potential v2 implementations with the versions you've delivered in your forks. This is exactly what I did for fabric-chaincode-go and fabric-contract-api-go to prove I could deliver a fully working chaincode implementation based on the v2 protobuf API.
For Idemix, I wonder if a core implementation could avoid Fabric-specific content (protobufs) entirely, with a fabric-idemix layer that presents that core Idemix capability in a form that is more consumable by Fabric if it doesn't make sense for that code to live in core Fabric. I say this without looking at the Idemix code in any detail to know if it makes real sense; just an idea to consider.

@pfi79 from my perspective, this is a great piece of work. I really like the way you tackled some of the sub-/pre-work in separate PRs, like avoiding pass-by-value for protobuf messages. All versions of the v1 protobuf APIs from the last few years are actually implemented on top of the v2 protobuf API, so it is possible to adopt some v2-specific functions in advance of a full switch by converting v1 proto.Message to v2 proto.Message structs.
One of the tricky aspects is that the protobuf change impacts not only the core Fabric codebase but also dependencies such as fabric-config and idemix. For cases where the public API of those libraries cannot remain unchanged, perhaps the right approach is to deliver v2 implementations of those dependencies (similar to fabric-chaincode-go/v2) in advance of the critical change in the Fabric codebase that would switch to those v2 dependencies. I think you've essentially proved out potential v2 implementations with the versions you've delivered in your forks. This is exactly what I did for fabric-chaincode-go and fabric-contract-api-go to prove I could deliver a fully working chaincode implementation based on the v2 protobuf API.
For Idemix, I wonder if a core implementation could avoid Fabric-specific content (protobufs) entirely, with a fabric-idemix layer that presents that core Idemix capability in a form that is more consumable by Fabric if it doesn't make sense for that code to live in core Fabric. I say this without looking at the Idemix code in any detail to know if it makes real sense; just an idea to consider.

Thank you so much for your comment.
I am ready to redo my pr in fabric-config and idemix similar to fabric-chaincode-go/v2

I suggest that you choose one of the code changes for idemix:
https://github.com/IBM/idemix/pull/47
or
https://github.com/IBM/idemix/pull/48
can someone run pipelines there (github actions)?

@denyeart at your request, I'm specifying what needs to be done:

What is the complete set of PRs that will be needed across all repositories? Are they all open at this time?

modify fabric-config
modify idemix
modify fabric

All pr's are open, I look forward to discussing them and am willing to make changes as soon as possible, as requested by the community.
There are no other repositories for changes

What tests will be required to mitigate the risks associated with the upgrade?

I don't have anything to suggest here yet. Can the community suggest what should be added?

Colleagues, I realize that pr in idemix we are waiting for @ale-linux .
But, can any maintainer consider pr in fabric-config?

I've merged the fabric-config PR.
In terms of testing... I've built Fabric components from the PR https://github.com/hyperledger/fabric/pull/4970 and tested them in a mixed environment with Fabric v2.5.9 nodes. Everything seems to work in a mixed environment. Nice job @pfi79 !

I've merged the fabric-config PR.
In terms of testing... I've built Fabric components from the PR #4970 and tested them in a mixed environment with Fabric v2.5.9 nodes. Everything seems to work in a mixed environment. Nice job @pfi79 !

That's weird. It shouldn't work in v2.5.9.
When the program starts, all protobuf files are registered in the global registry of the program. And github.com/hyperledger/fabric-protos-go and github.com/hyperledger/fabric-protos-go-apiv2 should fight over a single namespace.
You can test this by creating a simple application that plugs in both libraries. And run it. It should crash with panic.

it seems to me that this discussion can be closed

Great work getting these changes done @pfi79 ⭐

I've merged the fabric-config PR.
In terms of testing... I've built Fabric components from the PR #4970 and tested them in a mixed environment with Fabric v2.5.9 nodes. Everything seems to work in a mixed environment. Nice job @pfi79 !

That's weird. It shouldn't work in v2.5.9. When the program starts, all protobuf files are registered in the global registry of the program. And github.com/hyperledger/fabric-protos-go and github.com/hyperledger/fabric-protos-go-apiv2 should fight over a single namespace.
You can test this by creating a simple application that plugs in both libraries. And run it. It should crash with panic. https://go.dev/play/p/PL4AGl4U6mU
https://protobuf.dev/reference/go/faq/#namespace-conflict

What I meant is that I tested a mixed network comprised of v2.5.9 nodes (using old protobuf) and v3.0.0 nodes (using new protobuf) and everything works. This test was important because we would expect users to do a rolling upgrade of nodes where there would be a mix of old nodes and new nodes during the upgrade process.


#592 Use explicit uint size for maths on disk space

Signed-off-by: Lukasz Woznicki<EMAIL_ADDRESS>Proposed changes
Use explicit u64 (may be a little bit slower on some 32bit hardware but it is not exactly performance critical code).
This fixes compilation issues casued by using non explicit int size (usize/isize) with congragetation with different implementations of libc (gnu/musl).
Tested with:
cargo build -p download
cross build --target armv7-unknown-linux-musleabihf -p download
cross build --target armv7-unknown-linux-gnueabihf -p download
Types of changes
What types of changes does your code introduce to thin-edge.io?
Put an x in the boxes that apply

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
[ ] Documentation Update (if none of the other choices apply)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue
#592
Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have read the CONTRIBUTING doc
[x] I have signed the CLA (in all commits with git commit -s)
[x] I ran cargo fmt as mentioned in CODING_GUIDELINES
[x] I used cargo clippy as mentioned in CODING_GUIDELINES
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)

Redundant as a fix has already been propose.


IconMoon Aliases

The IconMoon may have few names for the same icon. Like "spinner, loader, wait"

Thanks!


HTTP fails and stops the container

Specifications

Image hash or version: d99fbaf65c5d63b186e1e997d8dafeec3e3e2267eb36959da024b8056bff4f94
Platform: Archlinux (linux 6.8.8.arch1-1) + Docker version 26.1.0, build 9714adc6c7
Subsystem: x86-64

Expected Behavior
With SERVICE_ENABLE_HTTP=true one should be able to access something in the browser via binded address.
Actual Behavior
The container runs normally with SERVICE_ENABLE_HTTP=false. But if I enable it, the container yields:
...
fr24feed-piaware-1  | [piaware] ADS-B data program 'dump1090' is listening on port 30005, so far so good
fr24feed-piaware-1  | [piaware] Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr <IP_ADDRESS> --net-bo-port 30005 --stdout
fr24feed-piaware-1  | [piaware] Started faup1090 (pid 248) to connect to dump1090
fr24feed-piaware-1  | [piaware] UAT support disabled by local configuration setting: uat-receiver-type
fr24feed-piaware-1  | [piaware] piaware received a message from dump1090!
fr24feed-piaware-1  | [piaware] piaware has successfully sent several msgs to FlightAware!
fr24feed-piaware-1  | ./run: line 17:   227 Killed                  /thttpd -D -h <IP_ADDRESS> -p 8080 -d /usr/lib/fr24/public_html -l - -M 60 2>&1
fr24feed-piaware-1  |        228 Done                    | mawk -W interactive '{printf "%c[32m[http]%c[0m %s\n", 27, 27, $0}'
fr24feed-piaware-1  | s6-rc: info: service legacy-services: stopping
fr24feed-piaware-1  | s6-rc: info: service legacy-services successfully stopped
fr24feed-piaware-1  | s6-rc: info: service legacy-cont-init: stopping
fr24feed-piaware-1  | s6-rc: info: service radarbox: stopping
fr24feed-piaware-1  | s6-rc: info: service planefinder-log: stopping
fr24feed-piaware-1  | s6-rc: info: service piaware: stopping
fr24feed-piaware-1  | s6-rc: info: service opensky: stopping
fr24feed-piaware-1  | s6-rc: info: service netcat: stopping
fr24feed-piaware-1  | s6-rc: info: service http: stopping
fr24feed-piaware-1  | s6-rc: info: service fr24feed: stopping
...

and exits.
 Is there anyway to print more verbose log?

Hello you can disable http and exec httpd manually to see the error and debug. Don't hesitate to see closed issues, it sounds familiar to me.

Hi, thank you for your hints.
the thttpd is killed by OOM killer:
[Fr Mai  3 09:51:25 2024] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=user.slice,mems_allowed=0,global_oom,task_memcg=/system.slice/docker-8bd35660a3190bbe7f501e1a3a8fc0226f392271f22e2fd86eefab8567427932.scope,task=thttpd,pid=2701529,uid=65534
[Fr Mai  3 09:51:25 2024] Out of memory: Killed process 2701529 (thttpd) total-vm:180355452kB, anon-rss:51083712kB, file-rss:320kB, shmem-rss:0kB, UID:65534 pgtables:100020kB oom_score_adj:0

It works by specifying ulimit according to https://github.com/Thom-x/docker-fr24feed-piaware-dump1090/issues/107#issuecomment-1516311871
In my case, it's adding
services:
  fr24feed-piaware:
    ...
    ulimits:
      nproc: 65535
      nofile:
        soft: 20000
        hard: 40000

to the docker compose file.
Interestingly, the adding this actually lower the limit, before:
root@111c7e4eb5c0:/# ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) unlimited
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 0
file size                   (blocks, -f) unlimited
pending signals                     (-i) 256081
max locked memory           (kbytes, -l) 8192
max memory size             (kbytes, -m) unlimited
open files                          (-n)<PHONE_NUMBER>
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 0
stack size                  (kbytes, -s) 8192
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) unlimited
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited
root@51e95bc16fed:/# nproc
20

after:
root@51e95bc16fed:/# ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) unlimited
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 0
file size                   (blocks, -f) unlimited
pending signals                     (-i) 256081
max locked memory           (kbytes, -l) 8192
max memory size             (kbytes, -m) unlimited
open files                          (-n) 20000
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 0
stack size                  (kbytes, -s) 8192
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) 65535
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited
root@111c7e4eb5c0:/# nproc
20

The difference in on "open files" and "max user processes".
and thttpd actually engages far less memory while running:
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    226 nobody    20   0    8936   7028    800 S   0.0   0.0   0:00.13 thttpd

I'm quite confused why this works... and also why thttpd allocates so much memory in that condition.

I would suggest mentioning it in your README. You may close the issue if you find it unnecessary.

Ahh I see the SYSTEM_HTTP_ULIMIT_N option when going through your source code. Sorry for missing it while reading README.
Could you please explain why the number 1048576 is chosen?

Yes, it was for fr24, if I remember it was the max value ?

I see.
What I figured out:

thttpd allocates its connection table with the number from getrlimit (ref: https://github.com/jpouellet/thttpd/blob/master/thttpd.c#L718 ). If the result is -1, use 8192 (ref: https://github.com/jpouellet/thttpd/blob/master/fdwatch.c#L162 ).
However from some version of docker the nofile limit insides containers becomes<PHONE_NUMBER> and some other software users encountered similar problems (ref: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/013821.html , https://github.com/haproxy/haproxy/issues/2043 )
thttpd tries to initiallize its connection table with size of<PHONE_NUMBER> and triggers OOM killer

I think the proper solution here is not set a lower limit. In this case I believe 1024 is far beyond enough.


求助** ARCHIVE FAILED **

** CLEAN SUCCEEDED **
User defaults from command line:
IDEArchivePathOverride = /Users/think/Documents/workspace/zznet/git/smart-class-iOS/smart-class/build/smart-class.xcarchive
Build settings from command line:
CFBundleVersion = 4
CODE_SIGN_IDENTITY = iPhone Developer: Gao Haitao (74E6NBPBCP)
2018-04-04 16:09:10.454 xcodebuild[4398:249345]  DTDeviceKit: deviceType from 4a30868e4f6a429d542619dac38fed1684036b2b was NULL
=== BUILD TARGET DTFoundation OF PROJECT Pods WITH CONFIGURATION Release ===
Check dependencies
Code Signing Error: DTFoundation does not support provisioning profiles. DTFoundation does not support provisioning profiles, but provisioning profile NO_SIGNING/ has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor.
=== BUILD TARGET DACircularProgress OF PROJECT Pods WITH CONFIGURATION Release ===
Check dependencies
Code Signing Error: DACircularProgress does not support provisioning profiles. DACircularProgress does not support provisioning profiles, but provisioning profile NO_SIGNING/ has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor.
=== BUILD TARGET AFNetworking OF PROJECT Pods WITH CONFIGURATION Release ===
Check dependencies
Code Signing Error: AFNetworking does not support provisioning profiles. AFNetworking does not support provisioning profiles, but provisioning profile NO_SIGNING/ has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor.
=====
请问这是为什么，我的使用 pod 构建的工程，pod里的第三方库会报这个错误！！

@stackhou

我只有一个target依然报这种错误 求助


Build new cache during check

During check, the cache is disabled for safety reasons, which means restic will access blobs stored in pack files as it needs them. When several blobs of a single pack file stored in the repo are needed one after another, restic accesses the same file in the backend several times. For some cloud-based backends (like B2), this behavior is billed, each download file transaction costs a very small amount of money.
Instead, we could change the behavior of check: Do not use the existing cache, but create a new one in a temporary directory. This means that the whole file is downloaded when the first blob is accessed, but then all further blobs in the same file can be read locally.
Shouldn't be hard to do, this is just a reminder issue to actually try that.

This cache is for directory packs only and should not grow too big, right?
Most systems have limited temporary directory space available, so the cache will need to capped at certain capacity if you plan to cache all data packs. Which in turn implies some packs may need to be downloaded multiple times during check, which in turn may need some optimization of how restic chooses pack download order.
FYI, I am working on concurrent restorer implementation where I plan to employ transient capped cache of downloaded data packs. Hope to submit (very rough) draft for discussion in the next few days.

Yes, the cache should not grow indefinitely, but adding such logic sounds complicated and error-prone, hm.
I'm looking forward to your idea for the restorer!

I would like to note, that even if you specify --with-cache --cache-dir /tmp/empty-folder/ , restic check does not seem to populate the cache correctly, since the same blobs are requested very often, and the cache directory is too small (~50mb) in comparison to the one on the machine which does the backups (~1.6gb).
The .cache/<id>/data folder is empty.
Unfortunately I did not log the requested ranges on the rest-backend, but I assume that even some ranges are downloaded multiple times. The most frequently requested blob was queried about 2 million times with an average response size of 800 bytes.
I do not know if overlapping ranges are possible, but if not, then some has to be downloaded multiple times.

Overlapping ranges aren't relevant, so I assume there's a bug.

I found the issue, it'll be fixed in #1696


This package added 1548ms to startup time.

Maybe too much 1548ms...that's too bad, mate. Could you do something about it?

Are you monitoring for files or folder?
Can you post the "watch" part of ".remote-sync.json" that you use?
Opening a project I'm working on, I have 82ms, and I monitor 15 files (minified versions of .js and .css)
  "watch": [
    "/js/functions.min.js",
    "/js/header.min.js",
    "/js/send_email_form.min.js",
    "/js/jquery.ui.datepicker-it.min.js",
    "/js/jquery-ui-timepicker-addon.min.js",
    "/js/jquery.ui.timepicker-it.min.js",
    "/css/style.min.css",
    "/template/01/cart.min.css",
    "/template/01/jssor.slider.min.css",
    "/template/01/magnific-popup.min.css",
    "/template/01/mfp.min.css",
    "/template/01/style.min.css",
    "/template/01/admin/style.min.css",
    "/template/01/style_mobile.min.css",
    "/template/01/admin/functions.min.js"
  ],

I am not using any watch values for any of my projects, and also have a 1500ms startup time for this package.

Actually I'm not using this package anymore: if you read the description

Remote Sync PRO is a fork of the remote-sync project which was abandoned in 2016
but it looks like there's non more activity in this fork, while the original "remote-sync" has been updated, so I revert back to that one (same config file, no action required to switch between the two).

Anyway, on my Windows PC, the "Package Activation" list of "timecop" shows 95 packages from 6ms to a max of 199ms, and this packaged took 80-89ms (same as "remote-sync").

@FabioDa10 Last commit was 7August 2018, but remote-sync 26 Oct 2017! Remote-sync-pro takes 369ms to start for me, I think it's normal.


raftstore: update raft only in store thread after confchange

RawNode is not designed to be thread safe, so we should only update RawNode in store thread after confchange is applied.
@siddontang @hhkbp2 PTAL

PTAL

LGTM

PTAL

PTAL @ngaut

LGTM


Make Core work with ReactPHP

It should be relatively easy to implement a connector that would use ReactPHP's Http Client.
Need to investigate this further (especially implementing promises and exposing them to higher level).

:+1: To this one. I have been investigating react recently and it looks very interesting. Maybe guzzle 5 which is async would be a good choice.

Yes, ReactPHP is definitely still on the plate and I read a bit about Guzzle 5, yesterday, after restructuring Core's code a bit (in devel). Though, I still have not reached a decision on the extent and implementations of compartmentalization (and therefore, extendability and customizability) of the Core. I will have to do some testing with Guzzle & ReactPHP in order to include the correct handling of that type of flow in the Core.

Well, after trying to learn Guzzle & ReactPHP to make them work with Core, I painfully found out that ReactPHP socket-client has a problem working with <IP_ADDRESS> in a docker container. Curl works ok inside the container, and Guzzle (using ReactPHP) also works outside the container in the docker host's (Boot2Docker) host (Windows 7) OS.
So, I'll first try to find out what's wrong and file an issue with whomever I have to (docker, ReactPHP?)...

So, after finding a solution to the "ReactPHP and linked Docker container" problem (see my blog post), I got the Guzzle Provider on the road pretty quick. The Result is this still experimental but working project: https://github.com/frankmayer/ArangoDB-PHP-Core-Guzzle.
There's still some work to do on the structure, tests & docs, so it's not stable yet. Will let you know.

:dancer:


Remove some of the unused CouchClient methods

What: Remove unused and unnecessary CouchClient methods

Why: More preperation for the 49297 'HTTP connection resilience'. This helps us to identify which methods need to be wrapped in a retry loop by ensuring that each method has a clear purpose and that there are not multiple overloaded methods which do very similar tasks. Also some methods were only ever called by test code.

Testing: One test which is no longer relevant has been removed: getDocument_docDeleted_exception. This fetched a document without specifying a revid which never happens in production code. All tests pass.

reviewer: @mikerhodes
reviewer: @rhyshort

+1

+!


feat: Add DataTypeMode config

Jira:

https://keboola.atlassian.net/browse/PSGO-531
https://keboola.atlassian.net/browse/PSGO-532
https://keboola.atlassian.net/browse/PSGO-533

:+1: Thanks for the explanation, so could we just give the test a better name?
simple-no-schema -> mode-schema-empty-manifest
dump-config-schema -> mode-schema-missing-manifest


Simplify property declarations

Can I use php-cs-fixer to simplify such property declarations:
private $myProperty = null;
private $yetOneProperty = null;

as follows ?
private $myProperty;
private $yetOneProperty;

Thanks in advance!

Hi!
Currently we've got a Fixer for this, however it shouldn't be a hard one to build.
Please let me know if you can help out, happy to help out :)

@SpacePossum , it would be very nice to have this feature.
Unfortunately, for now I cannot help with this, but I will happy to help after first stable release of MongoDB ODM, which is planned to the June, 2017.
For now ODM is using zend-code lib, which generates pretty ugly code, for example always generates property like private $property = null;, i.e. with null default value, so I'm wondering whether there is a quick solution for this for the ODM users, before I release normal library for code generation :)

Alright, no rush!
Lets see who can start on this first, you or I, and than we can get this fixer in.
Good luck with MongoDB ODM, looks promising :)

@ntzm , @SpacePossum , @keradus, @julienfalque  - thank you guys!

you're welcome @petr-buchin , enjoy the next release :)


Cannot find module ../storage/users

It appears there was some setup you did that was not accounted for during initial launch, and these details do not appear to be in the readme. After manually adding ../storage/users.json and adding {} to the file, the electron app booted perfectly
Note: I have not yet gotten the app to function as expected on Mac OS.

The storage/users.json is do to the require function not using the custom requreFromJSON function. In the latest dev build that has been fixed, it just hasn't been pushed to live yet.
As for the Mac OS not functioning as expected can you elaborate on that?

Changed how the component loads data to use electron-storage so the error for ../storage/users.json no longer applies


FramingIO optimizations

Build status:

Linux
Windows

Build status:

Linux
Windows

Build status:

Linux
Windows

Tested along https://github.com/eProsima/Micro-XRCE-DDS-Agent/pull/278 with crazyflie demo, looking good!


Add ConnectionChecker feature

Add ConnectionChecker
Add the ability to declare kafka settings directly inside of HOCON (declaring key and value serializer/deserializer is not implemented yet)

Added an issue to update documentation https://github.com/akkadotnet/Akka.Streams.Kafka/issues/191


ModalComponents不支持header drag

What problem does this feature solve?
全局模态框支持drag。目前是通过引入angular cdk drag，通过[title]传入方式来支持drag。但是这样重复代码太多，每一个模态框都需要复写title模板，是否能够提供一些方式解决以上需求。
1,默认支持drag，全局配置即可实现
2，支持配置全局默认的modal title，自行引入angular cdk drag来支持drag
What does the proposed API look like?
[dragable]=""

Much needed! Right now we're using CDK DnD via long complicated process to get components working inside a modal that's draggable.
Adding on to the feature requirement...

The draggable modal should also have an option allow users to click/use the document in the background (ie. CDK overlay should be disabled).
It would be great to have "Minimize" and "Maximize" capability to the modals too.

These features will make zorro Modals truly PRO.

@plusGo 您可以参考我的实现，在线演示地址为http://<IP_ADDRESS>:8081/ 。进入系统后点击 “功能》拖拽modal”来查看演示效果。源码地址为https://github.com/huajian123/ng-ant-admin/blob/master/src/app/widget/base-modal.ts


Story:  Help navigate in a lot of experiments

These comments are the only meaningful thing left in this ticket

outdated:
This epic is created so we can discuss the concepts together with the DVC team.
Ideas

[x] Star experiments in table #1676
[ ] Pin experiments to show them at the top (won't do)
[ ] Be able to drag and drop rows pinned expS (won't do)
[ ] Naming/renaming experiments after execution (won't do)
[ ] Able to add context to an experiment (labels https://github.com/iterative/vscode-dvc/issues/1720#issuecomment-1174473366, custom labels, pin, group, comments, free text, notes about experiments etc) (won't do)
[x] Collapse exps and checkpoints #2071 & Show a limited amount of checkpoints that can optionally be expanded further #1269

Figma specs

Star experiments in table
Label experiments in the table
Collapse exps and checkpoints
Group interesting runs in sections with a title
Able to add context to an experiment (comments)

Labels (using GH colour scheme), just so we can keep this ticket alive. Would probably make sense to sort by label, the same way we are planning to show only starred expS.

Hey @shcheklein . As a part of the task "Help navigate in a lot of experiments" I think that being able to fold not interesting EXPs can be useful. Please let me know WDYT.
Concept on Figma

@shcheklein here is another concept I would like to share in relation to this ticket: "Group interesting runs in sections with the title"
Figma

@mattseddon What do we need to unlock this: Naming/renaming experiments after execution?

@mattseddon What do we need to unlock this: Naming/renaming experiments after execution?

I believe the ticket for that is https://github.com/iterative/vscode-dvc/issues/2055
IMO this ticket needs user input and product decisions.
Hard to know what the next steps are from the OP.

@mattseddon What do we need to unlock this: Naming/renaming experiments after execution?

I believe the ticket for that is https://github.com/iterative/vscode-dvc/issues/2055

Yeah. My question was: How to unlock it?
From #2055 "I think it's not very hard to implement, but still need some time to finish it."

Yeah. My question was: How to unlock it?

First, we need to decide how high of a priority this is for us. We then need to convey that priority to the DVC team so that they can schedule the work... or not.

Let's keep it and get back when we have a bit more user input + we are done with the current activities. I'd like to keep it lightweight as much as possible. It would be a mistake to implement something complicated like labels. On the other hand, we naming + some lightweight notes/comments could be done I think. Anyways, let's not prioritize for now.

My feedback on the experiments table:

It's not clear which experiments and commits are being shown (or even the relationship between experiments and commits). TBH I'm not sure what's being shown here now so don't know what to suggest 🤔 .
Sorting and filtering across commits would be helpful (also true for CLI). It's not clear why certain experiments get sorted/filtered and others do not, and it's not helpful to only be able to sort within a commit. Maybe it makes sense to be able to toggle between a Git history view like we have now and more of a flat table view that treats all experiment runs/commits equally?
Commits without any metrics should probably be hidden/deemphasized.
What about using the exp show options for filtering the rows to show? It would be more consistent across interfaces and increase flexibility.

Also this is mentioned in #2726, but I would find renaming (as suggested above) helpful. If it's decided it's worth pursuing, we can look into it on the DVC side.

Modifying the table view to only show differences (vs all available parameters) would help navigate a table with lots of experiments.

Closing in favour #1994


Workspace: Base Docker Env Setup

GOAL: Get the World/Env Setup, so we eliminate the dependancy and can build abilities on top that interact with this world env, so we can then work on the actual processing layers/agents.
Deployment of an Linux Docker container (with persistent storage) for the agent

Create the standard Docker Build Image for the agent with preinstalled dependencies (pip, python, etc... – so that it already has some stuff predefined installed)
Add a Docker Swarm in the root that spins up this Linux Docker container when you start the agent (this docker swarm will be expanded to then also start the FastAPI server, etc...)

Implement the high level util functions to interact with the docker container:

get_docker_working_dir --> get the persistent storage location we will need to access from the abilities
https://pastebin.com/raw/7vNtd593 example
docker_run_command--> to interact with the linux docker container via shell
https://pastebin.com/raw/tePJGB2m example

Docker Python SDK https://docker-py.readthedocs.io/en/stable/

IDEA Maybe a synced "workspace" folder within the Agent´s repo thats also the main workspace or like the desktop of the agent in the docker container --> that maybe being a git repo --> when the Agent changes files -> we add to the abilities that that also trigger a commit on that Agent Workspace Repo & then we have a version history of his personal Workspace. Not 100% convinced with this, maybe later.

I have cloud and docker experience so I might be able to help with this one. Open to thoughts on how much of this we should be rolling ourselves. Should we use something like Coder Self-Hosted Cloud Development Environment?
Can we use AWS as the default Cloud Provider for our self-hosting instructions?

I had experimented with the self hosted cloud dev env in the past & I came to the conclusion that I think we really dont need it, like we essentially just need the Linux Container running -> docker exec to use the Terminal & interact with the container as a whole as an admin to run commands & we need the Real Directory Path of the persistent storage of that Linux Container hosted on the Server instance. & the general server (the abilities) are then doing the code changes, etc... directly within the persistent storage – With BrowserOps its the same -> there we are hosting an Headless brow besides that Linux Workspace Container --> the headless browser which is used.
I´d propose we just dockerise everything at the end & then you can use any cloud provider you like

Sounds good, based on our chat I think we can comfortably start in docker-compose. Feel free to mark me as assigned for this one.

Done, when do you think you´ll be able to PR the Linux Workspace for approx - as thats the blocker to building out abilities & subsequently layers/agents

when do you think you'll be able to PR the Linux Workspace for approx

@markokraemer just sent first PR, you can let me know if I have the right idea for next steps


ReqRep client does not receive response

I built nzmqt with zmq 2.1.11 on Windows 7 using the Qt SDK (Qt 4.7.4).
When running your Req-Rep example, there's no message received (only sent) and it just hangs there.
client output:
ReqRepClient::sendRequest>  ("REQUEST[1: 2012-01-25T12:38:08]", "ping")
server output:
ReqRepServer::requestReceived>  ("REQUEST[1: 2012-01-25T12:38:08]", "ping")
ReqRepServer::sendReply>  ("REPLY[1: 2012-01-25T12:38:12]", "ping", "REQUEST[1: 2012-01-25T12:38:08]", "ping")
Doing a little bit of digging, it appears that socketReadActivity never gets called on the requester side even after a message comes in.
This may be related to this thread:
http://lists.zeromq.org/pipermail/zeromq-dev/2011-December/014688.html
but I'll do some more digging.

You're right, I can reproduce this behaviour on OS X, too. It seems like this bug was introduced with the bugfix for gh-1 (changeset 1102204cda).

Hmm... I'm kind of new to Qt so I can't quite figure out how that change would have introduced the bug.  I have found a workaround though, which is to call receiveMessage after every time we send a message on the request socket.

Besides the QSocketNotifier solution for listening to incoming messages I've implemented a new polling-based solution which seems to work without problems. I've changed the examples accordingly. They use the new implementation now. The old implementation is still available (see the commit message for more details). I'd appreciate to get feedback for the new one... :)

Hi,
I've implemented a new polling-based integration into Qt's event loop.
It would be great if you could try it and check if it works for you. See
the examples on how to use it.
Best regards,
Jonny
On 25.01.12 20:35, yisding wrote:

Hmm... I'm kind of new to Qt so I can't quite figure out how that change would have introduced the bug.  I have found a workaround though, which is to call receiveMessage after every time we send a message on the request socket.

Reply to this email directly or view it on GitHub:
https://github.com/jonnydee/nzmqt/issues/2#issuecomment-3657285

I'll check it out.  Thanks for making the change.
On Mon, Jan 30, 2012 at 6:17 PM, Jonny Dee <
<EMAIL_ADDRESS>
wrote:

Hi,
I've implemented a new polling-based integration into Qt's event loop.
It would be great if you could try it and check if it works for you. See
the examples on how to use it.
Best regards,
Jonny
On 25.01.12 20:35, yisding wrote:

Hmm... I'm kind of new to Qt so I can't quite figure out how that change
would have introduced the bug.  I have found a workaround though, which is
to call receiveMessage after every time we send a message on the request
socket.

Reply to this email directly or view it on GitHub:
https://github.com/jonnydee/nzmqt/issues/2#issuecomment-3657285

Reply to this email directly or view it on GitHub:
https://github.com/jonnydee/nzmqt/issues/2#issuecomment-3730943


Update streaming-endpoint-concept.md

You can for sure delete the "default" streaming endpoint. I did it. Try it out.

@gtondato : Thanks for your contribution! The author(s) have been notified to review your proposed change.


UX = RADIO BUTTOM for FREE CODE CAMP RADIO !!!

Better UX for FCC radio listeners <<<

I think that radio is a great addition to the website. this feature gives a whole new dimension (AUDIO / SOUND) to the experience of using it.
+most of us listen to music when using the site = (pretty sure many ppl listening.)
the selection is great, the idea also...
BUT i discovered a flaw in the UX on how to reach it.
and this could be improved.

PRESENT STATE of UX
(standpoint = i know nothing about the radio)
i get a push note saying that FCC radio available (but i opt out) only to find out i need a change and don't want to listen to my selection anymore ...

OK BUT
how can i find the radio ??? ( i lost the link when i switched off the push note )
after some search on the forum (searched for "radio" , "free code camp radio" and found nothing)
i eventually asked this on the forum as i could not find the radio.

i got a nice response with the direct link to the radio embedded in the message:

OK. BUT how can i reach the radio form the site (i asked)...
than i got this message:

OK. OK it is on RCC you-tube channel.
GREAT!

THE ISSUE with this...
with present UX there is no way to find the radio on the website.
if the user wants to use this feature he has to click (1st) on >>> COMMUNITIES than click (2nd) >>>YOUTUBE and >>> click (3rd) >>> radio on top of the videos.
then it comes alive (in a separate window)
(notice that all other videos are about programming and music is on top.)

????
if Music is so much part of our everyday programming:
quote from an article on medium:
"campers have collectively spent more than 10,000 hours listening to it while coding."

THAN
-why not have a separate button? with direct access?
-why the station is on you-tube, and why it is a video? (video for audio files?)

I suggest that we first create a separate button (under >>>YOU TUBE<<< and name it >>>RADIO<<< or simple >>>MUSIC<<< or even >>>FCC RADIO<<< or >>>RADIO STATION<<<
than we can also argue about whether it is necessary to keep it on you-tube at all and if we could build this function in the website with a simple on / off button and a visual sign showing that the radio is on... (like the waves on the you-tube channel now.)
please note: i raised this issue to improve FCC website. i have no intention to criticise it's working or the persons/s who created the website and this function.
please let me know what you think.
thank you.
zoltan

Hi @zoltanalmodo.
The way you are presenting this issue appears almost spam like because of the excessive use of capital letters and very little sentence structure. There are more succinct ways to ask if the freeCodeCamp radio can be added as a separate button on the website. Or why the radio is hosted on YouTube as a video and not somewhere else. Can you rather edit this issue so that it would be more structured?

I see what you mean...
maybe better just to suggest creating a separate button on the website for the RADIO station (under YouTube). even before thinking about building this function into the website as an extra.

Building the radio into the website would incur charges for hosting and bandwidth. Whereas hosting on a free service such as YouTube there are no costs.

I understand. === still, a separate button would help a lot! ==== and this issue is about the button and how to access the service. rather than the service itself.

@zoltanalmodo Hello. Can you please modify your issue text so it is more readable? It is very hard to tell what your request is concerning FCC Radio due to the excessive use of capital letters and special characters. Thank you.

@zoltanalmodo Sorry, we are not going to build feature for radio. And we cant make a direct link to the live stream. since live stream link is always different. so we are not going to change the direct link every time when someone starts the live stream every time. that is why we put youtube channel link on there.
I have to close this issue. I don't see a reason for this have a flaw UX about radio issue. sorry again.


ChannelMaskConflict loop skips one element dependency sets

mask_conflict.ChannelMaskConflict.fix_mask() loop skips one element dependency sets. Should not those elements also be updated? For instance in my trials for BERT, 'bert.encoder.layer.0.attention.self.value' may enter the loop as one-element and its mask would not be fixed properly.
https://github.com/microsoft/nni/blob/928575b4a65ff4b26faf3ef55f178eefbec25364/nni/compression/pytorch/utils/mask_conflict.py#LL229C24-L229C24

Hello @fatih-ilhan , do you mean you want bert.encoder.layer.0.attention.self.value and bert.encoder.layer.0.attention.self.key in the same dependency set?

I am not sure about this. But, I was confused when the query, key weights were fixed after fix_mask() whereas the value weights were not fixed because they were skipped in the for loop.

I understand now, we can close the issue. Thanks!

I am very glad to hear that your issue had been resolved, congratulations! So could you close it? @fatih-ilhan


cannot show the installed extensions  immediately when I open Extension Manager.

When I open the Extension Manager, I need to wait until Brackets loads all necessary resource from  Internet, but sometimes I only want to manage my extensions and don't need to install new extensions.

There are already open issues about this...
#11567
#11657
#11729


Use the dxw fork at a specific tag

The dxw fork fixes security alerts.
The upstream repo doesn’t have much activity, and doesn’t seem actively developed.

 Fix security alerts for Zendesk Apps Tools by updating our fork of it


SQL Error

Hi there. I've been having an issue with Prism and MySQL. The database information is all proper but I am constantly being told something along the lines of:
Cannot add or update a child row: a foreign key constraint fails (apexMC28027.prism_data_extra, CONSTRAINT prism_data_extra_ibfk_1 FOREIGN KEY (data_id) REFERENCES prism_data (id) ON DELETE CASCADE ON UPDATE NO ACTION)
apexMC28027 being my login username.
Databases created by other plugins present no current issue:
https://gyazo.com/a65091a23d0ffdb492047535f876f897

This error is for Prism for Bukkit which isn't supported anymore. https://github.com/prism/Prism-Bukkit
The error means Prism was unable to correctly save data and relational data is missing.


create "rstudio" theme based on the enhanced css we are using in our examples

If all of our examples are using the enhanced CSS I think it will be frustrating if users can't use that in their own tutorials.

Fixed via https://github.com/rstudio/tutor/blob/master/inst/rmarkdown/templates/tutorial/resources/rstudio-theme.css


deprecation warnings in ember 1.12 and 1.13beta

I have deprecaton warning "Ember.required is deprecated as its behavior is inconsistent and unreliable."
For example, in the line: https://github.com/kaliber5/ember-bootstrap/blob/master/addon/mixins/type-class.js#L18

Thanks for reporting, will fix this. As well as the other API docs issue...

Fixed in master


ZXing (iOS) not resetting camera settings

After doing a succesful scan (and closing the component), the camera settings do not get reset.
This is referenced in https://github.com/Redth/ZXing.Net.Mobile/issues/491 , where the issue talks about the AutoFocus not working properly.
However, I find that the resolution I passed to the ZXing component also deforms any pictures taken after a succesful scan.
So, in my app, if I scan a barcode, then use the camera afterwards to take a picture, the picture output of the camera will be deformed to fit ZXing's picture resolution.
Has anyone found a way to properly reset the camera after ZXing has used it?

I can confirm this issue. +1 for fix in future release...

I too am seeing this issue.  +1 for fix in future release

I'm having the same issue. This needs fixing.

Also seeing this issue

Thanks for reporting this issue!  Unforunately it took me way too long to respond 😭.  Sorry, I apologize!  Recently the source code for this project was completely refactored to modernize it.  Many PR's were included in this effort, and many bugs were hopefully fixed.  Please try out the latest 3.x series of NuGet packages (currently in prerelease).  To try and make the project more maintainable in my spare time going forward, I've decided to close all existing issues to start with a clean slate.  If you're still experiencing this issue on the newest version, please open a new issue with as much detail as possible.  Thank you for your patience and understanding!  Happy scanning!


Layout changes for the send screen

Make the memo optional and present sheet for users to actually fill it in. That will shrink the address + amount enough to not deal with the keyboard issues

Closing, resolved with #651


[Question] How to prevent rigidBody from shaking when colliding with another static rigidBody ?

I'm writing a game using this lib and I make the player move by setting the liner velocity. But it will shake when the player hit the wall. Is there a solution?

😀I've solved this problem by setting the bounciness to 0.


[Bug]: When Using MM to open game my save files are no longer there, SE issues too

Operating System
Windows 10
BG3 Mod Manager Version
<IP_ADDRESS>
BG3 Game Version
full release patch 5 hotfix 14
Bug Summary
When I use the "Go Launch Game" when the game loads it has me accept terms and conditions and when I get through the set up for the game my save files are no longer accessible, but when I go through the Larian Launcher my files are there. I've also tried using the Tools "Download and Extract Script Extender" to download the SE update (not entirely sure if I need to continously do that) and it gives me an error about not being able to install it and to check error log, which im unable to find.
I'm also not sure if this is related, but none of my saves other than a small handful of my newest ones, are showing as saved to the steam cloud, even though before today every save file I had would auto backup and remain in the Steam Cloud.
Any assistance would be appreciated.
Links
No response

I am experience the same issue. It was launching perfectly fine a few days ago, as I was using the Mod Manager launcher and "-continueGame" thing in the preferences as a work around for the bug where changing mods would cause your saves to not load. I'm not sure exactly what changed since then, but somewhere down the line, it's suddently stopped finding any save data.

I am having the issue too. It looks like a debug profile is being created Everytime I try to launch the game. The first time it happened I deleted that profile and restarted bg3mm and it worked but now it creates it as soon as I launch and never gives me the option to continue my game only start new.


fix(speedup): support for a special torchscript op 'aten::to.layout' with no corresponding torch.to

Description
bug reason:
There are 4 torchscript ops of 'aten::to':
aten::to, aten::to.dtype, aten::to.device, aten::to.layout,
but the torch.to can only support the first three 'aten::to', and there is no no corresponding pytorch op of 'aten::to.layout'.
So it should be treated specifically.
Test Options

[ ] fast test
[ ] full test - HPO
[ ] full test - NAS
[x] full test - compression

Checklist

[ ] test case
[ ] doc

How to test
The bug is hard to reproduce. So, I just send it to the user then he said ok.

@Louis-J Could you link the issue to this pr, why it is hard to reproduce, did user show his code?

/azp run full test - compression


Stll empty

Downloaded wit git still empty

you can follow the steps explained here :
https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/How-to-clone-a-git-repository-with-submodules-init-and-update
or if you are on Windows, you can use a software like https://gitforwindows.org which does the necessary by default


Add mobile responsive breakpoint

Add mobile responsive breakpoint
Please add a mobile responsive breakpoint to all pages for the HRA Portal.
UX/UI Mobile Notes

The HRA hamburger menu should function similarly to the HuBMAP Data Portal's small breakpoint hamburger menu. View this in action on mobile or in a narrow internet browser window.
When the hamburger menu is open, the background behind it needs to be #000000 at 16% opacity
The title cards on content pages will no longer have icons at this breakpoint
Horizontal scrolling is needed for pages that have tables
2D & 3D pages have dropdown menus listing the organ instead of organ icon button lists

Resources

Figma design file mobile landing & navigation
Figma design file mobile overview pages
Figma design file mobile content pages
Figma mobile prototype
Video: mobile demo (no audio)

Mobile responsive 4th Release Notes page with FAB

The Release Notes will be made responsive by using a floating action button (FAB) to trigger the opening of the table of contents (TOC) menu.
The TOC FAB is always in view and floats above all content on the page.
Users can close the TOC menu by pressing the FAB or pressing anywhere outside the menu.
User Flow: The user presses the TOC FAB. A TOC menu opens. The user selects a menu item. Simultaneously, the menu closes and the view jumps to the selected section.

Prototype Interaction Details:

Resources

Release Notes Figma Prototype
Release Notes Design File

Example

Wikipedia has a great example of a similar implementation. See below:


Large PNG files

Hello,
I've implemented the sharp package and I'm seeing great performance in terms of speed and resources used. However, for large resolution resizes, the resulted file more often than not, tends to be bigger than the original.
For a 1000px x 750px PNG file I ran a test with for instance, the original file was a little less than 1 MB and the resulting file (same resolution as this size is less than the set .max() I was testing with) was 1.4 MB.
I should also mention that I used compressionLevel set to 9 and withoutAdaptiveFiltering for this test. What are the other recommended methods / settings to be used with the resize function that would result in a smaller file size for PNGs? What about JPEG files?
Thanks,
Constantin

Hi there, I suspect you've run into a limitation of libvips' PNG output supporting a minimum of 8 bits per pixel. PNG tools such as pngquant use quantisation to reduce this to 1, 2 or 4 bits per pixel.

Hope this answered your question. Feel free to re-open if not :)

Since sharp v0.28.0, libimagequant is included in the prebuilt binaries, which means palette PNGs can be generated.
https://sharp.pixelplumbing.com/api-output#png
await sharp(input)
  .png({ palette: true })
  .toBuffer();


Add block-style post-processing of hexdump rows

Add the ability to post-process rows of a hexdump, similar to zhexdump.

Going to hold this back from 1.0.0. Not feeling it.


Binary file

Hi, can u make precompiled binary file  ?

+1

@Slach This is super actual, especially when you setup monitoring using configuration management tools (Ansible,Chef, Puppet etc.), most of the prometheus exporters have a pre-build binaries like node-exporter that saves hundreds lines of code in configuration management. Can you add a pre-build binary for linux-amd64  at least, please?

@alexqrid clickhouse itself already have embedded prometheus endpoint
you don't need clickhouse-exporter for new versions of clickhouse