rpc: modify ReceiptBuilder build method

Describe the feature
At the moment, the build method of ReceiptBuilder returns a AnyTransactionReceipt which is basically a WithOtherFields:
https://github.com/paradigmxyz/reth/blob/dba6c012955c3e84efde8b2d6eca97c481226588/crates/rpc/rpc-eth-types/src/receipt.rs#L121-L125
In order to unlock https://github.com/paradigmxyz/reth/issues/11165 and use alloy_network::Ethereum in EthApiTypes implementation for EthApi, we need to modify this in order to return something like:
/// Builds a receipt response from the base response body, and any set additional fields.
    pub fn build(self) -> TransactionReceipt {
        let Self { base, other } = self;
        base
    }

without the WithOtherFields wrapper. Related https://github.com/paradigmxyz/reth/pull/11192#discussion_r1774902826.
Additional context
No response

Hey, I think I could do this, could I be assigned?


cgroup handling: constraining in case of docker

Background
In Kubernetes, a PodCgroup is created on the host by Kubelet, which is sized appropriately for the given pod. In Docker, the host cgroup sizing is handled only by the runtime (ie, they don't have the notion of a pod or a sandbox).
With the current default configuration for SandboxCgroupOnly=false, some constraints are applied, but not to all the Kata processes. I still wouldn't want to recommend this.
Eventually I think SandboxCgroupOnly=true should become default, and it is definitely what we should recommend.
Problem statement
When utilizing SandboxCgroupOnly=true with Docker (or equivalent),  none of the constraints are applied to the kata-sandbox-cgroup.  In Kubernetes this is ok, since PodCgroup will be constrained, and is the parent.  In Docker, no constraints are applied.
Suggested solution
If we care enough about Docker support, we should consider adding a ConstrainSandboxCgroup option, defaulted to false, with the intention of this only to be enabled when a user is using Kata with Docker, or other OCI CLI tools (not pod-based).
This should be straight forward, as we know the resource requirements for the workload (memory, CPU), since we receive the entire OCI runtime spec for the single container.

/cc @mcastelino @jcvenegas


Add Plausible analytics to website

This PR adds Plausible analytics to our website.

Per the Docusaurus docs, there's also an async option. Not sure if we want that.


USB CDC ACM has low throughput

Is your enhancement proposal related to a problem? Please describe.
To reproduce:

Disable loopback in cdc_acm sample by commenting out write_data(dev, data_buf, *bytes_read);.
Build and flash cdc_acm sample.
pv --force -B 256 sample.txt 2>&1 > /dev/ttyACM1 where sample.txt is a big file.
Observe the throughput.

Results:

cdc_acm without loopback: 51 KB/s
as above, with disabled logs: 96 KB/s

Describe the solution you'd like
CDC ACM should reach throughput of at least 400 kB/s.
Additional context
Board: nrf52840_pca10056
OS: Ubuntu 16.04, 4.13.0
Zephyr: c78c5e693679cc75f6e72e55c70f179ae9f6bea8

The bottleneck seems to be located in this read.

The bottleneck seems to be located in this read.

Since we do not have it for other classes, we can remove it. This should be handled in the dc code.

@finikorg can you send a PR to remove that read?

@finikorg can you send a PR to remove that read?

PR #14677


Adding multiple policies causes 403 responses

I have a web API and a test project where I'm testing all endpoints, mocking authorized calls with this package.
In my test project I do the following:
builder.ConfigureTestServices(services =>
{
	services.AddAuthentication(FakeJwtBearerDefaults.AuthenticationScheme).AddFakeJwtBearer();
});

In my web api I have a policy configured:
services.AddAuthorizationBuilder()
	.AddPolicy("SamplePolicy", p =>
	{
              p.AddRequirements(new CustomRole(new List<string> { "Admin", "Editor"  }));
              p.RequireAuthenticatedUser();
	})

Test code:
var client = ApiFactory.CreateClient();
client.SetFakeBearerToken(TestingConstants.AuthorizedUserClaims);

public static readonly Dictionary<string, object> AuthorizedUserClaims = new()
{
  { "sub", "123" },
  { "email"<EMAIL_ADDRESS>},
  { "client_id", "sample" },
};

This has worked great and all tests passes.
Now I have a need to add another policy for one of the endpoints.
This policy will require a specific scope, added like this:
services.AddAuthorizationBuilder()
	.AddPolicy("SamplePolicy", p =>
	{
              p.AddRequirements(new CustomRole(new List<string> { "Admin", "Editor"  }));
              p.RequireAuthenticatedUser();
	})
        .AddPolicy("SecondPolicy", p =>
        {
            p.RequireAuthenticatedUser();
            p.AddRequirements(new ClaimsAuthorizationRequirement("scope", new[] { "some-master-scope" }));
        });

// Then it's added on a single endpoint like this
[Authorize(Policy = "SecondPolicy")]

When I add this policy all previous tests that uses the other Authorize attribute fails with a 403.
They work again when I add the claim "scope" with the value of "some-master-scope" to the token set by the SetFakeBearerToken method. I don't want to do this because this claim shouldn't be required by the other endpoints.
It's strange because there's only one method in one controller that has this Policy attribute, meaning this policy shouldn't run for any other call.
Why am I getting 403s here? Am I missing something obvious?

I'd suggest increasing your logs verbosity to Trace for the authorization namespace so that you can see all the actions that is happening.
This can give you insight as to what causes the other authorize to fail.

I can see that it runs that policy by debugging, which is very strange since the endpoint I'm testing doesn't have that policy.
In that case it's most likely not an issue with this nuget, but instead something happening when running integration tests using the WebApplicationFactory.


Typo in README.md

In the README example for Use with any class it should be
pipe(
  untilDestroyed(this, 'destroy')
)

Currently it's
pipe(
 untilDestroyed(this),
 'destroy'
)

Thanks, fixed.


Fix entries of a deleted user break the UI

Removed user (owner object) isn't passed to EJS. Included fallback icon and text
Fix for #4159 #2041

Hi @villcabo,
I can't reproduce this. I've tried to setup a user and a host, delete that user, but the hostslist is still rendering.
I even delete the whole userrecord in the database.
Can you provide steps to reproduce this?

accidentally closed this PR, see #4187

@kerstenremco Thanks it's working


SSHFS: Tamir.SharpSsh.jsch.JSchException: Algorithm negotiation fail

I am using Dokan to connect to a Linux Debian system.
We have now upgraded to Debian 8.
Due to security reasons Debian 8 no longer allows a connection as root user by just entering a password, so I have to send an OpenSSH key.
By using this key I get the following exception in DokanSSHFS:

| 2015-09-09 17:41:39 | SSHFS: Tamir.SharpSsh.jsch.JSchException: Algorithm negotiation fail
at Tamir.SharpSsh.jsch.Session.connect(Int32 connectTimeout)
at Tamir.SharpSsh.jsch.Session.connect()
at DokanSSHFS.SSHFS.SSHConnect()
| 2015-09-09 17:41:39 | Error: failed to connect

Tamir.SharpSsh (version <IP_ADDRESS>) is from 2007 and is the latest version.
Is there any update or workaround available to handle this problem?
Thanks,
Juergen

Tamir.SharpSsh is old and should be changed, I agree with you.
https://www.nuget.org/packages/SSH.NET
Seems to be the most used ssh nuget library.
If someone have the possibility to make the change and PR, it would be very nice !

This project was updated to build and work and should be considered as a sample.
WinSSH based on dokan is originally a fork to use SSH.NET. I don't think we should do it here.
On September 10, 2015 11:32:24 AM GMT+02:00, Liryna<EMAIL_ADDRESS>wrote:

Tamir.SharpSsh is old and should be changed, I agree with you.
https://www.nuget.org/packages/SSH.NET
Seems to be the most used ssh nuget library.
If someone have the possibility to make the change and PR, it would be
very nice !

Reply to this email directly or view it on GitHub:
https://github.com/dokan-dev/dokan-sshfs/issues/2#issuecomment-139183392

--

I'm experiencing the same error with ubuntu. I could ssh to the ubuntu with cygwin using the same user name and password. but with sshfs, I saw this error.
I just want to test out dokan, is there a way to work around this problem? I don't have to connect to ubuntu. Mac or windows are both fine.
Thanks

You can use win-sshfs:
https://github.com/dimov-cz/win-sshfs


Stampy Chat seems to pull answers that aren't ready yet.

Please ignore the Japanese, that's just a browser extension.

We're using the https://nlp.stampy.ai/api/search?query= endpoint - might want to ask people on the stampy side.

For the record, this was the search to NLP endpoint.
The Scratchpad entry status probably needs to be switched from "Live on site" to something else?
{
"id": "i-ae099e9aca3ec680876f5dfcc73f823ea391a5400e6dce1c804a3074d4504e581",
"pageid": "6315",
"score": 0.476089,
"status": "Live on site",
"title": "Scratchpad:TODO: How are current AIs intelligent compared to certain animals? ref https://www.lesswrong.com/posts/SFuLQA7guCnG8pQ7T/all-agi-safety-questions-welcome-especially-basic-ones-may?commentId=S97dfpcTJCvzbKXCc",
"url": ["https://aisafety.info?state=6315"](https://aisafety.info/?state=6315)
},

Oh, looking at the document (https://docs.google.com/document/d/1GkphSo2tQOTzkJwuyQI1uJ6op-A3Ld7ZUAfsHRMoBCM/edit) I think the scratchpad is being treated as an alternate phrasing for by parser.

mruwnik fixed in gdocs parser to coda integration.


FR: Support stdin as input file

For use in Unix pipelines:
<some command that generates YAML> | gnmic set --replace-path /configure/router[router-name=Base] --stdin yaml

We can discuss about the syntax; other tools use '-' as filename for stdin, the format could be auto-detected as well

The '-' syntax should be supported now. Did it fail for you?

I could not find it in the documentation, I did not try

We had this same conversation a couple of years ago: https://github.com/karimra/gnmic/issues/369


[Error]: "Invalid config, wrong type for .drm.advanced.com.widevine.alpha.serverCertificate"

player.configure("drm.advanced.com\.widevine\.alpha.serverCertificate", with: "https://cwip-shaka-proxy.appspot.com/service-cert")
[Error]: "Invalid config, wrong type for .drm.advanced.com.widevine.alpha.serverCertificate"

The serverCertificate field is a byte array with the certificate contents, not a URL.  See also https://github.com/shaka-project/shaka-player-embedded/issues/109#issuecomment-598351313
Shaka Player v3.2.0 introduced the serverCertificateUri field, which does what you want.  I forget what versions of Shaka Player are currently supported in Embedded, though.

Thanks for your reply Here is some questions When I used shakaPlayer-embedded by release framework 1.0.0 https://github.com/shaka-project/shaka-player-embedded/releases 1.when I playback a webm resource：http://1302545507.vod2.myqcloud.com/298808a2vodcq1302545507/f47b23d3387702301286731497/R0pnqVc5v0EA.webm I got an error：load ErrorShaka Error, Category: 4, Code: 4000。 Is shakaPlayer-embedded support ?2.when I use  shakaplayers property playbackRate to set playback rate of the video. If the vaule is 1, everything is normal .but the if value is others from 0 to 2 , the video is normal ,the audio lost . If I want to set playback rate of the video, how do I do?3.when I played a resourse DASH, I will got a warning in console , and I cant get an instance of avplayer. [mov,mp4,m4a,3gp,3g2,mj2 @ 0x13e05d600] Protocol name not provided, cannot determine if input is local or a network protocol, buffers and access patterns cannot be configured optimally without knowing the protocol Looking forward to your reply------------------ Original ------------------From: Joey Parrish  @.>Date: Tue,May 10,2022 1:37 AMTo: shaka-project/shaka-player-embedded @.>Cc: fyanyan @.>, Author @.>Subject: Re: [shaka-project/shaka-player-embedded] [Error]: "Invalid config,wrong type for .drm.advanced.com.widevine.alpha.serverCertificate" (Issue#233)
The serverCertificate field is a byte array with the certificate contents, not a URL.  See also #109 (comment)
Shaka Player v3.2.0 introduced the serverCertificateUri field, which does what you want.  I forget what versions of Shaka Player are currently supported in Embedded, though.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.>
[
{
@.": "http://schema.org",
@.": "EmailMessage",
"potentialAction": {
@.": "ViewAction",
"target": "https://github.com/shaka-project/shaka-player-embedded/issues/233#issuecomment-1121387164",
"url": "https://github.com/shaka-project/shaka-player-embedded/issues/233#issuecomment-1121387164",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
@.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]


Adding the Index ID to explain_prediction_best_worst_output

Pull Request Description
Fixes #1119.
FYI @RezaAkhtar

After creating the pull request: in order to pass the release_notes_updated check you will need to update the "Future Release" section of docs/source/release_notes.rst to include this pull request by adding :pr:123.

LGTM 🆔

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


Addressed review comments for #390

This PR is created in order to address remaining review comments in https://github.com/0xPolygonMiden/miden-node/pull/390. We had to merge that PR in order to make miden-note compilable against the latest miden-base.
Here we remove in-memory notes map in favor of direct queries to database. Output notes consumed in the same batch now removed from output notes list and SMT, corresponding input notes also removed from a batch and don't affect produced nullifiers set. Input unauthenticated notes are checked for duplicates as well, as output notes. Hashes of all corresponding output/input notes are required to be equal.
Resolves: https://github.com/0xPolygonMiden/miden-node/issues/381

Also, we need to add tests to make sure the unauthenticated note handling works as expected. Let's create an issue for this and add tests in a subsequent PR.

Done: https://github.com/0xPolygonMiden/miden-node/issues/398


Need to constrain libsodium version

The current version of this recipe does not specify a version of libsodium.  On my machine (Mac), I encountered this error at runtime:
ImportError: dlopen(/miniforge/envs/flyem-forge/lib/python3.6/site-packages/libdvid/_dvid_python.so, 2): Library not loaded: @rpath/libsodium.23.dylib
  Referenced from: /miniforge/envs/flyem-forge/lib/libzmq.5.dylib
  Reason: image not found

Manually upgrading libsodium solved the issue:
conda install -c conda-forge libsodium
...

$ conda list libsodium
# packages in environment at /miniforge/envs/flyem-forge:
#
# Name                    Version                   Build  Channel
libsodium                 1.0.16                        0    conda-forge

Thanks! Just need to figure out how/when the libsodium package pins its ABI version to get the right pinning.

OK, I inspected the libsodium tarballs from anaconda.org/conda-forge/libsodium/files.  Here are the dylib names in the various packages:
./libsodium-1.0.10-0/lib/libsodium.18.dylib
./libsodium-1.0.15-0/lib/libsodium.23.dylib
./libsodium-1.0.15-1/lib/libsodium.23.dylib
./libsodium-1.0.16-0/lib/libsodium.23.dylib
./libsodium-1.0.8-2/lib/libsodium.18.dylib


docs: Fix the typo for SPIRE PVC installation option name

Sync the PersistentVolumeClaim installation option name as Helm document.
Fixes: 1c8157706df4 ("mutual-auth: Add note for PVC requirement")

/test


Example for LB service

Hi,
I saw in the operator project that support for providing pgbouncer or ha as LoadBalancer service has been added.
Just wanted to ask if there is already any kind of docs for it that explain how to apply it?
We would be very interested in that functionality.
Best
Patrick

Selection of a service type is not yet released. Any documentation around it will be in a future release.
In the interim, if you need a LoadBalancer Service, you will need to create one on your own and point it at the objects you are looking to serve.


random-between has no @return

In a function, it is usually better to always leave a @return statement outside of any conditional statements. Or an @error. Anyway, something that prevent the compiler from returning:

Function random-between finished without @return

I'm thinking that there are two different options for how to structure this function. The first option: absolutely exhaustive checks for errors in how the function is used, so that any possible use case would result in either an @error or a @return. The second option: try to account for the most common missteps, while, as you suggest, having a default @return.
I figure the second option is preferable in terms of both ease of implementation and ease of maintenance, so, yeah, I'll be adding in a default case.

fixed in 2cc3fa3b9d5d1c250ad801394653eee90cfa5a77


Refactor paging from recursive mapping to linear mapping

Motivation
The current page table use recursive mapping to access itself and do not have a linear mapping to all physical memory.
This mechanism follows BlogOS. It worked well at the beginning.
But we found several limitations as our OS grows:

It's a really complicated concept that hard to understand for beginners.
For some architectures, recursive mapping can not be implemented normally. For example, RISC-V and MIPS.
It's not easy to access page table and data of other processes. So forking process and coping the memory can not be implemented both simply and efficiently.
All access to an inactive page table needs to modify the active one, which causes unnecessary data race on multi-thread and multi-core.
It discourages us to access physical memory directly, which is unfriendly to driver and DMA.

Almost everyone agrees that linear mapping is a better choice.
Changes

Merge InactivePageTable and PageTable trait.
Add phys_to_virt function.
Remove all DMA mappings in drivers.
...

Progress

Arch
Status
Note

x86_64
✅

RISC-V
✅

AArch64
❌
aarch64 crate support is needed

MIPS
✅

Still one remain problem: #[repr(align(64)]] does not work with rv64.

RV32+64 is ready now.

I believe it is now feasible to merge these commits

Then aarch64 is broken. 😂
@equation314 Could you help fix linear mapping on aarch64?

OK, I will try to work in it this week...


Is this first or second edition?

I assumed this was first edition because the Wises aren't correct for second edition, but as I reference the combat cards with 1st and 2nd edition, the combat cards seem to line up more with second edition than first.
If this is intended to be more in line with second edition (or if its not asking too much, if it is supposed to be first), I'd love to get either an update or option toggle to track wises in conjunction with 2E!
I don't have any real coding experience, outside of minor copying and modifying to get what i want, but ive been poking around the files and I don't even know where I'd find the code used for the wises xD
Thanks so much for all the work either way <3

This is based off 2nd edition

Everything was built out using a physical copy of 2nd edition


⚠ Bofrost.at has degraded performance

In 21f41bd, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1346 ms

Resolved: Bofrost.at performance has improved in 3fb375b.


Identify failed steps in KEB deprovisioning

Description

At the moment, the deprovisioning processing queue is designed to log any failed steps but proceed further. And as long as Gardener succeeds in deleting the cluster which is the last step, mark the operation as successful. But this can leave cruft in various systems and residual resources behind without anyone paying attention as this information is buried by the volume of logs in the aggregated logging.
Reasons

There are situations where the residual resources left behind are filling up a quota that should normally be sufficient. As a result, some provisioning requests fail.
AC

Implement this ticket: KEB-core
Implement this ticket: KEB-cli
Implement this ticket: KEB-job
When all the above points are implemented test given scenario:

Simulate step failure when deprovisioning SKR instance
Fix the problem of the failing step
Check if job did a proper cleanup

Attachments

We need to store info of what failed and what is the reason of failure. We should be able to re-trigger the operation which has failed steps (EDP, AvS), so even when the cluster is gone we still should have the instance record in DB, but user shouldn't see the instance. There could be a job which runs deprovisioning again for such cases. This issue requires further analysis, SRE insights can help in finding the solution (how they gather data about instance deprovisioning for which operation hasn't successfully completed all the steps).

Once the step cannot do the job and goes to next one, marks the operation  that such step needs a retry.
at the end, instance is not permanently removed, but marked as deleted (deleted_at)
the get_instance endpoint has a check, if deleted_at is set. If yes, returns 404 (or 410). Check if any instance contains this field in the DB.
kcp cli prints steps which needs retry
A job which triggers (creates new deprovisioning operation) for instances which need a retry.

I have some availability so I will attempt to take a stab at KEB-core part.

https://github.com/kyma-project/control-plane/issues/2407 has closed, unassigning myself
anything left for https://github.com/kyma-project/control-plane/issues/2408 @jaroslaw-pieszka and https://github.com/kyma-project/control-plane/issues/2406 @MarekMichali?

#2406 is done

[ ] TODO: Documentation


Adding support for Mathjax for rendering

Hi, I stumbled across you https://github.com/euclio/vim-markdown-composer And it is an interesting proejct. I started to use markdown for report and sometimes I would like to use mathjax as well. So, I was thinking if you would like to add mathjax as default option?

Awesome, thanks for the PR! Do you mind squashing the commits into one?


Webform for generating meetup button no longer exits

I previously used the form at https://www.meetup.com/meetup_api/buttons/ to generate the JavaScript for a RSVP button to embed on my group's website. That page on meetup.com now gives a 404 error.
Is the button functionality still supported? If so, how do I create buttons for new meetings? Can I just update the event number in the button reference  tag? For example:
 RSVP

Do I just replace the 233553028 in the above HTML with the number for my latest meeting?
Thanks!

Hi @jfischer we have since removed this as a product feature but have not yet set plans to remove existing buttons in the wild. You can however replace the event ids as you mentioned.


V-Sekai.xr-grid grid lost when moving

Issue description
https://github.com/V-Sekai/V-Sekai.xr-grid/assets/32321/28e5ac61-c04d-4978-af43-81154449eb26
The grid positions pop in and out.
Steps to reproduce

Open the app.
Use the two controllers to pinch to zoom out

Minimal reproduction project (For SDK or engine issues)
Use https://github.com/V-Sekai/V-Sekai.xr-grid/commit/1e4fa47b9bdba30cc962754acb418c9efb99dab6 of v-sekai.xr-grid
Using a released version?
https://github.com/V-Sekai/V-Sekai.xr-grid/commit/1e4fa47b9bdba30cc962754acb418c9efb99dab6
What OS? Any other relevant information? (V-Sekai.xr-grid version, Godot revision, System information)
Windows 11, Valve Index, https://github.com/V-Sekai/godot/commit/7a01f6fa381544d86070fc4fd86fa0a86775b310

Fixed!!!!


feat: make Conan quiet if cmake is not verbose

Fixes #12

@lefticus @ddalcino please test this locally on your system. For me, Conan is so fragile that I cannot make it work.

The tests show that this is working as expected.


⚠ Turnos 24x7 has degraded performance

In ee4786c, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 885 ms

Resolved: Turnos 24x7 performance has improved in cf449b5.


FBX models not rendered in Android export

Godot version
4.2-dev6, 4.2-beta
System information
Windows 10, Godot 4,2.dev-6, Forward+ Renderer
Issue description
When exporting to Android, FBX models are not rendered at all. Only the default background is visible. In another project I noticed that UI is visible as well, so I'm sure this only happens for 3D models, and the minimal reproduction project contains 1 FBX model which is not rendered in Android builds, but rendered in testing on Desktop.
Rendering works correctly in 4.1.2-stable, 4.2-dev5.
Rendering does not work starting with 4.2-dev6, it does not work in 4.2-beta either.
This is my first bug report, so please be gentle if I did something wrong :)
Steps to reproduce

Open the minimal reproduction project with 4.2-dev5, export to Android (I left everything as default after installing the export thingies), see that the FBX model (a green truck) is visible on the phone.
Open the minimal reproduction project with 4.2-dev6 or 4.2-beta, export to Android and see that the FBX model is not visible on the phone.

FBX-Android-Issue.zip
Minimal reproduction project
Minimal reproduction project with the .godot and android folder deleted - so make sure to install the android export templates again. I left everything related to the export configuration at default expect the package name.

@m4gr3d Any ideas why the android platform cannot render skinned 3d meshes?

Just tested with 4.2.beta2 and it is still present. Not sure if it helps, but here's the console output:
Godot Engine v4.2.beta2.official.f8818f85e - https://godotengine.org
OpenGL API 3.3.0 NVIDIA 537.34 - Compatibility - Using Device: NVIDIA - NVIDIA GeForce RTX 4070 Ti

Editing project: D:/Projects/FBX-Android-Issue
Godot Engine v4.2.beta2.official.f8818f85e - https://godotengine.org
Vulkan API 1.3.242 - Forward+ - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce RTX 4070 Ti

WARNING: Blend file import is enabled in the project settings, but no Blender path is configured in the editor settings. Blend files will not be imported.
     at: _editor_init (modules/gltf/register_types.cpp:63)
Could not find version of build tools that matches Target SDK, using 34.0.0
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
WARNING: Upgrading mesh from older surface format. Once saved again (or re-imported), this mesh will be incompatible with earlier versions of Godot.
     at: _fix_surface_compatibility (servers/rendering_server.cpp:2047)
Could not find version of build tools that matches Target SDK, using 34.0.0
0 param: --remote-debug
1 param: tcp://localhost:6007
2 param: --xr_mode_regular
3 param: --use_immersive
ADDING: classes.dex
ADDING: classes2.dex
ADDING: classes3.dex
ADDING: classes4.dex
ADDING: lib/arm64-v8a/libc++_shared.so
ADDING: lib/arm64-v8a/libgodot_android.so
ADDING: kotlin/annotation/annotation.kotlin_builtins
ADDING: kotlin/collections/collections.kotlin_builtins
ADDING: kotlin/coroutines/coroutines.kotlin_builtins
ADDING: kotlin/internal/internal.kotlin_builtins
ADDING: kotlin/kotlin.kotlin_builtins
ADDING: kotlin/ranges/ranges.kotlin_builtins
ADDING: kotlin/reflect/reflect.kotlin_builtins
Adding feature android.hardware.vulkan.level
Adding feature android.hardware.vulkan.version
Adding permission android.permission.INTERNET
ADDING: AndroidManifest.xml
ADDING: res/anim-v21/fragment_fast_out_extra_slow_in.xml
ADDING: res/animator/fragment_close_enter.xml
ADDING: res/animator/fragment_close_exit.xml
ADDING: res/animator/fragment_fade_enter.xml
ADDING: res/animator/fragment_fade_exit.xml
ADDING: res/animator/fragment_open_enter.xml
ADDING: res/animator/fragment_open_exit.xml
ADDING: res/drawable-hdpi-v4/notification_bg_low_normal.9.png
ADDING: res/drawable-hdpi-v4/notification_bg_low_pressed.9.png
ADDING: res/drawable-hdpi-v4/notification_bg_normal.9.png
ADDING: res/drawable-hdpi-v4/notification_bg_normal_pressed.9.png
ADDING: res/drawable-hdpi-v4/notify_panel_notification_icon_bg.png
ADDING: res/drawable-mdpi-v4/notification_bg_low_normal.9.png
ADDING: res/drawable-mdpi-v4/notification_bg_low_pressed.9.png
ADDING: res/drawable-mdpi-v4/notification_bg_normal.9.png
ADDING: res/drawable-mdpi-v4/notification_bg_normal_pressed.9.png
ADDING: res/drawable-mdpi-v4/notify_panel_notification_icon_bg.png
ADDING: res/drawable-nodpi-v4/splash.png
ADDING: res/drawable-nodpi-v4/splash_bg_color.png
ADDING: res/drawable-v21/notification_action_background.xml
ADDING: res/drawable-xhdpi-v4/notification_bg_low_normal.9.png
ADDING: res/drawable-xhdpi-v4/notification_bg_low_pressed.9.png
ADDING: res/drawable-xhdpi-v4/notification_bg_normal.9.png
ADDING: res/drawable-xhdpi-v4/notification_bg_normal_pressed.9.png
ADDING: res/drawable-xhdpi-v4/notify_panel_notification_icon_bg.png
ADDING: res/drawable/notification_bg.xml
ADDING: res/drawable/notification_bg_low.xml
ADDING: res/drawable/notification_icon_background.xml
ADDING: res/drawable/notification_tile_bg.xml
ADDING: res/drawable/splash_drawable.xml
ADDING: res/layout-v21/notification_action.xml
ADDING: res/layout-v21/notification_action_tombstone.xml
ADDING: res/layout-v21/notification_template_custom_big.xml
ADDING: res/layout-v21/notification_template_icon_group.xml
ADDING: res/layout/custom_dialog.xml
ADDING: res/layout/downloading_expansion.xml
ADDING: res/layout/godot_app_layout.xml
ADDING: res/layout/notification_template_part_chronometer.xml
ADDING: res/layout/notification_template_part_time.xml
ADDING: res/layout/status_bar_ongoing_event_progress_bar.xml
ADDING: res/mipmap-anydpi-v26/icon.xml
ADDING: res/mipmap-hdpi-v4/icon.png
ADDING: res/mipmap-hdpi-v4/icon_background.png
ADDING: res/mipmap-hdpi-v4/icon_foreground.png
ADDING: res/mipmap-mdpi-v4/icon.png
ADDING: res/mipmap-mdpi-v4/icon_background.png
ADDING: res/mipmap-mdpi-v4/icon_foreground.png
ADDING: res/mipmap-xhdpi-v4/icon.png
ADDING: res/mipmap-xhdpi-v4/icon_background.png
ADDING: res/mipmap-xhdpi-v4/icon_foreground.png
ADDING: res/mipmap-xxhdpi-v4/icon.png
ADDING: res/mipmap-xxhdpi-v4/icon_background.png
ADDING: res/mipmap-xxhdpi-v4/icon_foreground.png
ADDING: res/mipmap-xxxhdpi-v4/icon.png
ADDING: res/mipmap-xxxhdpi-v4/icon_background.png
ADDING: res/mipmap-xxxhdpi-v4/icon_foreground.png
ADDING: res/mipmap/icon.png
ADDING: res/mipmap/icon_background.png
ADDING: res/mipmap/icon_foreground.png
ADDING: res/xml/godot_provider_paths.xml
ADDING: resources.arsc
Could not find version of build tools that matches Target SDK, using 34.0.0
Signing binary using:
C:/Users/username/AppData/Local/Android/Sdk/build-tools/34.0.0/apksigner.bat sign --verbose --ks <REDACTED> --ks-pass pass:<REDACTED> --ks-key-alias <REDACTED> C:/Users/username/AppData/Local/Godot/tmpexport.1697737537.apk
Signed

Installing to device (please wait...): Google Pixel 7
--- DEVICE API >= 21; DEBUGGING OVER USB ---
Reverse result: 0

I can't reproduce this issue using a Pixel 4 and 4.2 Beta4 (tested both Forward+ and Mobile).
A few things to check:

The console log from the phone. The console log you have uploaded is the console from your computer, not from the phone.
That you have the render_method.mobile option set to the rendering method you intend to use (in your description you say you are using the Forward+ renderer but the mobile renderer is set to "Mobile"
That the export templates match your version of the editor. If you are using export templates from a difference version, then the exported game may not work.

I also can't reproduce the issue on a Xiaomi Pocophone F1, tested both 4.2-dev5 and 4.2-dev6 like the OP with the provided MRP, both render fine with Forward+.

It seems this was fixed in beta-3 or beta-4, since nobody reproduced it since I last tested with beta-2.
Anyhow, a final test with the unchanged MRP and 4.2 release candidate 1 confirms this is fixed.


Add support for Kustomize components

See https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/1802-kustomize-components/README.md - I would like to see Kustomize components identified/validated by Monokle (just like kustomizations) and listed separately in the Kustomize panel - with all the existing validation/linking/preview functionality available as applicable

https://github.com/kubeshop/monokle-core/pull/457 adds some initial Component parsing support

need this for "proper" support for the https://github.com/GoogleCloudPlatform/microservices-demo repo


Provide apps access to Safe's addressbook / owners list

There are situations when certain apps would benefit from having access to addresses which are relevant to the Safe being used:

Users can attach real world names to be displayed in dashboards, etc. Useful for viewing Sablier streams or seeing how people voted through governance apps, etc.
In payments apps users can easily select names from address book in a dropdown to pay repeat clients, reducing errors

This is very much a nice-to-have for when the ecosystem is a bit more developed (plus it has some privacy implications which would need to be addressed)

plus it has some privacy implications which would need to be addressed

Very important for me :D this might require something like a permission model/ flow

On top of that, on my app I'd like to have a list of assets enabled in the current Safe (even if with a balance of 0), so for example I know what token to display.

Yes, I am currently writing a “CSV Airdrop” app which could be used by Accounting team to pay out suppliers and even employees. It would be a benefit to them if they were able to cross check the addresses from the CSV they upload with their own address book before submitting the transfers.
https://github.com/bh2smith/safe-airdrop/


Version with promisses

Summary
I think it would be interesting if there was a version of the database.run(), get() and all() methods that uses Promise instead of callback.
I can send a pull request with these changes, what do you think?
Proposed implementation
the database.run(), get(), and all() methods should be implemented using Promisses

Hey @SrStick 👋🏻 I would love to see a PR for this 🙂

This appears to be a duplicate of https://github.com/TryGhost/node-sqlite3/issues/834

Good point - closing as a duplicate of https://github.com/TryGhost/node-sqlite3/issues/834


fix: improved cassette file name generation

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Azure file sync - "last accessed date" attribute

Hi,
with regards to Azure file sync, which should remove files from being locally stored if they havent been accessed in last X days.
if the last accessdate attribute being updated is disabled, which seems to be default behaviour on all Windows Servers, how will this work.
Would there be a requirement to enable the Last access date attribute via the command
"fsutil behavior set disablelastaccess 0"
thanks
Colm

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

ID: 61bb35a5-e2f3-1ce8-1d6e-a926374de6c8
Version Independent ID: e4b3065a-5351-26ef-cdbb-ef2eaea3f301
Content: Deploy Azure File Sync
Content Source: articles/storage/files/storage-sync-files-deployment-guide.md
Service: storage
Sub-service: files
GitHub Login: @roygara
Microsoft Alias: rogarana

@smithcl167 Thanks for your question. We are checking on this and will respond to you soon.

#reassign: @SibonayK

@smithcl167 While Azure File Sync does use a file's last accessed time to determine whether to tier a file, we do not rely on the last access date attribute that is part of File Explorer. Rather, because we use our own filter driver, we track accesses and store them in our heatmap, which controls cloud tiering. Hence, it does not matter whether the File Explorer last access date feature is on or off.

@smithcl167 Thanks for reaching out, if you have any further questions please let us know. Otherwise we'll close this issue in two days.

#please-close


[Slider] Disabled slider can still be edited by clicking on the track

Hi,
I noticed that disabled sliders are not working properly, even in the case of the demo. The drag is disabled on the slider, which is normal, but clicking on the track will change the slider value ! Which is I bet not expected.
Thanks

Fixed by #1417


THRIFT-3857

thrift js:node complier support an object as parameter not an instance of struct

What should I do with the fail checks

I have rebased on upstream/master and add those commits into latest branch @jeking3

The only build failure can be attributed to THRIFT-4071.  Otherwise, this is just waiting for someone with node.js experience to review.  Specifically I need to know if this change is backwards compatible (i.e. will existing handler code work unchanged, or is this a breaking change?).

@jeking3 it's not a breaking change

I'll keep monitoring.  I would prefer a code review from someone else who uses node.js; it looks like a positive change to me.


DIS V2

Hi,
Would love to tryout DIS V2!
Looks like the update in the readme is from 6 months ago. I'm curious if there is any ETA on the release date?

be curious about the roadmap of DIS V2 dataset too. Any plan?


Update to the latest dependent crates

The vm-memory v0.4.0 has removed the atomic-integer feature, which causes trouble to dependency resolve.

wrong target branch


Travis

Fixes https://github.com/open-telemetry/opentelemetry-ruby/issues/20

@bogdandrutu are you able to activate this repo on TravisCI? I don't seem to have permissions to do that.


Ether share name or topic filter should be a primary factor for delivery on shared subscriptions ?

Consider the following scenario:
Here is a list of shared subscription.
c1: $share/sn1/t1
c1: $share/sn1/t2
c2: $share/sn1/t1
c3: $share/sn1/t1
c3: $share/sn1/t2

A publisher publishes t1,t2,t1,t2.... continuously.
Share Name based
If share name is primary factor to decide delivery target, then the expected delivery order should be as follows:

client
share name
topic
expected delivery order

c1
sn1
t1
1,7,9

c1
sn1
t2
4

c2
sn1
t2
2,6,10

c3
sn1
t1
3,5,11

c3
sn1
t2
8

Pros
Client based load ballancing can be achieved.
c1, c2, anc c3 has similar loads.
Cons
Difficult to implement. I'm not sure it can be acheived without O(N) complexity.
I guess that some LRU algorithm for client and share name is required.
It needs to care about not matched topics.
Topic Filter based
If topic filter is primary factor to decide delivery target, then the expected delivery order should be as follows:

client
share name
topic
expected delivery order

c1
sn1
t1
1,5,9

c1
sn1
t2
2,8

c2
sn1
t2
4,10

c3
sn1
t1
3,7,11

c3
sn1
t2
6

In this scenario the broker delivers to c2 very small amount of message.
Pros
Easier to implement.
Cons
Client based load ballancing can't be achieved.
NOTE: MQTT spec doesn't say anything about delivery algorithm. That means both satisfies the spec. But I guess that users expectation is Share Name based.

If I read:
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901250
Each Shared Subscription is independent from any other. It is possible to have two Shared Subscriptions with overlapping filters. In such cases a message that matches both Shared Subscriptions will be processed separately by both of them. If a Client has a Shared Subscription and a Non‑shared Subscription and a message matches both of them, the Client will receive a copy of the message by virtue of it having the Non‑shared Subscription. A second copy of the message will be delivered to one of the subscribers to the Shared Subscription, and this could result in a second copy being sent to this Client.
It is my understanding that not only the share name, or only the topic filter, but the combination (share name / topic filter) is the key to determine which clients receive a published message.
So if you have two subscribers with different group names::
c1: $share/sn1/t1
c2: $share/sn2/t1
And you publish to /t1, both c1 and c2 will receive a message.
If you have two subscribers with same group name:
c1: $share/sn1/t1
c2: $share/sn1/t1
And you publish to /t1, first c1 will receive message, second publish to /t1, c2 will receive message
If you have two subscribers with same group name but different but overlapping topics:
c1: $share/sn1/t1
c2: $share/sn1/+
And you publish to /t1, both c1 and c2 will receive message
You can have different load balancing strategies:

Round-robin: go through subscribed client one-by-one
Load based: you know the load of the subscriber and give it to the lowest load subscriber
Random: Pick a random subscriber, load will be evenly / normally distributed

https://en.wikipedia.org/wiki/Load_balancing_(computing)#Static_load_distribution_without_prior_knowledge

So in your scenario, you would actually have two round-robin load-balancers:
(sn1, t1) -> 1 (c1), 3 (c3), 5 (c1), 7 (c3), 9 (c1)
(sn1, t2) -> 2 (c1), 4 (c2), 6 (c3), 8 (c1), 10 (c2)

So in your scenario, you would actually have two round-robin load-balancers:
(sn1, t1) -> 1 (c1), 3 (c3), 5 (c1), 7 (c3), 9 (c1)
(sn1, t2) -> 2 (c1), 4 (c2), 6 (c3), 8 (c1), 10 (c2)

Could you write the same table format as my comment? It is easy to understand.

It is my understanding that not only the share name, or only the topic filter, but the combination (share name / topic filter) is the key to determine which clients receive a published message.

That is the same as my understanding. My example https://github.com/redboltz/mqtt_cpp/issues/716#issue-731179540 is using both share name and topic filter to determine. My point is which is the first key and which is the second key. That is order issue. Finally both keys are used.
For simplify the example I only use sn1. But off course, I care sn2.

So in your scenario, you would actually have two round-robin load-balancers:

I think that it is an interesting method.

Sorry I noticed my mistake. I will post the fixed version soon.

ok, i did not fully understand your explanation

client
share name
topic
expected delivery order

c1
sn1
t1
1,5,9

c1
sn1
t2
2,8,14

c2
sn1
t2
4,10,16

c3
sn1
t1
3,7,11

c3
sn1
t2
6,12,18

I updated https://github.com/redboltz/mqtt_cpp/issues/716#issue-731179540 second table.

But the load balancing is not based on all shares combined. So you are not load-balacing based on the total number of clients for all subscriptions combined. You are load balancing based on a single topic. All messages for a single topic are spread accross clients.
If a client subscribes to multiple topics, and receives 2x or 3x the amount of messages compared to another client, that is responsibility of the user.

https://github.com/redboltz/mqtt_cpp/issues/716#issuecomment-717925286
Thank you! It is completely the same as I updated one.
So this one is first key is topic filter and the second key is share name.
It is easy to implement but c2 receives small amount of messages.

But the load balancing is not based on all shares combined. So you are not load-balacing based on the total number of clients for all subscriptions combined. You are load balancing based on a single topic. All messages for a single topic are spread accross clients.
If a client subscribes to multiple topics, and receives 2x or 3x the amount of messages compared to another client, that is responsibility of the user.
So indeed:

In this scenario the broker delivers to c2 very small amount of message.

That is correct, c1 and c3 subscribe to two topics, c2 only to one

Yes, it is one of the point of view.
I think that shared subscriptions is designed for application server not iot devices.
Before shared subscriptions is introduced, sharding is common way to load balancing.
Let's say c1, c2, and c3 are application servers. They have similar computing resorces.
Devices publish to various kinds of topics. It is unpredictable.
If share name can balance across topics, then c1, c2, and c3 just set the same share name.
The broker automatically does load balancing.
I think that it could be helpful and perhaps it is more much to user needs than topic filter first way.
However, it is only my guessing.
If both topic filter first and share name first are easy to implement, I can implement both using something like strategy pattern and switch the strategy on compile time or runtime. (I love customize, you know ;)
As far as I considered, share name first strategy is pretty difficult to implement at least or me.

I also think that , if c1, c2, and c3 have similar computing resources, and user want to fair load balancing, then there is no reason to subscribing different topics. So on typical usecase, c1, c2, and c3 subscribe the same topics.
That means topic filter first strategy is enough to fair load balancing.

If both topic filter first and share name first are easy to implement, I can implement both using something like strategy pattern and switch the strategy on compile time or runtime. (I love customize, you know ;)

Yes, i want those Japanese options in broker now :)
But seriously, different strategies make sense.
You can use the subscription map also to tracker shares.
If client c1 wants to subscribe to share:
$share/sn1/t1
You add entry to "subscription map":
$share/+/t1 -> (sn1, c1)
If client c2 wants to subscribe to share:
$share/sn1/t1
You will have:
$share/+/t1 -> [ (sn1, c1), (sn1, c2) ]
If client c3 wants to subscribe to share:
$share/sn2/t1
You will have:
$share/+/t1 -> [ (sn1, c1), (sn1, c2), (sn2, c3) ]
When a message is published to /t1, then you group based on share name:
[ (sn1, c1), (sn1, c2) ] -> select one
[ (sn2, c3) ] -> select one

So I think there is no big reasons to support share name first strategy.
It can achieve fair load balancing even if each client that subscribe the same share name and different topics.
It is conceptually good but maybe not a practical usecase.
So it isn't valuable that supporting share name first strategy ( that is harder way).
That is my current conclusion. But before I start implementing the topic filter first strategy, I will wait a time.
Perhaps different idea would come up with.

Perhaps different idea would come up with.

yes, it is always good to step back and wait for a while.

But seriously, different strategies make sense.

I agree. Some of brokers support some strategy.
For example

very simple round robin (offline/online mixed)
online clients have high priority. If there is no online deliver targets, then try offline .
weight based round robin parameter using UserProperty (broker extension).

I guess that switching them are not so difficult. (But not well considered)
However, topic filter first and share name first are different. At least share name first strategy needs deep relationship with the data structure. So I wanted to discuss the topic first.

However, topic filter first and share name first are different. At least share name first strategy needs deep relationship with the data structure. So I wanted to discuss the topic first.

Yes, but also for (sharename/topic) combination key, we need to change the subscription map. Now on the callback, you do not know which topic filter was matched.
so when both /t1 and /+ will match,  according to specification, this would mean you receive 2 messages (overlapping topic filters)
It is possible to have two Shared Subscriptions with overlapping filters. In such cases a message that matches both Shared Subscriptions will be processed separately by both of them.

However, topic filter first and share name first are different. At least share name first strategy needs deep relationship with the data structure. So I wanted to discuss the topic first.

Yes, but also for (sharename/topic) combination key, we need to change the subscription map. Now on the callback, you do not know which topic filter was matched.

Ah, exactly. I think that we should have matched topic filter as additional callback parameter. (Not well considered.)
Or we can store topic filter as value similar as subscription identifier.

so when both /t1 and /+ will match on one client, according to specification, this would mean you receive 2 messages (overlapping topic filters)
It is possible to have two Shared Subscriptions with overlapping filters. In such cases a message that matches both Shared Subscriptions will be processed separately by both of them.

At first, I skipped to think about it. Because it was not essential point to decide share name first or topic filter first.
But now, I think it is a time to consider it :)
Let me clarify my understanding.
As you commented before:
Subscription:
c1: $share/sn1/t1
c2: $share/sn1/+
When you publish t1, then the broker delivers to both c1 and c2.
Subscription:
c1: $share/sn1/t1
c1: $share/sn1/+
When you publish t1, what would happen?

It is possible to have two Shared Subscriptions with overlapping filters. In such cases a message that matches both Shared Subscriptions will be processed separately by both of them.

I understand that describes topic filter overlapping case. It is OK. But how about share name ? At least the sentence above nothing refer to share name.
c1: $share/sn1/t1
c1: $share/sn2/+
When you publish t1, matched subscription t1 and + processed separately. It is reasonable.
Let's back to the following case
Subscription:
c1: $share/sn1/t1
c1: $share/sn1/+

The broker deliver the published message to c1 twice, even if the two subscriptions have the same share name.
The broker deliver the published message to c1 once. Choosing one of t1 or +. Imagine they have different QoS and subscription identifier.
The broker deliver the published message to c1 once. But subscription information is mixed. So QoS is adjusted to higher one and two subscription identifiers are added.

Note that non shared subscription case, send twice or send (mixed) once are implementation choice.
What happened shared subscription case ?

c1: $share/sn1/t1
c1: $share/sn2/t2
         .
         .
         .
c1: $share/snN/tN

c2: $share/sn1/t1
c2: $share/sn2/t2
         .
         .
         .
c2: $share/snN/tN

Could be a solution for Topic Filter first.

I understand that describes topic filter overlapping case. It is OK. But how about share name ? At least the sentence above nothing refer to share name.

In this case:
c1: $share/sn1/t1
c1: $share/sn1/+
In such cases a message that matches both Shared Subscriptions will be processed separately by both of them.
You have two load balancer here:
balancer1: (sn1, t1)
balancer2: (sn1, +)
So possibly, based on the states of the load balancers, c1 might receive 0, 1 or 2 messages.

For example
1. very simple round robin (offline/online mixed)

2. online clients have high priority. If there is no online deliver targets, then try offline .

3. weight based round robin parameter using UserProperty (broker extension).

My understanding of the shared subscription feature from the standard is that if there are online clients, the message must not be delivered to offline clients, even if those offline clients later re-connect.

A Session can explicitly detach itself from a Shared Subscription by sending an UNSUBSCRIBE Packet that contains the full Shared Subscription Topic Filter. Sessions are also detached from the Shared Subscription when they terminate.

An offline session and a terminated session are not the same thing.

An offline session and a terminated session are not the same thing.

No, so does it state somewhere in the specification how to handle shared topics and offline clients ?

Qos1: If the Server is in the process of sending a QoS 1 message to its chosen subscribing Client and the connection to that Client breaks before the Server has received an acknowledgement from the Client, the Server MAY wait for the Client to reconnect and retransmit the message to that Client. If the Client'sSession terminates before the Client reconnects, the Server SHOULD send the Application Message to another Client that is subscribed to the same Shared Subscription. It MAY attempt to send the message to another Client as soon as it loses its connection to the first Client.
Qos2:  If the Server is in the process of sending a QoS 2 message to its chosen subscribing Client and the connection to the Client breaks before delivery is complete, the Server MUST complete the delivery of the message to that Client when it reconnects [MQTT-4.8.2-4] as described in section 4.3.3. If the Client's Session terminates before the Client reconnects, the Server MUST NOT send the Application Message to any other subscribed Client [MQTT-4.8.2-5].

An offline session and a terminated session are not the same thing.

No, so does it state somewhere in the specification how to handle shared topics and offline clients ?

Yes, in multiple places, including the two details you located in your reply.
Some other notable points from the standard

In the case of a Shared Subscription where the message is too large to send to one or more of the Clients but other Clients can receive it, the Server can choose either discard the message without sending the message to any of the Clients, or to send the message to one of the Clients that can receive it.

Personally I think making the broker choose a client that can receive the message, instead of discarding it would be substantially better.

If the subscription was shared, then only the Subscription Identifiers that were present in the SUBSCRIBE packet from the Client which is receiving the message are returned in the PUBLISH packet.

Bit 2 of the Subscription Options represents the No Local option. If the value is 1, Application Messages MUST NOT be forwarded to a connection with a ClientID equal to the ClientID of the publishing connection [MQTT-3.8.3-3]. It is a Protocol Error to set the No Local bit to 1 on a Shared Subscription [MQTT-3.8.3-4].

If a Server receives a Topic Filter that is identical to the Topic Filter for a Shared Subscription that already exists on the Server, the Session is added as a subscriber to that Shared Subscription. No retained messages are sent.

If a Server receives a Shared Subscription Topic Filter that is not identical to any existing Shared Subscription’s Topic Filter, a new Shared Subscription is created. The Session is added as a subscriber to that Shared Subscription. No retained messages are sent.

So having searched for all instances of the "Shared" keyword in the standard... I'm not actually able to locate the passage that led me to the conclusion that offline sessions that are not terminated do not receive messages from the shared subscription.
That may not be something that the standard says anything about, and my reason for saying it may have been that as I was implementing the first pass of the shared subscription feature it seemed like the "correct" thing to do from an application's perspective.
I recommend assuming that I was incorrect unless someone finds a passage in the standard that explains how to handle sending messages to offline sessions in a shared subscription that agrees with my previous statement.

Well. The broker is free to choose how to perform the load balancing. I guess choosing to exclude offline clients from the set of clients is a load balancing approach. And i would say it makes sense. Especially if you read another client may be chosen when the client disconnects during delivery of a qos 1 and 2 message

I noticed that I misunderstood something about https://github.com/redboltz/mqtt_cpp/issues/716#issuecomment-717994904
It couldn't be a solution for https://github.com/redboltz/mqtt_cpp/issues/716#issuecomment-717991838
So topic filter first approach still has the problem.

Well. The broker is free to choose how to perform the load balancing. I guess choosing to exclude offline clients from the set of clients is a load balancing approach. And i would say it makes sense.

Let me define the term offline. offline means the client is disconnected but session state exists.

Both offline and online session could be a delivery target of shared subscription.
Delivery strategy is out of spec. So broker can choose any strategy.
Let's say prefer online is deliver to an online client if it exists, otherwise deliver to offline.
I think that prefer online strategy is reasonable to be the default strategy.

Especially if you read another client may be chosen when the client disconnects during delivery of a qos 1 and 2 message

Disconnects during delivery case is slightly different.
As you mentioned https://github.com/redboltz/mqtt_cpp/issues/716#issuecomment-718877168
The delivery target has already been decided. So waiting the reconnection of the same client is reasonable. QoS2
The class endpoint on mqtt_cpp does resend. It is existing mechanism. It is not relate to shared subscriptions.

Qos2: If the Server is in the process of sending a QoS 2 message to its chosen subscribing Client and the connection to the Client breaks before delivery is complete, the Server MUST complete the delivery of the message to that Client when it reconnects [MQTT-4.8.2-4] as described in section 4.3.3. If the Client's Session terminates before the Client reconnects, the Server MUST NOT send the Application Message to any other subscribed Client [MQTT-4.8.2-5].

I think it is good. Session Expiration happens after delivery target is decided. The spec above is reasonable.

Qos1: If the Server is in the process of sending a QoS 1 message to its chosen subscribing Client and the connection to that Client breaks before the Server has received an acknowledgement from the Client, the Server MAY wait for the Client to reconnect and retransmit the message to that Client. If the Client'sSession terminates before the Client reconnects, the Server SHOULD send the Application Message to another Client that is subscribed to the same Shared Subscription. It MAY attempt to send the message to another Client as soon as it loses its connection to the first Client.

However QoS1 is weird  for me.
Let's say the following subscription exists.

client id
share name
topic filter
session expiry interval

c1
sn1
t1
1hour

c2
sn1
t1
infinity

A publisher publish to t1 QoS1.
The broker decided that the delivery target is c1.
The broker PUBLISH to c1.
Before PUBACK receive, c1 disconnected.
The broker (actually class endpoint) store the PUBLISH message for resend. And start 1hour timer.
When 1 hour passed, then the broker PUBLISH the message (1 hour ago) to c2.

I think that it is weird. So I sent mqtt-comment (OASIS) https://lists.oasis-open.org/archives/mqtt-comment/202005/msg00000.html

Yes, it is weird because both clients have different session expiry intervals. I think in practice, this would not make much sense. And also, i think, no user would actually start using different session expiry intervals for different clients. But maybe there is a case where it does make sense.
And I don't think the broker needs to make a "prefered online" approach. The user/clients can configure this themselves. If the client configure no session expiry or session expiry interval = 0, the session is terminated immediatly when the client disconnects. Queued messages for this session are republished to other clients on the shared topic.
If the client does configure a session expiry interval, it will select a reasonable value in which it expects the client to reconnect. So it expects maybe a client will temporarily disconnect for a moment, but will reconnect within one minute, it will configure a expiry interval of maybe two minutes. The user will probably don't want the messages to wait for too long within the broker.
All the broker has to do is load balance the messages over different sessions. These sessions maybe online or offline. But if the session goes offline and expires (immediately or after an interval), the broker just takes the messages from this session and republishes this again to other sessions on the shared topic.

Why the behavior of QoS1 and QoS2 are diffferent ?

I think behaviour of QoS1 and QoS2 is different because, QoS2 guarantees: delivered at most once. If the message was send to a client, and the client disconnects. You can not be certain if the message was delivered or not (maybe yes, maybe no). Therefore you can not send it to another client at another time. Otherwise, you may deliver the message twice in some cases.

Why the behavior of QoS1 and QoS2 are diffferent ?

I think behaviour of QoS1 and QoS2 is different because, QoS2 guarantees exactly once. If the message was send to a client, and the client disconnects. You can not be certain if the message was delivered or not (maybe yes, maybe no). Therefore you can not send it to another client at another time. Otherwise, you may deliver the message twice in some cases.

I understand the policy some extent. Send twice violates "exactly once".
Send twice is worse than not send in QoS2 in the special case.

For QoS2 you would use a very large session timeout, hours, or maybe even days or infinite. Because you do not want the message to get lost.

Session has been expired is exactly the special case.
I think it depends on application. I think that session expiry means "I don't want to receive resended messages after session has been expired.". It is reasonable.
I think that QoS2 policy of https://github.com/redboltz/mqtt_cpp/issues/716#issuecomment-718877168 is reasonable.
I expect that QoS1 should have consistency.
Even if QoS1, I think that session expiry means "I don't want to receive resended messages after session has been expired.". It is the same as QoS2.
I know at least once.
When session has expired, QoS2 Exactly once is violated. Similarly, QoS1 At least once is violated. It is consistent.
I think that the combination of QoS1 and shared subscription and session expiration, the spec apply at least once meaning too much.

I mean the spec should allow message lost on QoS1 if already published but not received puback message and session expired case.

I understand and agree, but that would be something for the consortium behind MQTT specification to discuss :)

I'm implementing share name first strategy. The algorithm contains one O(N) part. N is number of shared subscribers that have the same shared name. (Typically scale outed servers). I think that it is efficient enough.
I need a couple of weeks to send the PR.

Excellent, looking forward to seeing the PR. More efficient algorithm can be added always later, or configurable algorithms :)

