More explicit build instructions

@ssomers does this help, or do you think there is more we should say?
Fixes https://github.com/rust-lang/miri/issues/1306

I still don't like the two titles "Building Miri with". They are more like "Configuring the working tree for". Here's how I would arrange things:
Getting started
(new header) Preparing the working tree or Configuring the build settings
Building Miri with a pre-built rustc
(moved up) Building Miri with a locally built rustc
Building and testing
(the paragraph you added)
Fixing Miri when rustc changes
Testing the Miri driver
Testing cargo miri

Hm... I see. That makes sense.
The reason I structured things the way they are is that "with a locally built rustc" is a rare thing to do (I think), so I wanted it to be last in the docs. Your proposal as you said moves it up, putting it "in the way" of what the normal reader will need (which is "pre-build rustc" followed by "building an testing"). What do you think about that?

You're right, I guess most people don't start off with a freshly built rust working tree, and I noticed myself it's not a good idea to ignore the rust-version file and "just compile with what I have". And it's good to have a quick ramp up to a working miri. But then I don't understand why "Fixing Miri when rustc changes" comes so early, spoiling the fun before it begins.

Hm... I see. That makes sense.
The reason I structured things the way they are is that "with a locally built rustc" is a rare thing to do (I think), so I wanted it to be last in the docs. Your proposal as you said moves it up, putting it "in the way" of what the normal reader will need (which is "pre-build rustc" followed by "building an testing"). What do you think about that?

But then I don't understand why "Fixing Miri when rustc changes" comes so early, spoiling the fun before it begins.

I think I did that because I thought that might be a good on-ramping exercise for new contributors. But I do not think that any more, so I agree this should be rearranged.

I noticed myself it's not a good idea to ignore the rust-version file and "just compile with what I have"

Indeed, and somehow I hope to write the docs in a way to convey this most clearly. :)

@ssomers I did some more editing, please let me know what you think.
@oli-obk I'd also be interested in your feedback, I hope you are okay with these edits.

Yes, it makes a lot of sense to move the rustup instructions to later, this isn't what ppl will be looking for the most.

However, I am not sure if they really make sense in the "Building and testing Miri" section... they are conceptually more like setting up the build environment.

Setting up the build environment does not require users to know anything about the correct nightly. We have a toolchain file that will automatically give them the correct nightly if they use rustup. Only if you want to modify that file, you need to know about the other steps. Maybe it should just be its own section?

So what about this?

We have a toolchain file that will automatically give them the correct nightly if they use rustup.

Not exactly (as we pin by commit, not by nightly), but we have rustup-toolchain to make that happen.

@bors r+

:pushpin: Commit fedca29e6979b77db1d4712dc62be041cf7f2d36 has been approved by RalfJung

:hourglass: Testing commit fedca29e6979b77db1d4712dc62be041cf7f2d36 with merge 910afefcf66800da6c7777984da31f0db697ac70...

:sunny: Test successful - checks-travis, status-appveyor
Approved by: RalfJung
Pushing 910afefcf66800da6c7777984da31f0db697ac70 to master...


Fixed #442 - CBL Java Unit Test Failure on Jenkins build server

Because of Jenkins Linux server (I heard it is slow), the replicator becomes IDLE state before completing all replication tasks. Currently I can not reproduce local machine or Android devices.
For work around, fragile test cases are not executed on CBL Java unit test cases by checking the running environment is Android.

https://github.com/couchbase/couchbase-lite-java-core/issues/442

Log messages for failed test cases

testGoOffline https://friendpaste.com/5w33PU5Bh99efrAhNZph1V
testExcessiveCheckpointingDuringPushReplication https://friendpaste.com/5w33PU5Bh99efrAhNZpeOp


Remerge Dave's branch?

Consider remerging https://github.com/davidchappelle/AutobahnCpp

Just to throw this out there as well. If you do not feel that my fork has gone in the direction that you would like to have seen would you be open to allowing for a project renaming and copyright change?

ah, shit. yes, I still have to respond to your last mail (I now remember). I will do now.
rgd copyright change: what do you mean? switch license?

would you be open to allowing for a project renaming and copyright change?

I hope you meant adding yourself (or your company) as a copyright holder. As in:
//  Copyright (C) 2014 Tavendo GmbH
//  Copyright (C) 2015 Other Contributor
//
//  Licensed under the Apache License, Version 2.0 (the "License");
//  ...

Or, as suggested in this Q&A:
//  Original work Copyright (C) 2014 Tavendo GmbH
//  Modified work Copyright (C) 2015 Other Contributor
//
//  Licensed under the Apache License, Version 2.0 (the "License");
//  ...

@davidchappelle
Yes, Emil is right indeed. Removing the "Tavendo GmbH" line isn't something we would support, and to be honest, I don't see a reason why you would want to do that?
I would support changing the license from Apache 2.0 to MIT - but no other license. For this, we would need to ask all contributors for permission. The reason for going MIT is: Apache 2.0 is incompatible with GPL 2. We've gone through that change for AutobahnJS and AutobahnPython already.
Note that neither we (Tavendo) nor anybody else can relicense or dual-license AutobahnCpp or derivative works (as any AutobahnCpp fork): for this we would have needed a contributor license agreement signed by all contributors before merging any code - and we (deliberately) haven't done that.

Now to the technical matter .. following up on our discussion here https://groups.google.com/forum/#!topic/wampws/GryF1YHc_go
I think I can get over the splitting up into many small files;) I don't like it a lot, but so what. Works.
The main concern for me is really the public API. Rereading the thread and the actual code in the fork, I don't get it:
You say, boost::any does malloc even on an integer. that's generally to be avoided (any malloc) if possible and sane. I follow that completely.
You say msgpack::object is a variant type just by accident also provided by the msgpack library, and does not "leak" msgpack as the only serialization possible into the public API. I can follow that argument - and would be totally convinced if there would be a second supported serialization format. If so, the we would just say: msgpack::object is better than boost::any, but under the hood, msgpack::object could be filled from JSON as well (which would then probably use a JSON library just serializing to msgpack::object
What I don't get is: https://github.com/davidchappelle/AutobahnCpp/blob/master/examples/caller.cpp#L68
This is a plain old STL container. I thought the public API is about msgpack::object? Or is that magically coerced from STL tuple to msgpack::object?

@ecorm : on a higher level, I am slightly concerned about the "proliferation" of user options with for C++ clients.
I mean, recently s.o. announced work on WAMP/C++ for Qt. This is fine, as it strives to deeply integrate into the Qt event loop.
Boost/ASIO is another event loop vastly different - so it probably deserves it's own WAMP library.
But CppWAMP also is based on ASIO (only)?
IOW: should we really move forward with like 3 flavors of WAMP client library based on ASIO? Just thinking loud here ..

@oberstet Remember that I had originally considered contributing to Autobahn|Cpp, as per this group discussion. I had concluded that we had different design philosophies, and "negotiating" changes to the Autobahn|Cpp API would take too much time.
I didn't realize it the time, but the experimental nature of boost::future ended up being a deal breaker for me. I now prefer the callback and co-routine based API of CppWAMP. And CppWAMP is architected in a way that a future-based API can be easily layered on top of the async API.
I would have welcomed contributions from Dave, but he decided instead to fork Autobahn|Cpp.
I say let people freely innovate and create their own C++ implementations if they choose. Ultimately, users will vote with their feet.

Remember that I had originally considered contributing ..

Ah yeah, right;) Sorry. All of this is moving at a pace which makes it sometimes hard to follow / remember everything.

I now prefer the callback and co-routine based API ..

Fair enough. Note to self: I really have to look how co-routines are done in C++ ..

I say let people freely innovate and create their own C++ implementations if they choose. Ultimately, users will vote with their feet.

Yes, I agree. And you just remembered me of the very reason why at least 2 C++/ASIO/WAMP libs: std::future vs callbacks vs co-routines ...
My personal view: callbacks is a no go for me. I prefer std::future. BUT: co-routines, that is interesting ..

fwiw, seems like boost::coroutine is also a std proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3985.pdf - at least same author ..

Libraries
It would be nice to only have 1 C++ WAMP library based on asio. For my
purposes, coroutines were not something the engineers I am working with
were going to get behind. So unfortunately I had to rule out CppWAMP. In
the end I decided that it was best to move forward with AutobahnCpp and try
to move that project forward. Although, boost::future is still experimental
it is where STL will eventually pull its implementation from so that is a
plus.
Licensing
I was just suggesting that if my fork was not going to get merged back to
AutobahnCpp, would it be possible to rename the project so as to detach it
from AutobahnCpp. The copyright as it is now is fine.
Technical Details

I think I can get over the splitting up into many small files;) I don't
like it a lot, but so what. Works.

I like to follow the 1 class per header file rule. It helps a fair bit with
maintainability.

The main concern for me is really the public API. Rereading the thread
and the actual code in the fork, I don't get it:

You say, boost::any does malloc even on an integer. that's generally to
be avoided (any malloc) if possible and sane. I follow that completely.

Yes. Msgpack is optimized for these intrinsic use cases. Furthermore, it
does not go to the system heap for all allocations which makes its
allocations much faster.

