Memfault-SDK integration with MyNewt (Alternate)

In this alternate PR I have utilized a slightly different strategy.
A new OS_COREDUMP_CB syscfg flag in conjunction with a new os feature to register a custom callback allow the memfault integration to register its own fault handling API.

I have already reviewed most of it. Please consider this approach based on our discussion on slack. @wes3 @mkiiskila @andrzej-kaczmarek @utzig

Registering callback via API is useless for any crash that happens before registration. This should be done in the same way as os_assert_cb, i.e. just have prototype for that function and call it - some package in the project should provide definition.
Also we do not really need any code related to Memfault in mynewt-core for this to work - the package implementing os_coredump_cb callback can reside in Memfault repo since you need to include it anyway. So the way this would be used is: set OS_COREDUMP_CB: 1, include Memfault package from other repo, done.

Registering callback via API is useless for any crash that happens before registration. This should be done in the same way as os_assert_cb, i.e. just have prototype for that function and call it - some package in the project should provide definition.
Also we do not really need any code related to Memfault in mynewt-core for this to work - the package implementing os_coredump_cb callback can reside in Memfault repo since you need to include it anyway. So the way this would be used is: set OS_COREDUMP_CB: 1, include Memfault package from other repo, done.

I can see how replacing the registration process with a compile time function pointer to the callback is beneficial but I don't see the benefit of keeping the package itself out of mynewt. Isn't it easier for a mynewt user to utilize os_coredump_cb if all the options to set it up also existed in mynewt rather than needing to scour the internet for potential packages? It would also mean that a change that affects the usage of os_coredump_cb can easily be done for all packages that use this functionality

I don't really see good reason why we should include support for paid-for proprietary product in Mynewt tree given that it can be easily done out-of-tree. Also I don't like that proposed solution pulls Memfault repo via some other 3rd party repo, so the benefit is that in your own repo you can do integration in whatever way you like and no one cares. And the clean and simple solution to have full official integration would be to add callback on our side and then let Memfault make use of it in their repository.

@andrzej-kaczmarek
I have a few thoughts of my own on this:

We should not restrict support for anything because its for profit/non-profit, that is really not what open source is all about. People should be free to use what they want. If the code is open, it is open source and in this case the SDK code is open. If somebody wants to write tools to utilize the SDK, that's their call. Mynewt is an open source RTOS and adds support and code for the OS and services in the OS, should not be caring about how it gets utilized on the other side.

We should also cater to changing needs of the demographic, if today people are using something, we need to make them aware that it is being supported. We do not have a dedicated marketing effort going on in mynewt. Don't you think we should do things that promote mynewt. Adding memfault as a utility does not really make us liable for support for it, that is maintained by the SDK. MCUmgr is our official device management protocol and will always remain. What we are doing here is showing that other device management protocol/services also work with mynewt, it's not just MCUmgr.

I do understand your point but it is a very narrow thought process and I do not agree with it.
Please try to understand the bigger picture. How do people get end -> end device management using mynewt ?
Either ways @t3zeng has gone ahead and done his part and opened up a new PR with what you want.
https://github.com/apache/mynewt-core/pull/2687

I do like this approach:

I can see how replacing the registration process with a compile time function pointer to the callback is beneficial but I don't see the benefit of keeping the package itself out of mynewt. Isn't it easier for a mynewt user to utilize os_coredump_cb if all the options to set it up also existed in mynewt rather than needing to scour the internet for potential packages? It would also mean that a change that affects the usage of os_coredump_cb can easily be done for all packages that use this functionality

@vrahane
I said explicitly that I do not like idea of having that package in Mynewt tree. I do not have any issue with adding APIs to support it, thus proposed callback, and I do not want to restrict anyone from using Memfault or any other tool with Mynewt, not even sure how you came to such a ridiculous conclusion.
Once we add os_coredump_cb, adding required support to Memfault repository is trivial and imo it's the best way to do this: we do not need to maintain it and we have proper support that we can advertise e.g. on webpage. Otherwise, as proposed here, we have a package that requires a 3rd party repo that includes some fork of actual memfault-sdk repo... good luck with maintaining that.

@vrahane I said explicitly that I do not like idea of having that package in Mynewt tree. I do not have any issue with adding APIs to support it, thus proposed callback, and I do not want to restrict anyone from using Memfault or any other tool with Mynewt, not even sure how you came to such a ridiculous conclusion.
Once we add os_coredump_cb, adding required support to Memfault repository is trivial and imo it's the best way to do this: we do not need to maintain it and we have proper support that we can advertise e.g. on webpage. Otherwise, as proposed here, we have a package that requires a 3rd party repo that includes some fork of actual memfault-sdk repo... good luck with maintaining that.

There are some misconceptions here. First off, the purpose of the wrapper repo is to house the necessary mynewt repo yaml files. This is there because mynewt only allows for the repo files to be at the top level and it provides the power to choose when to update the commit hash in case things break.
Second, it currently includes some fork of the actual memfault-sdk right now because that fork contains changes that I am currently working on merging into the official memfault-sdk repo. Once that merge is complete, the wrapper repo will host the official memfault-sdk repo and not some fork.
Taking out the memfault package from mynewt tree does not eliminate the need for the wrapper repo because you still need to pull in the memfault repo to mynewt to use it. The only difference is in your proposed solution the coredump callback is defined in the memfault sdk, users need to use the internet to search for what callback functions are available for them to use, and any changes to the mechanism on mynewt side will break all packages that leverage the new coredump callback since they will all live outside of mynewt.
What removing the memfault package from mynewt-core doesn't change is the need to have a repo that has the yaml files needed for mynewt to recognize it as a repo that can be pulled in for use.

There are some misconceptions here.

No, I know exactly why you "need" all those hacks to make it work. What I propose instead is doing this properly and add everything to Memfault repo and get rid of all those intermediate repos/packages/whatever. And that also includes repository.yml...

There are some misconceptions here.

No, I know exactly why you "need" all those hacks to make it work. What I propose instead is doing this properly and add everything to Memfault repo and get rid of all those intermediate repos/packages/whatever. And that also includes repository.yml...

Getting rid of the intermediate repo has no bearing to the changes in mynewt. All that changes is the path of the package that's included which is a very minor difference not worth fixating on in the context of this review.
Not including the package or any reference to this support on mynewt side simply seems strange since a user would not be able to easily know what is available to them if they want to use the feature. They would need to search on the internet which makes using mynewt less attractive to both hobbyists and companies alike in comparison to some other RTOS that does include support. Also, this os_coredump_cb functionality can't change in the future without breaking all of the different individual packages that live all across the internet because nobody can easily know what packages were supporting it and even if they did, they would need to make a PR to all of them or else they would just stop working forever.
I already made a PR that removes the memfault package so you're free to approve it if you support that strategy
https://github.com/apache/mynewt-core/pull/2687

Getting rid of the intermediate repo has no bearing to the changes in mynewt. All that changes is the path of the package that's included which is a very minor difference not worth fixating on in the context of this review.

Why would I want to pull in proxyco/mynewt-memfault-sdk instead of just using memfault/memfault-firmware-sdk directly? Why not PR the yaml files there? And btw, I think version.yml is not required anymore.

Getting rid of the intermediate repo has no bearing to the changes in mynewt. All that changes is the path of the package that's included which is a very minor difference not worth fixating on in the context of this review.

Why would I want to pull in proxyco/mynewt-memfault-sdk instead of just using memfault/memfault-firmware-sdk directly? Why not PR the yaml files there? And btw, I think version.yml is not required anymore.

Okay I can get rid of version.yml thanks. The wrapper repo is mainly because the memfault people didn't like that the yaml is required to be at the top level but it also acts as an anchor to commit ids that we know work well with mynewt

The wrapper repo is mainly because the memfault people didn't like that the yaml is required to be at the top level

Please link in the discussion.

The wrapper repo is mainly because the memfault people didn't like that the yaml is required to be at the top level

Please link in the discussion.

@chrisc11


[ACR] More changes for consistency

Packages impacted by this PR

@azure/container-registry

Issues associated with this PR

Fix #25389

Describe the problem that is addressed by this PR
Miscellaneous changes in response to consistency review, feature crew discussions, and architect feedback:

Rename containerRegistryBlobClient.ts to containerRegistryContentClient.ts to match name of exported class
Make OciAnnotations extend Record<string, unknown> instead of having additionalProperties for improved readability
Rename config to configuration on OciImageManifest
Make schemaVersion property on OciImageManifest required again
Do not throw on 404 for deleteBlob by adding Swagger transform

More changes still to come in future PRs!

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-container-registry


This library doesn't work

This library cannot be installed:
Invalid library found in /root/Arduino/libraries/DueTimer: Missing 'core-dependencies' from library

did you follow the installation instructions on : https://github.com/ivanseidel/DueTimer ?
and do you have "Arduino SAM Boards"  installed as a board in the Arduino IDE ( via boards manager ? )
Tools -> Board -> Boards Manager -> Arduino SAM boards

No, I'm working with Arduino Due.

Arduino SAM Boards is the installation package that contains Arduino Due ( cortex M3 ) core dependancies

I'm using a patched (bossac) version of Arduino IDE 1.5.4 compatible with the SAM3x of the UDOO Quad board. I must select "Arduino Due (Native Port)" in the "Board" menu. I don't have a SAM Boards entry.


Dependency Injection: Internal Null Reference Exception when Spawning unregistered actor

Hi,
first of all great work! I playing around with your framework for home automation 🥇
Yesterday I stumbled over a little bug.
Expected Behavior
When using Dependency Injection and an Actor that should be spawned is not registered in the ServiceProvider, some kind of error should be thrown. Otherwise it is hard to see what the problem is.
Actual Behavior
//Get props for dependency injected actor
var props = _actorSystem.DI().PropsFor<DependencyInjectedActor>();

//spawn the actor
var pid = _actorSystem.Root.Spawn(props);

does nothing, because a NullReferenceException is thrown and catched internally, the exception is only visible when activating the log
The exception happens in class Proto.Context.ActorContext in method DefaultReceive in the default case.
Because property Actor is null
private Task DefaultReceive() =>
            Message switch
            {
                PoisonPill               => HandlePoisonPill(),
                IAutoRespond autoRespond => HandleAutoRespond(autoRespond),
                _                        => Actor!.ReceiveAsync(_props.ContextDecoratorChain is not null ? EnsureExtras().Context : this)
            };

Steps to Reproduce the Problem