Is this issue still relevant or can be closed now ?

We can close it now.


set loglevel trace.

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

Project coverage is 89.30%.  Consider uploading reports for the commit ca722f5 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #147   +/-   ##
=======================================
  Coverage   89.30%   89.30%
=======================================
  Files          96       96
  Lines       10447    10447
=======================================
  Hits         9330     9330
  Misses       1117     1117


bob: Update to clarify ambiguity regarding shouted questions

TL;DR: the problem specification for the Bob exercise has been updated. Consider updating the test suite for Bob to match.

Details
The problem description for the Bob exercise lists four conditions:

asking a question
shouting
remaining silent
anything else

There's an ambiguity, however, for shouted questions: should they receive the "asking" response or the "shouting" response?
In https://github.com/exercism/problem-specifications/pull/1025 this ambiguity was resolved by adding an additional rule for shouted questions.
If this track uses exercise generators to update test suites based on the canonical-data.json file from problem-specifications, then now would be a good time to regenerate 'bob'. If not, then it will require a manual update to the test case with input "WHAT THE HELL WERE YOU THINKING?".
See the most recent canonical-data.json file for the exact changes.
Remember to regenerate the exercise README after updating the test suite:
configlet generate . --only=bob --spec-path=<path to your local copy of the problem-specifications repository>