You say msgpack::object is a variant type just by accident also provided
by the msgpack library, and does not "leak" msgpack as the only
serialization possible into the public API. I can follow that argument -
and would be totally convinced if there would be a second supported
serialization format. If so, the we would just say: msgpack::object is
better than boost::any, but under the hood, msgpack::object could be filled
from JSON as well (which would then probably use a JSON library just
serializing to msgpack::object

Msgpack actually advertises msgpack::object as an intentional variant type.
The intention is to eventually add json serialization support. Likely in
the same manner that was done for bonefish.

What I don't get is:
https://github.com/davidchappelle/AutobahnCpp/blob/master/examples/caller.cpp#L68

This is a plain old STL container. I thought the public API is about
msgpack::object? Or is that magically coerced from STL tuple to
msgpack::object?

Msgpack provides object serialization support for all of the STL container
types. Tuples, vectors, arrays, etc are represented as lists. Maps,
hashmaps, etc are represented as maps. These translate nicely to the wire
format specifications for WAMP messages. The API is templated such that it
can accept things like tuples, vectors, arrays, maps, etc. Which I find
allows the user to choose a container type that is appropriate to their
chosen data representation. Perhaps some comments and 'enable_if'
statements are needed.
On Mon, Sep 14, 2015 at 1:01 PM, Emile Cormier<EMAIL_ADDRESS>wrote:

@oberstet https://github.com/oberstet Remember that I had originally
considered contributing to Autobahn|Cpp, as per this group discussion
https://groups.google.com/d/topic/autobahnws/WzS4TZIDkZQ/discussion. I
had concluded that we had different design philosophies, and "negotiating"
changes to the Autobahn|Cpp API would take too much time.
I didn't realize it the time, but the experimental nature of boost::future
ended up being a deal breaker for me. I now prefer the callback and
co-routine based API of CppWAMP. And CppWAMP is architected in a way that a
future-based API can be easily layered on top of the async API.
I would have welcomed contributions from Dave, but he decided instead to
fork Autobahn|Cpp.
I say let people freely innovate and create their own C++ implementations
if they choose. Ultimately, users will vote with their feet.
—
Reply to this email directly or view it on GitHub
https://github.com/tavendo/AutobahnCpp/issues/50#issuecomment-140144569.

Curious what the user space context switching overhead of coroutines is.
On Mon, Sep 14, 2015 at 1:18 PM, Tobias Oberstein<EMAIL_ADDRESS>wrote:

fwiw, seems like boost::coroutine is also a std proposal
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3985.pdf - at
least same author ..
—
Reply to this email directly or view it on GitHub
https://github.com/tavendo/AutobahnCpp/issues/50#issuecomment-140148985.

FWIW @ecorm basically implemented his own variant type for CppWAMP.
However, I think msgpack::object is still more flexible and more efficient.
It also has the added benefit of already supporting a huge number of types
by default. Pretty much the entire STL container library. It also has very
active contributions from a wide range of platforms/compilers.
On Mon, Sep 14, 2015 at 1:31 PM, David Chappelle<EMAIL_ADDRESS>wrote:

Curious what the user space context switching overhead of coroutines is.
On Mon, Sep 14, 2015 at 1:18 PM, Tobias Oberstein <
<EMAIL_ADDRESS>wrote:

fwiw, seems like boost::coroutine is also a std proposal
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3985.pdf - at
least same author ..
—
Reply to this email directly or view it on GitHub
https://github.com/tavendo/AutobahnCpp/issues/50#issuecomment-140148985
.

@davidchappelle
Ok, let's make a decision. I am ready to merge back your fork and follow and actively support the decisions made: using msgpack::object in the public API, using CMake instead of SCons, source code organization.
There is only 1 thing left: I'd like to make the change to MIT. This requires your support and support by everyone that contributed to your fork.
I think having both AutobahnCpp and CppWamp continue is fine, as they made different decisions / tradeoffs .. and there isn't one that's "right" and the other wrong. Let users choose.
Deal?

Oh, rgd license: just noticed msgpack is Apache (https://github.com/msgpack/msgpack-c/blob/master/LICENSE) ..
So AutobahnCpp couldn't be used in GPL2 code even when it's MIT.

Is Boost license GPL2 compatible btw? If so, I'd be fine with that also. The main thing is: allow use in GPL2 code ..

Looks like Boost is listed as compatible with GPL v2:
http://gplv3.fsf.org/wiki/index.php/Compatible_licenses
And Apache v2 is listed as compatible with GPL v3
On Mon, Sep 14, 2015 at 2:12 PM, Tobias Oberstein<EMAIL_ADDRESS>wrote:

Oh, rgd license: just noticed msgpack is Apache (
https://github.com/msgpack/msgpack-c/blob/master/LICENSE) ..
So AutobahnCpp couldn't be used in GPL2 code even when it's MIT.

Is Boost license GPL2 compatible btw? If so, I'd be fine with that also.
The main thing is: allow use in GPL2 code ..
—
Reply to this email directly or view it on GitHub
https://github.com/tavendo/AutobahnCpp/issues/50#issuecomment-140163643.

My personal impression about AutobahnCpp, when I first saw it, was that it's a fairly minimal client that only adds extra code and dependencies where really necessary. That makes it both maintainable and easy to get into. I'm undecided whether I prefer @oberstet's all-in-one-file approach or @davidchappelle's one-file-per-class, but even after that split it's straightforward to read and contribute to. CppWAMP in that respect is more modular, and as a result offers more options but it's also more complex, with more concepts to understand. Maybe Dave's branch will develop into that same direction over time, I don't know.
In that sense, I like the dependency on futures. They've been in C++ since '11 and seem like more of a "core" feature that will underlie a number of other features. One could probably implement callbacks on top of futures and futures on top of callbacks, in the end those are pretty interchangeable for all practical purposes. The main difference being that callbacks require some sort of event loop integration and futures using mutexes/condvars underneath, plus exceptions are really nicely handled by futures imho.
Either way, I think there's room for a library that focuses on just one option and fully embraces it, with everything else tacked on top. For AutobahnCpp, futures and msgpack would be the underlying infrastructure and JSON can be that optional piece. For CppWAMP, callbacks and a custom variant type are the underlying infrastructure and JSON/msgpack/coroutines/futures are extensions.
@oberstet, are you looking at the license change just to make it work with GPLv2? Are you actually looking to intermingle it with GPLv2 or only use it from there? Because, as you yourself described beautifully in issue #16, Apache won't get viral and eat into GPL code because it's a separate library that only copylefts code in the AutobahnCpp code itself but no application code or anything.

@davidchappelle
Ok, so I'd be fine with changing AutobahnCpp to either MIT or Boost.
But then it still coudn't be used in GPL2 software .. the FSF explicitly mentions the Apache 2.0 as being incompatible with the GPL2 (though it's compatible with the GPL3).
Oh well. We probably just can't fix that.
@jpetso

are you looking at the license change just to make it work with GPLv2

That is my only itch.

A minor one would be it's nice to say: all Autobahn's are MIT. But that's cosmetics.

Screw it: I am fine if we stick to Apache 2.0. We can't fix the GPL2.
@davidchappelle so I guess I just merge?

That sounds great Tobias!
On Mon, Sep 14, 2015 at 2:27 PM, Tobias Oberstein<EMAIL_ADDRESS>wrote:

Screw it: I am fine if we stick to Apache 2.0. We can't fix the GPL2.
@davidchappelle https://github.com/davidchappelle so I guess I just
merge?
—
Reply to this email directly or view it on GitHub
https://github.com/tavendo/AutobahnCpp/issues/50#issuecomment-140167038.

Could you do me a favor? Create a new PR that I can just cleanly merge .. I am a bit "under water" with so many things in parallel ..

[http://www.apache.org/licenses/GPL-compatibility.html](Apache says):

This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then the Apache software would have to be distributed under GPLv3. This would be incompatible with ASF's requirement that all Apache software must be distributed under the Apache License 2.0.
We avoid GPLv3 software because merely linking to it is considered by the GPLv3 authors to create a derivative work. We want to honor their license. Unless GPLv3 licensors relax this interpretation of their own license regarding linking, our licensing philosophies are fundamentally incompatible. This is an identical issue for both GPLv2 and GPLv3.

I don't believe there's yet a court ruling that conclusively sorts out what the GPL can consider a "derivative work" and what it can't, but it seems fair to avoid legal gray zones. If you want to ask the msgpack authors to consider a switch to the Boost license, I'll support that request. Not sure how diligently they would handle such a request though, especially since they've had a few more contributors than AutobahnCpp and only recently started to add copyright lines other than the original author's one. From the Topology side, I'm sure we wouldn't have a problem with switching to Boost - if you would like to go that direction, let's not put it off for too long.

FWIW, CppWAMP does have experimental support for boost::future: https://github.com/ecorm/cppwamp/issues/3
I'm waiting for recent developments in Boost.Asio and Boost.Thread to be released, as described in the issue I referenced.

@jpetso I agree, unless and until there is precedence from court ruling, it's basically unclear. But at least the FSF clearly states that GPL2 and Apache 2.0 are incompatible (http://gplv3.fsf.org/wiki/index.php/Compatible_licenses#GPLv2-incompatible_licenses)
We have been approached by other projects rgd AutobahnJS and AutobahnPython: e.g. Buildbot (a GPL2 CI system) will be using AutobahnPython upcoming .. and we've gone through a license change so they can use it.
So I think it would be nice if AutobahnCpp had a GPL2 compatible license and msgpack too. If only one of these makes a switch, it doesn't make a difference for users: they still have a problem if they are on GPL2.
If you think you can ask and make msgpack change license, then let's do it too! And yeah, do it soon.
I am fine with MIT, and I am fine with Boost. The latter is probably even nicer, since then a user that "only" uses Boost, AutobahnCpp and msgpack just has to look at 1 license type.
If msgpack doesn't want to change license, then let's stick with Apache for AutobahnCpp. Because it doesn't make a difference anyway ..

As a matter of fact, I just merged! Wooaa. ;) Thanks Topology, thanks Dave!
We can sort out the license "issue" still .. I merged since I am fine with and support any of above mentioned license options.

Yay! Note that the filename and contents of the examples changed, so we had to adapt the links to not point to the tavendo repository. Those should now be switched back.

I will try and go through the README.md as well and take a pass at updating
the coding examples.
On Mon, Sep 14, 2015 at 2:59 PM, Jakob Petsovits<EMAIL_ADDRESS>wrote:

Yay! Note that the filename and contents of the examples changed, so we
had to adapt the links to not point to the tavendo repository. Those should
now be switched back.
—
Reply to this email directly or view it on GitHub
https://github.com/tavendo/AutobahnCpp/issues/50#issuecomment-140176283.

Awesome! Thx.
Am 14.09.2015 9:13 nachm. schrieb davidchappelle<EMAIL_ADDRESS>I will try and go through the README.md as well and take a pass at updating
the coding examples.
On Mon, Sep 14, 2015 at 2:59 PM, Jakob Petsovits<EMAIL_ADDRESS>wrote:

Yay! Note that the filename and contents of the examples changed, so we
had to adapt the links to not point to the tavendo repository. Those should
now be switched back.
—
Reply to this email directly or view it on GitHub
https://github.com/tavendo/AutobahnCpp/issues/50#issuecomment-140176283.

—
Reply to this email directly or view it on GitHubhttps://github.com/tavendo/AutobahnCpp/issues/50#issuecomment-140180151.

I guess this can be closed off for now.


[RFC] The case for EAR and CoCo

The Case for EAR and CoCo
EAR (EAT Attestation Result)
EAR is a format for carrying attestation results, i.e., the output of a verifier's appraisal over attester-produced evidence.
EAR an EAT token that can be serialised as JWT or CWT.  The semantic core is provided by the AR4SI "trustworthiness vector", i.e., a collection of well-defined appraisal categories that uses a standardised "scoring" system to present a normalised, yet rich view of the appraised attester.  The basic purpose of the trustworthiness vector is to decouple attesters from relying parties so that the latter can take fine-grained policy decisions without having any specific knowledge of the attester they are interacting with.  This property is especially valuable in systems where multiple different attesters co-exist.
An EAR claims set can be split in three main parts:

A bunch of top-level metadata associated with the appraisal context,
One or more attester-specific appraisal records (each including an AR4SI trustworthiness vector), and
An extensible block of claims allocated for application-specific needs.

Implementation status
Currently, there are three open-source implementations we know of, all under the Veraison project:

veraison/ear: complete producer and consumer in Go
veraison/rust-ear: (nearly) complete producer and consumer in Rust
veraison/c-ear: partial consumer in C

Attestation Results in the KBS Attestation Protocol Flows
A KBC (Key Broker Client) that has authenticated successfully receives an attestation result from the KBS (Key Broker Server) in the response to POST /kbs/v0/attest.  The result uses a JWT envelope and the claims set looks like this:
{
    "exp":<PHONE_NUMBER>,
    "iat":<PHONE_NUMBER>,
    "iss": "<URL of the issuing service>",

    "tee-pubkey": "<TEE public key>",
    /* Custom Claims */
}

A CoCo attester can use the attestation result token as a "passport" (with the cryptographic identity defined by tee-pubkey and an explicit validity period provided by the iat and exp claims) to make (strongly) authenticated requests for resources from external services.
AFAIU, the "Custom Claims" must embed another attestation result, the one from the attestation service, which carries the CoCo attester's TCB status and measurements.

Note: Further details can be found in the KBS Attestation Protocol documentation.

Discussion
As described above, the attestation service sends an attestation result to the KBS containing the appraisal of the CoCo attester.
A further attestation result (in fact, a passport) wraps the original attestation result produced by the attestation service alongside the identity key of the CoCo attester.  The bundle is then sent back by KBS to KBC where it is processed and used.
The EAR / AR4SI data and info models seem well suited for encoding the core appraisal:
flowchart LR
    KBS -- "EAR{CoCo appraisal}" --- AS["attestation service"]
    KBC -- "TEE-passport{tee-pubkey, EAR{CoCo appraisal}}" --- KBS

Potentially, it could also be employed for the wrapping passport, although this does not seem strictly necessary:
flowchart LR
    KBC -- "EAR{tee-pubkey, EAR{CoCo appraisal}}\n(?)"  --- KBS

There seems to be value adopting a standardised format like EAR / AR4SI for at least the following reasons:

Interoperability outside the CoCo flows - for example to reuse the AR computed by CoCo in subsequent TLS exchanges involving the CoCo attester,
Ease the task of defining and computing authorization policies by relying parties due to the reliance on AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results.  An example showing how to use OPA to evaluate a EAR in just a few lines of Rego can be found here (click on the Evaluate button.)
Code reuse via existing open-source libraries,
Normalised and attester-agnostic result format, which allows to accommodate all currently supported formats as well as any other kinds of attester / CC technologies in the future.

UPDATE(1): improve clarity in diagrams

If I am reading this correctly, this will be very helpful, especially in the trusted-io use case where we have a heterogeneous mix of attesting environments and verifier types.
Taking, e.g., the use-case of accelerator attestation (the GPU in my use-case) or any other devices (DPU) that get "added" to the TEE by any means (bounce-buffers, TDISP/IDE), we have different remote attestation services (Amber, Veraison, NVIDIA attestation service)
Confidential GPUs can work with different CPUs meaning for each, we have a tuple of CPU Attestation + GPU Attestation services combined or brokered.
Future accelerators like DPUs and NICs may bring their attestation service and attestation results, and having a TEE with multiple accelerators will increase the complexity of handling all of the attestation services and results.
@thomas-fossati Any opinion on the general flow of multiple attestations for different devices in a TEE? Are we doing attestation of each device separately, something like a multi-stage attestation pipeline, or is it more advisable to do a composite attestation with several reports simultaneously? Looking at the GPU use-case the NVIDIA attestation service should not be responsible for attesting the CPU, this should be done e.g. by Amber, Veraison etc.

Adding @Xynnn007 @jialez0 to gather their feedback.

@thomas-fossati Any opinion on the general flow of multiple attestations for different devices in a TEE? Are we doing attestation of each device separately, something like a multi-stage attestation pipeline, or is it more advisable to do a composite attestation with several reports simultaneously? Looking at the GPU use-case the NVIDIA attestation service should not be responsible for attesting the CPU, this should be done e.g. by Amber, Veraison etc.

hi @zvonkok, thanks for the very interesting comments.  I don't hold any strong opinions here, it basically depends on the deployment and the underlying trust model.  In principle, a EAR can support both recursive and iterative dispatching of the verification process, so from that point of view we should be safe.  Ideally though, to keep things simple for the relying parties, I guess one wants the verification process (irrespective of the amount of nesting involved) to end up with EARs containing a single appraisal record.

@thomas-fossati I think this makes a lot of sense. At that point, I have one generic, EAR-newbie question: if I understand your proposal correctly, most of the work would be on the attestation-service where we'd need to basically have it generate an EAR instead of a TEE specific claim set, and provide that back to KBS. Is that a correct summary?

Hi @sameo!  Yes, this is correct.

Overall, I think it is a good idea. Now we are facing different archs, which would make the verification and policy complicated. When we start to think carefully how to actually apply that into attestation-service (especially the format), some realities hit me:
Now tdx does not have a mapping mechanism/spec from a quote to an EAR. I'm not sure about SNP. I'm hoping to hear some points of views from @peterzcst @fitzthum. : )

This seems like a reasonable proposal. It would augment/replace our API between KBS and AS, which isn't particularly standardized. This would also be a more standardized form of the attestation-token that we currently have. It seems like we would probably need to implement some new code in the AS to generate an EAR, but this probably isn't too different from how we currently generate the claims map.
I wonder if this would be a good topic for a community meeting.

Now tdx does not have a mapping mechanism/spec from a quote to an EAR. I'm not sure about SNP. I'm hoping to hear some
points of views from @peterzcst @fitzthum. : )