Open the Dependency Injection example (https://github.com/AsynkronIT/protoactor-dotnet/tree/dev/examples/DependencyInjection)
Remove services.AddTransient<DependencyInjectedActor>(); from Startup
Call method Get from ActorController

Specifications

Version: 0.18.1-alpha.0.19 (also reproducable in current master)

Done


Fix Dupliacate criteria  checking

Previously, duplicate person was defined as someone that has the exactly the same attributes.
Now only checks with name, phone and email

Codecov Report

Merging #176 (64e725d) into master (8374017) will decrease coverage by 0.47%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #176      +/-   ##
============================================
- Coverage     71.39%   70.91%   -0.48%
+ Complexity      752      737      -15
============================================
  Files           103      103
  Lines          2332     2328       -4
  Branches        260      256       -4
============================================
- Hits           1665     1651      -14
- Misses          581      586       +5
- Partials         86       91       +5

Impacted Files
Coverage Δ

...c/main/java/seedu/address/model/person/Person.java
71.42% <100.00%> (-1.55%)
:arrow_down:

.../main/java/seedu/address/model/person/Address.java
75.00% <0.00%> (-16.67%)
:arrow_down:

src/main/java/seedu/address/model/person/Age.java
78.57% <0.00%> (-14.29%)
:arrow_down:

...c/main/java/seedu/address/model/person/Gender.java
80.00% <0.00%> (-13.34%)
:arrow_down:

.../address/model/person/interests/InterestsList.java
66.00% <0.00%> (-8.00%)
:arrow_down:

Continue to review full report at Codecov.

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


RFSoCs ports

This PR updateds the rfsocs ports in accordance to new interface in qibolab

To merge this, I'd wait for qiboteam/qibolab#469 to be merged, and Qibolab 0.0.5 to be released.

To merge this, I'd wait for qiboteam/qibolab#469 to be merged, and Qibolab 0.0.5 to be released.

Indeed, same for #14.


[Feature Request]

Allow command groups (@bot.group()) to be a category (just like cogs). I have a lot of command groups that have subcommands, but they're sort of hidden, as it's only one entry in the No Category section. It would be nice if I had a dedicated page for that command group and subcommands, similar to cogs, so that all the commands are more visible. I'm sure others also use command groups similarly, so it would be a useful feature.
Example:
@bot.group()
async def shop(context: Context):
    pass

@shop.command()
async def shop_a_name(context: Context):
    pass

@shop.command()
async def shop_b_name(context: Context):
    pass

You would do !help <group_command_name> to see that sheet.

I know, but perhaps I wasn't clear. I was referring to the default view when you type !help and you change pages. Cogs and their seem to have their own pages but not command groups.

Correct. The default help is just for representing cogs as pages. Command groups are treated as normal commands in their representation. I understand what you're saying, but commands groups can also contain other command groups and now you have issues with recursively adding X number of pages depending on how deep someone goes with group commands. If you'd like to make your users more aware that your command is a group command, I suggest making note of it in your command description 🙂 Thank you for the suggestion though!


Named Capture Groups

Describe the bug
Get and error message about named regular expressions not being valid regex.
To Reproduce
The following code triggers this
`
Expected behavior
A clear and concise description of what you expected to happen.
const exp = /https?:\/\/\S+(?<publicPath>\/\S+)/u

Desktop (please complete the following information):

OS: Ubuntu 18.10

To fix this, we need to change the "ecmaVersion" from 8 to 9.
module.exports = {
  parserOptions: {
    ecmaVersion: 9,
  }
}


docs: Add documentation for all SW360 integration options

Initial documentation for the usage of the SW360 integration.

FYI @mcjaeger, feedback is welcome as part of the PR review.

@sschuberth thanks will try to pick up this soon

@bs-ondem  Working on a re-write of this PR with the help of @adambhere  who is a native English speaker

hello, maybe out attachment types need clean up, but essentially, if the SPDX shall be processed by SW360, it would need to be set to "component license information (xml)". If that is not SPDX, scan result report could be also OK.

@bs-ondem - @adambhere  and myself rewrote the file so it's more clear & concise and in the style of other ORT docs see sw360-integration.txt.
If you want I can push it into this merge request...

@tsteenbe Thank you the improved documentation. Looks good to me, so you can merge it in this PR.

@tsteenbe Thank you the improved documentation. Looks good to me, so you can merge it in this PR.

@bs-ondem can you please just replace your file in this PR wiht @tsteenbe's one, rebase, and force-push? That way the reviews can also see the diff between the files.


importhook fails with "namespace" packages due to loader being None

The following code:
import importhook
import snowflake

Fails for me with:
File <frozen importlib._bootstrap>:1027, in _find_and_load(name, import_)

File <frozen importlib._bootstrap>:1006, in _find_and_load_unlocked(name, import_)

File <frozen importlib._bootstrap>:672, in _load_unlocked(spec)

File <frozen importlib._bootstrap>:632, in _load_backward_compatible(spec)

File ~/.venvs/my_venv_name/lib/python3.10/site-packages/importhook/loader.py:49, in HookLoader.__getattribute__(self, name)
     46     except AttributeError:
     47         return getattr(loader, name)
---> 49 raise AttributeError

AttributeError:

Seems that this is because snowflake is a "namespace package" that includes multiple submodules:
~/.venvs/my_venv_name/lib/python3.10/site-packages/snowflake/
├── connector
└── sqlalchemy

I believe the issue is that in this case spec.loader is None, but still gets wrapped in a HookLoader — thus Python/importlib's 'none checks' fail until it actually tries to access something inside spec.loader.

Do you find solution to the problem ? I have another failure case for from mpl_toolkits.mplot3d import Axes3D. Is there a way we can fail silently on the import hook ? The use case is that if a sub packages which doesn't have an import hook registered fails, we don't want the parent package fails because of that -


Completely flush the rendered html to stdout before exiting in mjml-cli

This fixes #1461 by switching from the non-blocking console.log() call in outputToConsole to a process.stdout.write() call. The outputToConsole promise would previously resolve immediately, but it will now resolve only after the output has been completely flushed to stdout.
Closes #1461

Hi @sangaline thanks for reporting this, and providing the solution !
We will merge it in the next version


Make description of Resolution phase to be explicit about resolved actions

the only resolved actions are currently invocations of handlers

Jenkins job istio.github.io/presubmit passed

Jenkins job istio.github.io/presubmit passed

Jenkins job istio.github.io/presubmit passed

@geeknoid Sounds good, would love to read the blog post.

The blog post is on the site now:
https://istio.io/blog/mixer-adapter-model.html
On Sat, Nov 4, 2017 at 10:56 AM, Vadim Eisenberg<EMAIL_ADDRESS>wrote:

@geeknoid https://github.com/geeknoid Sounds good, would love to read
the blog post.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio.github.io/pull/696#issuecomment-341916834,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVucHROK3SZnQKjQbzgMopCIkuyig_2jks5szKU7gaJpZM4QMu9D
.

ping?

As I said, I don't believe these changes are correct.
Handlers are not 'applied', they are used.
Additionally, the process involves more than just handlers. All types of Mixer config objects are selected based on the service, by virtue of the namespace.

I meant for vadim to update (or close) his pr


server: add inspect test

The inspect endpoint is used mainly in the CRI-O cAdvisor handler.
Let's make sure we don't break it by adding some trivial unit tests.
@mrunalp @derekwaynecarr PTAL
Signed-off-by: Antonio Murdaca<EMAIL_ADDRESS>

[retest]

need to fix curl --unix-socket not being available on Trusty ...

[retest]

[retest]


Implement CARGO_CONFIG_PATH config file search override

This implements the CARGO_CONFIG_PATH environment variable, which defines
in which order cargo searches for config files. This overrides the
default "search parent directories" order.
Fixes https://github.com/rust-lang/cargo/issues/7887

r? @Eh2406
(rust_highfive has picked a reviewer for you, use r? to override)

This is a significant change and will require the team to talk it over, if not an RFC. I will add it to our agenda.

We discussed this in the Cargo meeting, and came to the following conclusions:

This generally looked reasonable to us.
We would like some clear documentation on this.
This interacts with other proposals to change config-file searching, such as "don't search upwards outside the workspace". We'll need to discuss the interaction of such changes.

Personal opinions:

I'd support merging this, as soon as we have documentation for it.
I'd also support changing cargo to stop searching parent directories above the workspace for config files. (For instance, a build in /tmp/foo should never look at /tmp/.cargo (which anyone could create).

@joshtriplett Ping. I've updated the documentation.

:umbrella: The latest upstream changes (presumably #8124) made this pull request unmergeable. Please resolve the merge conflicts.

@joshtriplett Ping?

@jsgf can you provide more details on your specific use case and motivations? I see that the issue mentions excluding /tmp/.cargo/config, is that the only concern? Is that something that has happened in practice?  When would someone use this? Are there other scenarios besides the "don't look above the current workspace" that this would be used to address?
I'm not opposed to this change, but I'm concerned that it is not very ergonomic. It seems like it would only be useful in the context of another build system (presumably you want to use this with Buck?). There are a number of other issues around Cargo's config discovery (#2930, #6728, #7621, #7723, #8148), and I think it would be good to avoid making the search rules too complicated.
I think it would be good to explore what the alternatives are.  If the main motivation is to restrict configs to the current workspace, maybe that would be a specific option?  How would this interact with a possible enhancement where Cargo honors per-package config files?  Maybe more options should be in Cargo.toml to avoid needing configs in the first place?  Should Cargo check the file ownership of the config file, and avoid loading it if it is from a different user?
Presumably, also, on Windows the path would be separated by ;, so perhaps it should use  std::env::split_paths.
I also wonder if it makes sense to have explicit filenames in the search list instead of always inferring .cargo/config. Like CARGO_CONFIG_PATH=/path/to/my_config.toml.

@ehuss
Yes, I want this in a somewhat Buck-related context. I have a tool which can take a Cargo.toml specifying a set of third-party dependencies we want to use, and it vendors them and auto-generated Buck build rules for them.
This tool uses cargo vendor and cargo metadata, and wants to run them with extremely controlled environments. Since any Rust developer can use this tool to add new third-party crates to import, I need to make sure they'll always generate identical outputs regardless of any environmental factors, like what the current working directory is, what other Cargo config they have scattered around, etc.
While Cargo's current behaviour of "search up through .. and then $CARGO_HOME/config` is easy to describe and generally useful for individual developers, it's extremely non-hermetic. It means that it's possible to accidentally override Cargo's precise behaviour through both local config and latent config from current directory. (True story: I spend a couple of hours trying to debug a problem where I was using a temp directory in /tmp/random-generated-name as a working dir for cargo to try and isolate it from the environment, only to find that I had a left over /tmp/.cargo/config from some experiment weeks before which was interfering.)
This PR is an attempt to give scripting or programmatic users of Cargo absolute control over where it finds its config to allow complete reproducability. I'm not precious about this - I'd be fine with any other proposal which give the same level of control.
That said, it looks to me like this mechanism is sufficiently powerful and general to address the needs of #2930, #6728, #7621, and maybe #7723 to an extent.
In #2930's case, I think there's a lot to be said for the proposal that Cargo should have searched relative to the package dir rather than its own current directory, but it's too late to change now and having two separate "search up .. mechanisms" is too confusing to be useful. This PR at least allows that to be manually enforced if needed.
#7723 proposes and include mechanism, which needs its own definition of where to search for includes. I don't think that's strictly related to this PR, other than whatever that search mechanism is, it should be subject to the same control constraints that this PR aims for. Or depending on what the goal of having an include mechanism is, maybe this PR's mechanism subsumes them? (The primary functional difference is that this allows common definitions and overrides to be specified and controlled by the environment, whereas an include mechanism in Cargo.toml means that it's specified by the Cargo.toml author.)
#8148 seems to be more related to the current directory in which build scripts are run, so is orthogonal to this.

:umbrella: The latest upstream changes (presumably #8454) made this pull request unmergeable. Please resolve the merge conflicts.

Sorry for the long radio silence. We discussed this (several times) in the Cargo team meetings, and I think it would be best to have a change of this nature go through the RFC process. There are a lot of facets to consider, and I think it would be best to ensure that the community at least has some input to it, to help ensure that we reach a solution that will address most concerns.  Another problem is that nobody on the team has the time to really dig deep into this and help work out the design.  I hope this doesn't sound like we are brushing you off, because we do think this is an important thing to improve in Cargo, but team-wise we are very limited.
In regards to this specific design, one concern I would have is that it requires setting an environment variable to change the behavior. This would require setting the environment variable very specifically, and may need to be changed based on the project, which could be awkward. Cargo's current search behavior is not ideal, and it is certainly on the table to change it (perhaps with some manifest key?), though how it should work isn't clear. There could be more than one mechanism to change its behavior as well (though making it too complex isn't ideal).
Would you be willing to try to solicit greater community feedback and work towards a design that could potentially address most of those issues?  It might also be helpful if there are other tools of a similar nature that do config-file merging, and see what they do. And maybe collect a few alternative approaches. Also note PR #8652 also wanting to change the search behavior.

Closing as this PR is quite old and per the comment above, I think we would prefer to make sure changes to config are considered very carefully (and unfortunately none of us have much time to invest in this). I have opened #9769 as a meta issue to cover this.


move ValidatePackage method to pack command

The method CmfPackage.ValidatePackage() is being called on the CmfPackage constructor.
This should only be called on the pack command

Closed by #256


Update index.md

"These" is used with plural words like "patterns"

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 🎉


Step recorder with reversible trees

So... a basic mechanism that is able to

Record steps while solving something
Reverse to the branch's root whenever we fail to solve something within a method

This is step-by-step solving :duck:

Exactly 🦆

#28 :duck:


Access to (sub) meshes

Hi,
It's possible to access (sub)meshes of the model somehow?
I see in Renderable model property submeshCount but nothing more.
And in RenderableInstance is access only to Materials.
I want to show/hide some meshes in the object.
Related to: https://github.com/google-ar/sceneform-android-sdk/issues/242

Interesting question.
My first answer is also a question: Do you really need those meshes to be in the same glTF file?
Separating them will match all your requests since you will be able to show/hide them, handle the shadow casting/receiving of each Renderable and use the actual Sceneform collision system for physical interactions and raycasting.
You will also have access to ARCore collision raycast (HitTestResult) which takes care of the model bounding box for you and which is linked to ARCore Trackables = Planes/AugmentedImages and very soon in Sceneform DepthPoints and InstantPlacements.
In the last Blender versions you can do it very easily at the export time by selecting only visible objects.

It's not an issue if you are not familiar with Blender, you will only have to

Download and open Blender
Delete the default new Cube/Light/Camera

File>Import your .obj,/.fbx/.glTF/.glb (and even a lot more importable formats)
Export your meshes, objects, materials, animations,... (and even maybe one day, for Sceneform, lights and cameras) as separed glb files

You can keep most parameters as they are.
Simple make sure to check

[x] Visible Objects to only export the targeted object

[x] Apply modifiers (if your 3D designer is like me and prefers applying at the export time)

[x] Compression if you have a quite big model and since Draco is supported by Filament

You can than simply use one different Node per Renderable.
Parenting them (or not) to another or as much nodes as you want, AR Anchored or not.
Your second option is to access submeshes inside a RenderableInstance but you will have to make direct Filament Managers calls.
Working with Submeshed/Subentities of a Renderable will be for now very limited since we mostly object consider a Renderable Entity Instance as a closed parent group with limited access to its children.
But don't worry, there is always a solution without OpenGL and Unity since Sceneform mostly only wrap Filament job.
You will have to go more deeply inside Filament ECS from the Sceneform RenderableInstance.getFilamentAsset()

I can give you more infos about it but I have to say that today is a sunny bank holiday in France ;-) and that the Filament team will answer you a lot better than me on it (please link your Filament questions to here).
Editor/Contributor's note: Add the Blender export tutorial to /docs and .README

@PepaZapletal Did it covered your needs ?

@ThomasGorisse Thank you a lot for your answer! I sent it to the 3D designer and waiting for his reply.
I will try to go with your first option (more gltf files).
Maybe can you write some example of how to combine more gltf/glb files?
We are using it now for fences. We have one fence and want to change only the fence panel (filling). (One fence can have many panels/fillings)
Here is for example our current model: https://www.uschovna.cz/zasilka/NOF2TZMFW5U3CP4Y-969/ (now I'm waiting for the new information from the 3D designer)
Thank you a lot for your help!

@ThomasGorisse I tried it with separated files (parenting them) and it looks OK! So I close this issue.


[keyvault] add continuation token for key polling

fixes #12027
For context: this PR is adding a continuation token functionality, so users can pickle their pollers and restart the polling from the state where they left off. These two pollers in key vault are also quite unique, the reason being that

They're not defined as long running on the service side
When we make the initial call to the service, the final response object, i.e. a deleted key is returned. However, it takes a while for the key to be fully deleted on the service side, so we poll until the service has fully deleted the key. We do allow users to immediately get the response object from the service though (our result function doesn't call wait)

closing, @mccoyp has his own PRs


No way to provide leading element in SwitchListTile.

This use case came up in our app and there's no way to accomplish this. We'll use ListTile for now.

If you check out the source of SwitchListTile, you can find the following:
leading: secondary,

This means that the leading parameter is actually called secondary, so when creating your SwitchListTile, you can do something like this:
SwitchListTile(
  // some parameters
  secondary: Icon(Icons.close),
  // some other parameters
),

You will have a leading close icon. The naming is a little bit dumb, but it works.

Thanks!
This is very unintuitive. I will rename this bug to request that it be named "leading".

This got me today. Any progress?

Totally agree with this...took me a while to understand that the leading widget is called secondary in SwitchListTile...

The secondary name is confusing, as most used widgets, such as AppBar and ListTile,  use leading name.


makemigrations resulting in additional migration

db_index=True is missing from both devices making the 'makemigrations' command result in extra migration inside the package itself.

Please rebase your commits

done.


Fixes inconsistent events with backend when playing ranges/regions

Addresses #398 and #471: backend player not fires events for play and pause and wavesurfer forwards these events on; region now properly fires it's out event

Sorry, Math.round(time*100)/100  isn't a good solution. It will make other cases fail.

@katspaugh – Which cases?

Cases where precision matters.
Besides, I don't get why in your case it wasn't firing. The original code was like this:
if (!my.firedOut && my.firedIn && my.end <= time) {
So if audioprocess gives you 19.9999 at some point, and your end mark is 20, region-out would still be fired in the next frame (when the time would be, say, 20.00000001`), wouldn't it?
The rest of the PR (moving play, pause and finished events to the audio backends) was good, I'd merge these changes if you would be kind enough to make a separate PR (don't include the build, I'll update the version and rebuild anyway).

@katspaugh - that was the problem, the time stopped at 19.999 and never reached 20.000001. I tested regions in the very beginning and at the end and neither fired.
From my testing, Math.round(time*100)/100 is still quite accurate. For example:
19.994 = 19.99
19.995 = 20
So at most five-thousandths (.005) of a second is lost. I can't imagine how this would be a problem when the function is just calling out events:
my.fireEvent('out');
my.wavesurfer.fireEvent('region-out', my);

To me, this would be better than not having the events fire at all, but its your call.
If you still don't think the round is a good thing, I can make another PR without that part.

I may be wrong. Let's push it.

@kjantzer I've merged your patch manually, thanks!


db: fix Bluperint unique name migration

So I am assuming the migration did not come through, so we can update existing one. Good.
I suggest to add a comment explaining what happens:
-- Add " N" suffix to all blueprint names which row number is higher
-- than 2. For two blueprints named "test" it will leave one record as
-- "test" and the other will be updated to "test 2" and so on. The
-- order is picked at random.

It was easy - just partitioning by org_id as well did the trick

Does not work as expected.

temp_blueprint=# SELECT * FROM blueprints;
                  id                  |         name          | org_id |         created_at
--------------------------------------+-----------------------+--------+----------------------------
 b258589a-880d-492e-9864-a0f3b4481023 | Blueprint name        | 1      | 2024-04-03 18:42:36.369445
 39e300c2-36bf-46df-84ca-cb9c89b83932 | Blueprint name        | 1      | 2024-04-03 18:42:36.369445
 1f759bb1-d8c2-4f26-9ce2-abf90a92d13e | Blueprint name        | 1      | 2024-04-03 18:42:36.369445
 bd01576c-8638-4006-bdac-654a6e48feec | Blueprint cool        | 1      | 2024-04-03 18:42:36.369445
 325a8685-2520-4fdd-8ff2-97b2b39205a4 | Blueprint cool        | 1      | 2024-04-03 18:42:36.369445
 3e5566f4-f304-4759-9fc9-4571b40f8aa6 | Blueprint cool unique | 1      | 2024-04-03 18:42:36.369445
 1de9be95-3c56-4694-b55f-df66d5b7ed9b | Blueprint cool        | 2      | 2024-04-03 18:42:36.369445
 8dd66e1d-0fa6-4775-b854-5e907c6245bd | Blueprint cool        | 2      | 2024-04-03 18:42:36.369445
 b19afb04-90d9-418f-b88f-fc90511308d1 | Blueprint name        | 2      | 2024-04-03 18:42:36.369445
 5183fef6-2eb0-4dd8-af44-137313944697 | Blueprint name        | 2      | 2024-04-03 18:42:36.369445
(10 rows)

temp_blueprint=# UPDATE blueprints SET name = CONCAT(names.name, ' ', names.rn::text, ' (renamed at ', TO_CHAR(CURRENT_TIMESTAMP, 'YYYY/MM/DD HH24:MM:SS'), ')')
    FROM (SELECT * FROM (select id, name, row_number() over (partition by name, org_id order by created_at) as rn from blueprints) AS rns
    WHERE rns.rn > 1) AS names WHERE blueprints.id = names.id;
UPDATE 5
temp_blueprint=# SELECT * FROM blueprints;
                  id                  |                       name                        | org_id |         created_at
--------------------------------------+---------------------------------------------------+--------+----------------------------
 b258589a-880d-492e-9864-a0f3b4481023 | Blueprint name                                    | 1      | 2024-04-03 18:42:36.369445
 bd01576c-8638-4006-bdac-654a6e48feec | Blueprint cool                                    | 1      | 2024-04-03 18:42:36.369445
 3e5566f4-f304-4759-9fc9-4571b40f8aa6 | Blueprint cool unique                             | 1      | 2024-04-03 18:42:36.369445
 1de9be95-3c56-4694-b55f-df66d5b7ed9b | Blueprint cool                                    | 2      | 2024-04-03 18:42:36.369445
 b19afb04-90d9-418f-b88f-fc90511308d1 | Blueprint name                                    | 2      | 2024-04-03 18:42:36.369445
 325a8685-2520-4fdd-8ff2-97b2b39205a4 | Blueprint cool 2 (renamed at 2024/04/03 18:04:44) | 1      | 2024-04-03 18:42:36.369445
 8dd66e1d-0fa6-4775-b854-5e907c6245bd | Blueprint cool 2 (renamed at 2024/04/03 18:04:44) | 2      | 2024-04-03 18:42:36.369445
 39e300c2-36bf-46df-84ca-cb9c89b83932 | Blueprint name 2 (renamed at 2024/04/03 18:04:44) | 1      | 2024-04-03 18:42:36.369445
 1f759bb1-d8c2-4f26-9ce2-abf90a92d13e | Blueprint name 3 (renamed at 2024/04/03 18:04:44) | 1      | 2024-04-03 18:42:36.369445
 5183fef6-2eb0-4dd8-af44-137313944697 | Blueprint name 2 (renamed at 2024/04/03 18:04:44) | 2      | 2024-04-03 18:42:36.369445
(10 rows)

temp_blueprint=# SELECT * FROM blueprints;
                  id                  |       name       | org_id |         created_at
--------------------------------------+------------------+--------+----------------------------
 be78769a-abce-46a4-ba4d-70c30d9a782b | Blueprint name   | 1      | 2024-04-03 18:46:36.07728
 051d4fb2-b89d-45bb-b5ce-61ca1d0b6cb0 | Blueprint name   | 1      | 2024-04-03 18:46:37.374068
 5e56600f-50b9-4721-89b5-e32e45202b26 | Blueprint name   | 1      | 2024-04-03 18:46:39.830295
 1fe587ec-ece5-4891-b2ec-cc8589f805c0 | Blueprint cool   | 1      | 2024-04-03 18:46:45.874503
 0a0427cc-4a00-4e0b-a123-5c9e518cd554 | Blueprint cool   | 1      | 2024-04-03 18:46:46.803646
 4eb29ad8-525b-4fde-b755-bac0230001a2 | Blueprint name   | 2      | 2024-04-03 18:46:53.8471
 21530461-9981-4032-bb8b-f40e8aaa32a7 | Blueprint name   | 2      | 2024-04-03 18:46:54.80435
 d4f50450-9471-4cb9-ab7f-7aa61c4c8961 | Blueprint name   | 2      | 2024-04-03 18:46:57.712829
 546911cd-4640-4a2d-8e45-12961568bce3 | Blueprint name   | 2      | 2024-04-03 18:46:58.342171
 b076e0bd-e9f6-4210-9af0-5042f178d4dd | Blueprint name   | 2      | 2024-04-03 18:46:58.93005
 a15471b8-5e43-43f4-80cd-0e1eddbf9b77 | Blueprint unique | 2      | 2024-04-03 18:47:06.938094
 bf0dc923-a7ee-4089-9881-89b1fe3d6b3f | Blueprint unique | 1      | 2024-04-03 18:47:09.808783
(12 rows)

temp_blueprint=# UPDATE blueprints SET name = CONCAT(names.name, ' ', names.rn::text, ' (renamed at ', TO_CHAR(CURRENT_TIMESTAMP, 'YYYY/MM/DD HH24:MM:SS'), ')')
    FROM (SELECT id, name, row_number() over (partition by name, org_id order by created_at) as rn from blueprints) AS names
    WHERE names.rn > 1 AND blueprints.id = names.id;
UPDATE 7
temp_blueprint=# SELECT * FROM blueprints;
                  id                  |                       name                        | org_id |         created_at
--------------------------------------+---------------------------------------------------+--------+----------------------------
 be78769a-abce-46a4-ba4d-70c30d9a782b | Blueprint name                                    | 1      | 2024-04-03 18:46:36.07728
 1fe587ec-ece5-4891-b2ec-cc8589f805c0 | Blueprint cool                                    | 1      | 2024-04-03 18:46:45.874503
 4eb29ad8-525b-4fde-b755-bac0230001a2 | Blueprint name                                    | 2      | 2024-04-03 18:46:53.8471
 a15471b8-5e43-43f4-80cd-0e1eddbf9b77 | Blueprint unique                                  | 2      | 2024-04-03 18:47:06.938094
 bf0dc923-a7ee-4089-9881-89b1fe3d6b3f | Blueprint unique                                  | 1      | 2024-04-03 18:47:09.808783
 051d4fb2-b89d-45bb-b5ce-61ca1d0b6cb0 | Blueprint name 2 (renamed at 2024/04/03 18:04:36) | 1      | 2024-04-03 18:46:37.374068
 5e56600f-50b9-4721-89b5-e32e45202b26 | Blueprint name 3 (renamed at 2024/04/03 18:04:36) | 1      | 2024-04-03 18:46:39.830295
 0a0427cc-4a00-4e0b-a123-5c9e518cd554 | Blueprint cool 2 (renamed at 2024/04/03 18:04:36) | 1      | 2024-04-03 18:46:46.803646
 21530461-9981-4032-bb8b-f40e8aaa32a7 | Blueprint name 2 (renamed at 2024/04/03 18:04:36) | 2      | 2024-04-03 18:46:54.80435
 d4f50450-9471-4cb9-ab7f-7aa61c4c8961 | Blueprint name 3 (renamed at 2024/04/03 18:04:36) | 2      | 2024-04-03 18:46:57.712829
 546911cd-4640-4a2d-8e45-12961568bce3 | Blueprint name 4 (renamed at 2024/04/03 18:04:36) | 2      | 2024-04-03 18:46:58.342171
 b076e0bd-e9f6-4210-9af0-5042f178d4dd | Blueprint name 5 (renamed at 2024/04/03 18:04:36) | 2      | 2024-04-03 18:46:58.93005
(12 rows)

Let’s go and fix stage.


Battery upower

upower is the new standard for knowing the power status of devices connected to the Linux kernel > v3.x. The acpi package is now only an optional package that requires an additional installation. This change-set adds support for upower over-riding acpi for first preference. However, the acpi mechanism has been maintained as a fallback mechanism for legacy systems running the Linux  kernel < v3.
Reading Reference : https://askubuntu.com/questions/69556/how-to-check-battery-status-using-terminal

Great - thanks!


Blogpost card styling should match that of the Marketing site

class="d-inline-block caption-sm rounded py-1 px-3 bg-purple-transparent font-weight-bold text-purple-300 m-0" is different from Marketing site styling. See attached.

vs.

@luciaaaaaaa, not sure on the way forward here. Marking it as design needed.


Chrisda to Master

Docs Build status updates of commit 484e2c2:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/New-AntiPhishPolicy.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/New-HostedContentFilterPolicy.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/New-SafeLinksPolicy.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Set-AntiPhishPolicy.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Set-HostedContentFilterPolicy.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Set-SafeAttachmentPolicy.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Add multiple base game upgraded talismans

Add multiple base game upgraded talismans:

amber medallions
drake protection talismans
charms

I started working on this too. I'll merge my changes and add the DLC content along with it


refactor(environments): eliminate extra dev code/markup in production

Pinging @neverfox, @mtsr, and @nhagen since you are all fairly active contributors, I'd just like to get your opinion on this if you have a minute. It stems from https://github.com/davezuko/react-redux-starter-kit/issues/189 and a deeper issue where a lot of DevTool-related code still makes its way into production, so this is one sure-fire way of eliminating it. It's inelegant and a bit obtuse for people new to the starter kit, so I'm wondering if any of you share my wariness.

@davezuko no prob, i will take a look this afternoon. i was playing around with babel 6 migration last night and the only issues were with the current devtools setup, so this was going to be an problem down the road either way.
i will try the same with this PR and let you know results.
another solution i was looking into was using babel transforms to inject devtools in development using https://github.com/alexkuz/react-transform-debug-inspector
will follow up later :smile:

Would it not accomplish the same thing to do a conditional require of DevTools inside of a single Root.js?

@neverfox that could work, but if we go that route then both the store and Root are configured at compile time rather than at runtime, since configureStore would have to know to never import the DevTools. I wish dead code removal would remove unused imports, would make this whole issue trivial.

I'm going to close this because I think it complicates the starter kit, and anybody concerned with an as-slim-as-possible production bundle can figure this out on their own. Might offer an explanation for how to do this in https://github.com/davezuko/react-redux-starter-kit/issues/221, but I want this starter kit to be (relatively) approachable.

I think that's very reasonable, though I still favor this being optimized for production out of the box. If that's how it goes, there should definitely be a section of documentation that identifies optimizations that might be useful in production environments (like this)... Though I'm not aware of any other outstanding issues like this.

@nhagen I totally agree with it being optimized for production out of the box, so I'll keep playing around with solutions for this, but documentation will unfortunately have to suffice in the meantime.


NetworkCloud 2024-07-01 API - Update generated SDK and sample tests

Update SDK for 2024-07-01 API version with generated code and sample tests

API change check
API changes are not detected in this pull request.


chore: fixed colors

Fixes Issue

closes #134
Changes proposed

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[x] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

Summary by CodeRabbit

Style

Updated the background color of rating radio buttons for a more consistent visual presentation.
Enhanced text color on radio buttons to match the new background color.

Thank you 👍  could you please add a screenshot of how the new changes look

Thank you 👍 could you please add a screenshot of how the new changes look

sure


DashLoader

CurseForge link
https://www.curseforge.com/minecraft/mc-mods/dashloader
CurseForge Mod Distribution
No response
Modrinth link
https://modrinth.com/mod/dashloader
Source/other link
https://github.com/alphaqu/DashLoader
Mod file size
5.62 MB
What it does
This mod accelerates the Minecraft Asset Loading system by caching all of its content, This leads to a much faster game load. It does this by caching all of its content on first launch and on next launch loading back that exact cache. The cache loading is hyper fast and scalable which utilises your entire system.
Why should it be in the modpack
Because it speeds up the loading time of Minecraft by many times.
Why shouldn't it be in the modpack
DashLoader has been known to be incompatible with a lot of mods. DashLoader 3.0 has massively improved compatibility by not forcing mod developers to add explicit support to make their assets cachable. This means that DashLoader will load assets normally for mod assets that cannot be cached. While this improves mod compatibility it hurts speed as the minecraft loading system is quite slow.
Categories
Performance optimization
Additional details
No response

Duplicate of #48
If you have new arguments, post them there.


No primary site exists

So lots of tries i almost got you repo working. But when i use your config i get 'No primary site exists'.
Then when i remove the config it seems to work. Then i can loggin to the admin and see all fields, settings and more. But then when i try to acces the front end i get "Invalid path alias: @assetsUrl".
Do you have any idea?

Hey!
can you share your .env file?
Spontaneously I would say there are env variables missing but not sure.

Hi there,
Offcourse i can. Its just you example and added my database credentials and things you mentioned in your readme. So not sure what im missing.
# General settings
CRAFT_ENVIRONMENT=dev
CRAFT_SECURITY_KEY=31R0o1E1cpvVAZY7_N0fNDaNG2Lo3bnR
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
# Blitz settings
ENABLE_BLITZ_CACHING=0

# ImagerX
FALLBACK_IMAGE=/assets/templateImages/placeholder.png
# MOCK_IMAGE=/assets/templateImages/placeholder.png

# Custom Settings
HARD_MODE=1
LOCAL_DEV_PERFORMANCE=0

# Database
CRAFT_DB_DRIVER=mysql
CRAFT_DB_SERVER=<IP_ADDRESS>
CRAFT_DB_PORT=3306
CRAFT_DB_USER=root
CRAFT_DB_PASSWORD=
CRAFT_DB_DATABASE=baukast
CRAFT_DB_SCHEMA=public
CRAFT_DB_CHARSET=utf8mb4
CRAFT_DB_COLLATION=utf8mb4_unicode_ci
CRAFT_DB_TABLE_PREFIX=

# URL & Paths
ASSETS_URL=http://baukast.test/assets
SITE_URL=http://baukast.test
WEB_ROOT_PATH=.

# Vite
VITE_DEV_SERVER_PUBLIC=http://localhost:3100/
VITE_DEV_SERVER_INTERNAL=http://localhost:3100/

# Redis
CRAFT_APP_ID=baukasten
REDIS_HOSTNAME=<IP_ADDRESS>
REDIS_PORT=6380
REDIS_DEFAULT_DB=0
REDIS_CRAFT_DB=1

# MailGun
MAILGUN_SYSTEM_MAIL=
MAILGUN_DOMAIN=
MAILGUN_API_KEY=
MAILGUN_ENDPOINT=

# Plugins
PLUGIN_BLITZ=U9QKTMZNFIUFC0FI90EHWIE9
PLUGIN_FORMIE=O93RLZT58J3GS61PB1Y4FRZV
PLUGIN_IMAGERX=YJJ8P7KLYP8N73FGNVXDC2Y4
PLUGIN_NAVIGATION=FO3QCK4KH1G1DLQA5QVTLDLU
PLUGIN_SEOMATIC=MZK1VHT16A7I5FZG57KA7Q4Z
PLUGIN_SUPER_DYNAMIC_FIELDS=PLHH8V2HC9JBVJALP5HWJDPO
PLUGIN_HYPER=IGUW1NIF2L5178YK1A27ZVLE

# Xdebug
DBGP_IDEKEY=phpstorm

# Dev mode
DEV_MODE=true

Nevermind. I needed to edit a redis server. Now its working. But making redis optional? I saw you had this added but how does it work?

Yep should be optional. have a look tomorrow or wednesday. Bit busy these days, sorry.

I think you have to use the dev/craft-vite branch. It's more up2date.
Here is the redis commit.
https://github.com/davidhellmann/craftcms-baukasten/commit/f17ac0d8d1be3e43d34f6ae4019da49c344c2932


Calyptos: Zookeeper zoo.cfg servers not incrementing

https://github.com/eucalyptus/midokura-cookbook/blob/master/templates/default/zoo.cfg.erb#L28
midokura.zookeepers:
- <IP_ADDRESS>:2181
- <IP_ADDRESS>:2181
Results in /etc/zookeeper/zoo.cfg:
server.1=<IP_ADDRESS>:2888:3888
server.1=<IP_ADDRESS>:2888:3888

Instead of:
server.1=<IP_ADDRESS>:2888:3888
server.2=<IP_ADDRESS>:2888:3888

https://github.com/eucalyptus/midokura-cookbook/blob/master/templates/default/zoo.cfg.erb#L28
Would be great if we could get this changed from<EMAIL_ADDRESS>to '@item', don't see any reason to alter the default port of 2181 at this early stage and in fact I don't see the midokura-cookbook picking up the port

https://github.com/eucalyptus/midokura-cookbook/pull/15

merged


Edit communication template

This PR aims to close #445 .

After all communication PR's are merged. The will be a cleanup PR.


curl is used but official Docker image does not contain curl

See https://github.com/getmoto/moto/blob/7b982522144e3f75e936560e76a92a798fe4e0fd/moto/settings.py#L125
 cmd = "curl -s --unix-socket /run/docker.sock http://docker/containers/$HOSTNAME/json"

But curl is not installed in the Dockerfile.

Thank you for raising and fixing this @benjamin9fin!


Moves all testing into gulpfile.

/botio test

/botio test

/botio test

/botio preview

/botio unittest

/botio lint

There appears to be an issue on the Windows bot with this patch regarding output buffering. The lint command fails directly without even trying and the unittest/test commands show no output in the logs until everything is done. Any idea what is causing this?

Any idea what is causing this?

I'm thinking we had this issue before. Trying to fix.
/botio lint

/botio lint

/botio-windows lint

installing newer node.js on botio fixed the issue

/botio preview

/botio lint

/botio unittest

/botio test

/botio test

/botio lint

/botio unittest

/botio preview

/botio test

Nice work, thanks!


Do not calculate checksum when generating the changelog key.

Impact

[X] Bug fix (non-breaking change which fixes expected existing functionality)
[ ] Enhancement/New feature (adds functionality without impacting existing logic)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description
Do not calculate checksum when generating the changelog key.
Fixes #3675

Superseeded by https://github.com/liquibase/liquibase/pull/3588


Nginx-proxy-manager

Im using nginx proxy manager integrated with the open appsec but what i can see all the attempt didn't blocked by open appsec, the security action only on detect state and not block even i already change the enforcement mode to prevent learn . Refer screenshot below. What can I change to make the WAF block on any security attempt.

Hi @fathhhhh,
Thank you for reaching out! I recommend asking NGINX Proxy Manager questions in the dedicated repo so you could get help from our community as well!
Regarding the issue, could you please verify that the open-appsec local policy file is in the  /appsec-localconfig folder? and run the following command to verify the policy was loaded?
docker exec appsec-agent open-appsec-ctl -s
I also recommend making a small change to trigger the policy load, like changing the "minimum confidence level".
If this doesn't solve the issue could send a screenshot of the NGINX Proxy Manager configuration? (You can also send it to info@openappsec.io).
Best,
open-appsec team

Hi @fathhhhh,
Closing the issue as there's no comment.
Best,
open-appsec team


Generated API methods in API class, not Client

It makes more sense for me to define the API methods inside the API instances themselves, rather than on the top-level client. This involves moving a few things around, but I think this will make things nicer moving forward. In particular, the issue of duplicate kinds across group-versions becomes more manageable, and we can even expose a more Go-like syntax such as
client.apis.core_v1.get_pods
client.apis.extensions_v1beta.get_ingresses
# etc...

In order to expose the 'simpler' API by calling methods directly on a client, we can leverage method_missing? and delegate down to API objects. We can further guard against mistakenly forwarding the 'wrong' method by keeping a table of dynamically generated methods on each API instance (kept in a hash table for fast lookup). This also lets us do:
client.get_pods
client.get_ingresses
# etc...

This PR is getting big, since the integration test component is hitting heretofore untested codepaths. One thing I need to reckon with is the actual response types of RESTClient responses. I'm taking a page from abonas/kubeclient and using RecursiveOpenStruct objects by default, but allowing users to provide their own custom classes or the raw Faraday response (this needs work and test, still). Once the basic RESTClient response organization is dealt with, we just need to integration test the client for all the RESTful methods.
It will also be nice to guarantee that discovery is indeed isolated between clients (e.g. we are actually defining REST methods on API instances on not on the class/all-objects). This is the observed behaviour but I still want a test.


[popup] integration not working when checking hover fields

str

create map
add points
go to popup
check fields in "hover"

expected behaviour

tooltip should work with fields checked

actual behaviour

tooltip won't work

this seems related to cartodb.js, as it doesn't happen with popup "click"; actually if I changed tab and checked/unchecked "click" fields, interactivity starts working so does tooltips
it would also work when having some field checked in popup "hover" on window load
/cc @alonsogarciapablo

After refreshing the page, you can hide fields but new ones are not added dynamically.

can't reproduce


bug?

so, having only just discovered this... and wanting to see if i could cause issues to the parsers...
I used this:
this *is* a **test** of various ~markdown~~impl^ementations^~~.~
while yours is admittedly the best (among the various results in babelmark), it only "works" when the period exists at the end (separator between the closing ~~ and ~). I say "works" because i've not actually checked the commonmark spec for how it should be handled, rather it's based on what i'd expect it to do.
I'll let you determine how my example fits into everything... just wanted to mention it. (also, have fun seeing how the other parsers handle it! yours was by far the closest)
otherwise, keep up the good work :)

This is a CommonMark spec behaviour, though if you look at an equivalent with simple emphasis on this is an emphasis *test*** you will see that there is a trailing **
Not strictly related to this case, but CommonMark folks are thinking about changing the behaviour of emphasis for some corner cases


UI issue in lock screen control on android oreo.

Note: I don't know if this is issue or something related to internals of android.
Hi
Our lock screen control are looking different on android nougat and android oreo.
This is the screen shot from android oreo's (8.0) lock screen.

This is the screen shot from android nougat's (7.0) lock screen.

Please see the area marked with red rectangle. You can see that image size is different and also image have effect in case of android oreo.
Do we have any solution for this?
Thanks

I don't think its an issue. notification style upgraded in Oreo.

I install this but on lock screen it is showing nothing.
Please help me.


[sil] Rename {,Strong}Copy{Unowned,Unmanaged}.

As requested in #27375

@swift-ci test

Build failed
Swift Test Linux Platform
Git Sha - e2a18e0b02b0a79c4d210496a5bdff428b715c28

Build failed
Swift Test OS X Platform
Git Sha - e2a18e0b02b0a79c4d210496a5bdff428b715c28

The given test failed since the order in which the functions were output changed. It changed b/c the file uses a special flag that orders functions in the output by name and I renamed the test function from test_copy_* to test_strong_copy_*. I fixed the order in the test case.

@swift-ci test

@swift-ci test

@swift-ci test

Resolved the merge conflict. Trying again.

@swift-ci test

@swift-ci test

@swift-ci test

@swift-ci test


Sounds

Maybe, it will be a good idea to add sounds to roulette?

Hello, @leineveber. Thank you for your ideas. It’s ease to use a sound effect after the roulette stop spinning using ‘onPrizeDefined’.
I’ll think how to implement a sound effect while spinning. I’ll let you know here.

On 28 Feb 2022, at 12:14 AM, Egor Leineveber @.***> wrote:

Maybe, it will be a good idea to add sounds to roulette?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.

Hello, @leineveber. I’m going to implement a sound playing while the roulette spinning when I have free time. But it won’t be a sound when a roulette item crosses the center roulette seporator by performans reasons. It’ll be a static sound while the roulette spinning. Thank you for your idea!

🎉 Implemented in React Roulette Pro 2.1 🎉
The roulette now supports the soundWhileSpinning prop.
Available in the live example - https://react-roulette-pro.ivanadmaers.com/
If you have any more ideas or questions, feel free to open a new issue.


Not working with BullyMP

It keeps crashing with BullyMP

Known issue - debugging code left in SPBully detects internal errors BullyMP has. Should be fixed on their part (and devs are already aware so hopefully won't take long).

Thanks for the quick answer, ill close the issue then and hopefully they'll relase the fix sooner


Accession id not found

Hi,
I have been using Taxoniq successfully for some time but now many of the accessions I am looking for are not being found.
I use the following command line:
t = taxoniq.Taxon(accession_id="PSS23614.1")
And here is the list of accessions that are not found:
2022-07-12 10:30:32,131 ERROR    Taxid not found with taxoniq for PSS23614.1
2022-07-12 10:30:32,131 ERROR    Taxid not found with taxoniq for RVX10864.1
2022-07-12 10:30:32,131 ERROR    Taxid not found with taxoniq for CBI30819.3
2022-07-12 10:30:32,131 ERROR    Taxid not found with taxoniq for XP_034697749.1
2022-07-12 10:30:32,131 ERROR    Taxid not found with taxoniq for XP_034697748.1
2022-07-12 10:30:32,132 ERROR    Taxid not found with taxoniq for XP_002266388.1
2022-07-12 10:30:32,132 ERROR    Taxid not found with taxoniq for RVX04110.1
2022-07-12 10:30:32,132 ERROR    Taxid not found with taxoniq for XP_034708330.1
2022-07-12 10:30:32,133 ERROR    Taxid not found with taxoniq for AQK92860.1
2022-07-12 10:30:32,133 ERROR    Taxid not found with taxoniq for QKY74088.1
2022-07-12 10:30:32,133 ERROR    Taxid not found with taxoniq for PWZ38118.1
2022-07-12 10:30:32,133 ERROR    Taxid not found with taxoniq for AGH55661.1
2022-07-12 10:30:32,133 ERROR    Taxid not found with taxoniq for PPR94295.1
2022-07-12 10:30:32,133 ERROR    Taxid not found with taxoniq for RVX22827.1
2022-07-12 10:30:32,133 ERROR    Taxid not found with taxoniq for RVW56456.1
I have updated NT database following the documentation but it didn't change anything...
Any idea ?
Thanks,
Marie

I have a similar issue. In my case, it looks like Taxoniq treats the 'version' as an essential part of the accession id, and does not include older versions. For instance, I have results from a search against an 1-year old database, and it includes a hit to the following sequence: 'NC_023861.1'. This is not recognized by taxoniq (just installed using the nr/nt databases from version 0.6.1). I searched for NC_023861.1 on NCBI Nucleotide, and saw that it has been replaced by a newer sequence. Taxoniq recognizes the newer version (NC_023861.2), but does not recognize the root accession number (NC_023861)

Hi @aretchless,
If it ever helps: I stopped using taxoniq even though it was very effective.
I use NCBITaxa from ete3 which is much more up to date.

Hi @marieBvr - it looks like you are trying to use Taxoniq to query for protein sequence accession IDs. Taxoniq was never designed to work with protein sequences and their IDs, only nucleotide ones. I spot checked your list and all of the accession IDs seem to produce results in nr, not in nt. Let me know if that sounds incorrect.
I will note that one reason Taxoniq has not been updated as frequently is that unlike ete3 (ETE Toolkit) and Entrez, Taxoniq receives no funding and is updated in my spare time. Perhaps I should apply for a grant from my ex-employer, CZI, where I originally developed Taxoniq!
@aretchless your issue is different. This is an unfortunate side effect of an optimization that I made, where an unversioned accession ID is assumed to be version 1 by default. I could add a heuristic to scan for subsequent versions if there is no hit for an unversioned ID query, but the heuristic would be inherently limited because it's unclear at what version number to give up, and a lengthy sweep will introduce a performance hit in some applications.
Instead, the better solution seems to be to reindex all accessions at index build time, so that an unversioned accession ID is not assumed to be version 1, but instead always points to the latest version. This should be achievable at zero cost to the index size. I'll work on that next.


Migrate from Enzyme to react-test-renderer

hey,  I just wanna say sorry that I was not nice to you


How to add a guideline on this?

The repository already have contribution guidelines (contributing.md) with criteria to add a service and how to write a correct description. Do you have anything else in mind ?


Calling twice BleClient.write() one after another

Describe the bug
Something happens when await BleClient.write() called twice, one after another and second write is not performs at all
To Reproduce
Steps to reproduce the behavior:
Was used following method to send string to LE device:
  async sendMsgToDevice(msg: string) {
    console.log(`vova: sendMsgToDevice: ${msg}`);
    await BleClient.write(this.getDeviceId(), this.uuids!.srv, this.uuids!.txCh, textToDataView(msg))
  }

Most of time when we call sendMsgToDevice() two times is correct behavior:
I/Capacitor/Console: File: http://localhost/main.js - Line 12840 - Msg: vova: sendMsgToDevice: b8d8
I/Capacitor/Console: File: http://localhost/main.js - Line 12840 - Msg: vova: sendMsgToDevice: go
V/Capacitor/Plugin: To native (Capacitor plugin): callbackId: 20997892, pluginId: BluetoothLe, methodName: write
V/Capacitor: callback: 20997892, pluginId: BluetoothLe, methodName: write, methodData:
D/Device: resolve: write|f5351050-b2c9-11ec-a0c0-b3bc53b08d33|f53513ca-b2c9-11ec-a0c1-639b8957db99 Characteristic successfully written.
V/Capacitor/Plugin: To native (Capacitor plugin): callbackId: 20997894, pluginId: BluetoothLe, methodName: write
V/Capacitor: callback: 20997894, pluginId: BluetoothLe, methodName: write, methodData: {"deviceId":"34:AB:95:8F:62:5A","service":"f5351050-b2c9-11ec-a0c0-b3bc53b08d33","characteristic":"f53513ca-b2c9-11ec-a0c1-639b8957db99","value":"67 6f"}
D/Device: resolve: write|f5351050-b2c9-11ec-a0c0-b3bc53b08d33|f53513ca-b2c9-11ec-a0c1-639b8957db99 Characteristic successfully written.

and go is sent after b8d8. But happens when go is not sent to LE device. Than in logs I see only:
I/Capacitor/Console: File: http://localhost/main.js - Line 12840 - Msg: vova: sendMsgToDevice: f3e5
I/Capacitor/Console: File: http://localhost/main.js - Line 12840 - Msg: vova: sendMsgToDevice: go
V/Capacitor/Plugin: To native (Capacitor plugin): callbackId: 20997930, pluginId: BluetoothLe, methodName: write
V/Capacitor: callback: 20997930, pluginId: BluetoothLe, methodName: write, methodData: {"deviceId":"34:AB:95:8F:62:5A","service":"f5351050-b2c9-11ec-a0c0-b3bc53b08d33","characteristic":"f53513ca-b2c9-11ec-a0c1-639b8957db99","value":"66 33 65 35"}
D/Device: resolve: write|f5351050-b2c9-11ec-a0c0-b3bc53b08d33|f53513ca-b2c9-11ec-a0c1-639b8957db99 Characteristic successfully written.

Expected behavior
Each string is sent/written in same order
Screenshots
N/A
Plugin version:

@capacitor-community/bluetooth-le: 1.7.0

Smartphone (please complete the following information):

Device: Samsung A3 or any other
OS: Android
Browser N/A
Version N/A

Additional context
N/A

Adding mutex solves issue:
  async sendMsgToDevice(msg: string) {
    await this.lock.acquire()
    console.log(`vova: sendMsgToDevice: ${msg}`);
    await BleClient.write(this.getDeviceId(), this.uuids!.srv, this.uuids!.txCh, textToDataView(msg))
    this.lock.release()
  }

A  we see:
I/Capacitor/Console: File: http://localhost/main.js - Line 12949 - Msg: vova: sendMsgToDevice: f1b5
D/Device: resolve: write|f5351050-b2c9-11ec-a0c0-b3bc53b08d33|f53513ca-b2c9-11ec-a0c1-639b8957db99 Characteristic successfully written.
I/Capacitor/Console: File: http://localhost/main.js - Line 12949 - Msg: vova: sendMsgToDevice: go
V/Capacitor/Plugin: To native (Capacitor plugin): callbackId: 100409782, pluginId: BluetoothLe, methodName: write
V/Capacitor: callback: 100409782, pluginId: BluetoothLe, methodName: write, methodData: {"deviceId":"34:AB:95:8F:62:5A","service":"f5351050-b2c9-11ec-a0c0-b3bc53b08d33","characteristic":"f53513ca-b2c9-11ec-a0c1-639b8957db99","value":"67 6f"}
D/Device: resolve: write|f5351050-b2c9-11ec-a0c0-b3bc53b08d33|f53513ca-b2c9-11ec-a0c1-639b8957db99 Characteristic successfully written.

Should  BleClient.write() be thread protected?

Thank you for using this plugin.
I cannot reproduce the behavior you're describing. The BleClient has an internal queue which should handle this. Are you by any chance calling BleClient.disableQueue() (which is not recommended)?

Do you get any errors? Anything else in the logs that looks suspicious?

No, all logs that I see are attached here
Are you trying both methods of reproduction with async and non async reproduce()?

Are you trying both methods of reproduction with async and non async reproduce()?

Yes, I tried both async and non async and got the same successful result (in case the queue is enabled).

I think in my case it occurs after >~80 writes

Also 200 writes is no problem in my tests.

Hi,
I have been able to reproduce this. Having several users of our app reporting issues, whilst most fine, I had initially put it down to faulty hardware. It seems all devices are Android 11 and budget devices. We picked up a cheap TCL 10" Android device, split our write down into smaller chunks and loop through. If we send too fast the device receiving errors out after 4-5 runs, around 80-150 writes.
I have put a small 20ms wait after each write and the issue has completely gone away. I hope this is helpful.
Thanks again for the plugin.

Currently I don't see how this could be fixed in the plugin, as it's an issue with specific Android devices. Therefore I'm closing this issue for now. If anyone has an idea how this could be fixed, let me know and I'm happy to take another look.


[RFC] How compatible should we be with CPython?

Summary
How compatible should rustpython be with cpython?
Detailed Explanation
Currently we strive for pretty high compatibility with cpython. This is a difficult path. Maybe we can ease development by deliberately not implementing certain parts of python that might be weird in the first place.
Examples of things we could explicitly not implement:

Access to the __dict__ attribute. We could hide this, and implement in a simpler way.
The handling of the locals keyword. Also, the possibility to modify a local dictionary.
String glueing: "fu" "bar" == "fubar", a leftover from the C era, and error prone.

Background information about this topic:

Keynote from Łukasz Langa: https://www.youtube.com/watch?v=KDXhu4rxTNY
Micropython list of deviations: http://docs.micropython.org/en/latest/genrst/index.html
mypyc with a restricted subset of python: https://github.com/mypyc/mypyc

Unresolved Questions
What should we leave out?

I would say that anything that is not documented in the CPython documentation can be changed without discussion. On any other deviation an issue should be opened and once accepted we will document the deviation.

Access to the dict attribute. We could hide this, and implement in a simpler way.

This is used in many places in the stdlib so I am not sure about this.

String glueing: "fu" "bar" == "fubar", a leftover from the C era, and error prone.

+1

String glueing: "fu" "bar" == "fubar", a leftover from the C era, and error prone.

This is really useful for formatting long literal strings without taking a hit from using +.


feat: Updated font support and definition

Description

Added built-in support for cyrillic, cyrillic-ext and latin-ext
Changed font-name used internally to SourceSans3. This change will not break old use of SourceSansPro since we keep its definition.

Små forskjeller i bredde på noen av de spesielle tegnene kan bety breaking? (om en tittel plutselig wrapper ned til 2 linjer og slikt).

Looks like font-weight:500 gives bold text now, but not sure if it matters? (According to Chromatic)

Looks like font-weight:500 gives bold text now, but not sure if it matters? (According to Chromatic)

Yes since we set a font-range from "400 600" every weight between those two will now work, and not snap to closest available. Could see this changing a few instances, but since it is only 100 weight difference i recon few will notice it if they have used "font-weight 500". Did a git-search and found a few cases, but some of those also used different fonts so might not actually change anything 🤷
As for allowing 500 weight, when discussed with brand they said it was ok for now as long as we still only recommend/use 400 and 600 internally.

I have a few things I would like to discuss/suggest about the stories, when you have time,


[BUG] Project Name in export is weird

Describe the bug
The initial value of the textbox project bname is all messed up

13


small difference is ignored and automatically accepted

While working on my anti aliasing feature, I've run a few tests and discovered that with a pixel difference of 33 and below, the new image is automatically saved as new baseline.
I started working on my own forked branch with some additional logging and wrote a test for this scenario. However, if any of the contributors has time to help out, please let me know. My closure is still a bit limited.

I'm mostly away-from-keyboard until next week, I'll look into it then.

Ok great. So far I've managed to solve it with a dirty fix:
https://github.com/xebia/VisualReview/compare/master...FinKingma:smallDiffBug
The issue lies in the following scenario:

Given the image contains 686080 pixels
When an image is uploaded with 33 pixel difference
Then the percentage difference is 0,004809934701  <- Fail: percentage gets rounded to 0%

In DiffReport.java I still get the value 0,004809934701. But interpreted by clojure, this becomes 0%.
My dirty fix looks for values between 0% and 0.1% and saves them as 0.1%.

The loss of double-precision could be caused by the database table format in which the data is stored. It lists the percentage field as NUMERIC(5, 2), which limits the percentage's precision to xxx.xx .
Question remains if we really need a higher percentage-precision. Is the user better informed if the percentage is 0.01 or 0.001 ? Or should the system just round it up to the lowest amount, just as your current fix does. I'm leaning towards the latter.
So how to fix this.. I agree the current implementation being confusing and error-prone. The PixelComparator API defines a percentage in the form of a double, so we'd expect a double to be stored and retrieved. Perhaps we could change the percentage value type of PixelComparator API to something more specific, maybe even a limited-precision BigDecimal of some sorts..? This way, other developers won't get into this same confusion. I'll look into some options next week.

@FinKingma I've added a small bit of javadoc in DiffReport on master which explains how the percentage field should be filled in terms of rounding and precision. Could you create a PR for your bugfix?

Hm I can't seem to find the javadoc. Added a PR with my fix.

ah my bad, forgot to push the commit. It's on master now. Closing this issue as fixed


docs: update comment syntax in order to auto-document

Preview environments are getting posted here, as soon as they are ready!


Chrome crashes when launched with the latest Ubuntu 22.04 image

Description
We're seeing an issue with our CI pipeline where all the integration tests fail (the ones that spin up and connect to a chrome instance), due to the Chrome instances crashing. We think it's due to the version of the runner image. Locally these tests run and pass. The exact errors we're seeing when Chrome crashes is:
signal: segmentation fault (core dumped)

The last successful CI pipeline ran for this commit. In a commit I made to main on the same day about an hour after, the integration tests started to fail for one of the workflows, which you can find here.
Since then we've been unable to successfully run our CI pipelines in any of ours branches (until yesterday where we upgraded to a larger instance of the runner which seems to be running a newer version (20230619.1.0)). We've tried to diagnose the issue on our end, looking at trace logs from Chrome, debugging our codebase but nothing seems to resolve the issue.
I took another look at the logs from the first occurrence of this issue in this workflow, and noticed that the runner image used in the ones that passed differ from the runner image where the workflow fails:
 ##[debug]Starting: Set up job
 Current runner version: '2.304.0'
 Operating System
   Ubuntu
   22.04.2
   LTS
 Runner Image
   Image: ubuntu-22.04
+   Version: 20230611.1
-   Version: 20230517.1
+   Included Software: https://github.com/actions/runner-images/blob/ubuntu22/20230611.1/images/linux/Ubuntu2204-Readme.md
-   Included Software: https://github.com/actions/runner-images/blob/ubuntu22/20230517.1/images/linux/Ubuntu2204-Readme.md
+   Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20230611.1
-   Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20230517.1
 Runner Image Provisioner
   <IP_ADDRESS>

Platforms affected

[ ] Azure DevOps
[X] GitHub Actions - Standard Runners
[ ] GitHub Actions - Larger Runners

Runner images affected

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

Image version and build link
Image version: 20230611.1
Link: https://github.com/grafana/xk6-browser/actions/runs/5276735080/jobs/9549080290
Is it regression?
20230517.1
Expected behavior
The instance of Chrome doesn't crash with signal: segmentation fault (core dumped).
Actual behavior
Chrome crashes with signal: segmentation fault (core dumped).
Repro steps

Fork the repo: https://github.com/grafana/xk6-browser from commit 970b5e766192e858f4998391cf484827ff990057.
Enable the actions.
Create a branch with a minor change in the readme.
Push the branch.
Create a PR.
The pipeline will fail.

Hey @ankur22 we'll take a look. Thx for the repro steps!

Hey @ankur22. I tried running your workflow multiple times with different versions of golang and Chrome. Looks like tests fail randomly sometimes without any regularity. Neither I found any correlation between failures and software updates.
Also I see that there was a successful build in you repo today: https://github.com/grafana/xk6-browser/actions/runs/5386308631.
Therefore I assume that it's something about tests itself or about some dependent software but not runner images.

Hi @vpolikarpov-akvelon,
Thanks for taking the time to investigate the issue.

I have taken the time to thoroughly test your workflow using various versions of golang and Chrome. After multiple runs, it appears that the tests fail randomly, without any discernible pattern.

Yes, unfortunately we do have many flaky integration tests which cause the CI pipeline to fail. It was not uncommon for at least one of the four jobs to fail in the test workflow (e.g. this failure here).
What we never witnessed before was all four of the jobs failing in the test workflow.

I would also like to draw your attention to a successful build in your repository today: link to the successful build.

As of 26th of June, we have upgraded our test workflow to work with a larger runner (ubuntu-latest-8-cores). This runner is running the image version 20230619.1.0. We haven't changed any of the tests, all we have done is work with a different runner.
I have created a new branch and PR off of the latest main version where the tests were passing. This new branch does two things:

Reverts back to working with the normal ubuntu-latest runner.
Skip the known flakey tests.

In both these commits the pipeline has started to fail again where non of the test jobs pass. The reason is that Chrome is crashing with signal: segmentation fault (core dumped). This is running on runner image version 20230619.1.0.
I suspect if you were to run this PR against the runner image prior to this one (20230517.1) the test workflow will pass (or maybe one of the jobs will fail due not skipping a flaky test).
I hope this helps makes things a little clearer as to what the issue we're running into is.

Thanks @ilia-shipitsin for debugging the issue.
While I was taking a look at the release notes for this project, i noticed that both the standard and large runners are running the same image (at least they were yesterday) which is 20230619.1.0. Our pipeline fails when ran on the standard runner but passes on the larger runner. So now i'm confused as to what's going on. Does the image change in anyway when ran on the different sized runners?

@ankur22 , image propagation is not immediate indeed, and may be confusing.
however, the image version shown under "Set up job" is correct, if you see identical versions, images are identical

@ilia-shipitsin,
I see, so the images don't differ between the standard and larger runners.
I've just re-ran the failed jobs from yesterday's investigative PR, and now the image is version 20230625.1.0, but it's still failing with the same issue when Chrome is started on the standard runner 😞 Do you still think it's an issue with Chrome and not the standard runner?

to make sure, please add /usr/bin/chromium --version to see whether they differ or not.
as for bug, it was confirmed on chrome side https://bugs.chromium.org/p/chromium/issues/detail?id=1458834
it is claimed to be fixed in newer version

@ilia-shipitsin,
I see, so the images don't differ between the standard and larger runners.
I've just re-ran the failed jobs from yesterday's investigative PR, and now the image is version 20230625.1.0, but it's still failing with the same issue when Chrome is started on the standard runner 😞 Do you still think it's an issue with Chrome and not the standard runner?

it is 100% on the chrome side since we have segfault and core dump and backtrace.
on the image side we just install chrome/chromium avaialable when image is generated

it was confirmed on chrome side https://bugs.chromium.org/p/chromium/issues/detail?id=1458834
it is claimed to be fixed in newer version

Brilliant, thanks!

to make sure, please add /usr/bin/chromium --version to see whether they differ or not.

The image version on standard and larger runner is currently different but they're both running chrome version 114.0.5733.0.
For the time being I'll wait until the runner image updates to Chrome version 114.0.5735.26 or above and retest on the standard runner.

I can confirm that once we work with the latest runner and google chrome (not chromium) binary it all works as expected. You can close this ticket. Thanks for all your help!


Update namespace cmdlets to optimize for filesystem

Summary of the new feature / enhancement
The current namespace cmdlets (get-childitem, move-item, etc...) goes through a complex set of code that eventually goes to the FileSystemProvider.  This has resulted in complex code when attempting to fix issues and also noticeable perf impact.  The majority of usage of the namespace cmdlets is with the filesystem.
Proposed technical implementation details (optional)
Rather than try to have a FileSystemProviderv2, the namespace cmdlets should try the filesystem first and fallback if it's a different namespace.  This may also allow addressing some common complaints using the filesystem that would be breaking changes.  This would initially be an experimental feature, but with the breaking changes, it might make sense to have a setting/preference to turn it off.

Please link existing filesystem issues that are relevant to this idea


Add link to show more info about traffic lights (high, low, average)

http://fr.openfoodfacts.org/reperes-nutritionnels

That link is French-only?  Though it contains a link to a PDF file in English.

fair point: http://world.openfoodfacts.org/nutrient-levels
It has not been translated to other languages, and it gives a 404. Bug to file against Product Opener.

where do you want to show this link ? Nutrition tab or Advanced Nutrition tab ?

we show the nutrition lights in the nutrition tab, so the reference should be right next to it.
I remember that you wanted to put the nutriscore in a more visible position (eg summary). If so, then there.


fix: avoid error when updateNextStateHistory called with state

When I navigated to a SwitchRouter that hadn't been initialized yet and then immediately tried to navigate within it using a subaction, this would cause an error because I failed to check if prevState was populated. This fix checks that prevState exists in updateNextStateHistory.
This fixes an edge-case bug that I introduced in my last change - sorry!
I also added a test.

@satya164 - let me know if this looks OK! This was a bug introduced by my change


Parsing the attestation data explicitly

We would like to easily parse the attestation data, but the library does not expose an explicitly method to do this. Right now that means we need to almost fake calling verifyRegistrationResponse again with the right inputs whenever we want this. It would be really great to have the method to parse the attestation data available on the exposed interface.

Check out decodeAttestationObject() and parseAuthenticatorData() exported from @simplewebauthn/server/helpers. Do either of those help you achieve your goals? There are many other helpers exported from there that you might find interesting too:
https://github.com/MasterKale/SimpleWebAuthn/blob/ba7048cfd791cd9400871d008d21d1354543e2b3/packages/server/src/helpers/index.ts#L17-L36

Thanks for the feedback @wparad. These helpers are used internally by the various option-generation and response-verification methods that represent the core methods of the @simplewebauthn/server package. I make them available via the helpers import for those who are intrepid enough to break out of the core WebAuthn use cases, so a bit of extra work should always be expected when using them.


Hornet Fountain Incorrect Logic?

Just started playing rando again and I quickly got softlocked. It appears the reason for the softlock was that the hornet fountain talk was in logic despite me never encountering hornet (I had nothing to kill baldurs with, couldn't even get in to greenpath). Let me know if you need any additional files to debug, I'm not sure what to provide here.

Hey, the logic does seem fine to me. Which type of traveller order did you choose? In any case, could you provide me:

The modlog of that play session
The userX.modded.json file in the same directory (X = Save Slot number)
The whole folder under Randomizer 4 from the seed you played.

Traveller order was set to Vanilla. I do have quite a few connections (as you will see in the files) and the issue may have been caused by an incompatibility somewhere. Unfortunately I was a bit stupid and saved over the old save with a new one, so I don't think the save will be useful, in fact none of it may be (but I have included the latest save backup instead of the save, just in case it's from the old run).
This is the randomizer 4 folder for the new run, settings were MOSTLY the same but I did change more doors to use all the doors instead of some doors.
This is the latest backup of the modded json, may be from the new run.
This is the only old modlog with any randomization attempts. The current one may also be useful (has both old run play and new run play).
This is the modlog from when I deleted the old run and made the new run. It has some play of the old run in there, unsure if it will be useful or not.
Apologies for losing most of the evidence, I am quite frustrated with myself. Hopefully this gives some info for you. Let me know if there's anything else I can do. Thanks!

I'm pretty sure the incompatibility is with darkness randomizer. NPCs can be talked to in darkness when it thinks they can't. Additionally, there's no logic for eg. Hornet Greenpath when the room is totally dark. Not too sure what to do about it.

Sorry for the late response.
Without the actual files it is hard to determine how this issue came to be.
Let me clarify this.
The logic assumed you can talk to Hornet at the fountain. Presumably because you already picked up a Hornet level before, as encountering her there doesn't have to be in sequence if the level has been obtained prior. Basically like this: If you don't have a Hornet level, she only appears in Greenpath. If you have 1, she can be encountered in Greenpath AND the fountain (assuming you haven't already picked the item up).
Did she not appear at the fountain despite having a Hornet level already or didn't you obtain a level for her to appear in the first place?
Regarding the other connections. Darkness Rando may in fact cause issues with the locations which I will address with the dev of it. Breakable Wall Rando is known for having some issues, but the dev isn't active anymore. Considering other connection devs also ignore BWR cause of this fact. I'll do the same.

The Hornet Fountain wasn't working due to a bug in KorzUtils. It should work now


Can't get logrus to work outside matterbridge.go

Describe the bug
No matter what log level I set -- either hardcoded or via -debug flag -- I can't get any of the debug messages to show up. In particular, trying to get logging output to show here:
https://github.com/42wim/matterbridge/blob/54adb0509e8f22bdfa70a88834c6499e4078648b/gateway/gateway.go#L260
To Reproduce
Adding -debug flag to CLI command of matterbridge results in no debug output when messages sent from Slack to Slack.
Expected behavior
Would expect to see output for when messages are sent and received from gateway.
Screenshots/debug logs
$ go run matterbridge.go -conf ~/scratch/matterbridge/matterbridge.translate.toml -debug
[0000]  INFO main:         Enabling debug
[0000]  INFO main:         Running version 1.11.4-dev
[0000]  INFO main:         WARNING: THIS IS A DEVELOPMENT VERSION. Things may break.
[0000]  INFO gateway:      Parsing gateway translate-test
[0000]  INFO gateway:      Starting bridge: slack.g0v-tw
[0000]  INFO slack:        Connecting using token (sending and receiving)
[0000]  INFO bridge:       slack.g0v-tw: joining i18n-test-en (ID: i18n-test-enslack.g0v-tw)
[0000]  INFO bridge:       slack.g0v-tw: joining i18n-test-tw (ID: i18n-test-twslack.g0v-tw)
[0001]  INFO main:         Gateway(s) started succesfully. Now relaying messages.

Environment (please complete the following information):

OS: ubuntu 16.01
Matterbridge version:

$ go run matterbridge.go -conf ~/scratch/matterbridge/matterbridge.translate.toml -version
version: 1.11.4-dev

Additional context
Please add your configuration file  (be sure to exclude or anonymize private data (tokens/passwords))
$ cat ~/scratch/matterbridge/matterbridge.translate.toml
[general]
RemoteNickFormat="{NICK} ({BRIDGE}): "

# [slack.civictechto]
# Token="xxxxxxxxxxxxxxxxxx" # bot user
# ShowJoinPart=true

[slack.g0v-tw]
Token="xxxxxxxxxxxxxxx" # real user: bridgebot-patcon
ShowJoinPart=true
Debug=true

[[gateway]]
name="translate-test"
enable=true
  [[gateway.inout]]
  account="slack.g0v-tw"
  channel="i18n-test-en"
    [gateway.inout.options]
    locale="en"
  [[gateway.inout]]
  account="slack.g0v-tw"
  channel="i18n-test-tw"
    [gateway.inout.options]
    locale="zh-TW"

I've been running into this while trying to get started on: https://github.com/42wim/matterbridge/issues/499

Copied your config, did change the channel names to something else, works fine as expected
Are you sure you're running on a clean source and not one where you changed stuff ?
$ go run matterbridge.go -conf p.toml  -debug
[0000]  INFO main:         Enabling debug
[0000]  INFO main:         Running version 1.11.4-dev
[0000]  INFO main:         WARNING: THIS IS A DEVELOPMENT VERSION. Things may break.
[0000]  INFO gateway:      Parsing gateway translate-test
[0000]  INFO gateway:      Starting bridge: slack.g0v-tw
[0000]  INFO slack:        Connecting using token (sending and receiving)
[0000]  INFO bridge:       slack.g0v-tw: joining testing (ID: testingslack.g0v-tw)
[0000] DEBUG slack:        Choosing token based receiving
[0000] DEBUG slack:        == Receiving event &slack.ConnectingEvent{Attempt:1, ConnectionCount:0}
[0000]  INFO bridge:       slack.g0v-tw: joining testing2 (ID: testing2slack.g0v-tw)
[0000] DEBUG slack:        == Receiving event &slack.ConnectedEvent{ConnectionCount:0, Info:(*slack.Info)(0xc420542000)}
[0000]  INFO main:         Gateway(s) started succesfully. Now relaying messages
[0000] DEBUG slack:        == Receiving event &slack.HelloEvent{}
[0001] DEBUG slack:        Start listening for Slack messages

Jeez, this is very unsatisfying, but with your sanity check, i went back to this commit, and it seems that this helped me figure out my own issue.
I'm sorry I was being a bother, but THANK YOU or shaking me to my senses! I can now carry on :)

For others who hit issues, it was two-fold: I had Debug=true in my config for one gateway, and i was also importing packages that were not yet being used


[popups] can't restore tooltip from custom html in the editor when going back from the builder

str

create map in builder
add point
add tooltip, go to builder and select light with or without fields
go back to editor
go to hover
disable custom html

expected behaviour

restore default tooltip_light template and go to fields pane

actual behaviour

cartodb/table/views/tooltip/custom_templates/infowindow_light not found

it will throw the same error if you choose tooltip > none, for tooltip light without fields it should error at least with the none template (added in a separate PR)
similar to https://github.com/CartoDB/cartodb/issues/8312

go back to editor

ugh, not happening, closing then


PWA Workbox mxentries 50 limitation

Problem:- Using below code snippet we have increased maxEntries to 100, Only 50 entries are getting cached.Is there any other workbox strategies which will help us to store/cache more than 50 entries of API (Currently we have requirement to store approx 450-500 entries)
workbox.routing.registerRoute(
  new RegExp('.+\/api\/'),
      workbox.strategies.networkFirst({
      cacheName: 'myapp-apiCache',
          plugins : [
             new workbox.expiration.Plugin({
                 maxEntries: 100,
                 maxAgeSeconds: 30 * 24 * 60 * 60 // 30 days
              })
         ]
 })

It sounds like the DevTools user interface might be confusing you: https://github.com/GoogleChrome/workbox/issues/1189#issuecomment-358683185
There's nothing in Workbox itself that would limit the number of items cached to 50.