You can download the most recent configlet at https://github.com/exercism/configlet/releases/latest if you don't have it.
Note that pull request https://github.com/exercism/swift/pull/323 locks the problem description for 'bob' to match the current implementation by adding the exercises/bob/.meta/description.md file. If that PR is merged before this issue is resolved, then you will need to delete the exercises/bob/.meta/description.md file as part of the change.

Keeping as is. Thanks for the PR! https://github.com/exercism/swift/pull/323/files#diff-3021f3ae24668ef16774bd5d2c48de9a


fitPanelWidth broken in Calendar

It works fine whenever I set it. But when I click the arrow to switch to another month, the calendar shrinks back to it's original size

Yap, I can repeat the issue.
Will fix it.

Not sure if this is the same issue, but when I set fitPanelWidth to true for my calendar, it makes it really tiny (like almost illegible) and I can't do anything to resize it. Changing fixedScale doesn't do anything.

Please reinstall the plug-in.
I have renewed the version.

This is a related request, but it might need moving elsewhere... Can we have the ability to extend the x-axis, so that it is longer than the y-axis is high to fit the pane width, so as the 'stretch-out' the graph a bit? Rather than just scale the existing proportions to fit the pane width? This would facilitate the visibility of tightly bunched data-points. TY

Please reinstall the plug-in. I have renewed the version.