I know there are discussions about this - let me try to find someone smart who can shed some light.

I wonder if this would be a good topic for a community meeting.

Great idea.  In case, I'd be happy to join that meeting.


[DeepLearning/Ops] Add MatmulInt32Op, BatchMatmulInt32Op benchmarks

for input matrix size [3,512,512,512,i32],the comparison:
Benchmark                                      Time             CPU   Iterations
DL_OPS_BATCH_MATMUL/Scalar                 27630 ms        27586 ms            1
DL_OPS_BATCH_MATMUL/AutoVectorization      17898 ms        17896 ms            1
DL_OPS_BATCH_MATMUL/Vectorization           3795 ms         3795 ms            1
DL_OPS_BATCH_MATMUL/RvvVectorization        1255 ms         1254 ms            1

Recommand to update benchmarks/DeepLearning/README.md when adding new directories(new operations here).

When I reproduced the experiment, the RVV implementation was surprisingly five times faster than the general vector implementation(743ms VS 3773ms), but the length of the vector in their iterations was the same. Do you have any idea what might be the cause? Is it only because the RVV implementation can throw away broadcast operation?


Package dependencies

I'm a bit of a newb with package.json and npm stuff, but it doesn't seem right that xstream and run are inside devDependencies. For instance, the jsonp driver has xstream as a peerDependency and run as a dependency: https://github.com/Widdershin/cycle-core/blob/bbad3d6ef832e6131f1c81a32de856b3d56ecda2/jsonp/package.json#L12
@nickbalestra @goshakkk not sure how peerDependencies work but maybe you guys can help?

Yes those are actual dependencies, not devDepenencies

https://github.com/cyclejs-community/redux-cycle-middleware/pull/15


Turns the Peacelover's Shirt invisible for females

Both myself and a friend have had an issue where the Peacelover's Shirt is invisible on females - the torso is completely invisible, and when trying on the piece over another glam, the game doesn't load a new model at all and leaves it as the previous gear's model. When that model is the first to be "loaded" (selected for the try on feature, or loading into the instance with it glammed on), the character appears torsoless.
Friend had this issue on a completely modless install, I myself removed all mods and even went as far as reinstalling the game to "fix" it - which only worked until I installed alexander onto the fresh install.
Have uninstalled and reinstalled several times to be completely positive, and as soon as Alexander is removed and the game rebooted, the top shows up completely fine. When it's installed again, it's visible until the game is booted with Modding > Enable turned on - appears fine if the game is booted with Alexander disabled. Enabling and reinstancing has no affect, just as disabling and reinstancing doesn't make the top show up if it's already invisible.
I'm assuming this has coincided with the addition of the ability to install TexTools Modpacks. I was using version <IP_ADDRESS> since 14/10 until today, when I updated to <IP_ADDRESS> and the issue persists. Unsure which version friend is running.
Have not found a similar issue with any other gear pieces as of yet.

I am having exactly the same issue.

XivAlexander_353cf75.zip
Can you test whether this works? I've confirmed that it happened on my side too, and did check that with this fix the item is properly visible.

