Proposal: add a new codepoint for QUIC v1 (RFC 9000), and for future incompatible versions

Current Status
libp2p started deploying QUIC a few years ago, when RFC 9000 was not deployed yet. Back then, we deployed QUIC draft-29. Since node operators are slow to update their go-ipfs nodes, draft-29 is now the most deployed version.

QUIC draft-29
QUIC draft-29 + v1
QUIC v1

QUIC draft-29
✔
✔
❌

QUIC draft-29 + v1
✔*
✔
✔*

QUIC v1
❌
✔
✔

*: There's a 1 RTT penalty if the version offered on the initial connection attempt doesn't match the nodes version, as Version Negotiation is performed.
Currently, go-libp2p has support for QUIC draft-29 and QUIC v1. Since draft-29 is the most commonly deployed version (and supported by all nodes on the network), we use that version for dialing new connections.
What happens when rust-libp2p gains QUIC support
rust-libp2p is adding QUIC support, and quinn only supports RFC 9000. If we don't do anything, this means:

Legacy nodes (those supporting only draft-29) won't be able to connect to rust-libp2p nodes. This is only fair.  You asked for it.
rust-libp2p nodes won't be able to tell which QUIC versions a node supports. It will try to connect to legacy nodes, and the QUIC connection will fail after 1 RTT.
go-libp2p nodes now have two options:

continue preferring draft-29. This will incur a 1 RTT penalty when connecting to rust-libp2p nodes, as we'll need to perform version negotiation.
prefer QUIC v1. This will remove the 1 RTT penalty, but will incur a 1 RTT penalty when connecting to legacy nodes. Given the large number of nodes, this might affect our TTFB metrics.

Proposal: add a new QUIC v1 code point
We could add a new code point for QUIC v1 (string representation: quicv1). The existing code point would be reinterpreted to mean QUIC draft-29.
Nodes that support multiple versions can (and should!) offer them on the same port. There's no need to worry about demultiplexing, since QUIC packets contain the version number and any QUIC stack will be able to handle packets from different QUIC versions (if it's a multi-version stack).
But what about QUIC v2
Does this mean that we need to add a new code point for every new QUIC versions? Wouldn't that be wasteful. Yes and no.
The IETF is currently working on specifying QUIC v2, and quic-go already has support for that QUIC version. We don't need a new code point though, because QUIC v2 is a compatible version (to QUIC v1). The exact definition of what constitutes compatibility between QUIC versions is subtle, but as a rule of thumb, if there's a transformation of the ClientHello from one version to a ClientHello of the other version, chances are that the versions are compatible. QUIC versions that use TLS 1.3 (or successors) are likely to be compatible.
Using Compatible Version Negotiation (shipping as an RFC very soon), it is possible to do a version upgrade between two compatible versions without incurring any round trip penalty. Thus, it's fine to continue advertising QUIC v1, as the connection can seamlessly be upgraded to v2 during the handshake.
Only when / if QUIC v2 becomes a dominant version on the internet, AND there are good reasons to not use QUIC v1 any more, would it make sense to introduce a v2 code point, so that compatible version negotiation can be skipped.
Hypothetical: an incompatible QUIC version is defined
A QUIC that uses a different handshake protocol than TLS 1.3 would almost certainly not be be compatible with QUIC v1. Assuming that libp2p would want to support both versions, it would make sense to introduce a new codepoint for that QUIC version, as we'd incur an additional roundtrip for version negotiation when nodes offer an unsupported version.

cc @Stebalien @elenaf9 @MarcoPolo @kpp @thomaseizinger

3. prefer QUIC v1. This will remove the 1 RTT penalty, but will incur a 1 RTT penalty when connecting to legacy nodes. Given the large number of nodes, this might affect our TTFB metrics.

I guess ideally, we go with this option but somehow minimize the 1 RTT penalty. What do you think of this idea:

For the time being, prefer draft-29.
Define a sunset date at which point go-libp2p will switch to prefer QUIC v1 instead.
Emit a warning every time you hit the 1 RTT penalty by having to upgrade to QUIC v1.
Emit a warning every time you connect you connect to a draft-29 node that this connection will incur a 1 RTT penalty from .

This should give node operators some time to notice the issue and upgrade their software accordingly. Making an informed decision on  should allow you to mitigate most of the risk on affecting the TTFB metric.

Emit a warning every time you hit the 1 RTT penalty by having to upgrade to QUIC v1.
Emit a warning every time you connect you connect to a draft-29 node that this connection will incur a 1 RTT penalty from .

You can't do that: You can't update old nodes, so the node operators who need to see the warning will never see it. Instead, you'd just be spamming the logs of node operators of updated nodes, potentially with multiple messages per second. Even worse, these messages wouldn't be actionable.

Emit a warning every time you hit the 1 RTT penalty by having to upgrade to QUIC v1.
Emit a warning every time you connect you connect to a draft-29 node that this connection will incur a 1 RTT penalty from .

You can't do that: You can't update old nodes, so the node operators who need to see the warning will never see it.

Hmm okay, I assumed that people will update at some point but yeah, if there are many operators who don't update at all, then this is definitely an issue.

Instead, you'd just be spamming the logs of node operators of updated nodes, potentially with multiple messages per second. Even worse, these messages wouldn't be actionable.

I mean, that is fixable. You can just emit the log only once per peer. Also, you'd remove the log again in the version that prefers QUICv1 so updated nodes would not emit that.

I am a bit on the fence here. On the one hand, adding a new protocol is a legitimate upgrade path. On the other hand, it feels like a bit of a waste to use when the situation is:
a) temporary
b) penalizes mostly nodes which run outdated software
Can we make an estimate of how long the grace-period of a time-based trigger that switches to v1 would have to be to have most of the network prefer v1? Are we talking weeks, months or years?
Another, more sophisticated mechanism for such kind of upgrades is to have nodes keep track[^1] of how many of their peers support v1 and switch to preferring that once it hits a configured threshold.
Assuming that nodes connect to a representative subset of the network, this would make the switch gracefully as soon as a configured threshold is capable of v1.
[^1]: This will need to be persisted between restarts which slightly complicates the implementation.

it feels like a bit of a waste to use when the situation is:
a) temporary

It’s not any more temporary than any other update of QUIC from one incompatible version to the other.
I find it quite instructive to think about what we’d what to do once an incompatible QUIC version is specified, e.g one that’s using a different handshake protocol: As I’ve described in my original post, we’d want to specify a new code point in that case. Thus, minting a new code point for QUIC v1 seems consistent.

Should we then be more elaborate in the naming of the new code point? Like quic-rfc9000? I guess ideally, the current quic one would be called quic-draft-29. Might be a good mental note to take for future protocols.
I am okay with a new code point, it is a valid upgrade / negotiation technique and really the only annoying thing is the aesthetics and documentation effort.

b) penalizes mostly nodes which run outdated software

That’s totally fine. We don’t want to penalize nodes that run up-to-date software though, which is what we’d do if we switched to dialing v1 by default.

I would still find it interesting to back this with some data. Does go-libp2p support RFC9000 today? Does it use RFC9000 if both nodes support it? Are there any numbers on what % of connections that is?

@elenaf9 What would your implementation strategy be on the Rust side? Can you give an estimate how much work this would be?
I wrote up what's needed in go-libp2p in https://github.com/libp2p/go-libp2p/issues/1841.
Not sure if you want to support draft-29 in rust-libp2p as well, it might be fine to just support QUIC v1. Since rust-libp2p never had QUIC support to begin with, you'd not be causing a regression.

@mxinden @MarcoPolo I'm in favor of moving forward with this proposal, but it would be helpful to get your input here.

First off, thanks for the detailed write-up @marten-seemann!

rust-libp2p is adding QUIC support, and quinn only supports RFC 9000. If we don't do anything, this means:

Not sure if you want to support draft-29 in rust-libp2p as well, it might be fine to just support QUIC v1. Since rust-libp2p never had QUIC support to begin with, you'd not be causing a regression.

For the record, does quinn support draft-29 or does it not @elenaf9?

2. prefer QUIC v1. This will remove the 1 RTT penalty, but will incur a 1 RTT penalty when connecting to legacy nodes. Given the large number of nodes, this might affect our TTFB metrics.

To be able to make an informed decision, can someone add numbers to "large number of nodes [running draft-29 in the IPFS network". Unfortunately I don't have this data with kademlia-exporter.max-inden.de/. @dennis-tra maybe?

We could add a new code point for QUIC v1 (string representation: quicv1). The existing code point would be reinterpreted to mean QUIC draft-29.

I think renaming the text representation of the /quic code point to /quic-draft29 adds complexity which is unfortunate. That said, with the suggestion below, in case we are consistent across the many multiaddr implementations, it would be worth it.

Implementations MAY choose to continue accepting /quic multiaddresses (and interpret them as quic-draft29 or quic-v1 at their discretion).

https://github.com/multiformats/multicodec/pull/298
I think we should be consistent, i.e. either interpret /quic as /quic-draft29 or /quic-v1 across all our multiaddr implementations.

Overall I don't have a strong opinion here. My intuition tells me to:

Not add a new code-point.
Make the change to prefer QUIC RFC-9000, thus pay the extra cost of 1RTT to older nodes.
See this as another argument for investing into upgrade-your-IPFS-node advocacy.

To be able to make an informed decision, can someone add numbers to "large number of nodes [running draft-29 in the IPFS network". Unfortunately I don't have this data with kademlia-exporter.max-inden.de/. @dennis-tra maybe?

These are the go-ipfs v0.7.0 nodes, so it's a very large fraction of the IPFS network (30-40%).

See this as another argument for investing into upgrade-your-IPFS-node advocacy.

The cost is only paid by nodes that upgraded, so the incentives are severely misaligned here.

Thanks Marten! I think this is worth doing sooner rather than later. I think I’m in agreement with the original post. Here’s a bit of clarification on the exact semantics since I think we’ve been discussing a lot of different things in this thread (that’s a good thing!).
This issue is only about adding a new code point for quic-v1, not about whether to rename the existing code-point to quic-draft-29. Let’s talk about the rename in a another issue (I’m for it, but it needs some thought around implementation). Letting nodes be explicit in their support of quic-v1 seems like a great thing, and (besides an extra multiaddr or two) I don’t see any downsides here. rust-libp2p may only want to advertise quic-v1, although according to the release notes on quinn they support draft-29.
I think we should add the new codepoint as soon as possible so that rust-libp2p can start using it and we can start advertising it in go-libp2p. The new codepoint allows dialers to know ahead of time what version to use.
Then there’s the very closely related issue of:

go-libp2p nodes now have two options:
i. continue preferring draft-29. This will incur a 1 RTT penalty when connecting to rust-libp2p nodes, as we'll need to perform version negotiation.
ii. prefer QUIC v1. This will remove the 1 RTT penalty, but will incur a 1 RTT penalty when connecting to legacy nodes. Given the large number of nodes, this might affect our TTFB metrics.

(I’m defining new nodes as nodes post this upgrade; old nodes as nodes prior to this upgrade)
If new nodes advertise their explicit support of quic-v1 then we don’t pay the 1 RTT penalty when new nodes dial other new nodes (they know to use quic-v1). If a new node only sees a node support the quic codepoint (draft 29) then it should dial with draft-29. We don’t incur a 1RTT penalty if rust-libp2p nodes advertise quic-v1 since the new node would have seen that multiaddr.
Option i. is strictly better than ii. because we can avoid the 1RTT penalty by only dialing quic-v1 if the other node explicitly advertises it, which will be the case if we agree on a new this new codepoint sooner and have rust-libp2p use the quic-v1 codepoint. Option ii. forces a 1 RTT penalty when connecting to older nodes (a significant portion of the network currently). Am I missing something here?
I think codepoints are cheap. The way we represent a list of multiaddrs is a bit inefficient, but we can optimize this in the future if it becomes a problem.
—-

I think we should be consistent, i.e. either interpret /quic as /quic-draft29 or /quic-v1 across all our multiaddr implementations.

Agreed. Let’s keep the current codepoint and string /quic to mean quic-draft29. We may even want to alias this to have new nodes represent this as the string /quic-draft29 to be clearer, but this is a bit of a tangent.
—-
tl;dr I agree the new codepoint is a useful addition. I don’t see any major downsides to introducing it. Let’s do it.

Thank you for your comprehensive response, @MarcoPolo!

I think we should be consistent, i.e. either interpret /quic as /quic-draft29 or /quic-v1 across all our multiaddr implementations.

Agreed. Let’s keep the current codepoint and string /quic to mean quic-draft29. We may even want to alias this to have new nodes represent this as the string /quic-draft29 to be clearer, but this is a bit of a tangent.