I found a very funny bug here:

Hi!
This is still occurring.


Added Follow us on Socials in all pages

I added Follow us on Socials to the remaining pages too (Appearance, movies, videos)
This solves issue number #163

@aslams2020 Please add the respective labels to this PR.

Hi, @nksmanya
I got My account back today. On next leaderboard update you'll be able to see your points.
Sorry for the inconvenience. Keep contributing.🚀


Connecting to non-existent broker does not fail as expected in Node-Red

While implementing status in the node-red library, the guys report that with 0.20.3, connecting a client to a non-existing broker, then starting a worker, reports that the worker is connected (does not report a broken connection).

This may be due to the connection retry strategy. The ZBClient retries the connection and does not throw.

Noticed the same behavior in my implementation. With 0.20.1 I got an connection error, and as soon as a running broker was shut down the onConnectionError handler (as described here) was fired.

Yes, it is because of the gRPC retry behaviour.
Otherwise all your workers will explode whenever the nodes are pre-empted in Camunda Cloud, or if the broker is still coming up in docker-compose.
Not sure how to handle this one...

I have the approach figured out now.
Initially, I will provide as first-class on the ZBClient an onReady event that fires whenever a stable connection is achieved, and an onConnectionError event that is debounced, and a connected property that can be examined.
Each worker has its own gRPC channel, so it possible that a worker created from the client could be in a failed connection state when the client is connected. If that shows up, I'll make it more sophisticated.