Hmm. It does seem to make the Peacelover's Shirt visible again, but I've encountered a new issue.
This version seems to be incompatible with XIVlauncher and its plugins. Whenever I run the game with Alexander enabled, the game doesn't load any of the plugins I have installed, and the game crashes to desktop whenever I try to open the Dalamud settings or (curiously) press the Exit Game button. It seems to be prompting the game to crash on startup occasionally, about the time I assume it normally loads in said plugins.
Much like the invisible shirt issue from before, they load fine if Alexander isn't installed, or the game is booted without it enabled (such as the first time after it's hooked to the .exe)
Tried uninstalling and reinstalling a few times, as well as deleting and re-extracting the folder in case it's user error, but it seems consistent.
Thanks for looking into this!

Oops, wrong button!

Personally I never encountered any conflicts with Dalamud, so I can't test it myself, but try the following.
There should be an option on FFXIVQuickLauncher which delays Dalamud load. Try extending the delay, so that it doesn't try to load while XivAlexander is starting up. Otherwise, try disabling Dalamud or launch the game via official launcher, and then run Dalamud via %APPDATA%\Roaming\XIVLauncher\addon\Hooks\dev\Dalamud.Injector.exe when the game shows up logos.
If it indeed fixes the problem, I believe that there are stuff I can implement so that Dalamud does not attempt to inject while XivAlexander is loading.

It did manage to load plugins once last night after I wrote up the previous comment, something like 1 in 15 attempts all told. (was at 0ms delay)
Added 3000ms delay, relogged three times and 2/3 loaded plugins just fine. Upped it to 5000ms and all three attempts loaded fine.
So, looks like it is indeed something about them trying to load up at the same time! I wonder if it was causing problems for me because I know my computer isn't the fastest out there.

XivAlexander_61d4c57.zip
This should prevent Dalamud from attempting to load before the game window shows up. Try this one by removing Dalamud delay-load from FFXIVQuickLauncher.

Yep, seems to be working on my end!
Thanks again!

I'll close this issue when I make a next full release. Just keeping it open until then!

I'm still having this issue, with the latest version of XIVAlex. Is there something I'm forgetting to do?

I updated to v<IP_ADDRESS> the other day and can confirm, the shirt has turned invisible again.

This will be fixed in next release. Also, it should not have worked back in previous release, but I have no idea why did it work.


Add the remaining tasks

This should address issues 52

thank you, was done. didn't close issue in time


Improve handling of translations

Localization does not match with the in game spellings in Russian language

Need to redo the method for generating the locale-data.ts file. Maybe we can pull the information from Eco files somewhere? That would be a lot simpler and better than using Google Translate. If that's not possible, we need some kind of script that can read the items, recipes, skills etc. from the data files, call the Translate API, and generate the LocaleEntries.
One concern is avoiding overwriting locale data (in case there are manual fixes made to results from the API).

Hi, problem solved:
I got all the translations of the Eco game from "defaultstrings.csv" on https://fr.crowdin.com/project/eco-by-strange-loop-games, to put them in Update locale-data.ts.
Please validate it.
What is not translated on https://fr.crowdin.com/project/eco-by-strange-loop-games is therefore in English as in the game for more consistency.
Please remove the notion of google translation.
Send me a message when you have the version for Eco 9.6 so that I can redo the update, and the same for future versions...


Accessing cython_runtime object when its reference count is 0

The following piece of code ends up accessing the cython_runtime module when its reference count is 0 and its destructor has already been called. This is undefined behaviour and can cause the interpreter to crash.
import sys

def generator():
    yield
    yield

g = generator()
next(g)

del sys.modules["cython_runtime"]
del g

Even if sys.modules["cython_runtime"] is not deleted explicitly, the bug can still occur during shutdown depending on whether the reference count for g or cython_runtime goes down to 0 first.
The problem is caused by __Pyx_CLineForTraceback being called when stopping a started generator and trying to look up the cython_runtime.cline_in_traceback variable introduced in 0.26. See Exceptions.c#L665 and Exceptions.c#L673.
It only has a borrowed reference to cython_runtime from ModuleNode.py#L2839 obtained during initialisation which is not reference counted and thus there is no guarantee that the object has not already been destroyed.
I believe adding a call to code.put_incref() after obtaining the reference would be sufficient to resolve the issue, but there may be better ways of going about this.
Note that this particular example is not guaranteed to crash. However I confirmed the illegal access by
breaking at the lines mentioned above in a debugger, and seeing that __pyx_cython_runtime->ob_refcnt is 0 at the point of access.

Right, PyImport_AddModule() returns a borrowed reference that we should better not keep un-owned.

Thanks for the excellent analysis.


Plug in installation path customization function

Issue Type: Feature Request
Can users choose the root directory of the plug-in installation by themselves? Now the default installation path of the plug-in is under "c:\users\xxx.vscode\extensions". Can there be a place to set or change this path.
VS Code version: Code 1.69.0 (92d25e35d9bf1a6b16f7d0758f25d48ace11e5b9, 2022-07-07T05:28:36.503Z)
OS version: Windows_NT x64 10.0.19043
Restricted Mode: No

Yes, you can use --extensions-dir and provide the directory in which you want to install the extensions from the command line.

We closed this issue because it is a question about using VS Code rather than an issue or feature request. Please search for help on StackOverflow, where the community has already answered thousands of similar questions. You may find their guide on asking a new question helpful if your question has not already been asked. See also our issue reporting guidelines.
Happy Coding!


Proposal: A more robust way to unit test views

I took at look at the test examples for views and gave it a try. While the *Viewer types are very helpful and the overall mechanism works I think it's kind of an anti-pattern on how it is demonstrated here (and in the docs).
Obviously you can build your tests that way, but I don't think you should. Especially not when you're dealing with more complex view hierarchies, and when you're beginning to build your UI which may at that time be subject of change quite often.
Because every time the hierarchy changes your tests would break and require you to update them. Which is a tedious process as you need to scan your hierarchy and replicate it in your tests. So you not only end up with a lot of boilerplate code but very fragile boilerplate code.
Example
let loginPage() =
    View.ContentPage(
        content = View.ScrollView(
            content = View.StackLayout(
                padding = 30.0,
                children = [
                    View.Frame(
                        verticalOptions = LayoutOptions.CenterAndExpand,
                        content = View.StackLayout(children = [
                            View.Entry(
                                placeholder = "User name",
                                isEnabled = (not model.IsBusy),
                                textChanged = (fun args -> (dispatch (LoginUserNameChanged args.NewTextValue))))
                            View.Entry(
                                placeholder = "Password",
                                isPassword = true,
                                isEnabled = (not model.IsBusy),
                                textChanged = (fun args -> (dispatch (LoginPasswordChanged args.NewTextValue))))
                            View.Button(
                                automationId = "SignInButton",
                                text = "Sign in",
                                heightRequest = 30.0,
                                isVisible = (not model.IsBusy),
                                command = (fun () -> dispatch LoginStarted),
                                canExecute = model.Login.IsCredentialsProvided)
                            View.ActivityIndicator(
                                isRunning = true,
                                heightRequest = 30.0,
                                isVisible = model.IsBusy)])
                    )
                ]
            )
        )
    )

I have that login form and want to make sure the sign in button is enabled only when the IsCredentialsProvided property is set to true. This is crucial to the whole thing and worth testing (from my point of view).
A test would now look like:
[<Theory>]
[<InlineData(true)>]
[<InlineData(false)>]
let ``The Sign In Button is only enabled when the Credentials are provided`` credentialsProvided =
    let model = initialModel()
    let model = { model with Login = { model.Login with IsCredentialsProvided = credentialsProvided } }

    let view = (App.view model ignore)
    let contentPage = ContentPageViewer(view)
    let scrollView = ScrollViewViewer(contentPage.Content)
    let stackLayout = StackLayoutViewer(scrollView.Content)
    let frame = FrameViewer(stackLayout.Children.[0])
    let stackLayout = StackLayoutViewer(frame.Content)
    let button = ButtonViewer(stackLayout.Children.[2])

    button.CanExecute |> should equal credentialsProvided

This is not a new problem, though. UI test frameworks seem to agree on unique identifiers within the view hierarchy which they can use to "pick" an element effortlessly. Xamarin.Forms has those as well and is turns out they are even part of the Fabulous "bindings".
I wrote a small helper function what covers the most common scenarios right now (Content, Children, and Pages) and is able to find a given element by its AutomationId in the hierarchy:
/// Looks for an view element with the given Automation ID in the view hierarchy.
/// This function is not optimized for efficiency and may execute slowly.
/// Which shouldn't be noticable in pure test scenarios, though.
let rec tryFindViewElement automationId (element:ViewElement) =
    let elementAutomationId = element.TryGetAttributeKeyed(ViewAttributes.AutomationIdAttribKey)
    if elementAutomationId.IsSome && elementAutomationId.Value = automationId then
        Some(element)
    else
        let childElements = ResizeArray<ViewElement>()

        let content = element.TryGetAttributeKeyed(ViewAttributes.ContentAttribKey)
        if content.IsSome then
            childElements.Add content.Value
        else
            let pages = element.TryGetAttributeKeyed(ViewAttributes.PagesAttribKey)
            if (pages.IsSome) then
                childElements.AddRange pages.Value
            else
                let children = element.TryGetAttributeKeyed(ViewAttributes.ChildrenAttribKey)
                if (children.IsSome) then
                    childElements.AddRange children.Value

        let childElementResult =
            childElements
            |> Seq.map (fun e -> e |> tryFindViewElement automationId)
            |> Seq.filter (fun e -> e.IsSome)
            |> Seq.tryHead

        match childElementResult with
        | Some result -> result
        | None -> None

My test is now much simpler and doesn't rely on the concrete structure of the form as long as the button still is to be found somewhere:
[<Theory>]
[<InlineData(true)>]
[<InlineData(false)>]
let ``The Sign In Button is only enabled when the Credentials are provided`` credentialsProvided =
    let model = initialModel()
    let model = { model with Login = { model.Login with IsCredentialsProvided = credentialsProvided } }

    let view = (App.view model ignore)
    let button = view |> tryFindViewElement "SignInButton"
    button.IsSome |> should be True

    let button = ButtonViewer(button.Value)
    button.CanExecute |> should equal credentialsProvided

I'm pretty sure tryFindViewElement can be optimized in certain ways (bear with me, I'm a C# developer by day :-)). But maybe someone may find it helpful anyway.

Ironically AutomationId seems broken right now. But ClassId works, too.