That makes sense. The hope is that in the long term (as QUIC draft-29 is phased out), the /quic string representation will also slowly die. For the transition period, we should parse /quic as /quic-draft29. Once we disable draft-29 support (https://github.com/libp2p/go-libp2p/issues/1841 suggests a transition period of 6 months), we might also stop parsing /quic.

Apologies for the late reply here.

https://github.com/libp2p/rust-libp2p/pull/2289, and quinn only supports RFC 9000. If we don't do anything, this means:

Not sure if you want to support draft-29 in rust-libp2p as well, it might be fine to just support QUIC v1. Since rust-libp2p never had QUIC support to begin with, you'd not be causing a regression.

For the record, does quinn support draft-29 or does it not @elenaf9?

Quinn supports draft-29, however it does not support version negotiation on the client side. Instead, when initiating a new outbound connection we have to set the QUIC version in the client config. If the server sends back a Version negotiation packet because it does not support that version the connection attempt will error with VersionMismatch. See quinn-rs/quinn#1249.

@elenaf9 What would your implementation strategy be on the Rust side? Can you give an estimate how much work this would be?

Given the above, it wouldn't be much work to support both the new and the old-codepoint. When initiating a new dial we'd check the codepoint, in case of /quic or /quic-draft-29 set out client config version to draft-29, else use default QUIC v1. As a server we support all (>= draf-29) versions, but our listening addresses would have the /quic-v1 codepoint.

Once we disable draft-29 support (https://github.com/libp2p/go-libp2p/issues/1841 suggests a transition period of 6 months)

What's the difference between dropping draft-29 support in 6 months compared to dropping it right now? I understand that go-ipfs v0.7 makes up a significant portion of the IPFS network, however go-ipfs v0.7 is two years old. If those nodes did not upgrade for all that time do we expect anything to change in the next 6 months?
If I understand it correctly dropping support for draft-29 would avoid the need for a new codepoint (at least until a new incompatible version is published)?

What's the difference between dropping draft-29 support in 6 months compared to dropping it right now? If I understand it correctly dropping support for draft-29 would avoid the need for a new codepoint?

No we still would want a new codepoint so that new nodes can know before dialing if the node speaks v1 or draft 29. If we don’t adopt a new codepoint and assume everyone uses quicv1 then you incur a penalty when communicating with (the many) old nodes.

What's the difference between dropping draft-29 support in 6 months compared to dropping it right now? If I understand it correctly dropping support for draft-29 would avoid the need for a new codepoint?

No we still would want a new codepoint so that new nodes can know before dialing if the node speaks v1 or draft 29. If we don’t adopt a new codepoint and assume everyone uses quicv1 then you incur a penalty when communicating with (the many) old nodes.

Okay makes sense.

Don't have a strong opinion on this; adding a new codepoint sounds reasonable 👍. Will do a PR for it on rust-multiaddr.

iiuc we executed on /quic-v1 and /quic-v1/webtransport, implemented in Rust/Go,
and  recently shipped in Kubo 0.18 and the rollout has begun:

https://github.com/ipfs/kubo/blob/master/docs/changelogs/v0.18.md#differentiating-quic-versions

is there anything else to be done here, or can we close this?

This has been fully resolved and released.


Adding docs

Fixes #58

Codecov Report

Merging #60 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master      #60   +/-   ##
=======================================
  Coverage   98.39%   98.40%
=======================================
  Files          13       13
  Lines         749      751    +2
  Branches       95       96    +1
=======================================
+ Hits          737      739    +2
  Misses          9        9
  Partials        3        3

Impacted Files
Coverage Δ

...itor/src/azure_monitor/auto_collection/__init__.py
100.00% <ø> (ø)

...zure_monitor/auto_collection/dependency_metrics.py
100.00% <ø> (ø)

...ure_monitor/auto_collection/performance_metrics.py
100.00% <ø> (ø)

...c/azure_monitor/auto_collection/request_metrics.py
100.00% <ø> (ø)

azure_monitor/src/azure_monitor/export/__init__.py
100.00% <100.00%> (ø)

...nitor/src/azure_monitor/export/metrics/__init__.py
96.00% <100.00%> (ø)

...monitor/src/azure_monitor/export/trace/__init__.py
100.00% <100.00%> (ø)

azure_monitor/src/azure_monitor/options.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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

https://travis-ci.com/github/hectorhdzg/opentelemetry-exporters-python/builds/154868101?utm_medium=notification&utm_source=email


Add Nim to the list of language identifiers

Now that the Nim programming language has an early stages, but working, language server I think it's time to add it to the list of identifiers.

@PMunch there is a difference between listing a server on the server page and adding a new language to the list of well know language ids. I have no problem of adding Nim to this list https://microsoft.github.io/language-server-protocol/implementors/servers/ (PR necessary against the corresponding servers.md file). But listing it as a well know standard language ID usually requires a broader use of that language in the community.
Please note that you can still use the nim langueg id.

@PMunch. Thanks for pointing this out. I created: https://github.com/Microsoft/language-server-protocol/issues/598


Following Quick Start Guide generates error at step two

The second command of the Quick Start Guide generates an error:
vagrant@microk8s:~$ microk8s.status --wait-ready
Insufficient permissions to access MicroK8s.
You can either try again with sudo or add the user vagrant to the 'microk8s' group:

    sudo usermod -a -G microk8s vagrant

The new group will be available on the user's next login.

It is an obvious one, of course, just a small thing, but as a quick starter I now have to ask myself:

What are the implications if I add the current user to the microk8s group?
Will everything still work?
How can I be sure that adding the user to the group is supported by microk8s?
Or do I have to use microk8s with sudo all the time?
Why is information about such an important thing missing?
Why is the second command in a documentation of one of the leaders in Linuxland generating errors?
Will there be even more errors?
Why is nobody testing this?
Will I have lots of problems using a K8S distribution that generates errors on the second command found in the quick start?
Is this project dead?
Should I dig deep into the implications of K8S and system groups?
Is this a quick and easy tool that I can "just use"?
Why is this stopping my workflow?
Should I build my own K8S distribution?
What do I have to think of a company that publishes quick guides that fail?
Where went the software quality level of the good old days?
Why do we have to spend so much time with computers that constantly produce errors?
Why is there so much darkness in the universe?
Why do we all have to die?

You get it... of course I still love you, but please do not do such things. Step two in a quick start guide should be checked by at least three persons before publishing it. Thank you!

You are right @supersexy. We should be more precise in our docs. Unfortunate all users that gave the +1 to the docs were already in the microk8s group so we missed this error.
@evilnick I think we should add the sudo and point the users to a doc discussing the microk8s group. What do you say?

when I close a terminal session and try to run kubectl command I get the same insufficient permission error again. the group isn't persisting through sessions.

Seconding this I ran straight into this issue and the first result on googling takes you off to microk8s.kubectl requires sudo
its not ideal to run into this on the second item in a guide on https://microk8s.io/
perhaps while the project is still actively developing it may be prudent to redirect users to the github readme as that looks to be accurate.
Interestingly being a member of the microk8s group does not actually seem to fix the problem at least not on Mint 19.3

Bump, this is still an issue. Almost every new user will start with this guide and thus experience this.


upgrade uuid dependency version

Unable to use extended_image library because of uuid dependency version issue.
Need to upgrade uuid to 3.0.0.
Because extended_image >=3.0.0 depends on extended_image_library ^2.0.1 which depends on crypto ^3.0.0, extended_image >=3.0.0 requires crypto ^3.0.0.
And because uuid 2.2.2 depends on crypto ^2.0.0, extended_image >=3.0.0 is incompatible with uuid 2.2.2.
Because every version of audioplayers from git depends on uuid ^2.2.2 and no versions of uuid match >2.2.2 <3.0.0, every version of audioplayers from git requires uuid 2.2.2.
Thus, extended_image >=3.0.0 is incompatible with audioplayers from git.

+1

Fixed by https://github.com/luanpotter/audioplayers/pull/785


Remove FontAwesome dependency

FontAwesome is a great library, but we don't want to lock users into it as a dependency. By providing a custom icon font, or set of SVGs, we reduce bloat/dependencies and provide more flexibility.

icomoon is a good tool for managing an icon library
or re-purposing this editable SVG icon component pattern

Would be preferable options. If you have questions, comments, or concerns; please feel free to chime in. If you would like to claim this issue, please feel free to 🙌

https://github.com/OHIF/react-viewerbase/releases/tag/v0.6.1


The removed allowBackup attribute

Need a release to avoid sync project error.
9d76e4cf34a53f2a70d0604ef7a7b1bfbd259208

Until it is released, you should be able to ignore the error by adding tools:replace="android:allowBackup" on the <application> tag in your AndroidManifest.xml file.

Another one has the attribute too, just an error in IDE Gradle Sync.


uCaptcha preventing form rendering

Have site where the Umbraco Forms are rendered via a form picker on a blockgrid formBlock.  Form works fine. Added uCaptcha package, set up for Turnstile in appsettings uCaptcha section and added to an Umbraco Form. Page displays:-
Could not render component of type: formBlock
This likely happened because the partial view blockgrid/Components/formBlock could not be found.
If I remove uCaptcha from the form, it renders ok.  This is on localhost, which is one of the configured domains in the Cloudflare account.

Turns out the fix is to put this file (FieldType.uCaptcha.cshtml) in the Views/Partials/Forms/Themes/default/Fieldtypes/ folder
https://github.com/UmbHost/Our.Umbraco.Forms.uCaptcha/blob/main/src/Views/Partials/Forms/Themes/default/Fieldtypes/FieldType.uCaptcha.cshtml


PooledStackAllocator helps improve performance of thread creating

In typical scenarios, we utilize photon::thread_pool primarily due to the efficiency gains from reusing existing photon threads rather than creating new ones.
From my observation, the most resource-intensive aspect of creating a photon thread is the allocation of its stack memory. It is notably more straightforward and offers better performance to reuse pre-allocated stack memory directly compared to reusing it through a thread pool mechanism.
Although the current IOAlloc toolset isn't compatible with stack allocation operations that cannot rely on photon thread utilities, I have developed a thread-local stack pool, enabling the practical reuse of already allocated stacks.
In our tests, the photon::WorkPool utilizing a pooled stack allocator outperforms the version using a traditional ThreadPool, and both these approaches significantly surpass direct thread creation in terms of performance.

Why the pooled stack allocator is faster than the thread pool?

Why the pooled stack allocator is faster than the thread pool?

The most heavy step of creating new photon thread is stack allocation, both thread pool and pooled stack allocator try to reuse allocated stack, but in different way.
In ThreadPool, all photon threads will not be put into DONE state when task finish, but keep in a indentity-pool to wait for reuse. The thread state is always kept and have to carefully deal with.  Every step with locks and cross-vcpu notifications are always slow and too heavy.
The pooled-based allocator kept only stack memory allocation, never keep thread state at all. That makes it do not need to deal with locks and thread states, just a simple thread-local allocator. That is much simpler and efficient in tests.
Though, if workload always create new thread from one vcpu and then migrate to another, and let photon thread finished in vcpus that never create new threads, the thread local pool will never helps. (For example: always thread create in vcpu-A, then migrate to B, when work done, it will return stack to PooledStackAllocator in B. if B never create new threads, those stacks will never be reused.)


Confirm the Ending Instruction issue

Challenge Name
Confirm the Ending
Issue Description

That is what you need to do in order to pass this specific excercise, but one of the parameters is completely the opposite of what you should do.

confirmEnding("He has to give me a new name", "me") should actually return false
Browser Information

I'm using the latest version of Chrome on a Windows 10 laptop

@Ollysho I believe it is correct. The target does not need to match the last whole word in the string. Therefore, "name" in the str does match "me" in the target because the last two letters of name are "me".

@dhcodes Ahh. That makes sense. My misunderstanding then.
Cheers!


Testflight: build with —obfuscate --split-debug-info flags

#skip_changelog
:scroll: Description

build with —obfuscate --split-debug-info flags
:bulb: Motivation and Context

Relates to #1983
:pencil: Checklist

[x] I reviewed submitted code
[ ] I added tests to verify changes
[ ] No new PII added or SDK only sends newly added PII if sendDefaultPii is enabled
[ ] I updated the docs if needed
[ ] All tests passing
[x] No breaking changes

Grouping works if the flags are applied the same for both platforms. https://github.com/getsentry/sentry-dart/issues/1983#issuecomment-2110401362


Ultimos detalles.

For the latest version, we need to complete the following functions:

Add effect when adding to cart on the clicked icon and on the cart icon on the top right.
All elements on the "carritoCompras" array have a field in the object called "cantidad". we can use the latest to renderer:

Is rendered next to each item in the cart

Is rendered in the shopping cart icon at the top right

We have a design error. Since we rely on the index of the array to create the IDs of the HTML elements, it works against us when they are removed from the array. On some occasions the index no longer matches the ID.


[DT] fix flaky cancel test for translation

We cancel the job and then try to assert on a canceled status, but sometimes the operation is "NotStarted" and creates a flaky test. To fix this, we will wait until the operation is complete and then check that the job was successfully canceled.

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


added explanation why exponents of form 2^t + 1 are good.

Also Changed a bit the beginning of the subsubsection

Thanks @mpzajac - I incorporated these changes in #6 directly. Closing this PR as a consequence.


feat(shared utils): add new docs, and fix others for consistency

Some utility functions has docs, other don't.
This PR added missing inline docs to all the functions and update existing docs to use consistent description.
When creating "is" functions (isPrimitive, isObject, isPromise, isRegExp),
the description should start with "Check whether...".
When creating "to" functions (toString, toNumber, toArray, toObject),
the description should start with "Convert a value to...".

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[ ] Feature
[x] Code style update
[ ] Refactor
[ ] Build-related changes
[x] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:

[x] It's submitted to the dev branch for v2.x (or to a previous version branch), not the master branch
[ ] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[x] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
[ ] New/updated tests are included

If adding a new feature, the PR's description includes:

[ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Thanks for the PR... but honestly I don't think these are objective improvements. The original comments are better for the specific context they were written in.

@yyx990803
Please note that currently not all the utility functions has inline docs.
I was just trying to add descriptions to all of them and use consistent description for better readability.

I think current code is self-explanatory enough and adding comments for all functions are not necessary because we are not generating the docs with JSDoc.


MG - 7.2.6 vs 7.2.8 Equilibrium Equations Question

Are the equilibrium equations similar/shared? Do they depend on each other in any way?

No, They are not dependent on each other. Each equation is created separately :)


Add edit button and link to external repositories

Currently there is no edit button that links to the content's source.

[ ] Implement edit button linking to source files form external repos

this should be possible with the editURL Plugin.
I'm not really familiar with docusaurus just yet though.
I'd really like to have this feature, maybe if you could guide me I can implement it?

Okay, the way to go seems to use the EditUrlFunction, but I need a better understanding of the structure of the docs page first, before I can implement this myself, as there are many different docs from different repositories rendered via the same docusaurus instance it seems.

Hi, yes you are correct, the way to go would be the EditUrlFunction
The way it works: There a several docs that come from external repositories with a custom workflow, see this link for reference.
This docs.package.json is the single source of truth, where the docs to be included are defined. There is also a guide for new external repos to add.


code - navbar components

#4
todo

[x] code - navbar component

@input 📦 navbar_v0.0.12 from https://github.com/dat-ecosystem/organization/issues/72
@input 📦 button_v0.0.1 from #1
[x] add all the buttons into the navbar
@output 📦 navbar_v0.0.1 from comment

[x] update navbar_v0.0.1

@input 📦 navbar_v0.0.1
[x] update the navbar to be mobile first and responsive
@output 📦 navbar_v0.0.2 from comment

[x] update navbar_v0.0.2

@input 📦 navbar_v0.0.2
[x] update the code links
[x] read feedback
[x] code navbar toggle
[x] create and update tasks, worklog etc
[x] adding all the icons with navbar, window_bar etc
[x] passing all the states to icon_button component
[x] create and update worklogs and task
@output 📦 navbar_v0.0.3 from comment

[x] update navbar_v0.0.3

@input 📦 navbar_v0.0.3
[x] code theme protocol for navbar
@output 📦 navbar_v0.0.4 from comment

[x] update navbar_v0.0.4

@input 📦 navbar_v0.0.4
[x] update theme protocol
[x] update logo button
@output 📦 navbar_v0.0.5 from comment

[x] update navbar_v0.0.5

@input 📦 navbar_v0.0.5
[x] update - navbar events and responsiveness
@output 📦 navbar_v0.0.6 from comment

[x] update navbar_v0.0.6

@input 📦 navbar_v0.0.6
[x] update navigation protocol
[x] code page toggle/navigation
[x] update svgs
[x] update dropdown toggle
@output 📦 navbar_v0.0.7 from comment

[x] update navbar_v0.0.7

@input 📦 navbar_v0.0.7
[x] updated - background pattern
@output 📦 navbar_v0.0.8 from comment

...

[ ] finalize navbar

@output :question: navbar_v?.?.? from comment

next #4

tasks - 2023.05.20

code - navbar component   - 1h06min

add all the buttons into the navbar
@output 📦 navbar_v0.0.1

update navbar_v0.0.1

update the navbar to be mobile first and responsive - 1h48min
create and update tasks, worklog etc  - 6min
@output 📦 navbar_v0.0.2

worklog

feedback

created navbar components
updated navbar component to be responsive and mobile first

proposal

feedback 2023.05.19
code looks good. i linked the issue above to its parent issue. output should be used in page component issue as an input and also listed in dat-website issue. the issues all need some updates, but if you accept the invite you should hopefully be able to edit the issues.
otherwise

the code isn't yet in standardjs style (e.g. 2 spaced + function fn_name () { } instead of function fn_name(){ }
require('buttons') instead of require('../buttons/index.js') is why we use /src/node_modules/buttons as folder structure
per navbar instance we create, there should be just one style sheet, so it should be like:

const buttons = require('buttons')

module.exports = navbar

// CSS Boiler Plat
const sheet = new CSSStyleSheet
const theme = get_theme()
sheet.replaceSync(theme)

function navbar () {
  const el = document.createElement('div')
  const shadow = el.attachShadow({ mode: 'closed' })

  // ...

}

tasks - 2023.05.26

update navbar_v0.0.3

update the code links - 17min
read feedback - 2min
code navbar toggle - 23min
create and update tasks, worklog etc  - 6min
adding all the icons with navbar, window_bar etc - 1h52min
passing all the states to icon_button component - 41min
create and update worklogs and task - min
@output 📦 navbar_v0.0.2

worklog

feedback

created navbar components
updated the project structure
added navbar toggle function
added proper path of icon images
pass all the icon_button states and toggle function

proposal

tasks - 2023.06.03

update navbar_v0.0.3 - 1h33min

code theme protocol for navbar
create - worklog comment, and task- 10min
@output 📦 navbar_v0.0.4

worklog
worklog-149
worklog-150

feedback

proposal

feedback 2023.06.08
regarding navbar buttons
icons should be svgs, agree,makes it more flexible and themeable,lets convert
could we make the "dat ecosystem" black with green font
but all other buttons green with black font?
=> that way the hexagon leaf logo sticks out more compared to green on green

we need a "hover" color or pattern, maybe:

we need an "active" color or pattern, maybe:

...for example, but of course with our exact pink, not some random pink :P

tasks - 2023.06.17

update navbar_v0.0.4

update theme protocol - 40min
update logo button
create - worklog comment, and task- 19min
@output 📦 navbar_v0.0.5

worklog
worklog-154
worklog-155

feedback

proposal

tasks - 2023.06.23

update navbar_v0.0.5 - 28min

update - navbar events and responsiveness
create - worklog comment, and task- 18min
@output 📦 navbar_v0.0.6

worklog
worklog-157

feedback

proposal

tasks - 2023.07.06

update navbar_v0.0.6

update navigation protocol - 2h
code page toggle/navigation - 1h
update svgs
update dropdown toggle
create - worklog comment, and task- 14min
@output 📦 navbar_v0.0.7

worklog
worklog-160

feedback

proposal

tasks - 2023.11.11

update navbar_v0.0.6 - 32min

updated - background pattern
create - worklog comment, and task - 8min
@output 📦 navbar_v0.0.8

worklog
worklog-181

feedback

proposal

tasks - 2023.12.08

update navbar_v0.0.8

updated - protocol and change highlight - 25min
create and update tasks - 5min
@output 📦window_bar_v0.0.9

worklog
worklog-186

feedback

proposal

Grat job,
I am noticing we hve our main links to the socials still inactive, so let's add these too:

they should open in a new tab
BLOG https://blog.dat-ecosystem.org/
Discord https://discord.com/invite/egsvGc9TkQ
Twitter https://twitter.com/dat_ecosystem
Github https://github.com/dat-ecosystem

tasks - 2023.12.20

update navbar_v0.0.9

added social links - 33min
create and update tasks - 5min
@output 📦 navbar_v0.0.10

worklog
worklog-188

feedback

proposal

tasks - 2023.12.29

update navbar_v0.0.10 - 19min

updated protocol to toggle terminal
create and update tasks - 5min
@output 📦 navbar_v0.0.11

worklog
worklog-190

feedback

proposal

tasks - 2024.01.13

update navbar_v0.0.11

updated the active status bug on terminal command
@output 📦 navbar_v0.0.12

worklog
worklog-191

feedback

proposal


Add tests and update property

Related https://github.com/graphql/graphql-js/pull/2786#issuecomment-702230485

@ardatan Thanks a lot, looks great 👍
@ForbesLindesay Can you please merge it?
Alternatively, I manually add it to your PR tomorrow if you don't mind?


Use functional composition to log azure resource creation

Codecov Report

Merging #100 into master will not change coverage.
The diff coverage is 0%.

@@            Coverage Diff            @@
##             master     #100   +/-   ##
=========================================
  Coverage     41.83%   41.83%
  Complexity      146      146
=========================================
  Files            59       59
  Lines           772      772
  Branches         45       45
=========================================
  Hits            323      323
  Misses          419      419
  Partials         30       30

Impacted Files
Coverage Δ
Complexity Δ

...gration/eventhub/DefaultEventHubClientFactory.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

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


update: Dev Journey video links + general fixes

Thank you for your contribution to the IC Developer Portal. This repo contains the content for https://internetcomputer.org and the ICP Developer Documentation, https://internetcomputer.org/docs/.
If you are submitting a Pull Request for adding or changing content on the ICP Developer Documentation, please make sure that your contribution meets the following requirements:

[ ] Follows the developer docs style guide.
[ ] Follows the best practices and guidelines.
[ ] New documentation pages include document tags.
[ ] New documentation pages include SEO keywords.
[ ] New documents are in the .mdx file format to support the previous two components.
[ ] New documents are registered in /sidebars.js, otherwise, it will not appear in the
side navigation bar.
[ ] Make sure that the .github/CODEOWNERS file is
filled with new documents that you added. This way we can ensure that future Pull Requests are reviewed by the right people.

@jessiemongeon1 thanks for providing a PR so quickly!
there is one thing more you should clarify in the journey:

according to the guide, the webpack.config.js is automatically created by dfx. I just played the tutorial again after your adjustments and this doesn't seem to be true -> the user also needs to create the webpack.config.js in the root "manually"


Add CORS to webserver.

Hi,
I currently use the carp webserver server behind a nginx reverse proxy. Due to the fact that express doesn't do well without the CORs package even if specified in the nginx config. I have to add it myself everytime I do a fork sync to a new release.
I was wondering if you guys would be willing to add it, if I submitted a simple PR to include cors in the carp webserver server.
Below are two files where the change would happen, package.json to include cors and its types and in the index.ts to pull it in and have express recognize it.
https://github.com/onchainapps/carp/blob/7c21ca5810fae78bc61492022ff8717feac3fa18/webserver/server/package.json#L43
https://github.com/onchainapps/carp/blob/7c21ca5810fae78bc61492022ff8717feac3fa18/webserver/server/package.json#L47
https://github.com/onchainapps/carp/blob/7c21ca5810fae78bc61492022ff8717feac3fa18/webserver/server/app/index.ts#L11
Thank you.
Mike

Seems latest version of express corrects this issue on its own.


Silent Aimbot

I have some quick questions about the silent feature of the aimbot:
Is it perfect silent - as in do spectators / over watchers see the snap to the enemy?
Thanks

After running a couple tests I have come to believe it is perfect silent but would like to know what anyone else thinks

There is no such thing as pSilent anymore, silent aim is completely clientside.

There is no such thing as pSilent anymore, silent aim is completely clientside.

Ah OK, so to check if it looks legit can you watch replays / demos? Or will that still not show what it looks like on OW / to spectators

There is no such thing as pSilent anymore, silent aim is completely clientside.

Ah OK, so to check if it looks legit can you watch replays / demos? Or will that still not show what it looks like on OW / to spectators

watch the demo whilst using silent aimbot, it will snap ur aim

There is no such thing as pSilent anymore, silent aim is completely clientside.

Ah OK, so to check if it looks legit can you watch replays / demos? Or will that still not show what it looks like on OW / to spectators

watch the demo whilst using silent aimbot, it will snap ur aim

i watch demo, and it looks completely silent for me. my friend using Osiris, and when he shoot the enemy the bullet hit the nearest target but i dont see any snap back to crosshair.

There is no such thing as pSilent anymore, silent aim is completely clientside.

Ah OK, so to check if it looks legit can you watch replays / demos? Or will that still not show what it looks like on OW / to spectators

watch the demo whilst using silent aimbot, it will snap ur aim

I've only tried it at like 1 fov or so, and that seems fine so will test at a higher amount some time

There is no such thing as pSilent anymore, silent aim is completely clientside.

Ah OK, so to check if it looks legit can you watch replays / demos? Or will that still not show what it looks like on OW / to spectators

watch the demo whilst using silent aimbot, it will snap ur aim

i watch demo, and it looks completely silent for me. my friend using Osiris, and when he shoot the enemy the bullet hit the nearest target but i dont see any snap back to crosshair.

Yeah same, but I use 0.5 to 1.2 fov max with it as I only really need a very slight assit

0.5 fov is the minimum i go for. Anything above 1 fov is blatant and too consistent. if you want to go for 1 fov and above go for silent aim = disabled, bone = nearest, smooth = 2, and between shots = disabled. Snappy sometimes so I don't recommend.

Osiris.zip

my configs

Osiris.zip

no one asking for your config, but ok


fix(ci): correct plugin reference

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


added boolean methods to option helper

these methods provide easier access to bools inside the options.
also added a method for considering empty strings as nil.

👍👍👍👍👍👍👍👍 great!


added option to set default shell globally

Current Behavior

Use global default shell in publish-crates.yml workflow
Proposed Changes
added deafult shell option in workflow file

Checks

[ ] All commits in this Pull Request are signed and Verified by Github.
[ ] All commits in this Pull Request follow the Ockam commit message convention.
[ ] I accept the Ockam Community Code of Conduct.
[ ] I have accepted the Ockam Contributor License Agreement by adding my Git/Github details in a row at the end of the CONTRIBUTORS.csv file in a separate pull request to the build-trust/ockam-contributors repository.

One last bit @RishiKumarRay
To merge PRs in our repository, we require you to accept our CLA.  To accept the CLA, please send a different pull request to our contributors repository indicating that you accept the CLA by adding your Git/Github details in a row at the end of the CONTRIBUTORS.csv file.
We also have a commit message convention which is key to how we generate our changelogs.

Hi @metaclips added , please check
https://github.com/build-trust/ockam-contributors/pull/172

Thanks for an amazing PR @RishiKumarRay we should get it merged now.
We noticed that there was a mail mismatch, the email indicated in this PR https://github.com/build-trust/ockam-contributors/pull/172<EMAIL_ADDRESS>points to a different account  https://github.com/Rishirai7 we were able to use a mail recognised by GitHub https://github.com/build-trust/ockam-contributors/commit/1471b45183d28a69ad0919aec110b8c84df168d3. Can you please sign another CLA with your GitHub recognised email. Thanks.


Display the slide feedback in the slides

@DanBotero Could you please elaborate on this a bit?

We have a feedback widget which allows the user to send us feedback.
Right now messages are saved, but there's no good way to retrieve it.
The task is to fetch a list of messages for from FireBase and display below the form.
Only messages filed for the specific slide should be displayed.

fixed


push() on parallel & sequence

var db = crud.parallel();
db.push(db2);
db.push(db3);
```

implemented as add and remove


aerostack2: 1.0.0-3 in 'humble/distribution.yaml' [bloom]

Increasing version of package(s) in repository aerostack2 to 1.0.0-3:

upstream repository: https://github.com/aerostack2/aerostack2.git
release repository: https://github.com/ros2-gbp/aerostack2-release.git
distro file: humble/distribution.yaml
bloom version: 0.11.2
previous version for package: 1.0.0-2

aerostack2

No changes

as2_alphanumeric_viewer

No changes

as2_behavior

No changes

as2_behavior_tree

No changes

as2_behaviors_motion
* Merge pull request #195 <https://github.com/aerostack2/aerostack2/issues/195> from aerostack2/add_follow_reference_behavior
  Follow reference typos fix
* typos fix
* Merge pull request #193 <https://github.com/aerostack2/aerostack2/issues/193> from aerostack2/add_follow_reference_behavior
  Add follow reference behavior
* clang test passes, format changes, new individual launcher
* feedback fixed
* removed gdb from compiling
* new behavior created and tested, modify tbd
* Merge pull request #176 <https://github.com/aerostack2/aerostack2/issues/176> from aerostack2/175-as2_behaviors_motion-land-behavior-not-loading-land-speed-condition-parameter
  Loading parameters in land behavior fixed
* fixes #175 <https://github.com/aerostack2/aerostack2/issues/175>
* Merge pull request #163 <https://github.com/aerostack2/aerostack2/issues/163> from aerostack2/crazyflie_swarm_demo
  Crazyflie swarm demo updates
* Merge pull request #160 <https://github.com/aerostack2/aerostack2/issues/160> from aerostack2/trajectory_generation
  Change trajectory generator name
* Demo cf swarm updates
* Change trajectory generator name
* Revert "Change trayectory generator"
  This reverts commit fe17ea3f0a5ef1eb377e0779359bd75dc8c3212d.
* Change trayectory generator
* Merge branch 'main' into aruco_detect
* Merge pull request #156 <https://github.com/aerostack2/aerostack2/issues/156> from aerostack2/go_to
  [as2_behaviors_motion] Change goto to go_to
* Change goto to go_to
* Merge pull request #152 <https://github.com/aerostack2/aerostack2/issues/152> from aerostack2/151-as2_behaviors_motion-follow-path-launch
  Stripping whitespaces in launch file name
* stripping whitespaces in launch file name
* rename movement_behavior launcher into motion_behaviors_launcher.py
* Merge pull request #125 <https://github.com/aerostack2/aerostack2/issues/125> from aerostack2/as2_behaviors
  [as2_behaviors] Reorganize behaviors
* Behaviors motion clang test
* Reorganize behaviors
* Contributors: Javilinos, Miguel Fernandez-Cortizas, RPS98, Rafael Pérez, pariaspe

as2_behaviors_perception
* Merge branch 'main' into trajectory_generation
* Merge pull request #157 <https://github.com/aerostack2/aerostack2/issues/157> from aerostack2/aruco_detect
  [as2_behaviors_perception] Change aruco_detector to detect_aruco_marker
* Merge to main
* Merge remote-tracking branch 'origin/aruco_detect'
* Change auro detector to auro_detect
* Merge pull request #125 <https://github.com/aerostack2/aerostack2/issues/125> from aerostack2/as2_behaviors
  [as2_behaviors] Reorganize behaviors
* Reorganize behaviors
* Contributors: David Perez-Saura, Miguel Fernandez-Cortizas, RPS98, pariaspe

as2_behaviors_platform

No changes

as2_behaviors_trajectory_generation
* Merge pull request #183 <https://github.com/aerostack2/aerostack2/issues/183> from aerostack2/153-as2_behaviors-extra-foreach-in-cmake
  [bug] extra foreach removed
* [bug] extra foreach removed
* Merge pull request #163 <https://github.com/aerostack2/aerostack2/issues/163> from aerostack2/crazyflie_swarm_demo
  Crazyflie swarm demo updates
* Merge pull request #160 <https://github.com/aerostack2/aerostack2/issues/160> from aerostack2/trajectory_generation
  Change trajectory generator name
* Demo cf swarm updates
* Change trajectory generator name
* Revert "Change trayectory generator"
  This reverts commit fe17ea3f0a5ef1eb377e0779359bd75dc8c3212d.
* Change trayectory generator
* Contributors: Miguel, RPS98, Rafael Pérez, pariaspe

as2_cli

No changes

as2_core

No changes

as2_gazebo_classic_assets

No changes

as2_ign_gazebo_assets
* Merge pull request #174 <https://github.com/aerostack2/aerostack2/issues/174> from aerostack2/as2_simulation_assets_for_windmill_project
  [as2_simulation_assets] Windmill updates
* ground truth bridge in cmakelist was missing
* fix bug tf broadcaster
* tf broadcaster renamed to object tf broadcaster
* last changes
* stop windmill gps reference frame from rotating when blades rotate aswell
* object tf bridge added, windmill object finished
* added controller for windmill in ros2
* grass patch with sky added
* joint controller bridge added, windmill joints controllable from ros2
* added velocity controller to windmill for box
* Merge remote-tracking branch 'origin' into as2_simulation_assets_for_windmill_project
* Merge pull request #171 <https://github.com/aerostack2/aerostack2/issues/171> from aerostack2/ign_empty_gps
  [as2_ign_gazebo_assets] Add GPS coordinates to empty world
* Add GPS coordinates to empty world
* azimuth bridge added
* added gps odometry for azimuth calculation, gps bridge for windmill
* Merge pull request #145 <https://github.com/aerostack2/aerostack2/issues/145> from aerostack2/add_objects_ignition_enhancement
  Windmill + load objects with bridges
* removed windmill world
* Merge pull request #163 <https://github.com/aerostack2/aerostack2/issues/163> from aerostack2/crazyflie_swarm_demo
  Crazyflie swarm demo updates
* Demo cf swarm updates
* changes and bug fix
* deleted comments
* structural changes
* fix, check for objects in json file
* added working windmill model, added feature to load object with bridges into the world from config file
* Merge pull request #124 <https://github.com/aerostack2/aerostack2/issues/124> from aerostack2/123-ground-truth-bridge-segmentation-fault
  Ground truth bridge segmentation fault fix
* move publishers before ign subscriber
* Merge pull request #114 <https://github.com/aerostack2/aerostack2/issues/114> from aerostack2/devel
  [all] Reduce packages and update names
* Update namespace names
* Rename ignition_assets to as2_ign_gazebo_assets
* Contributors: Javier Melero, Javilinos, Miguel Fernandez-Cortizas, RPS98, pariaspe

as2_keyboard_teleoperation

No changes

as2_motion_controller
* Merge branch 'main' into aruco_detect
* Merge branch 'main' into state_estimator_plugins
* Merge pull request #158 <https://github.com/aerostack2/aerostack2/issues/158> from aerostack2/motion_controller
  [as2_controller] Change as2_controller to as2_motion_controller
* Change as2_controller to as2_motion_controller
* Contributors: Miguel Fernandez-Cortizas, RPS98

as2_motion_reference_handlers

No changes

as2_msgs

No changes

as2_platform_crazyflie

No changes

as2_platform_dji_osdk
* Merge pull request #149 <https://github.com/aerostack2/aerostack2/issues/149> from aerostack2/148-add-missing-licenses
  Updated liceses and description
* updated liceses and description
* Merge pull request #144 <https://github.com/aerostack2/aerostack2/issues/144> from aerostack2/136-as2_platform_dji_osdk-add-dji-m200-and-m300-support-using-dji-osdk
  as2 platform dji osdk add dji m200 and m300 support using dji osdk
* Use aerostack fork
  >
  >
  Co-authored-by: Miguel Fernandez<EMAIL_ADDRESS>* Remove gps utils package dependence
* Remove GeographicLib dependence
* DJI tested in simulation
* use has_new_references attribute before sending command
* 1st integration
* first iteration before sync with main
* Contributors: Miguel, RPS98, Rafael Pérez, pariaspe

as2_platform_ign_gazebo
* Merge pull request #145 <https://github.com/aerostack2/aerostack2/issues/145> from aerostack2/add_objects_ignition_enhancement
  Windmill + load objects with bridges
* structural changes
* added working windmill model, added feature to load object with bridges into the world from config file
* Merge pull request #114 <https://github.com/aerostack2/aerostack2/issues/114> from aerostack2/devel
  [all] Reduce packages and update names
* Update namespace names
* Rename ignition_assets to as2_ign_gazebo_assets
* Merge pull request #113 <https://github.com/aerostack2/aerostack2/issues/113> from aerostack2/as2_platforms_rename
  Rename platforms
* Rename platforms
* Contributors: Javilinos, Miguel Fernandez-Cortizas, RPS98, Rafael Pérez, pariaspe

as2_platform_tello

No changes

as2_python_api

No changes

as2_realsense_interface

No changes

as2_state_estimator
* Merge branch 'main' into trajectory_generation
* Merge pull request #159 <https://github.com/aerostack2/aerostack2/issues/159> from aerostack2/state_estimator_plugins
  [as2_state_estimator] Change plugins names
* Clang format
* Chnage plugins names
* Merge pull request #137 <https://github.com/aerostack2/aerostack2/issues/137> from aerostack2/main
  Sync branch with main
* Merge pull request #134 <https://github.com/aerostack2/aerostack2/issues/134> from aerostack2/71-all-include-gps-translator-functions
  GPS behavior support
* fixing gps origin earth to map tf
* set and get origin srvs created on external_odom plugin
* Merge pull request #114 <https://github.com/aerostack2/aerostack2/issues/114> from aerostack2/devel
  [all] Reduce packages and update names
* Clang format fix
* State estimator launch config file bug fix
* Update namespace names
* Merge pull request #119 <https://github.com/aerostack2/aerostack2/issues/119> from aerostack2/as2_state_estimator_unify
  [as2_state_estimator] As2 state estimator unify
* Add license header
* Unify state estimators in one package
* Contributors: Miguel, Miguel Fernandez-Cortizas, RPS98, Rafael Pérez, pariaspe

as2_usb_camera_interface

No changes

Wrong track, closing...


Datadog receiver

This adds the datadog receiver code.  The intent is we can then cut a release so customers can use this in the OCB.

Re this @MikeGoldsmith

Do we intend to try to push this back upstream into collector contrib?

Yep, absolutely. We want to have some prospects use it in anger first though, so we can tweak it here and there before contributing upstream.

@MikeGoldsmith, made updates. Let me know if there is still anything out standing.


feat(frontend): auto load erc20 user token if not enabled

Motivation
When a user converts an ERC20 token to a ckERC20 twin token, the UI needs information about the counterpart token (ERC20). For example, the user might have a CK token (e.g., ckUSDC) enabled, but its token counterpart (e.g., USDC) disabled.
As a result, the UI might lack necessary information. Notably, the balance displayed on the "How to convert" modal wizard might remain zero even if the user has effectively transferred tokens to Oisy (this is a bug that was reported).
Consequently, the user waits indefinitely and cannot proceed with the conversion unless they understand what's happening and finally figure out they should manually add the ERC20 token.
That's why this PR aims to automatically enable ERC20 tokens if required.
Source
Reported per PM and shared on Slack.
Changes

New service function autoLoadUserToken.
On openCkETHReceive proceed by calling the function first and if required enable automatically the token.
Refactor setUserToken which is now called manually and automatically.

Screenshot
"Wait for ..." remains zero for ever:

No, no, nothing, I was thinking wrongly


make docker-build always recompiles

make docker-build will always re-compile, even if there are no changes in the source code. This slows down the dev deployment process.

I suspect they're unrelated, because docker for mac always recompiles from scratch, whereas etcd/pachd data gets wiped whenever the VM is restarted.

FWIW, I think the question here is where the caching is happening. The go compiler re-uses build artifacts from ~/.cache/go-build, so even if docker-is building from scratch every time, make docker-build should be fast after its first run because the go compiler, running inside the docker container, is not building from scratch every time.

Out of curiosity, did we figure out why the go caching wasn't working in docker for mac?

TBH, no -- I just took the opportunity to do a general cleanup of the build process


[Bugfix] Add repair compaction to repair rowsets with small segments

What type of PR is this：

[x] bug
[ ] feature
[ ] enhancement
[ ] refactor
[ ] others

Which issues of this PR fixes ：

Fixes #5538
Problem Summary(Required) ：

This PR add a background thread to execute repair compaction tasks, and a web interface to submit repair compaction tasks.


adding initial mqtt support

This adds simple MQTT publishing support. You can configure an MQTT broker to which all properties will be published to.

Thank you. LGTM!


Implement a functionality of customer view in admin account, so that by just clicking on it front-end for that account will open.

Framework Version: 0.1.2

This had been implemented and will come up in the next release.


feat: allow for configurable source diretory location and selector pr…

…efix at app creation

Mostly LGTM, but I think this will fail horribly on Windows because of using / in some cases and path.sep in others...

path.sep is used mostly, the only time I explicitly use / is when creating the barrelUrl which is a browser path that systemJS is using so it should be a /
As for path.normalize I don't see that buying us anything here, and if it is a matter of validating the value of sourceDir then that should be done when we read the configuration file, so that it is consistent throughout the application.

LGTM.

@spboyer Can you take a look at this and run the tests on Windows? @Brocco needs a windows tester.
git fetch origin pull/571/head:pr571
git checkout pr571
npm i
npm test

Thanks!

@filipesilva has also dug into the windows build issue and has reported this:
import {Component} from 'angular2/core';

@Component({
  moduleId: __moduleName,
  selector: 'testproj2-app',
  templateUrl: 'testproj2.component.html',
  styleUrls: ['testproj2.component.css']
,
  directives: [ROUTER_DIRECTIVES]
})
export class Testproj2App {
}

weird comma there
also no ROUTER_DIRECTIVES import
also no routeConfig?
The code for injecting those things in can be found in:

addon/ng2/blueprints/route/index.js

I have no idea about the imports. I can't repro it on my computer and it's obviously not the problem with the Appveyor build.


HackOWASP 4.0 (March 11 - 13)

Leads : @Shubhangi0304  & @Jatinpandya26

Event Type: Hackathon
Website: https://hackowasp.live
Expected participants: 1500
atsigns expected : 2000

Activities:

[ ] Tshirt Giveaway
[ ] Treasure Hunt Campaign
[ ] Potential @mosphere pro campaign
[ ]  Session on the @ platform
[ ] Opening Note
[ ] AMA about @ Platform
[ ] Blog about the platform

[ ] Giveaway (This Weekend) - Online
[ ] Treasure hunt campaign - Potential @mosphere pro campaign
[ ] Giveaway (This Weekend) - Offline
[ ] Opening Note for us
[ ] AMA about @ Platform

*Note - Might be postponed a week late due to management issues for dates in the week hack has been planned now.

Dates of the hackathon were changed.


Install dart link change suggestion

Hi!
I suggest that the link for the automatic installation of dart on INSTALLATION.md should change from https://www.dartlang.org/install to https://www.dartlang.org/tools/sdk or to include the second link as an option too.
I recently started the dart track. I already had flutter installed on my computer, so I thought everything would worked fine but I couldn't use pub. So I went to the install dart section and followed the steps which took me to this page https://www.dartlang.org/install that suggests to install flutter, web or server. But I already had flutter installed, which wasn't enough for the dart track, and I didn't wanted to installed web or server. The right solution for me was to install the dark sdk at https://www.dartlang.org/tools/sdk.
That's why I think the link to install the dart sdk should replace the install dart link or should be added as an alternative solution.
Cheers :)
Ricky

@rickygutim Good point, I'll update it soon


Angularfire is not loading

I'm trying to run angularfire after having the plain firebase library working (used only for login so far). I'm using ionic and ionic serve is not working. I'm getting this during ionic serve:
[19:04:51]  ionic-app-scripts 0.0.44
[19:04:51]  watch started ...
[19:04:51]  build dev started ...
[19:04:51]  clean started ...
[19:04:51]  clean finished in 4 ms
[19:04:51]  copy started ...
[19:04:51]  transpile started ...
[19:04:55]  build dev failed: Cannot read property 'indexOf' of undefined
[19:04:55]  copy finished in 3.41 s
[19:04:55]  watch ready in 3.43 s
[19:04:55]  dev server running: http://localhost:8100/
In the www/build folder the html and the js file are not there so the build is not completing.
Ionic info
Cordova CLI: 6.4.0
Ionic Framework Version: 2.0.0-rc.2
Ionic CLI Version: 2.1.12
Ionic App Lib Version: 2.1.7
Ionic App Scripts Version: 0.0.44
ios-deploy version: 1.9.0
ios-sim version: 5.0.11
OS: macOS Sierra
Node Version: v6.9.1
Xcode version: Xcode 8.1 Build version 8B62

Please follow the issue template so we can better help you. It's important to know what versions of everything you are running. Feel free to open another issue that follows the template :)


feat(api): add retract_axis to OT-2 and FLEX hardware-control api

Addresses hardware-control side of RQA-997
Protocol engine & app changes will follow in #13006
Overview

Test Plan

Changelog

Review requests

Risk assessment

The only issue observed was that motion planning doesn't seem to know that the axis is already at its highest and doesn't need to move to a different point to clear all labware on deck. Pretty sure that's on the engine so will confirm and get back to you so we can merge this PR in.

Alright, verified that fixing this issue required only a protocol engine change.
So @andySigler or @ahiuchingau you can undraft this PR and merge in edge. I'll rebase by branch on top of this one.


Weekly PR

Fix #95 GetPlayDurationMillis does not take into account timeScale

@borisspektor @refaelos, it's ready to merge.

@borisspektor @refaelos, there is one more PR, this one will be closed.


Add namespace support for HashiCorp Vault

Describe the feature
HashiCorp Vault component does not have support for namespaces, which are a feature used by SaaS solutions that offer cloud-hosted HashiCorp Vault services.
This was brought up in dapr/dapr#4779 and in Discord.
Release Note
RELEASE NOTE: ADD Support for "namespaces" for HashiCorp Vault Component.

Thank you for posting this as an issue @tmacam.
Indeed we can retrieve our secret from the SaaS using this curl request:
curl --location "https://myvaultsaas.secretmgmt.mycompany.com/v1/MySecretPath/data/MySecret" --header "X-Vault-Token: s…f" --header "X-Vault-Namespace: MyNameSpace"
But I don't see anywhere in the hashicorp secret store component, a way to reference this Vault-Namespace
To further document...
Our Hashicorp provider created a temporary token given us access to their root name space and using this token I was able to retrieve their tests secrets using the dapr api:
curl http://locahost:3500/v1.0/secrets/hashicorp/bulk
However trying to use the dapr api to our assigned Vault-Namesapce = MyNameSpace results in this error:
status code 403, body {\"errors\":[\"1 error occurred:\\n\\t* permission den ied\\n\\n\"]}\n"}
Exactly the same error as if I was omitting to provide header X-Vault-Namespace in my native curl request above
So basically the feature would just allow adding into the header "X-Vault-Namespace: <vault namespace from component store>"
Thank you!

The main challenge that I foresee is the ability to test this feature. Vault is a stable component, so any new field must be tested in its certification tests. Unfortunately, the documentation for namespaces make it seem like this is a cloud-only feature, so I am unsure we will be able to test this properly using the OSS Vault server.
I can think of ways to test this regardless (forcing HTTP and bringing up a python HTTP server just to verify this header) but this would be far from ideal.

/assign

The main challenge that I foresee to implement this feature is the ability to test it appropriately. Vault is a stable component, so any new field must be tested in its certification tests. Unfortunately, the documentation for namespaces make it seem like this is a cloud-only feature, so I am unsure how we will be able to test this properly using the OSS Vault server.
I can think of ways to test this regardless (forcing HTTP and bringing up a python HTTP server just to verify this header) but this would be far from ideal.

I understand this might not be a bullet proof test but my organization can offer to test this feature as soon as it is in an alpha stage. Our provider could create additional test namespaces and we could test it against different namespaces, using different policies and/or secret path. Then on your end, you could take care of the regression testing to ensure no negative impact on existing features.
Any thing we can do to help, please let me know. We really need this feature otherwise, we will start implementing a native approach and I won't be able to justify rework just to use dapr.

@tmacam For the vault certificate test, it creates a hashicrop vault instance using docker, and then you can set the test namespaced value and get it using dapr. EnginePath test is an example.
For namespace support, from my point of view, it would be better to have component-level metadata as well that can be overwritten by request-level metadata. For each application, its namespace is more likely to be a fixed one.
For example, if I use the following component configuration, dapr adds MyNameSpace namespace for every request. And users can overwrite this value by sending a request with namespace metadata.
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: vault
spec:
  type: secretstores.hashicorp.vault
  version: v1
  metadata:
  - name: namespace
    value: "MyNameSpace"
# ...

WDYT?

I was hoping for the same. I'd rather not expose the vault namespace to the application as this would be specific to Hashicorp.
Also the existing API seems to already provide a metadata override for the namespace (see example HERE)
But I tried it in our case, and it didn't work so I don't think that "namespace" is the Vault Namespace.
Therefore that new attribute should be very explicit and ensure we do not confuse them

Thanks @tmacam  and @Taction

For namespace support, from my point of view, it would be better to have component-level metadata as well that can be overwritten by request-level metadata. (For each application, its namespace is more likely to be a fixed one.)

I agree with the suggestion of having it as a component-level metadata. I think that given how this is exposed and vended by cloud-providers, it makes perfect sense to expose this setting at a component-level.
As for having this configurable on a per-request basis, could you think of a use-case where this (per-request) would be required instead of the component-level route?

Great to hear we are on the same page. As far as I am concerned, I do not see a use case where that parameters could be overridden at the application level because to me it's a vault host specific parameter and doing so would break the agnosticism  of the API.
The name of the attribute should ensure we differentiate it from the namespace of the local cluster, so for instance it could be vault-namespace or even vault-sas-namespace
I feel bad asking but any ETA for an alpha version? Then again, we can help for testing – as our implementation is blocked for now.
And also, not sure if this is the right place but how does this change would fit with the current option of providing a namespace in the metadata like in the documented example:
curl http://localhost:3500/v1.0/secrets/vault/db-secret?metadata.version_id=15&?metadata.namespace=production
which BTW I think this example has a typo since it shows 2 ‘?’ where the 2nd one should be replaced by ‘&’

As for having this configurable on a per-request basis, could you think of a use-case where this (per-request) would be required instead of the component-level route?

@tmacam The main concern is that users may have multi namespaces for one application. But I am not an end user, I am inclined to have a component level that is enough. We needn't support per-request level metadata unless there is any end users ask to.
As @Kreestyan seems to be an end user, is there any use case that you will use different namespaces in the same application?

As @Kreestyan seems to be an end user, is there any use case that you will use different namespaces in the same application?
We only need it to be defined at the secret component store level. I do not see any use case where this value would have to be overridden by the application.

The name of the attribute should ensure we differentiate it from the namespace of the local cluster, so for instance it could be vault-namespace or even vault-sas-namespace

Good point. And prefixing with vault would be consistent with other vault properties naming.

I feel bad asking but any ETA for an alpha version? Then again, we can help for testing – as our implementation is blocked for now.

I don't think this will make to 1.11. But if I made it in a branch of mine could you test it?

And also, not sure if this is the right place but how does this change would fit with the current option of providing a namespace in the metadata like in the documented example: curl http://localhost:3500/v1.0/secrets/vault/db-secret?metadata.version_id=15&?metadata.namespace=production

which BTW I think this example has a typo since it shows 2 ‘?’ where the 2nd one should be replaced by ‘&’

Could you cut an issue under dapr/docs for this and cc me to it? I think there are multiple issues with that document honestly:

The multiple ? in that URL. That is wrong. :P
That example URL is problematic in multiple ways. I guess it is a made up example that was not even tested and I guess its intent was to show how to provide metadata using the HTTP interface to a hypotetical secret store that supported those features (namespace and versions). But it is an unfortunate one because it is showing features that no secret store currently support at the same time.

We do not support namespaces on vault. But we do support versioning on vault.
We do support namespace in k8s secrets, but we do not support versions** in k8s secrets.

So it could be something as simple as 2808, which is available on my branch on https://github.com/tmacam/dapr-components-contrib/tree/VaultNamespace. Now: I haven't tested it yet.

I feel bad asking but any ETA for an alpha version? Then again, we can help for testing – as our implementation is blocked for now.

I don't think this will make to 1.11. But if I made it in a branch of mine could you test it?

I can definitely volunteer to test it. Will I have to build a local dapr or can I install an alpha version with helm? If the former, I may need some directions to build the project and and have it running and tested on my local laptop,

which BTW I think this example has a typo since it shows 2 ‘?’ where the 2nd one should be replaced by ‘&’

Could you cut an issue under dapr/docs for this and cc me to it? I think there are multiple issues with that document honestly:

I created a new issue #3353
Thank you!

So it could be something as simple as #2808, which is available on my branch on https://github.com/tmacam/dapr-components-contrib/tree/VaultNamespace. Now: I haven't tested it yet.

I just had a quick look at the changes, they look exactly to what I was expecting. I do believe that it is indeed an easy and low risk change as if one does not use that metadata, I don't see how it could break the other ones.

Hi All,
Do we have any update on when this change might be available in an alpha release? Our dapr deployment is on hold because of this.
Thank you

@Kreestyan , could you follow https://github.com/dapr/dapr/blob/master/docs/development/developing-dapr.md and deploy the changes from my branch in your test cluster to verify this works? This vault is a stable component, I can't submit a half-done feature as a PR for it until it is completed, and I can't complete without proper testing.

Also, one additional note to those following this issue, from Vaults documentation on https://developer.hashicorp.com/vault/docs/enterprise/namespaces#usage

Alternatively, the fully qualified path can be provided without using the X-Vault-Namespace header. In either scenario, Vault will construct the fully qualified path from these two sources to correctly route the request to the appropriate namespace.
For example, these three requests are equivalent:

Path: ns1/ns2/secret/foo
Path: secret/foo, Header: X-Vault-Namespace: ns1/ns2/
Path: ns2/secret/foo, Header: X-Vault-Namespace: ns1/

So just prepending your namespace to enginePath should unblocking you while a proper fix is released.
In the meantime I would appreciate if anyone could report if the fix I have proposed in my branch/PR works with either enterprise or HCP. Namespaces is not available in vault OSS version so all I can do is "reproduce what they document" sort of tests.

Also, one additional note to those following this issue, from Vaults documentation on https://developer.hashicorp.com/vault/docs/enterprise/namespaces#usage

Alternatively, the fully qualified path can be provided without using the X-Vault-Namespace header. In either scenario, Vault will construct the fully qualified path from these two sources to correctly route the request to the appropriate namespace.
For example, these three requests are equivalent:

Path: ns1/ns2/secret/foo
Path: secret/foo, Header: X-Vault-Namespace: ns1/ns2/
Path: ns2/secret/foo, Header: X-Vault-Namespace: ns1/

So just prepending your namespace to enginePath should unblocking you while a proper fix is released.
In the meantime I would appreciate if anyone could report if the fix I have proposed in my branch/PR works with either enterprise or HCP. Namespaces is not available in vault OSS version so all I can do is "reproduce what they document" sort of tests.

Hi, I tested this, and YES, it worked. So now I don't know... to me it is good enough. Not sure why our Hashicorp SME did not mention that earlier. So happy, to finally get dapr talking to my Hashicorp vault!!! Thank you so much.


Table constraints are not shown when expanding a table, neither are the included in generated sql.

SQL Operations Studio Version: sqlops 0.24.1 (dbb421f5033405236bb43a14fc2ac1dd87a36b43, 2017-12-19T08:48:53.957Z)
OS Version: Darwin x64 17.3.0

I am connecting to a sql server linux docker image (on a nonstandard port, 1434) running inside a local Mac Docker (17.12.0-ce-mac45 (21669) ).
When I expand tables to inspect constraints, no constraints are shown (Keys, Triggers, Indexes, and Statistics all work)
If I right-click a table, and select "Script as Create", the generated SQL does not contain contstraints as well.

@stroiman I fixed the issue with script didn't include indexes, triggers ... in my PR in the sqltoolsservice but I cannot repro the other issue you're talking about. When I expand the table node in the object explorer, I can see the indexes and keys, constraints and everything else. can you please confirm if you still see the issue and if you can then please send me the script to create the table (including all the keys and indexes ...) Thanks

I'm seeing the same behavior

Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) Developer on Windows 10
SQL Operations Studio 0.25.4

After I run
DROP TABLE IF EXISTS b CREATE TABLE b (     id INT IDENTITY(1,1) PRIMARY KEY     ,value INT     ,fk INT  NOT NULL DEFAULT 0 )
the Constraints branch is empty. In SSMS I can see the constraint.

@llali I just downloaded the latest SQL Operations Studio, 0.25.4 - and I am still seeing this issue, easily reproducible with the script @bciesielski provided.

@stroiman yes I was able to repro it. DEFAULT Constraints are not loaded correctly for table when expanding Constraints. I'll create a separate bug for it

#627


Fix track_comments view.

feeds.views.track_comments will cause an unexpected comments-count update, see in Issues #113.
To solve this, server better judge if feed has any comments before response to client, because client is not easy to judge if the response is a hint or user's comment (regular expression may not good idea). So when a feed doesn't has comment, server will return 0 and client will not overwrite document.
I'm new to web development, @sebastian-code any good suggestions?

Coverage decreased (-0.1%) to 75.292% when pulling 184553363b6a32dcc2791c933e4ac784dec43a85 on rthel:rthel-patch-feeds-comments into 9c04aa10541393e5b865185684832e9ef4eebac2 on vitorfs:master.

Hi @rthel Why are changing the two files? It appears to me than both changes aim to the same issue, so I think than we only need to change just one of those (I would prefer to change the view because I'm biased always to backend, but thats me)

Merged.


Update Jackson version

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@14dbe91). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master       #2   +/-   ##
=========================================
  Coverage          ?   80.48%
  Complexity        ?       16
=========================================
  Files             ?        1
  Lines             ?       41
  Branches          ?        4
=========================================
  Hits              ?       33
  Misses            ?        4
  Partials          ?        4

Continue to review full report at Codecov.

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


New projects no longer work with current instructions

With the introduction of commit ce82efb1c626d5c4b344c3369cd991092920c0ea, the current instruction of

Make sure to add:
|> Code.eval_file(".elchemy.exs").init
to your mix.exs file as the last line of the project() function.

is no longer sufficient.
elchemy new myapp does not generate a :name atom in the project keyword list, so line 6 in the .elchemy.exs file  if !project || !project[:name] do will always fail.
Some possible fixes:

The warning message should reflect that the project keyword list should contain a :name and the instructions updated

the requirement should be dropped

elchemy new myapp` should generate the :name

the value of :app turned into a string and added to the projects keyword list as :name in ElchemyInit.init function

Good call @deke. Mentioned in a PR, how about checking for :deps instead. I don't think it's possible to create a project without deps field in it.

Fix released in 0.7.3


connect or subscribe don't get callbacks when in thread other than main

Is there a specific reason why the connect and subscribe functions don't work properly when thrown on a background thread?
Thanks.

Same here

here also i am facing that issue.any other solution for that.


The validation loss and accuracy

I use the framework to train a RGB image dataset, the train loss is decreasing and the accuracy is increasing, but the validation loss is decreasing at first, then the loss is increasing, what's the reason? Thank you very much!

Hi @lgbwust , this is not exactly a Keras related issue. You are likely overfitting on your training set. The [user forum] would probably be a better place for this.

https://en.wikipedia.org/wiki/Overfitting


Blender lockup and endless IPR refreshing

Ran into a possible bug.  Started up an IPR session and tried to change a material from LMDiffuse to PxrDisney while it was running.  Blender locked up and the 'it' window started a loop where every 2nd pass it would perform a full refresh, and it never stopped.  Even after three minutes it was still going.  This happened when I tried switching to regular PxrDiffuse as well so it' not isolated to the Disney BXDF.  File size is 50MB so it's not too realistic to post it here.
using the latest PRMan for Blender download, RenderMan 20.6 and Blender 2.76b.

Ok we'll see if we can reproduce in a simple scene.

This is not reproducible on my end with a simple scene (or even with a 200MB scene.) I did get Blender to freeze until IT finished rendering but after that the material did change. jdent02 could you provide some more information on the object that you used (what properties type etc.)?

Also if you could give a basic setup... like if there's parented objects, or materials shared or multi -material objects....

It's the ISS mesh from BlendSwap.  It is comprised of numerous modules that are parented together and by default they all use the same material datablock.  Also there are several objects that use the same mesh datablock (the main solar foils being a prime example).  Now that I dig into it more, the hierarchy of this file is more complex than a typical .blend so maybe I will post it, as it seems to be generating some unique behavior from the plugin.

ISS_Mesh_Only.zip
Here you go.  Forgot I could ZIP it.  I just tried it again and it still generates the error.

I've tracked down where the IT multi-refresh is coming from. Turns out the fact that most of the station geometry is multi-user is causing the re-render to try and update the scene over and over. This behavior can be replicated by Alt-D (link copying) copying a cube about five times.

Actually after letting this effect propagate for about 40 times (or so) the entire space station is updated. Not the idea behavior I know, but Blender does eventually become unfrozen after refreshing for each link of data.

So it might be something that we're stuck with?

Not necessarily. I need to look into some things. This might not get fixed until after Christmas depending on how much trouble it is to correct.

With prman, There are two basic edits to materials.
One where you edit the material network (which is what you do when you change from Disney to Diffuse) and the network must be rebound to all gprims that it is attached to.  So you're not really endlessly looping just a bunch of edits
Another where you just change a parameter.  That can happen globally once.
Anyway I think the issue is that we could batch the rebind edits all to one and then flush the edits.

Going to call this closed for now.


CFT

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
I just want to option out my phone was tampared with
What part(s) of the article would you like to see updated?
I just want to option out my phone was tampared with
Additional information
I just want to option out my phone was tampared with

در تاریخ چهارشنبه ۲۲ دسامبر ۲۰۲۱، ۱۴:۲۶ Cgju @.***>
نوشت:

Code of Conduct

I have read and agree to the GitHub Docs project's Code of Conduct
https://github.com/github/docs/blob/main/CODE_OF_CONDUCT.md

What article on docs.github.com is affected?
I just want to option out my phone was tampared with
What part(s) of the article would you like to see updated?
I just want to option out my phone was tampared with
Additional information
I just want to option out my phone was tampared with
—
Reply to this email directly, view it on GitHub
https://github.com/github/docs/issues/13316, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AW4BNFRC5QKWTOBGKMJSUXDUSGVHVANCNFSM5KSIXJYA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


[POSIX] Add Regex to POSIX

[ ] Add Regex to POSIX module using the implementation in https://github.com/ZewoGraveyard/POSIXRegex.
[ ] Improve the API

https://github.com/Zewo/Zewo/pull/168


Delay Http2ConnectionPrefaceAndSettingsFrameWrittenEvent by one Event…

…Loop tick when using the Http2FrameCodec
Motivation:
We should delay the firing of the Http2ConnectionPrefaceAndSettingsFrameWrittenEvent by one EventLoop tick when using the Http2FrameCodec to ensure all handlers are added to the pipeline before the event is passed through it.
This is needed to workaround a race that could happen when the preface is send in handlerAdded(...) but a later handler wants to act on the event.
Modifications:
Offload firing of the event to the EventExecutor.
Result:
Fixes https://github.com/netty/netty/issues/9432.

@Bennett-Lynch PTAL... I did not find a better way for now :/

Thanks for the fix, @normanmaurer.
I assume there is some non-zero latency incurred with this approach?
If so, would it make more sense to make the Http2FrameCodec lookup inside of Http2MultiplexHandler be lazily initialized on the first read/write, rather than at insertion time?

@Bennett-Lynch it should not really matter much as it will just put the task at the end of the task queue and pick it up while processing all events. So it is not an extra wakeup etc.

Got it, thanks.  LGTM.


Add isotropic thermal conduction and RKL2 supertimestepping

New features

Added support for isotropic thermal conduction
Separated configuration of "isotropic/anisotropic" flux with "constant/Spitzer" coefficient
Support for second-order, RKL-based operator split diffusive terms (in addition to unsplit fluxes)

Open items

[x] Add more doc

It looks like this also adds a new reconstruction method. Would it make sense to split that off into its own PR? or is that needed for the test problems here?

That recon is already in main. I need to rebase this branch.

@forrestglines @BenWibking I just fixed the tests and updated to latest main.
In other words, this is ready for review ;)


Enable TLS PKI in the Docker Compose example

This PR closes #60

This change is

Reviewed 14 of 14 files at r1.
Review status: 12 of 14 files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Reviewed 2 of 2 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Reviewed 1 of 1 files at r3.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Reviewed 1 of 1 files at r4.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Reviewed 4 of 4 files at r5.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Reviewed 1 of 1 files at r6.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

All test are passing now.


Remove this comment

https://github.com/Mirajkam/Pomofocus/blob/77e27ec24efdd3ac8e46a912f7088287efc051fe/frontend/src/app/types.ts#L1
As stated in title. Also name the folder to models and file to User.ts

I would like to work on this issue.


Cant log into snapchat

What do i suppose to do to log back in my snapchat

Boy, check the other opened issues

Boy, check the other opened issues


App Config Labels

The app config module does not use the delimiter properly so labels are not passed.  This will cause different app config clients to have 404s when querying for values if no label is present

Closing as not active.


Added problem related to sliding windows blog

Fixes #389
Added problems related to sliding window problem blogs

Hey @subhadipbhowmik, can you kindly check this PR and merge it accordingly?

Hey @subhadipbhowmik, can you kindly check this PR and merge it accordingly?

Just wait a while.


iPadOS rendering issues while multitasking

Things that sometimes happen when switching to the app:

workspace not rendered at all
tab strip not rendered or flickers

https://discord.com/channels/1014184997751619664/1288694029889830973/1288701227802165248

dupe of https://github.com/lockbook/lockbook/issues/2765


MTV-70: CBT workaround

https://issues.redhat.com/browse/MTV-70
Add CBT bug and workaround to Known Issues.
Preview: https://deploy-preview-156--forklift-documentation.netlify.app/documentation/doc-migration_toolkit_for_virtualization/master/#known-issues_forklift

Looks good to me


Create Spaces [16]

Description
As a user, I want to create projects from the system. A project is a higher context for work items and other data in the system. A work item always "belongs" to exactly one project and all data in the system is always displayed in the context of a specific project. Projects are "owners" of work items and work item links.
Functional Acceptance Criteria

The user can create a project from the "create project" view.
Creating a project requires a name (alphanumeric value).
It is not possible to create a project with an empty name.
Projects are working in a way that users in the system are global and can be associated with more than one project (will be a later story).
Projects are working in a way that cross-linking of work items between projects is possible (will be a later story).

Note: as mentioned above, users are "global" to the system and can be "member" of more that one project at the same time. This is not a direct functional requirement, but a hint for design decisions.
Note: projects are "owners" of work items and work item links. Work items and projects should be designed that cross-linking of work items between projects are possible later. TBD is the ownership of the work item link instance on cross-linked work items. This is not a direct functional requirement, but a hint for design decisions.
Note: on the scope of this story: as part this story, we will extend our object model by introducing a 1:n relationship between the newly created "project" and work items. On the back end, we will have to introduce a CRU(D) service for projects and extend work item creation with a mandatory "project" parameter. How that parameter is passed and stored needs to be discussed as part of implementation.
The front end needs to add UI to create a new project and introduce the notion of a "selected" project that is passed when creating a work item. As part of migration, we will have to create a default project and assign all existing issues to that project.
Out of scope (explicitly not addressed by this user story): authorization, orgs, teams, areas, configuration of process for a project (WI types, etc.) and moving work items between projects.
Non-functional Acceptance Criteria

The "create project" view is easily accessible from anywhere in the system UI.
Creating a project adds the new project in-place to the project selector.
The result of the implementation of this story should also be a basic data model and a concept for organizing projects and other entities.

Dependent Stories

Userstory #358

Tasks

Create Repository for project crud(l) #509
Create API Endpoint for project crudl #510
Update work item create/update to include optional "project field" if empty, assign to a default project
*migrate all existing work items to default project #511
Update search services (wi list and @searchrepo) to allow filtering by project #512
Make project field in work item create/update mandatory

this can be done once the front end is ready to pass a project with work item create/update (#358)

Not in Planner scope.


Allow ln-dlc-node tests to be skipped on bors

Bors treats skipped required jobs as failed. We want to be able to selectively skip certain tests in ln-dlc-node because they're slow.
We define a new job whose only purpose is to report a job success to bors whether the run-tests-ln-dlc-node job is skipped or succeeds.

Gonna bors this to see if it works.
bors r+

bors retry

bors r+

bors ping

bors ping

bors retry

bors r+

Have you considered using a pattern like the one we used in the POC?
We checked against not containing failure for the results of the jobs as far as I understand:
https://github.com/get10101/10101-PoC/blob/main/.github/workflows/ci.yml#L152-L166

I think the problem is that the name of the outputs is not aligned with the name used for checking the result.
The name of the output in changes is defined as ln-dlc-node - I think this is what we have to use as name for checking on the outputs in tests-ln-dlc-node.
I'll add a fixup, let;s see if that fixes it :)

OK, no point in adding a fixup here :D
I force pushed it with the changes - will try to bors it

bors r+

I think the outputs.result might also be wrong in this context - it might just be .result here, because we select the output by name already. If it fails that's the next thing I would change :)

bors retry

bors r+

I think the problem is that the name of the outputs is not aligned with the name used for checking the result.
The name of the output in changes is defined as ln-dlc-node - I think this is what we have to use as name for checking on the outputs in tests-ln-dlc-node.
I'll add a fixup, let;s see if that fixes it :)

OK, this is bogus, what was there before is correct - because we are in the context the needs of tests-ln-dlc-node.
It is surprising that the version that was there did not work; one difference is that changes is not part of the needs of tests-ln-dlc-node - maybe that makes a difference? I would not see how though.

bors r+

bors retry

self approval is the best!