Looking into this: no error is caused in the gRPC connection until you try to use it.
I can put a call to topology() in the constructor to provoke a failure...

This commit: https://github.com/jwulf/zeebe-client-node-js/commit/e12db74ae76e566af642434d71ff9490cae32d24 adds to ZBClient:

a boolean connected property that makes a statement about the connected status.
an onReady() callback that is called when the client is connected and ready to operate.
an onConnectionError() callback that is called when the client connection fails.

I need to write tests to inspect what happens when a broker goes away after a successful connection.

Looks good when a broker goes away / comes.
I am adding  onConnection and onReady handlers per-worker in the createWorker constructor options (the existing onConnectionError trailing param will override one supplied in options).
The workers will inform the client if they detect a failed connection, so unless per-worker behaviour is needed, you can just listen on the client callbacks.
@TODO: add debouncing in the client's listeners, because now they can be called multiple times in succession by the workers.

I added the wiring to bubble up worker errors into the client.

[ ] test that multiple workers on a client do not cause multiple invocations.

[ ] test that the workers can have independent onConnectionError handlers and that those work.

@todo: Make sure that business errors (like CREATE failed) do not call the onConnectionError handler.

[ ] Make sure that business errors (like CREATE failed) do not call the onConnectionError handler.
Update: business errors do call this handler :-(

[ ]  Test that the previous API for attaching an onConnectionError handler to the worker (last param) still works.


Scope validation is not happening for Implicit Grant flow.

Description:
In the authorization code grant flow, we have proper scope validation happening based on roles. But when the implicit flow is executed scope validation is not happening and all the requested scopes are attached to the token.
Steps to reproduce:
Use this command to generate an access token using the implicit grant.
https://localhost:8243/authorize?response_type=token&client_id=y4m0YV1kbSfdKxh4jh16NCf0Awka&redirect_uri=http://example.com&nonce=abc&scope=
Introspect with,
curl -k -u admin:admin -H 'Content-Type: application/x-www-form-urlencoded' -X POST --data 'token=a805f69f-057a-352f-a580-da2bd59f00c5' https://localhost:9443/oauth2/introspect
Gives the invalid scope attached to the token.
Affected Product Version:
2.5.0
Environment details (with versions):

OS: Linux
Client:
Env (Docker/K8s):

Further troubleshooting details:
It seems like in the implicit flow when it goes through the TokenResponseTypeGrantHandler scope validation happens through https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.keymgt/src/main/java/org/wso2/carbon/apimgt/keymgt/util/APIManagerOAuthCallbackHandler.java#L63-L72 which sets all the requested scopes as approved.
But for authorization code grant it goes through the grant handler which has ScopeIssuer to perform scope validation. If this same logic can be used in the response type handler for the implicit grant, we will be able to handle the concern.

Need to fix in WUM 2.2.0 as well.


Bridges in Graph

Type
Algorithm
Directory
Algorithms => Graph-Algorithms
Description
Bridge -> A bridge is an edge removing which increases number of disconnected components.
Programming Language

[x] c++
[ ] c
[ ] python
[ ] java
[ ] kotlin
[ ] javascript
[ ] typescript
[ ] c#
[ ] swift
[ ] ruby
[ ] scala
[ ] go
[ ] php
[ ] haskell
[ ] bash

I would like to do this in c++

I am good with grapg problem ,I can do this ,please assign me

I am good with graph problem ,I can do this ,please assign me

Hey @ahampriyanshu I have a query do i have to make my own branch or i can commit through the branch you made by your name.

as you wish
On Mon, Oct 4, 2021, 11:07 PM Akhilesh Singh Bhadauriya <
@.***> wrote:

Hey @ahampriyanshu https://github.com/ahampriyanshu I have a query do i
have to make my own branch or i can commit through the branch you made by
your name.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ahampriyanshu/algo_ds_101/issues/1841#issuecomment-933705127,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASCWQN2FRELPYDT6SPHLXNTUFHQ6JANCNFSM5FJVDBQQ
.


Add method to parse the offers

Currently, the only thing the parser is doing - is extracting offers from a search page into a database.
The task is to add a function to follow the offer URL and extract:

Price + additional payments
Apartment size (in square meters)
Amount of rooms
Floor
Description

I started working on the parser function and successfully implemented a baseline for OLX website, the otodom is to be done.
Currently, all the meta-data isn't extracted and converted to the proper type, but stored as a raw string. This should be fixed later.
Also, additional refactoring would be useful in order to reduce the complexity of a parsing function and choose proper names for structures' attributes.

Added functions to pars both olx and otodom offers.


Cannot upgrade existing site with remote mysql to php7

Please attach the output of following command when open a new support request.

[ ] lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.4 LTS
Release:        14.04
Codename:       trusty
[ ] ee -v
EasyEngine v3.7.1
[ ] ee info
NGINX (1.10.0):

user                             www-data
worker_processes                 auto
worker_connections               4096
keepalive_timeout                30
fastcgi_read_timeout             300
client_max_body_size             100m
allow                            <IP_ADDRESS>
PHP (5.6.22-4):
user
expose_php                       Off
memory_limit                     128M
post_max_size                    100M
upload_max_filesize              100M
max_execution_time               300
Information about www.conf
ping.path                        /ping
pm.status_path                   /status
process_manager                  ondemand
pm.max_requests                  500
pm.max_children                  100
pm.start_servers                 20
pm.min_spare_servers             10
pm.max_spare_servers             30
request_terminate_timeout        300
xdebug.profiler_enable_trigger   off
listen                           <IP_ADDRESS>:9000
Information about debug.conf
ping.path                        /ping
pm.status_path                   /status
process_manager                  ondemand
pm.max_requests                  500
pm.max_children                  100
pm.start_servers                 20
pm.min_spare_servers             10
pm.max_spare_servers             30
request_terminate_timeout        300
xdebug.profiler_enable_trigger   on
listen                           <IP_ADDRESS>:9001
MySQL (5.5.49) on localhost:
port                             3306
wait_timeout                     300
interactive_timeout              28800
max_used_connections             34
datadir                          /var/lib/mysql/
socket                           /var/run/mysqld/mysqld.sock
my.cnf [PATH]                    /etc/mysql/conf.d/my.cnf

@ichpen Sorry for a delayed reply. I hope your issue is fixed by now.
If you are still facing the issue, please use http://community.rtcamp.com/c/easyengine for further support.
We are cleaning up issue tracker and closing this issue because we won't be able to contribute to this discussion further.


Use volatile reads

bug-fix for infinite loop on reads, change hot/cold swapping pattern with reading volatile directly to avoid error conditions

Closing this PR to create a new one. My changes overrode the changes from the master branch.


if canvg is passed in, use instead of drawImage

enables support for IE

Glancing over it, looks good. Go ahead and bump the version in package.json to 1.1.0.
Thanks for tackling this. Take a look at the open issues and let me know if there's any that can be closed.
Thanks for documenting the option. I recommend re-writing the Support section of the readme to explain how to use this with IE. It doesn't need to be extensive, but I expect that's where others will look first when troubleshooting IE support.

Looks like there aren't any issues around this. 👍


[Mobile] keyboard did not popup after image inserted

In my app, I tried to insert an image and the problem is after that the keyboard did not show again. I listened the focus and console showed _focusNode.hasFocus is true. In this case, the only way get keyboard back is changing some text color. I am not sure it's a problem in my side or a library's bug, would you like to give me some suggestion? Thanks.
by the way, it happened in iOS, not simulator.

    widget.focusNode.hasFocus ? widget.focusNode : FocusNode();
    FocusScope.of(context).unfocus();
    Timer(const Duration(milliseconds: 1), () {
      FocusScope.of(context).requestFocus(currentFocus);
    });

Add this code after handle image in order to focus on editor.

@phuongtinhbien Thanks a lot for your code, it works for me!
May I have another question? Is any way to listen users delete the image they upload before submitting?

    widget.focusNode.hasFocus ? widget.focusNode : FocusNode();
    FocusScope.of(context).unfocus();
    Timer(const Duration(milliseconds: 1), () {
      FocusScope.of(context).requestFocus(currentFocus);
    });

Add this code after handle image in order to focus on editor.

Should this code be in the repo? If you believe so, PR is welcome


Added missing project files, gitignore file, and implemented an easier way for custom nodes to be created

Hey there!
I found your post in Facebook the other day, and since I'm interested in seeing this work for a project of mine, I though I'd help by making some stuff better and also adding a few features.
In this pull request I added the Unity project editor files and the meta files of the project.
I coded a way to find via Reflection all classes that implement the Node base class instead of letting users add their custom nodes in the library's code.
Also, I added a new attribute that will allow placing context menu items in hierarchies and also changing their names, if needed.
Feel free to drop me a line anytime :+1:
~ ikromm

Hello ikromm,
thank you for the pull request. I really appreciate that! I thought that it would not be a good idea to use reflection for this project.. but I must agree that the annotation for the nodes is very nice. There a re just two points:
I would like to return a Node and not an object for the CreateNode method. Let us do the casting in this method.
I dont know if it is a good idea to commit a .gitignore  to the project. I usually have my individual one because of different IDE files. If you want we could add it but have to add some file types that are created by my IDE (Rider EAP).
I would like to have a consistent coding style. I am still not sure wich one to use.. but meanwhile let write method names wit a capital letter. (GetItemMenuName).
I will merge the request later and add the changes. Are you ok with that? Thank you for the effort!

Hey there!
Thanks for getting back to me.
Why do you want to avoid Reflection? I suppose the code will work only on the Editor, so there would be no problem if that part of the library is missing from a few of Unity's framework implementations.
I added the meta files and the gitignore because not all people know what to commit. For example I do not use a global gitignore since other projects might have different "rules" for which file to ignore or not.
I'd say IDE files will be bad. Not everyone uses the same IDE and they have no need to download them in the first place. That's why I didn't commit the Visual Studio project files Unity creates for example
As for the coding style, I generally create private methods with the first letter lowercase and protected and public with uppercase. It's just an easy way to recognize the scope of the function when glancing the name.

I thought avoiding reflection would make to code easier for beginners. But I like your solution and I will merge it in.
Yes, IDE files are bad. I do not want to commit them.. so I will add the Rider files to your gitignore.
The coding guideline is a topic that I need to investigate more.. until then let's try to be consistent at least in this project.

excellent!
yes, please add stuff to the gitignore file at will.
update the readme file with your thoughts and I'll create a new pull request when I get a chance :)
I'll stick to first capital letter for all methods defined, no worries.


fix Chinese title on mac

Here are two issues when window title has Chinese characaters:
1, title string has to init with stringWithCString
2, NSString length method is not right for Chinese characaters, use lengthOfBytesUsingEncoding:NSUTF8StringEncoding instead.

@freerdp-bot test

clang-format changed settings->ServerPort for me. Should I change it back since there is a failure?
https://ci.freerdp.com/job/code-quality-checker/4459/console
@akallabeth

@amazingfate looks like a formatter issue. you might want to deactivate it for these lines, see https://clang.llvm.org/docs/ClangFormatStyleOptions.html

@freerdp-bot test

@freerdp-bot test again please


Need support for "Updating the pull request branch with latest upstream changes"

Currently there is no way to update the pull request with the latest upstream changes, when using the library. Github has provided a REST endpoint for it - https://developer.github.com/v3/pulls/#update-a-pull-request-branch
It will be good use case to add to the library.

Cool. It looks like it is in preview so the implementer will need to use the Preview API structures like this using @Preview @Deprecated attributes. Other than that seems like something anyone with the time can do.


[Snyk] Security upgrade org.apache.jena:jena-fuseki-core from 4.9.0-SNAPSHOT to 4.9.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to fix one or more vulnerable packages in the `maven` dependencies of this project.
Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

jena-fuseki2/jena-fuseki-main/pom.xml

Vulnerabilities that will be fixed
With an upgrade:

Severity
Priority Score (*)
Issue
Upgrade
Breaking Change
Exploit Maturity

579/1000  Why? Has a fix available, CVSS 7.3
Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') SNYK-JAVA-ORGAPACHEJENA-6043134
org.apache.jena:jena-fuseki-core:  4.9.0-SNAPSHOT -> 4.9.0
No
No Known Exploit

(*) Note that the real score may have changed since the PR was raised.
Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

Checkmarx One – Scan Summary & Details – 6de3e9d9-59d9-4261-8eb8-147b4b1d6a2d
New Issues

Severity
Issue
Source File / Package
Checkmarx Insight

CVE-2023-36478
Maven-org.eclipse.jetty:jetty-http-10.0.15
Vulnerable Package

CVE-2023-43646
Npm-get-func-name-2.0.0
Vulnerable Package

CVE-2023-45133
<EMAIL_ADDRESS>Vulnerable Package

CVE-2023-36479
Maven-org.eclipse.jetty:jetty-servlets-10.0.15
Vulnerable Package

CVE-2023-40167
Maven-org.eclipse.jetty:jetty-http-10.0.15
Vulnerable Package

CVE-2023-42503
Maven-org.apache.commons:commons-compress-1.23.0
Vulnerable Package

CVE-2023-44270
Npm-postcss-8.4.21
Vulnerable Package


[FEATURE]:  Auto Doc | Template overview

Ticekt Nr: #141

I see that you based the auto-doc plugin on the type designer package. If you need help to distinguish files you need to keep and those you can delete, I'll be glad to help.

Most of the changes came from Felix's branch to do a standalone plugin. Do you see bits and pieces that need to be removed from the auto-doc plugin?

Hi Sergio, some points from my side:

Is the plus in the add Button an Icon? It looks like its only a character. Maybe you can take the same add icon as used in the template geneartor plugin.
Do the icon only buttons have labels while hovering? If not i would recommend for the labels: "Edit", "Delete", "Duplicate", "Generate Document".
"Export Document" Button should be renamed to "Generate Document". But also i am not 100% sure if we need it, because the user could use the icon only buttons or the checkboxes. What do you think?

Hi @LissiEitel  thanks for the input. Here are my replies to the following bullet points:

Yes indeed it'sa simple + for now as I wasn't focusing on the btns. I'll replace it with a proper icon

Good point, labels aren't currently being shown when the user hovers.

I am not quite sure if I fully understood your point, so correct me if I'm wrong...  Are you saying we may not need an export button at all and instead just use the download button?  I think the advantage of having the button is so that I can select multiple rows and download them all at once. However, since we currently don't have this functionality anyways it can be gone for now also. What are your thoughts on that?

Looks fine for me :)