@aspnetde I agree with you.
To be honest, the Viewer API was something I was able to quickly put together to provide an easier way to unit test UI (with some docs and samples -- even if not really applicable to real world cases).
So any improvement is more than welcome :)
Your tryFindViewElement seems like a good helper we can integrate in Fabulous.
It's more akin to what I'm used to when testing C# Xamarin apps (though I mostly do integration testing with App Center)
The samples will also benefit from being redone I think, to be more real world-like.

@TimLariviere

To be honest, the Viewer API was something I was able to quickly put together to provide an easier way to unit test UI (with some docs and samples -- even if not really applicable to real world cases).

Actually it's way more than good enough for now I think. Working with it was straight-forward and it provides all information and data that's needed for testing I think.

Your tryFindViewElement seems like a good helper we can integrate in Fabulous.

Feel free to do so :-). (I don't know where to put it, otherwise I would prepare a PR myself.)


Adding dtypes option to Workflow

Adds dtypes option for Workflow in functions apply and write_to_dataset.
1.1. Should I also add it to update_stats ?

Should I remove the existing dtypes option from Dataset? No, it makes sense to keep it.

Should I remove the existing dtype option for Categorify? Not sure if it will be used, but so far we will keep it and we will see in the future.

@rjzamora all changes applied.


[ONNX] add mobilenet support

What does this PR do?
This PR tries to add mobilenet models for ONNX support
Partially fixes https://github.com/huggingface/transformers/issues/20856
Related: https://github.com/huggingface/transformers/pull/20860
Also it seems that Mobilenet used to be supported by transformers? At least when I run:
from transformers import  AutoModelForImageClassification
from transformers.onnx import FeaturesManager

model = AutoModelForImageClassification.from_pretrained("google/mobilenet_v2_1.0_224")
model_kind, model_onnx_config = FeaturesManager.check_supported_model_or_raise(model)

Everything works fine, so maybe mobilenet has be forgotten by mistake?
cc @fxmarty @michaelbenayoun

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Question -

I am working with DaisyUI.
There is a requirement to set a color scheme like this:
<html data-theme="cupcake"></html>
I can't figure out how to do that with this library.  Am I missing something?
PS: Please consider opening up the GitHub discussions on this. I always think that asking a question should be under discussions and reporting a real issue under issues.

Hi @chrismalek, consider using something like this:
Html(attrs.Props{attrs.DataPrefix + "theme": "cupcake"}, Text("foobar"))

Here attrs.DataPrefix + "theme" is your attribute name.
@chasefleming, what do you think about introducing a new method like DataAttr(suffix string) string to generate data-attributes names?

Yep @whisk is correct. That should work. Your attribute key could also just be a string, but it's recommend using constants for type safety. But I agree @whisk, a function for data attributes would be much better. We should add that and maybe drop DataPrefix all together as an option since it doesn't follow the same naming conventions and a function is a much better way to do it. Are you interested in taking that issue?

@chasefleming, you could assign this to me.
Though I think we should keep DataPrefix until the next major update, since removing it would be a breaking change.

Sounds good @whisk . Let's leave it in. Also, do you mind putting this in a new utils.go file in the attrs subpackage with a utils_test.go as well. Thanks!

Hi @chasefleming, please check PR #78

Sorry late to the game here.  I must have needed more coffee. Of course this would work as well
Html(attrs.Props{attrs.DataPrefix + "theme": "cupcake"}, Text("foobar")) it is just string concatenation.

Yep, that will work @chrismalek , but the version @whisk is putting in will be more performant than string concatenation if you're rendering a decent amount of elements with attributes. So it will be recommended to use that once it's out. Probably next release.


Build only enabled scenes when using "Build Visual Studio SLN" button in Build Window

When building an app from unity it's possible to have multiple scenes in
the build window, but only have one scene enabled. Unity only includes the
enabled scenes, see https://docs.unity3d.com/Manual/BuildSettings.html.
Have HoloToolkit build window match this behavior.

Thanks a ton!


Improvement/member_resolves

Changes
This adds an additional member resolve API, which will eventually deprecate the previous memberResolves API. This API depends on a brand new CL, which will inhherit the user profile iASP, which the current API does not.
I also created tests for this new API.
Checklist

[x] have tested my change
[ ] updated relevant documentation
[ ] Remove any/all console.logs I added
[ ] eslint is not complaining
[ ] have added myself to the contributors' list in CONTRIBUTING.md
[ ] for feature PRs: PR only includes one feature enhancement.

Converted to draft as there may be an easier way with our existing API after all....

I have thought of a better way to do this PR so I am going to close and have another branch for it in the future.


Add Profile Summary field to information section to profile, with a specific limit of characters allowed.

@wunc what's the character limit for this field?

@betsyecastro I think my initial thought was the same max length as a Twitter tweet (i.e. 280 characters). I don't think we need a Livewire component for it. We can just use regular HTML5 validation for the front-end and for back-end validation, you should be able to edit the ProfileUpdateRequest.php file.


Permission denied

git clone git@github.com:tom-doerr/vim_codex.git
returns:
Cloning into 'vim_codex'...
The authenticity of host 'github.com (<IP_ADDRESS>)' can't be established.
ECDSA key fingerprint is SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.
Are you sure you want to continue connecting (yes/no/[fingerprint])? y
Please type 'yes', 'no' or the fingerprint: yes
Warning: Permanently added 'github.com,<IP_ADDRESS>' (ECDSA) to the list of known hosts.
So I just cloned the repo URL. But for the record, this is what the README says to do.

Where do you get Permission denied?

I get a similar issue. I am trying to install it on Manjaro KDE 21.2.3. After following manual install provided in the README fil, this is is exact error that I received:
Cloning into 'vim_codex'...
<EMAIL_ADDRESS>Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.


:seedling: Refactor patternfly, i18n, and dayjs initialization

Refactoring:

Explicitly add i18n initialization on the root index.tsx.

Move dayjs initialization to its own file dayjs.ts referenced from index.tsx.  This follows the i18n init style.

Move PF css includes from App.tsx to index.tsx

Nice - LGTM


Translated React without JSX

Issue https://github.com/reactjs/es.reactjs.org/issues/112
@carburo @alejandronanez  @dmoralesm

Ok, we are good. Thank you!
Merging :rocket:


status code: 400 bad request

When I use restler, almost all the returned status codes are 400 bad request, is that because too many query parameters? is that normal?
shell script
$RESTler_DIR"/"Restler fuzz --grammar_file $WORKING_DIR/Compile/grammar.py --time_budget 1 --dictionary_file $WORKING_DIR/Compile/dict.json  --settings $WORKING_DIR/Compile/engine_settings.json --no_ssl --token_refresh_interval 100000 --token_refresh_command /auth
network.testing.*.txt output
`2021-04-20 04:01:03.300: Sending: 'GET /api/v4/projects?archived=true&id_after=0&id_before=0&last_activity_after=6/25/2019 12:00:00 AM&last_activity_before=6/25/2019 12:00:00 AM&membership=true&min_access_level=0&order_by=id&owned=true&repository_storage=fuzzstring&search_namespaces=true&search=fuzzstring&simple=true&sort=asc&starred=true&statistics=true&visibility=public&with_custom_attributes=true&with_issues_enabled=true&with_merge_requests_enabled=true&with_programming_language=fuzzstring HTTP/1.1\r\nAccept: application/json\r\nHost: localhost:30000\r\n_OMITTED_AUTH_TOKEN_\r\nContent-Length: 0\r\nUser-Agent: restler/7.3.0\r\n\r\n'
2021-04-20 04:02:08.322: Received: 'HTTP/1.1 400 Bad Request\r\nServer: nginx\r\nDate: Tue, 20 Apr 2021 04:01:03 GMT\r\nContent-Type: text/plain; charset=utf-8\r\nTransfer-Encoding: chunked\r\nConnection: keep-alive\r\n\r\nf\r\n400 Bad Request\r\n0\r\n\r\n'
`

Hello @xlx-nju,
Yes, this is possibly due to the fact that RESTler-generated values for the query parameters are not valid or not all parameters can be used together (you should investigate this for one endpoint+method just to make sure).
As a potential workaround, can you please try to add the following to the engine settings file and see if it improves the coverage (this will cause just required query parameters to be tested, in addition to all which is the current default. ):
"max_combinations": 100,
"test_combinations_settings": {
"query_param_combinations" : "required"
}

Note, due to #320 and #284, looks like below should be a valid construct:
"test_combinations_settings":
{
 "header_param_combinations":
  {
 	"max_combinations": 10,
 	"param_kind": "optional"
  },
 "query_param_combinations":
  {
 	"max_combinations": 15,
 	"param_kind": "required"
  },
 "example_payloadds":
  {
 	"payload_kind": "all"
  }
},

@marina-p, please confirm if the above construct is correct to be placed in restler_user_settings.json?
Otherwise, the compiler will fail with this error:
$ cat EngineStdOut.txt
Initializing: Garbage collection every 30 seconds.
No checkpoints used at this phase
Terminating garbage collection. Waiting for max 300 seconds.
Traceback (most recent call last):
  File "/usr/local/bin/restler_bin/engine/engine/core/fuzzer.py", line 42, in run
    self._num_total_sequences = driver.generate_sequences(
  File "/usr/local/bin/restler_bin/engine/engine/core/driver.py", line 618, in generate_sequences
    logger.print_req_collection_stats(
  File "/usr/local/bin/restler_bin/engine/utils/logger.py", line 683, in print_req_collection_stats
    val = r.num_combinations(candidate_values_pool)
  File "/usr/local/bin/restler_bin/engine/engine/core/requests.py", line 908, in num_combinations
    for combination in self.render_iter(candidate_values_pool):
  File "/usr/local/bin/restler_bin/engine/engine/core/requests.py", line 834, in render_iter
    for req in self.get_schema_combinations():
  File "/usr/local/bin/restler_bin/engine/engine/core/requests.py", line 624, in get_schema_combinations
    for hpc in self.get_header_param_combinations(header_param_combinations):
  File "/usr/local/bin/restler_bin/engine/engine/core/requests.py", line 1019, in get_header_param_combinations
    for param_list in param_combinations.get_param_combinations(self, header_param_combinations_setting,
  File "/usr/local/bin/restler_bin/engine/engine/fuzzing_parameters/param_combinations.py", line 45, in get_param_combinations
    max_combinations = Settings().max_combinations
NameError: name 'Settings' is not defined

Just to clarify, is it correct to say that response code with "500" is only considered as bug? any other error code with 400, 405, 415, etc are considered only failure and not a bug? Please clarify

Yes, your statement is correct.


Server not starting with Space Engineers

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/34472549-server-not-starting-with-space-engineers?utm_campaign=plugin&utm_content=tracker%2F6855523&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F6855523&utm_medium=issues&utm_source=github).

This has been resolved for awhile.


barebones functionality

Description

Added the very minimum functionality for this to be a usable tool.
Optional command line argument for the project you are working on.
This enables you to track punches in and out but also allows you to track more descriptively, like how much time spent working on a project.

Looks good! Attaching csv of test punches.
punches.csv


Enable and configure eslint-plugin-import rules

Description for CAW-8
Enables a starting set of import-related ESLint rules.
Rules

sort-imports

Configured to sort named imports alphabetically, case sensitively
e.g. import { A, B, a, b } from "."

import/export

Configured to disallow exporting of default or named exports multiple times

import/order

Configured to sort import statements alphabetically, ascending (A-Z) by filename, and grouped to indicate distance from importing file
e.g. external packages, then distant relative paths, then siblings

import/newline-after-import

Configured to require a newline after the full set of import statements

import/no-duplicates

Configured to disallow two separate import statements from the same place

// not allowed
import { A } from "react"
import { B } from "react"
// allowed
import { A, B } from "react"

import/no-useless-path-segments

Disallow import paths that include useless information like the trailing index.tsx

👩🔬 Test Instructions

Run npm run test:lint

🔎 Reviewer Checklist

Checked off by the PR Reviewers

Required

These always need to be checked

[x] Merge destination is correct
[x] Code is correct as understood and conforms to quality standards
[x] Tests have been added where appropriate (unit, visual, end-to-end)
[x] Acceptance Criteria have been met

Roles & Responsibilities
👨💻 Assignee

Initiator of this PR (be sure to set in GitHub UI)
Addresses feedback and change requests
Merges PR once approved (usually deletes branch unless develop or release)

👩💻 Reviewer

Invited to review PR by Assignee (via GitHub UI)
Is expected to complete a review and address followup

@roblafeve
Note that this does not include a rule about named/default exports. I think the feasibility of that rule should be evaluated separately.


Display tag suggestion if the tag has content

When displaying suggestions for user input in the URI bar, we should only display tags that have content so that the user does not end up opening a tag page with no content to display.

Would this be done in redux? The desktop app would need something similar.


[Question]: How to get the raw SQL queries generated when using SubQuery Engine?

Question Validation

[X] I have searched both the documentation and discord for an answer.

Question
I have built Natural Language to SQL-based ChatBot for a dataset I'm having by utilizing LlamaIndex's SubQuestionQueryEngine. I'm able to get the response to my complex queries as well. However, even after analyzing the run logs and extracting from the response object, I'm NOT able to find the raw SQL query that was run against my table.
I have tried setting synthesize_response=False while creating the SQLTableRetrieverQueryEngine, however, it is throwing a key error if I try to extract the query from metadata as suggested in this discord thread.
Here's my code for reference:
# Create an instance of the SQLTableRetrieverQueryEngine class using the SQLDatabase object and object index
sql_query_engine = SQLTableRetrieverQueryEngine(sql_database,
                                                obj_index.as_retriever(similarity_top_k=1),
                                                synthesize_response=False
                                                )

# Define a list of query engine tools
query_engine_tools = [
    QueryEngineTool(
        query_engine=sql_query_engine,
        metadata=ToolMetadata(
            name="Customer Loan Database",
            description="Database containing the Loan Application Data table"
        )
    )
]

# Create a subquery engine using the query engine tools, service context, and enabling asynchronous execution
subquery_engine = SubQuestionQueryEngine.from_defaults(
    query_engine_tools=query_engine_tools,
    service_context=service_context,
    use_async=True
)

Please help me print the individual SQL queries too. Thanks!

Hello sumit did you find answer on how to do this?


DNN-6818 - Added logic to check is DisplaySearch setting has a valid boo...

...lean value or not

merging into 7.4.2 and cherrypicking into release/7.4.1


FIX: Treat missing field maps as empty list instead of None

Changes proposed in this pull request
When field maps are ignored or unavailable, the associated variable is an empty list, but most bools associated with the field maps (i.e., use_fieldwarp) assume that they're None.

Closes #1818.
Replaces all uses of fmaps is not None with bool(fmaps) in workflows/bold/base.py.

Documentation that should be reviewed

The generated boilerplate should now have "the transforms to correct for head-motion" instead of "a single, composite transform to correct for head-motion and susceptibility distortions" when field maps are ignored or not present in the dataset.

Tests appear to be failing because of the bump of sdcflows to 0.1.2, where init_sdc_wf dropped the bold_meta argument.

Yes, when field maps are ignored the generated boilerplate now has

The BOLD time-series (including slice-timing correction when applied)
were resampled onto their original, native space by applying
the transforms to correct for head-motion.

instead of

The BOLD time-series (including slice-timing correction when applied)
were resampled onto their original, native space by applying
a single, composite transform to correct for head-motion and
susceptibility distortions.

I don't know the downstream effects in init_bold_std_trans_wf, init_ica_aroma_wf, init_bold_t1_trans_wf, but they can only fix possible bugs, right?


[DO NOT MERGE] Investigating performance regressions on service-invocation-grpc

Signed-off-by: Marcos Candeia<EMAIL_ADDRESS>Description

Issue reference

Please reference the issue this PR will close: #[issue number]
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[ ] Code compiles correctly
[ ] Created/updated tests
[ ] Unit tests passing
[ ] End-to-end tests passing
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Specification has been updated / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Provided sample for the feature / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

/ok-to-perf

/ok-to-perf

/ok-to-perf

@yaron2 seems that this is the root cause of the lantency increases
The test is asserting that the latency on p90 is <=2.5ms.
Considering that our logs are allocating memory (thanks to @ItalyPaleAle to confirm that) and logging itself is not cheap (i.e more memory to flush, GC pressure, etc), that makes sense to me. Coincidentally, @ItalyPaleAle has already opened a PR to fix this (for other reasons), that should be sufficient. Let's wait for the tests results there.

@yaron2 seems that this is the root cause of the lantency increases
The test is asserting that the latency on p90 is <=2.5ms.
Considering that our logs are allocating memory (thanks to @ItalyPaleAle to confirm that) and logging itself is not cheap (i.e more memory to flush, GC pressure, etc), that makes sense to me. Coincidentally, @ItalyPaleAle has already opened a PR to fix this (for other reasons), that should be sufficient. Let's wait for the tests results there.

We are deprecating the method, and thus we must log an entry for it. I'm not sure removing the log is the correct solution.

He's not removing the log however, he's just logging it only once instead of per-request, If I'm not wrong: https://github.com/dapr/dapr/pull/5740/files#diff-ce3f68305f0eb28b6b8911c281186536c80d8cac9dff3cece2c8bdf3dd955315R423

Yeah I saw it, will comment there.

Perhaps a proper solution would be update the test to use the new method?

That needs to be done anyway, as it's a deprecated path now and will be removed in 1.12.


[ANCHOR-342] Add type to clients configuration

PR Checklist
PR Structure

[ ] This PR has reasonably narrow scope (if not, break it down into smaller PRs).
[ ] This PR avoids mixing refactoring changes with feature changes (split into two PRs
otherwise).
[ ] This PR's title starts with name of package that is most changed in the PR, ex.
paymentservice.stellar, or all or doc if the changes are broad or impact many
packages.

Thoroughness

[ ] This PR adds tests for the most critical parts of the new functionality or fixes.

What
Add type field to the client configuration. The required fields will change according to the type assigned.
Why
To clearly distinguish the custodial and noncustodial wallet clients.

Reference Server Preview is available here:https://anchor-ref-pr967.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr967.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr967.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr967.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr967.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr967.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr967.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr967.previews.kube001.services.stellar-ops.com/


[CI] add the missing branch env var for ECR push

Motivation
This fixes the issue in https://app.circleci.com/pipelines/github/libra/libra/31904/workflows/b1a835f8-5006-46cc-95dc-579f8d51bc46/jobs/225120
Test Plan
Canary https://app.circleci.com/pipelines/github/libra/libra/31920/workflows/954d25f4-3600-4eff-8aaa-4e1f24a96e7f

/land


Chrisda to Master

Docs Build status updates of commit 6520ab1:
:clock10: Pending: waiting for processors (5 builds ahead of you)
:warning: Docs Build is busy, currently there are 5 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 6520ab1:
:clock10: Full build: the average full build time is 17 min(s) 37 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit be1fbf8:
:clock10: Pending: waiting for processors (5 builds ahead of you)
:warning: Docs Build is busy, currently there are 5 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 6520ab1:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Disable-SafeAttachmentRule.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Enable-SafeAttachmentRule.md
:white_check_mark:Succeeded
View (exchange-ps)

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

exchange/exchange-ps/exchange/Get-SafeAttachmentRule.md
:white_check_mark:Succeeded
View (exchange-ps)

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

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

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

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

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

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

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

exchange/exchange-ps/exchange/Remove-SafeAttachmentRule.md
:white_check_mark:Succeeded
View (exchange-ps)

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

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

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

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

Docs Build status updates of commit be1fbf8:
:clock10: Full build: the average full build time is 17 min(s) 37 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit be1fbf8:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/docs-conceptual/connect-to-exchange-online-powershell.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Disable-SafeAttachmentRule.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Enable-SafeAttachmentRule.md
:white_check_mark:Succeeded
View (exchange-ps)

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

exchange/exchange-ps/exchange/Get-SafeAttachmentRule.md
:white_check_mark:Succeeded
View (exchange-ps)

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

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

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

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

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

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

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

exchange/exchange-ps/exchange/Remove-SafeAttachmentRule.md
:white_check_mark:Succeeded
View (exchange-ps)

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

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

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

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

Docs Build status updates of commit 35639fb:
:clock10: Full build: the average full build time is 17 min(s) 38 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit 35639fb:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/docs-conceptual/connect-to-exchange-online-powershell.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Disable-SafeAttachmentRule.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Enable-SafeAttachmentRule.md
:white_check_mark:Succeeded
View (exchange-ps)

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

exchange/exchange-ps/exchange/Get-SafeAttachmentRule.md
:white_check_mark:Succeeded
View (exchange-ps)

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

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

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

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

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

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

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

exchange/exchange-ps/exchange/Remove-SafeAttachmentRule.md
:white_check_mark:Succeeded
View (exchange-ps)

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

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

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

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


Thread-safe prediction by making the prediction cache thread-local.

Also remove prediction cache mutex, which did not help: a race
condition still occured whenever the cache was cleaned but at the
same time entries pointing into the cache were alive.

@boxdot Could you please elaborate on this a bit more?  How can I trigger a race condition in current code base.

entries pointing into the cache

The PredictionCacheEntry?  The data has to go out of scope before the entry does right?  In which case data passed into Learner::Predict goes out of scope before the entry does?

Sorry for the late response, I was on vacation. I added a test to pin data races by using thread sanitizer. Looks like there are still data races. When I have them all I'll describe the problems.

@boxdot Be careful that Thread sanitizer doesn't do well with openmp.  It will generate a lots of false positive.

@boxdot Could you please elaborate on this a bit more? How can I trigger a race condition in current code base.

I added a test which triggers a race.

The PredictionCacheEntry? The data has to go out of scope before the entry does for triggering a race right? Could you please guide me through the case that, data passed into Learner::Predict goes out of scope before the entry does?

this->PredictRaw(data.get(), &prediction, training, ntree_limit);

in learner.cc:1018 modifies the cache entry. This can happen from different threads at the same time. Even the cache retrieval method Cache is thread-safe, the read/write access to cache entries is not. If you want, I can also add my thread sanitizer output.

@boxdot Be careful that Thread sanitizer doesn't do well with openmp. It will generate a lots of false positive.

Thanks, I also figured that out. :) I run thread sanitizer with disabled OpenMP, and now it looks good.

Testing rejected. Reason: Today's spending (56.52 USD) exceeded the budget (50.00 USD) allocated for today! The spending limit gets reset every midnight UTC. You can monitor the spending at the dashboard https://xgboost-ci.net/dashboard/.

It looks like we've hit today's cloud budget. The tests hosted on Jenkins will not run. We'll re-run these tests in 16 hours.

in learner.cc:1018 modifies the cache entry. This can happen from different threads at the same time. Even the cache retrieval method Cache is thread-safe, the read/write access to cache entries is not.

That helped a lot.  Looks good to me in general.  Thanks for fixing the data race.

@hcho3 Marked blocking.  I will try to push to this if needed.

Looking into the failing tests.

@boxdot I made the cache local to each learner.  Could you please take a look?

Thanks, let me keep fixing it.

@boxdot I made the cache local to each learner. Could you please take a look?

Ah, very nice, this is much better. My colleague, @VeaaC, pointed out that it might be a problem with the Singleton implementation (no modern thread local), that it would leak unused cached. This is solved now, as far as I understand.

Codecov Report

Merging #5853 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #5853   +/-   ##
=======================================
  Coverage   78.11%   78.11%
=======================================
  Files          12       12
  Lines        2979     2979
=======================================
  Hits         2327     2327
  Misses        652      652

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 8d77027...472ec52. Read the comment docs.

@boxdot Thanks for fixing the race condition!


Add auto-create chat when a match is generated

Auto create chats when a match is generated

Update: Due to the update in our model. I wonder if we would like to close this issue or re-define our scope to be "add auto-create chat when a tournament is generated" @rqueiroz20

Update: Due to the update in our model. I wonder if we would like to close this issue or re-define our scope to be "add auto-create chat when a tournament is generated" @rqueiroz20

This is a good idea, I will update the title right now.

@rqueiroz20 Are you still able to do this PR before the Soft Freeze? If not, we will have to push it to back log

Yes I am, I just finished the code for it now. Will push my branch now.

Issue Score: Excellent
Comments:
Nicely implemented auto-creation of chat!


Move Client.Watch inside Client.Attach

What this PR does / why we need it:
Move Client.Watch() inside Client.Attach() to hide it from external interface.
This PR also introduces Client.Subscribe() which performs similar functionality with other SDKs.
This PR is recreated from https://github.com/yorkie-team/yorkie/pull/593
Which issue(s) this PR fixes:

Fixes #584
Special notes for your reviewer:
I prefer keeping this PR size as small as possible to wrap up this task on time.
Does this PR introduce a user-facing change?:

Go SDK user will use `Client.Subscribe()` instead of `Client.Watch()`, just like other SDKs.

Additional documentation:

Checklist:

[x] Added relevant tests or not required
[x] Didn't break anything

Thank you for your contribution. In JS SDK, there is also a setting for SyncMode as shown in the link below. How about applying them together?
https://github.com/yorkie-team/yorkie-js-sdk/pull/772#pullrequestreview-1988728945

Is the syncMode feature big? Like I mentioned, I want to keep this PR small.

@krapie, @karockai Thank you for your contribution.


Sound issues on iPad iOS 15+

I am using WebRTC for a long time now. The main reason I am started using it was the lag issue and the no sound issue of my Foscam camera with Home Assistant.
Lately I am having issues with the sound on our wallmounted iPad, that the sound is doing crazy. I hear a lot of noises but not the sound of my son for example. I already re-downloaded the master version or deleted the integration from hacs and reinstalled it. Also used the add-on in HA, but the problem didn't solved my issue. On my mobile with the dedicated HA app I don't have the problem. Anyone can help with it?

Any response someone?

The stream is WebRTC or MSE?

Streaming is webrtc. I am using the config of webrtc with the rtsp path. What do you mean with MSE?

https://github.com/AlexxIT/WebRTC#status-icons

I am using the webrtc on the dedicated app on iOS.

What version of OS is on your mobile phone? What is your camera model?

On my phone is 15.4.1 and on the wallmounted ipad is 15.3.1.
Model of camera is: Foscam C1

Sound problems seem to be quite common with Apple devices
https://github.com/AlexxIT/WebRTC/issues/163
I don't know solution yet. You can try the built-in HA component. Maybe it don't have this problems
https://www.home-assistant.io/integrations/rtsp_to_webrtc/

It also have the same issue 😩. I already try that one out. It worked for almost a year perfectly. Then I will check it out myself thanks Alex.

Its working with the new iOS firmware 15.4.1. Thanks for the effort Alex!


Unable to import Node builtins

Steps to reproduce
Repro URL:
https://github.com/joshwcomeau/pigmentcss-fs-issue

Run npm run dev
Note the issue in the terminal:

EvalError: Unable to import "fs/promises". Importing Node builtins is not supported in the sandbox.

Context
In my project, I'm using the fs/promises module to load MDX content. This obviously wouldn't work in-browser, but I'm doing this specifically inside a Server Component, within the next.js App Router. So none of this code is included in the client-side bundles.
It seems as though Pigment is unable to load any Node built-ins, but I don't think it has to; I don't think any of this stuff affects the generated CSS.
I also realize that this is likely an issue with @wyw-in-js, rather than Pigment CSS itself, but I wanted to highlight it here since that repo doesn't seem active.
Your environment

npx @mui/envinfo
  System:
    OS: macOS 14.5
  Binaries:
    Node: 20.16.0 - ~/.nvm/versions/node/v20.16.0/bin/node
    npm: 10.8.1 - ~/.nvm/versions/node/v20.16.0/bin/npm
    pnpm: 9.1.4 - ~/Library/pnpm/pnpm
  Browsers:
    Chrome: 128.0.6613.138
    Edge: Not Found
    Safari: 17.5

Search keywords: import, Node, fs, sandbox

Thanks for the report. I'll check this out. Ideally, if something is imported and not used in the css directly, wyw-in-js should tree-shake it before evalutating the code for css.

Not sure if you have tried this with the latest versions of Next.js and Pigment CSS. I tried with @joshwcomeau's repo and I was getting a different error (after updating Nextjs to 15.0.2 and Pigment to 0.0.25) -

which meant that this one was not about sandbox. It wasn't able to find the file relative to itself. So as a workaround, I passed the root directory with src through an env var in next.config.mjs.
// next.config.js
import * as path from "path";
import { withPigment } from "@pigment-css/nextjs-plugin";

const nextConfig = {
  env: {
    DATA_DIR: path.join(process.cwd(), "src"),
  },
};

export default withPigment(nextConfig);

and in the file where you want to read it's contents, I did -
import * as path from "path";
import fs from "fs/promises";

export async function loadContent() {
  const data = await fs.readFile(
    path.join(process.env.DATA_DIR as string, "data.txt"),
    "utf-8",
  );
  return data;
}

This worked and the app built successfully. I am stating this as a solution as I am also doing the same thing for our Pigment CSS docs where we'll be authoring content in MDX and reading the contents through the fs module. Here's the code.
One thing to note here is that as long as your function where you are using built-in modules are not being called at the file scope, rather somewhere inside one of the next.js primitives, it should be fine. Here's an example -
function loadContent() {
}
const content = await loadContent();

export default function PageComponent() {
  return
{content}
;
}

This will throw an error because loadContent() is being called at the file scope.

function loadContent() {
}

export default function PageComponent() {
  const content = await loadContent();
  return
{content}
;
}

This should work as the actual call is inside another function.
@mathieuhasum Can you follow the above and see if it works for you ?


Add percentage completion in the options page

The options page currently shows all the pages whose scroll positions have been saved.

It can be improved to show the amount of the page that is completed in form of percentage or progress bar.
For this, you'll need to store the total scrollable length of the page as well while storing the scroll position as well.

Hey, I want to work on this issue.

I think we can close this now.

Yeah right, forgot to close this. Thanks again @shikharsaxena98 👍


add support local LLM integratgion

#GPT4 is not the state of the art! It was besiged by Dromedary two months ago. Please for the sake of data protection refer to models that can be run on your own hardware. There are several purpose specific models that outperform OpenAI freely available on HuggingFace.

#GPT4 is not the state of the art! It was besiged by Dromedary two months ago. Please for the sake of data protection refer to models that can be run on your own hardware. There are several purpose specific models that outperform OpenAI available on HuggingFace.


Feature/locate multiple beacons

Concurrent error is given during loop if iterators list is modified same time.

Codecov Report

Merging #9 into master will increase coverage by 13.8%.
The diff coverage is 60.71%.

@@             Coverage Diff              @@
##             master       #9      +/-   ##
============================================
+ Coverage     22.97%   36.78%   +13.8%
- Complexity       14       28      +14
============================================
  Files             6        7       +1
  Lines           222      261      +39
  Branches         10       14       +4
============================================
+ Hits             51       96      +45
+ Misses          171      162       -9
- Partials          0        3       +3

Impacted Files
Coverage Δ
Complexity Δ

...ava/fi/helsinki/btls/services/LocationService.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...in/java/fi/helsinki/btls/services/MqttService.java
73.33% <68.75%> (+34.87%)
8 <6> (+6)
:arrow_up:

src/main/java/fi/helsinki/btls/domain/Beacon.java
75% <75%> (ø)
3 <3> (?)

...java/fi/helsinki/btls/domain/ObservationModel.java
58.82% <0%> (+58.82%)
5% <0%> (+5%)
:arrow_up:

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 d4a2e3f...771c12a. Read the comment docs.


DBZ-3377 Restart Oracle connector on ORA-01291, missing logfile

https://issues.redhat.com/browse/DBZ-3377

Applied, thx!


CXXCBC-494: fix memory issue in range scan implementation

We must be careful when invoking items callback for the range scan results, as the whole iteration might be canceled after any of the invocation. The library should not be calling any callbacks on canceled request to avoid memory issues.
In particular the test "integration: range scan cancel during streaming using pending_operation cancel" uses stack-allocated vector for results, and cancels request during itertion. The range scan completed, but the library might still call the items callback, which will try to insert items into deallocated result vector.

jenkins, test this please


Need bulk change of ownership

It needs to be possible -- when migrating data -- to add an owner to a large set of resources.

this issue is solved with This PR?
3625 bulk add owner #3626

Released to Production https://github.com/hydroshare/hydroshare/issues/3643


Missing information about IP packet forwarding config changes in tutorial

It turns out this tutorial is missing one vital piece of information in order for the solution to work. This is in regards of configuring for IP forwarding in the OS on the backend servers. This might be obvious for the seasoned engineer, but not necessarily for an engineer not well versed in networking topics.
I propose the following change:
The change needs to be performed in the OS. For Linux (Ubuntu) you need to make a change in the /etc/sysctl.conf file. Uncomment the line net.ipv4.ip_forward=1 to enable packet forwarding for IPv4.

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

ID: 0ad13676-0e4b-6e1d-bd9c-e7b6e6698da9
Version Independent ID: 37f5f9b3-c78e-78ff-7d94-ea70c2958ed7
Content: Access on-premises SQL Server from Data Factory Managed VNet using Private Endpoint - Azure Data Factory
Content Source: articles/data-factory/tutorial-managed-virtual-network-on-premise-sql-server.md
Service: data-factory
Sub-service: tutorials
GitHub Login: @lrtoyou1223
Microsoft Alias: lle

@RuneORakeie
Thanks for your feedback! We will investigate and update as appropriate.

@lrtoyou1223
Could you please review add comments on this, update as appropriate.

@RuneORakeie
Thank you for bringing this to our attention.
I've delegated this to content author @lrtoyou1223, who will review it and offer their insightful opinions.

Thanks @RuneORakeie for your dedication to our documentation. Unfortunately, at this time we have been unable to review your issue in a timely manner and we sincerely apologize for the delayed response. The requested updates have not been made since the creation of this issue, and the timeline for resolution may vary based on resourcing, so we've created an internal work item to incorporate your suggestions. We are closing this issue for now, but feel free to comment here as necessary. #please-close


SPE11c

Hello, I tried to run the SPE11c model but faced the following issue. Can you please help me to resolve it? The screenshot of the error message is attached below:

Hei,
It seems it is a memory issue https://github.com/OPM/opm-simulators/issues/4836#issuecomment-1706797492
This could be confirm if the case with less cells runs https://github.com/OPM/pyopmspe11/blob/main/examples/hello_world/spe11c.txt

Thank you for the reply. What is the size of the memory you recommend to use in order to run the full scale simulation for SPE11C?

What is the size of the memory you recommend to use in order to run the full scale simulation for SPE11C?
This is a non-trivial question that I hope the benchmark will answer in the end. The memory size scales with the number of grid cells, so the question is what resolution is sufficient to capture the CO2 dense fingers in the brine sufficiently accurate. A classical grid-convergence study may but require access to large super-computer resources. I would suggest you start testing on a coarse grid (just change the input file for the c case) that fits your current memory in your VB.


Remove Hosting dependency

https://github.com/aspnet/Identity/blob/dev/src/Microsoft.AspNet.Identity/project.json#L8

3e9433639021255c1373c9a4bd36c4a511982d18


Documentation enhancement for a truly portable environment

First, thank you the existing documentation!! I would like more detailed information for creating a portable VS Code environment with a python virtual environment. If something like this exists somewhere I would be ecstatic to read it, but can you also add a link from the VS Code Portable Mod page to it?  Hopefully, I'm including all the relevant info and apologies for any confusing wording ahead. I have some mental fog due to chronic fatigue/arthritis.
First steps: I first posted to Stackoverflow and got one person trying to help, my stackoverlow post. They provided links to information I had already read but didn't find enough new info to help: Global, Virtual, and Conda Environments and Getting Started>Settings.
Other pages I read:
-VS Code Setup>Windows,
-VS Code Portable Mode. Side Note: RFE "Portable Mode" is misleading since the info provided is merely for running from a different drive of a single machine. For it to be a portable mode, it needs to accomodate a variable mount point on any machine. For example, I thought using ${workspaceFolder} in the VS Code settings.json files would stand in for a variable drive but it didn't seem to work.
-VS Code Python Environments
Hardware setup: Windows 10 OS. I am working with a HP laptop workstation and a small SurfaceGo that I switch back and forth on for day and night time work. On the HP laptop, the USB mounts to the F:\ drive with the user name "Dev". On the SurfaceGo the USB mounts to the D:\ drive with the user name "megha".
Software setup: Initially setup everything from the HP workstation. "VSCode-win32-x64-1.49.0.zip" was unzipped to F:\Programs\Microsoft\VS Code. Also did a custom install of "python-3.8.6rc1-amd64.exe" to F:\Python\Python38; checked marked "Add to Path". My code development is located at F:\MyProject.
Cleanup: I removed C:\Users\Dev\.virtualenvs\, C:\Users\Dev\.vscode\, C:\Users\Dev\AppData\Local\Programs\Microsoft VS Code, C:\Users\Dev\AppData\Roaming\Code, F:\Programs\Microsoft VS Code\data\user-data\User\settings.json, F:\MyProject\.venv\, F:\MyProject\.vscode\, F:\MyProject\rr.code-workspace.
Usual VS Code/Python environment setup:
from powershell.
pipenv automatically installs to :\Users<user>.virtualenvs even after the venv command. Therefore I've been using py -m pip install -t ...
> cd F:\MyProject
> py -m venv --system-site-packages .venvHP
> py -m pip install -t .\.venvHP\Lib\site-packages\ -r .\requirements.txt
> py -m pip install -r requirements
> & "F:\Programs\Microsoft VS Code\code.exe" .

from VS Code

File > Open Folder
File > Save Workspace as (rr.code-workspace)
Termial > New Terminal
Ctrl+Shift+P to add new .venv\Scripts\python.exe interpreter

I can get VS Code/Python venv set up and working for one machine but after trying to make accommodations in the settings.json files (MyProject\.vscode, Microsoft VS Code\data\user-data\User) by changing F:\MyProject to ${workspaceFolder} I got stuck. I'm not sure where else changes need to be made.
Goal: I would like a way to set up my environment to actually be Portable between machines. I would prefer no VS Code settings show up in any of my ~\<user>\ folders on the hard drives. Is it possible to do this?
Side Note: RFE If it is possible to for VS Code to work with a variable USB mount point, can there be instructions for addressing that? Is there a way to do it without having to download too much to the hard drive? There are probably more places than settings.json that need adjustment, but VS Code Portable Mode page doesn't discuss it or have links to relevant info.
It would also be useful if the docs were written in a more sequential fashion rather than scattered bits and pieces.
Unanswered questions:

Do I need to create individual python virtual environments for each separate computer?
Do I need separate .vscode\settings.json files for each environment? And if so how exactly do I activate each one within VS Code. How does that look directory-wise? See the Directory Maps below.
While I can run <usbdrive>:\Python\Python38\python.exe from both machines, it requires using "python-3.8.6rc1-amd64.exe" to do a full custom install to the USB for each machine, I assume in order to get all the registry and pathing setup for the most part. Does that sound correct? Does this cause any problems for VS Code?

Directory Map 1
-MyProject\
    -.venvHP\
    -.venvGo\
    -.vscode\
      settings.json
      settings-HP.json  ***assume I would copy this to settings.json when using HP***
      settings-Go.json  ***assume I  would copy this to settings.json when using SurfaceGo***

Directory Map 2 the method below would mean copying my programming code between them. This way doesn't make sense to me, so pretty sure I'm off track here.
-MyProjectHP\
    .venv\
    .vscode\
-MyProjectGo\
    .venv\
    .vscode\

Not sure why this was assigned to me or whether it's actually possible. @kieferrm?  If it's possible, we can move this to vscode-docs and assign the author of the original article.


R2 calval datasets

Purpose

Update the CalVal input lists for RTC and CSLC processing

Proposed Changes

Added a number of scenes to the default input dataset -- these were added throughout R2 CalVal

Issues
NA
Testing

Repeated processing has been completed on this set of SLC inputs

@niarenaw , @Alex-Lewandowski - how does this pull request relate to the Processing Requests submitted last week (issues 17 - 30 in this repository)?
I assume this PR makes the calval datasets complete?