workaround ThunderX2 DNRM2 fault with ssq=inf,scale=0

fixes #3654

Locally I did MACOSX_DEPLOYMENT_TARGET=11.0 make TARGET=VORTEX then rebuilt numpy+scipy and all seems well. Thanks for digging into this @martin-frbg !


anisotropy of bodies at the end of the simulation (when nbRoutine > 1)

Sequence:

load conf-fra-00000.bods
run the simulation till bodies are stabilized

Problem:

an anisotropy appears at the end
it seems short range repulsion is overtaken with a local repulsion field

see
https://github.com/thomaspeugeot/tkv/barnes-hut/Anisotopry%20issue.pptx

heavy work : render the repulsion field around the anisotropy
light work : make short repulsion stronger

attempt with 1/r3 repulsion vector intensity makes no changes. This goes along that the the field anisotropy must be rendered

Note: the issue is not dependant on the siee (8000 or 200000 bodies
Note: the issue is not dependant on the theta of the barnes hut (try to lower theta to 0 at the end has no effect)
A programming issue ?

the problem is solved when NbRoutine == 1. So the problem is concurrency provoked

solved : commit log !
	startIndex := (i*sliceLen)/nbRoutine

  endIndex := ((i+1)*sliceLen)/nbRoutine -1

  endIndex := ((i+1)*sliceLen)/nbRoutine


Lots of stuff broken with conda-build 1.18

The rules for when numpy is included in the build string changed https://github.com/conda/conda-build/pull/573

Ugh.

Can we pin the version to fix that?

We could, but I think the new behavior is an improvement. We just have to figure out how to work with it.

How much stuff is broken that needs to be upgraded/fixes?

http://binstar.org now redirects to the crazy new https://anaconda.org/ "Anaconda Cloud" page.

lol their logo looks like 80% of the proposed omnia logos

Per some debugging with the mdtraj recipe, the solution is to add -numpy x.x to both the build and run section. Literally x.x
This is an improvement. Packages that only import numpy only need to be built once. Packages that link against the numpy c api will work as before (with the addition of x.x to the recipes)

Fixing this now.

Due to this changes in conda-build we ended up in having binaries which are generic (includes only targeted Python version like 'linux-64/bhmm-0.5.1-py34_0.tar.bz2' uploaded 8 days before this post) and some which specify the Numpy version (like inux-64/bhmm-0.5.1-np19py34_0.tar.bz2).
Actually it seems like a duplication and I wonder what is the cause for that. If you install a package with duplicate candidates, conda takes forever generating the hint message, that there are duplicates. So I guess we should fix this - shall I open up a new issue for that one?

That's just a matter of deleting the older, generic packages from binstar/whatever-they-call-it-now, no?

@marscher i deleted the files that don't properly specify the number version, so it should be fixed now.

I was just wondering why the generic packages were more recent than the version specific ones.

Fixed.


[Feature Request]: Improve chatbot UI

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description

The chat UI is very basic and there is no visible differentiation in chatbot and user messages. I will make it look like a chat (user msgs are aligned towards right and ai msgs are aligned towards left). Also there should be a back to home button to redirect to ambuFlow homepage. Also we have to match the color scheme with the logo.
Use Case
It will enhance and improve UX
Benefits
No response
Priority
Medium
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC contributor
[X] I want to work on this issue
[X] I'm willing to provide further clarification or assistance if needed.

@mansiruhil13 assign me this issue

assigned already.


merge case-sensitive note to live

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

BingAds/hotel-service/reference.md
:white_check_mark:Succeeded

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


J

https://github.com/orgs/readthedocs/projects/156/views/3

@Aleis007891
We are going to close this thread if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.


Add zap to qqmusic cask

Thank you for the contribution. It was merged directly as 13477b2adb5cebd61a16cadab8b38f700d843bbb to keep commit history cleaner. Your contribution is still credited to you.


[ListView] Use function refs and support composed refs

Fixes an issue where if you implement renderScrollComponent and have a ref callback on the returned element, the ref used to be clobbered by the ref that ListView adds to the element.
This is accomplished by converting the ref from a legacy string-based ref to a callback-based ref, and then using cloneReferencedElement, which is a simple utility to compose callback refs.
Test Plan: Open the ListView examples in UIExplorer (iOS)

Note that this adds a small dep to package.json, so it'll be necessary to rebuild npm-shrinkwrap.json.

FYI @ide we removed shrinkwrap from master (but are still shipping it to NPM), so no need to worry about dep updates and updating shrinkwrap for PRs anymore.

Looks good to me.

@facebook-github-bot shipit

@mkonicek this failed for some reason...not sure why

The error is:
Unable to resolve module react-clone-referenced-element

It's likely because this PR changes package.json and need to import it manually into the fb npm cache.
Any PRs that touch package.json need manual import. Can you do this without adding a dependency? Just an idea.

I'll let @ide speak to that. It's a small dep...just a function...it could possibly live within RN...but shouldn't be a big deal to add as a dependency.

It's a small dep and pretty stable unless React's ref API changes. There is at least one other place in the codebase (Navigator) that needs this behavior too, though, so having it be a shared helper function makes the most sense to me. And most React libs that clone elements and set refs should be using this, so that's why the helper is published to npm.

OK that makes sense, need to find some time to import this into our internal "npm cache" :)

catping =)

Haha nice macro! :) Sorry for the delay, I'll try to merge this tomorrow.

Removing the 'Import failed' label on this one. Using the 'Import failed' to track random failures we can fix. Automatically merging PRs that change package.json is unsupported and likely won't be for quite a long time (although it should be possible to implement).

Trying to merge it internally now, sorry for the (long) delay!

It's failing with an error installing node_modules from the internal cache in our CI. Looking into it, might have to wait for people in California. Merging PRs that change package.json is too hard unfortunately.

It worked! 🎉  Sorry I forgot about it for 13 days :( Feel free to ping me on messenger next time.

@mkonicek thanks for pushing it though - appreciate it =)

I'd recommend wrapping instead. Makes it a bit more seamless, doesn't take on another dependency, and is backwards compatible with old-style refs.


Remove these repos from documentation

This issue is for people to post the names of repos they want excluded from the documentation process. By default this is just private repos.
Current docs: https://strands-project.github.io/strands_documentation/

[ ] autonomous_patrolling


Background

We accidentally did a lot more than simply update background. Here is a list of enhances and bug fixes.
Player - #2 #10 #12
Enemy - #3 #6
Background - #1
Game Engine- #9

Looks good.


TextualBodyEditor

This is one of our (eventually several) annotation body editors... or maybe they are capture models...

The creation process uses a single multi-lingual field and the editing process uses a list of editors (as at this point they are multiple content resources). Room for improvement, and also limitation that you cannot add extra languages after initial creation - this requires deletion and recreation of the annotation. However closing as it's MVP.