REST pistache server not always capturing REST requests

Hello,
I Wrote a REST Server based on Pistache, integrated in a multithreaded application, and the submitted REST requests should contain data structured as a google protocol buffers. Sometimes, the server captures the incoming requests and sometimes it not capturing.
Can anyone help me please ??
This is my code :
`***********************************
RESTHandler.hxx
#include "pistache/endpoint.h"
using namespace Net;
class RESTHandler : public Http::Handler
{
public:
RESTHandler();
~RESTHandler();
HTTP_PROTOTYPE(RESTHandler)
void onRequest(const Http::Request& request, Http::ResponseWriter response);
};
RESTHandler.cxx
#include "RESTHandler.hxx"
using namespace Net;
RESTHandler::RESTHandler() {}
RESTHandler::~RESTHandler() {}
void RESTHandler::onRequest(const Http::Request& request, Http::ResponseWriter response)
{
response.send(Http::Code::Accepted, "202 Accepted!! \n");
}
MyProgram.hxx
#include "RESTHandler.hxx"
using namespace Net;
class MyProgram
{
private:
static bool end;
public:
MyProgram();
~MyProgram();
static bool launchRestServer();
static void* restListener(void* params);
}
MyProgram.cxx
#include "MyProgram.hxx"
#include <boost/thread.hpp>
#include <boost/chrono.hpp>
MyProgram::end=false;
MyProgram::MyProgram()
{
launchRestServer();
}
MyProgram::~MyProgram()
{
end = true;
}
void* MyProgram::restListener(void* params)
{
std::shared_ptrNet::Http::Endpoint server = *((std::shared_ptrNet::Http::Endpoint *)params);
auto opts = Http::Endpoint::options().threads(1);
opts.flags(Tcp::Options::ReuseAddr);
server->init(opts);
server->setHandler(std::make_shared());
server->serveThreaded();
}
bool MyProgram::launchRestServer()
{
Net::Address addr(Net::Ipv4::any(), Net::Port(9080) );
std::shared_ptrNet::Http::Endpoint restServer(std::make_sharedNet::Http::Endpoint(addr));
cout << "Initializing a REST server on port " << restPort << endl;
boost::thread m_Thread= boost::thread(restListener,  (void*)&restServer);
while (true)
{
if (end)
break;
}
restServer.shutdown();
return true;
}

Hello,
Do you mean that sometimes your handler gets called, and sometimes it does not get called when you send requests ?
Could you please post a sample of the requests your are sending so that I can reproduce it on my side ?

Hello,
Thanks a lot for your answer ans sorry for the delay to reply !
Yes, when i send requests, sometimes my handler gets called, and sometimes, it doesn't get called. The requests are sent from a Java application being deployed on a Wildfly 9 server, so i'm not able to give you its code, but i have captured with wireshark packets in case of  successful case and fail case (in attachment text files, i tried to put wireshark captures in pcap in a zip, but i couldn't download it).
Thank you really for your help, i'm blocked on this issue !
failTest.txt
successTest.txt

Hello,
I am working with Nabila on this project and I'm coming back to you since the problem is still occuring. We have done some Wireshark captures and I will link mine in this message.
As you;ll be able to see in the captures it seems that when it is not working right my client wait for 5 seconds for an Accepted response, finding none my client close the connection.
Hopping this will help you figure out the problem.
WiresharkTraces.zip


[v4] Fallback to full reload if React version doesn't support Fast Refresh

fix #9807
Changes
Fallback to the full reload if React version doesn't support Fast Refresh

Overwrite FAST_REFRESH to false if the current react version doesn't support (< 16.10.0)
Remove Fast Refresh warning on the older react version since we will automatically fallback to do full reload.

Verify steps
Default setup

yarn create-react-app my-app
yarn start
Modify App.js content
The app gets updated through Fast Refresh

FAST_REFRESH=false

Start the app by using FAST_REFRESH=false yarn start
Modify App.js
The app should do a full reload

React version that Fast Refresh is unavailable (e.g. 15)

Change React version to 15.7.0

yarn add<EMAIL_ADDRESS><EMAIL_ADDRESS>Remove <React.StrictMode> from index.js

yarn start and
Modify App.js
The app should do a full reload

We took a different approach in #9861 by attempting to import react/jsx-runtime as recommended by the React team. They have back-ported support to a number of major releases.
Thanks for the PR!

@ianmcnally I think this one is different from #9861.
This is more about detecting if the React version is supporting Fast Refresh or not, otherwise, it will fall back to full reload.
As I understand, #9861 is more on jsx-runtime.

Ah, apologies I confused the two.

@ianschmitz Dun worry! 😄  Should I create another PR for this or just leave it here?

@ianschmitz
I moved to #9971 since this has duplicated fixes with others, and I have messed up this branch.


Firefox's tracking protection can interfere with feed requests

Icon for livemarks shows up for reddit.com homepage but live feed preview displays nothing and it doesn't pull anything into the bookmark. (site url or feed). I originally imported this using the firefox generated opml file then deleted and manually tried to add https://www.reddit.com/.rss
any suggestions?

the issue is because of "tracking protection" feature in FF. i disabled it and now it works. need more debugging to see how to get around this without disabling the whole feature

@evilpie Maybe we could add a notification when a feed failed to fetch ? With an indication that tracking protection might be behind the problem

Filed a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1514054

It seems like we can start prompting optional permissions for the hosts we want to bypass tracking protection from.

I'm working on a way to work around this.

How do I whitelist Reddit so that the extension works? I clicked the shield icon while on the subreddit in question and selected to disable on this page, but the RSS feed still does not load.

Black Menu for Google opens up an extension page that allows you to unblock content blocking. Maybe that can be used here:

This should now finally be fixed in Firefox 77 by https://bugzilla.mozilla.org/show_bug.cgi?id=1629436.

@evilpie Thanks for following and updating the issue!


Recommended approach for logging?

Good day,
@kares is helping to develop some improvements to the has-guarded-handler gem that we plan to push to a PR soon.  They include detection of ConcurrencyError conditions that should not occur under normal circumstances.
What would be the recommended method of introducing the concept of logging to this gem?  We're hesitant to reference pb_logger, logger or any other construct that would infer specific dependencies.
Wondering what thoughts are on the matter of having loosely-coupled logging.
Thanks very much!

Two potential approaches we could take that I thought of.  I prefer option 2.  Thoughts?
1.) trigger :log events using HasGuardedHandlers itself
Allow consumers to optionally register and implement handlers for :log events however they choose.
Pro: Fits the HGH way of things
Con: Would be difficult to log events within methods like trigger_handler without the risk of infinite recursion
2.) Create and use an overridable hgh_logger NullObject
Using an approach similar to the pb_logger from Adhearsion 2.x & Punchblock 2, provide a dummy logger object that can later be overridden.

@benlangfeld @bklang Any recommendations on how best to handling logging from within has-guarded-handlers?

My opinion: Option 2 is more conventional, the way I've seen it done in other libraries. That would be my vote.


standardize binder cache store

Fist half of the second step of https://github.com/kubewharf/godel-scheduler/issues/45
Standardize binder cache implementation based on the common store interface.

lgtm overall, just nits

@lzlaa Could you also help take a look at this PR when getting a chance? Thank you.

@NickrenREN Could you help merging this PR? Thanks.


Modernize when_all and friends (when_any, when_some, when_each)

This also moves those facilities into namespace hpx and deprecates the same in namespace hpx::lcos

bors merge


[SPARK-45039][SQL] Include full identifier in Storage tab

What changes were proposed in this pull request?

If you have 2 databases with tables with the same name like:  db1.table, db2.table
scala> spark.sql("use db1")
res8: org.apache.spark.sql.DataFrame = []

scala> spark.sql("cache table table")
res9: org.apache.spark.sql.DataFrame = []

scala> spark.sql("use db2")
res10: org.apache.spark.sql.DataFrame = []

scala> spark.sql("cache table table")
res11: org.apache.spark.sql.DataFrame = []

You cannot differentiate it in the Storage tab

What is proposed is to add the full identifier

With this PR it’s also modified the node name in the sql tab

Why are the changes needed?

Facilitates the interpretation of the Storage tab
Does this PR introduce any user-facing change?

Yes, in the UI
How was this patch tested?

Unit testing and manual tests
Was this patch authored or co-authored using generative AI tooling?

No

CC @cloud-fan

The error in the test does not appear to be related to change

@cloud-fan I made the changes, what do you think? thanks!


clang-tidy auto fixes for braces, using, nullptr and braced return

Summary
Running clang-tidy with the checks below. This refactor is only aesthetic and does not change how any of the code is executed.
readability-braces-around-statements:

Adds braces around conditionals and ifs

modernize-use-using:
everywhere clang-tidy can replace a typedef with a using it will aka
typedef double A; becomes using A = double;
modernize-return-braced-init-list:

Replaces explicit calls to the constructor in a return with a braced initializer list. This way the return type is not needlessly duplicated in the function definition and the return statement.

Foo bar() {
  Baz baz;
  return Foo(baz);
}

// transforms to:

Foo bar() {
  Baz baz;
  return {baz};
}

modernize-use-nullptr:
using nullptr instead of NULL
Tests
refactor is only aesthetic so no new tests
Checklist

[x] Math issue #1308

[x] Copyright holder: Steve Bronder
The copyright holder is typically you or your assignee, such as a university or company. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
- Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
- Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

[x] the basic tests are passing

unit tests pass (to run, use: ./runTests.py test/unit)
header checks pass, (make test-headers)
docs build, (make doxygen)
code passes the built in C++ standards checks (make cpplint)

[x] the code is written in idiomatic C++ and changes are documented in the doxygen

[x] the new changes are tested

@serban-nicusor-toptal
Distribution tests have been running for about 6 hours now with the error below

./runTests.py -j25 test/prob

Cannot contact i-08bc3a088b9f6c8ef: hudson.remoting.ChannelClosedException: Channel "unknown": Remote call on i-08bc3a088b9f6c8ef failed. The channel is closing down or has closed down

Is there some way I can manually kickoff/restart the machine when these sorts of things happen?

On Sep 3, 2019, at 12:17 PM, Steve Bronder<EMAIL_ADDRESS>wrote:
Summary
Running clang-tidy with the following checks adds these new additions
readability-braces-around-statements:
• Adds braces around conditionals and ifs

-1.    But I'll go along if this
is the new standard.

modernize-use-using:
everywhere clang-tidy thinks it can safely swap out typedef for using it will

That seems really unsafe given scoping.  Can you explain more what it does and
what a potential change is going to look like?  Will it work properly with
argument-dependent lookup?

modernize-return-braced-init-list:
Replaces explicit calls to the constructor in a return with a braced initializer list. This way the return type is not needlessly duplicated in the function definition and the return statement.
Foo bar() {
Baz baz;
return Foo(baz);
}
// transforms to:
Foo bar() {
Baz baz;
return {baz};
}

This looks very strange, but I could get used to it.  I find all
this auto stuff a tradeoff between easy understandability and
conciseness.

modernize-use-nullptr:
using nullptr instead of NULL

Good.  We shouldn't be using NULL anywhere.

Tests
refactor so no new tests

We've been trying to add missing tests when we refactor.  But nobody's going
to be able to read through hundreds of munged files, which is why we need
to know the general replacements being done here and how safe they are.

  Should rarely happen tho, will check if the prices have increased.
For how to restart a job, see all the pull requests jobs here
Pick yours and just do Build with parameters here

That seems really unsafe given scoping. Can you explain more what it does and what a potential change is going to look like? Will it work properly with argument-dependent lookup?

In my meta refactor PRs I replaced some of the typedefs with using for type aliases. I think its considered "modern C++". Is it really an issue for argument-dependent lookup?
Example from https://www.internalpointers.com/post/differences-between-using-and-typedef-modern-c
typedef std::map<std::string, std::vector<std::string>> Map;
is equivalent to
using Map   = std::map<std::string, std::vector<std::string>>;
The advantage of using is that it the syntax for cases like the following:
template <typename T>
using str_map<T> = std::map<std::string, T>;

You can do the same with typedef but the syntax is less clean:
template <typename T>
struct str_map {
    typename std::map<std::string, T> type;
};

A lot of the meta template metaprogramming in Stan Math could get cleaned up by this if we want to do it. I was planning on doing this but held off waiting for the meta flattening. But it seems that Steve will be able to do the work for me with a script :)

Never mind.  This PR is doing the opposite of what I thought it was doing.  It's replacing typedefs with using statements not vice-versa.  E.g.,
typedef stan::math::fvar<T> ReturnType;

is being replaced with
using ReturnType = stan::math::fvar<T>;

but
  using std::exp;

is left unchanged.

-1.    But I'll go along if this
is the new standard.

There's more than one place where we do something like
if (blah)
  for (blahblah) {
// doing stuff
}

imo I usually have to read that sort of thing twice.
More vertical space and indents can be a bit annoying but I do like that scope is given a bit nicer

Never mind. This PR is doing the opposite of what I thought it was doing. It's replacing typedefs with using statements not vice-versa. E.g.,

Yes sorry for the poor wording, I updated it in the docs

(the braced init lists) This looks very strange, but I could get used to it.  I find all
this auto stuff a tradeoff between easy understandability and
conciseness.

Yeah, it's more "dry" but I'm sort of indifferent one way or the other on this one

We've been trying to add missing tests when we refactor.  But nobody's going
to be able to read through hundreds of munged files, which is why we need
to know the general replacements being done here and how safe they are.

This refactor shouldn't change how any code is executed since they changes are only aesthetic. Is there any more info you need on this one that is not provided in the summary at the top? I edited it just now to include links to the clang-tidy check descriptions

Can that misalignment of the last closing brace happen in clang-format?  If so, that's too bad.
In any case, I agree thta we should have braces in cases like this conditional, even though they're not technically necessary:
if (a > b) {
  for (int i = 0; i < I; ++i) {
  ...
  }
}

What will this do to a one-liner like:
if (a > b) c = 3;

Will it just add braces
if (a > b) { c = 3; }

or will it turn it into a three-liner:
if (a > b) {
  c = 3;
}

Anyway, I don't care about this enough to have a long dragged-out discussion of it if we can make whatever you want to do happen automatically.  I'll start a new project if I want to get my way on everything. :-)

Anyway, I don't care about this enough to have a long dragged-out discussion of it if we can make whatever you want to do happen automatically. I'll start a new project if I want to get my way on everything. :-)

Stan' 4: Electric Boogaloo
This script takes like 5 minutes to run so I'm gonna open up a new branch with separate commits for each. So if we are like "Actually I hate this" it's pretty easy to revert out


Don't allow first-round transfers

I'm seeing some results where the first round is a transfer. I think this is the result of the fix for #16. Overall should audit how touched stops are being used.

I think this is fixed, but evaluate.


CodeCommit - NullReferenceException for previously-working credentials in VS2017

Expected Behavior
Open Visual Studio 2017. In Team Explorer, have the projects ready to be opened and worked on under AWS CodeCommit.

Current Behavior
Where "AWS CodeCommit" should be in Team Explorer, the title is instead: "Error".
Where the projects should be is the following exception stack trace:
System.TypeInitializationException: The type initializer for 'Amazon.AWSToolkit.VisualStudio.TeamExplorer.CredentialManagement.TeamExplorerConnection' threw an exception. ---> System.NullReferenceException: Object reference not set to an instance of an object.
   at Amazon.AWSToolkit.VisualStudio.TeamExplorer.CredentialManagement.TeamExplorerConnection..cctor()
   --- End of inner exception stack trace ---
   at Amazon.AWSToolkit.VisualStudio.TeamExplorer.CredentialManagement.TeamExplorerConnection.add_OnTeamExplorerBindingChanged(TeamExplorerBindingChanged value)
   at Amazon.AWSToolkit.VisualStudio.TeamExplorer.CodeCommit.Model.ConnectSectionViewModel..ctor()
   at Amazon.AWSToolkit.VisualStudio.TeamExplorer.CodeCommit.Connect.ConnectionSection.CreateViewModel(SectionInitializeEventArgs e)
   at Microsoft.TeamFoundation.Controls.WPF.TeamExplorer.TeamExplorerSectionBase.Initialize(Object sender, SectionInitializeEventArgs e)
   at Amazon.AWSToolkit.VisualStudio.TeamExplorer.CodeCommit.Connect.ConnectionSection.Initialize(Object sender, SectionInitializeEventArgs e)
   at Microsoft.TeamFoundation.Controls.WPF.TeamExplorer.Framework.TeamExplorerSectionHost.Initialize(Object context)

Possible Solution
I have no idea. I haven't changed anything - I was on a recent version of VS 2017, and AWS Toolkit for VS 2017 & 2019 was on the latest version, and previously this setup has been working since I began using it about 5 months ago.
I tried updating VS2017 to the latest version (it was less than a month our of date). No luck, error message still the same.
I also tried completely uninstalling and re-installing the AWS Toolkit for VS2017 extension. No luck, error message still the same. And no, it didn't even ask me to enter any credentials again or anything, it's just immediately presenting me with that error.
EDIT: I also tried restarting my computer. No luck, error message still the same.

Steps to Reproduce (for bugs)

Have working credentials and be connected to projects successfully for 5 months.

One day, have AWS CodeCommit crash?

Maybe this was a Windows Update issue?
Please help.

Context
This is how I connect to my client's codebase. With this out, it will severely hamper my ability to do work as a contractor.

Your Environment
VS2017 Professional, v15.9.10.
Windows 10 Pro, 64-bit version.

This probably won't help much, but this is a screenshot of the part of the Team Explorer pane where AWS CodeCommit normally is.

I want to confirm was this issue happening with the version before the recent <IP_ADDRESS> version of the toolkit that added VS 2019 support as well as the new latest version? Or is it only happening with the latest version that added support for VS 2019?
As an experiment could you try rename the following directory to see if that changes the behavior. You will need to have Visual Studio shutdown to rename this directory and then you should see the AWS Toolkit reset itself back the original settings.
C:\Users<user-id>\appdata\Local\AWSToolkit
Once you have done the experienment you can delete the new AWSToolkit directory that will be created when you launch Visual Studio and rename this directory back to the original name so you don't lose any of your settings.

I was experiencing a similar issue. Renaming the folder and adding back in my credentials seems to have fixed it for me. It started after updating the toolkit to the latest version with VS 2019 support. I am using VS 2017.

Unfortunately, this did not fix my issue.
I renamed the old folder to AWSToolkit-Old, started VS 2017, and a new AWSToolkit folder was automatically created. But I'm still just seeing that error in the Team Explorer pane.
As for version, I'm on 1.15.0. I have these kinds of VS extensions set to auto-update so I don't need to worry about them, and it was working for me as early as last Friday (29th March), so maybe it updated to this version when I shut down VS for the day/week at the end of Friday and it's this update which is causing the issue?
Is there a place I can download previous versions so I can uninstall this one, re-install the older one, and see if that helps?

I'm have been unsuccessful in reproducing the problem. Looking at the code indicating by the stack trace it looks like this could happen if the AWS Toolkit had an error during its main initialization and then when Team explorer opened up it threw this error trying to access an uninitialized instance of the toolkit.
Can either of you check the toolkit logs for any errors that might have happen before this error. The toolkit's logs can be found at C:\Users<user-id>\AppData\Local\AWSToolkit\logs\visualstudio.
Also can you confirm if the AWS Explorer windows is open when you go into Team explorer. If it is not can you open the AWS Explorer window to see if that component works. You shouldn't need the AWS Explorer open I'm just trying to figure out if that is also broken in your installs.

log.txt
Attached: Log from yesterday (in the newly created folder from the previous experiment).
Also, I'm not entirely sure what you're referring to by seeing if the AWS Explorer windows are open, but if I go to Team Explorer pane --> Manage Connections --> Connect to AWS CodeCommit, then I get (basically) the same error. E.g:

I was able to reproduce the issue and it is a timing issue. If you have pined the AWS Explorer which can opened via View -> Explorer then restart Visual Studio the toolkit will be loaded before Team Explorer attempts to access it and you won't get the error.

I'm working on a fix now and we keep you all updated.

I can confirm that this workaround (pinning the AWS Explorer window and then restarting VS 2017) works on my side too.
Thank you for looking into this for me. Looking forward to hearing more about the fix making its way to a new version to update to, so I don't need to continue to keep the AWS Explorer window open and pinned. :)

I have a fix for VS2017 but VS2019 is being challenging. I'm assuming the users that are running into this issue are using VS2017 so I'm going to focus on getting the release out for just VS2017 and then come back to VS2019. Thanks for your patience.


Create UI microservice for querying the LLM / VectorStore

Still in progress.
Related issue: https://github.com/LarryBattle/DocuDive/issues/2

We now need a to build the UI as a single HTML page that's hosted in S3 or in the microservice.... or we could just run it locally for the demo.
@alxschlz98 Thoughts?


Added OperatorMisconfigured.json

On https://redhat.pagerduty.com/incidents/PM2J3CV
We found the a customer installed operator in the openshift-operators-redhat namespace is misconfigured, hence, @mrbarge and I wrote this template for all notification for misconfigured operators

/assign @billmvt

/lgtm


Avoid dangling references in wait_all

@sithhell as said before, this does not make any sense to me. The reference is guaranteed to stay valid as the referenced data (https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/lcos/wait_all.hpp#L394) will be kept alive until after all futures have become ready. If this change silences one of the sanitizers then we have bigger problems than a dangling reference.

As with #3656, I assume that there is a similar race between waiting on the future and the lifetime of the stuff we wait on.

Well, assumptions are not enough to warrant copying everything instead of just referring to it. I really would like to understand what's wrong here.

@sithhell Can we close this in favor of #3663 as well?

@sithhell Can we close this in favor of #3663 as well?

I'm not sure yet. I am still getting lots of failures on the sanitizers branch

After some more tests, I am certain we can close this now as it has been resolved by #3663 and #3666.


Add momentum updates following BYOL

The momentum value for the momentum encoder gets updated following a cosine policy from 0.99 to 1. Missed adding that to the train_backbone.py script.

Done.


[Hotfix] Added isort, black, flake8 and tox to dev dependencies

Introduced optional dev dependencies, which aren't needed for installing the base functionality.

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

Project coverage is 94.77%. Comparing base (fc0dc38) to head (b8d4512).

Additional details and impacted files
@@           Coverage Diff           @@
##           master      #40   +/-   ##
=======================================
  Coverage   94.77%   94.77%
=======================================
  Files           3        3
  Lines         134      134
=======================================
  Hits          127      127
  Misses          7        7

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

Thank you so much for working on the PR!

Why was the PR closed?

For documentation: Only internal restructuring of the branch names due to version tag misnaming. Changes have been published.


Moya website.

Hey guys! In #1078, @orta made a good point that maybe we should think about a website for Moya project. What do you think about it, @Moya/contributors? 🤔
Personally, I don't have much experience with that, so we would need to have someone taking care of that project.

Using github.io website generator, or even jekyll can be a good solution for a brief and good website !

What would be the advantage compared to a list in the repo? Or maybe: what would we want to get out of a website apart from just a list of project built with / on top of / extending Moya?

Also, as @juliengdt mentioned, I think doing so with Jekyll would be pretty nice, as I think most - and at least some of us - already have some experience with it.

I think we don't have to constraint it only to the community around Moya (projects/extensions/etc), but we can also show examples/tutorials/documentation there as well. We could also show how we do open source or how to start contributing. We'd have everything in docs, but website may be an alternative way of presenting the important stuff. But that makes me wonder, can we connect the website with our markdown docs fairly easy? Would it be time-consuming to maintain it?

Even without Jekyll. A good start could be to check the Github Pages, which can use easily the markdown doc in the repo.
Source: Github Pages

I've helped out with similar sites like this one: https://github.com/RxSwiftCommunity/rxswiftcommunity.github.io Jekyll is great, Middleman is also great. Whatever people are familiar with sounds good to me.

Great! I think we can start with a skeleton in Jekyll as a first step. Does anyone here want to take a stab at it?

I was thinking of cleaning up Moya's in source documentation and generating documentation using jazzy. We would need to create a moya.github.io repo to host the page. Is anyone opposed to this? @Moya/contributors
I have no web development skills so it would only be jazzy for now, but this gets the ball rolling.

I have no objections – starting with Jazzy makes sense. As I mentioned above, Middleman is also nice, but the cool thing the hip kids are using these days is Gatsby. I've not used it yet but am planning on looking over the free Eggheads course tonight.

Awesome, I started here: https://moya.github.io. Checking out what the current status of the docs look like.
That Eggheads link is awesome btw, I may try to learn a little web development. I feel limited because I don't know Javascript (would prefer learning Typescript first if possible TBH). I doubt anyone wants me to work on the Moya website in Elixir or Go 😂

I'm starting to learn React this morning so I will probably move forward with making Moya a website. Likely using Gatsby. Hope everyone is ok with that setup

Go for it!


The engine "yarn" is incompatible with this module

OS:

[ ]  Windows
[X]  MacOS
[ ]  Linux

Output of node -v && npm -v && yarn version && npm ls --prod --depth=0
node -v && npm -v && yarn version && npm ls --prod --depth=0
v8.11.3
5.6.0
yarn version v0.27.5
info Current version: 0.0.1

The output when yarn adding:
$ yarn add react-native-sentry
yarn add v0.27.5
[1/4] Resolving packages...
[2/4] Fetching packages...
error<EMAIL_ADDRESS>The engine "yarn" is incompatible with this module. Expected version ">=1.0.2".
error Found incompatible module
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

Can you try to update your yarn version?

@HazAT Thank you, that was indeed the cause of this issue. No problem with yarn v1.10.1


How to use save_map service ?

Hello, friends
When I use the voxblox node, I want to save the TSDF. But when I enter the following instructions:
$  rosservice call /voxblox_node/save_map "test1.vxblx"
But nothing happened,  and I couldn't find the saved file. Is it stored in a strange location? Why can't I search for it?
And
$  rosservice type /voxblox_node/save_map | rossrv show
string file_path
---

Where am I wrong? Can someone help me? thank you very much

Sorry, I asked myself, I am stupid, I should understand it after think about it.
rosservice call /voxblox_node/load_map ~/test1.vxblx


Repo Server Image should use spec.version if spec.repo.version is not set

Describe the bug
When using a different ArgoCD version than the default version set by the operator, we set spec.version in the CR.
Documentation states for spec.version: "The tag to use with the container image for all Argo CD components." (https://argocd-operator.readthedocs.io/en/latest/reference/argocd/#version)
The repo server, however, does not respect this value but only looks at spec.repo.version or falls back to defaults
https://github.com/argoproj-labs/argocd-operator/blob/68e1197b38ab9ce2461d8825765564eece2e1e4d/controllers/argocd/util.go#L149-L159
https://github.com/argoproj-labs/argocd-operator/blob/68e1197b38ab9ce2461d8825765564eece2e1e4d/controllers/argocd/util.go#L168-L172
To Reproduce
Steps to reproduce the behavior:

Install ArgoCD with operator version 0.3.0
Create an ArgoCD instance and set spec.version to 2.2.5
Observe repo server deployment - it has the image SHA digest of ArgoCD image 2.3.3

Expected behavior
Repo Server falls back to spec.version if spec.repo.version ist not set

This is still an issue in the latest version, we encountered this due to a helm bug that was fixed in the newer bundled helm version with argo however the repo server pod which actually generates the manifests was still running into the bug.
Workaround is possible by specifically setting spec.repo.version as mentioned but it would be nice for the repo version (if not set) would fallback to the set version instead of the default version. Will see if I can provide a PR for this later.


Discrepancy in results buoy in wave

Hello everybody,
I am currently working on an model comparison between MoorDyn V2 and OrcaFlex.
I ran a model of a line with 2 fixed end points in a regular wave and the results there are almost the same.

Now I use the same wave input or a buoy with a center of mass that is lowered. (input files below)(wave amplitude 4m, period 8.33s)
buoy_mass.txt
water_grid.txt
wave_frequencies.txt
But here something strange happens. The buoy is moving backwards. The usefful results are shown below.

The buoy does not lay flat and for a basic calculation no cd or ca coefficients are included.
When only a current acts on the buoy the models show the same results.
Any ideas?
The buoy has a center of mass 2.67m above the bottom of the buoy. I think this is correctly implemented no?

Hi @ewoudVL13,
Sorry for the slow response here. It seems like your buoy has no hydrodynamic properties (Rod: Cd, Ca, CdEnd, and CaEnd). Is this intentional? My guess is this is causing the discrepancies.

@RyanDavies19 Yeah it was done on purpose to see how the to programs act when only buoyancy is in the play.

Yeah indeed I found that during the simulations. Dou you know something about the influence of wave height or wave period on the results?

I'm not sure I can give specifics, but without the hydrodynamic forcing I would think the buoy would drift towards the anchor point rather than stay where it is. It could also be good to check decay tests of the buoy with no mooring, to make sure the dynamics are matching between the two (if results differ when including hydro stuff, then setting the water density to zero will determine if the kinematics are right). With no mooring and a cylindrical shape, pitch and heave should be sufficient.


Notifications

Is it possible to notify users and admins every status change?
Actually it seems that emails are sent only to Agents.

What's the use case here? I might be able to help you out.

It would be fine if the user that opens the ticket could have updates on it, receiving an email when the ticket:

is opened
every status change is made

Actually the user is notified only on comments and status changes that are made by AGENTS, every change made by administrators or users are not sent by email.


CORS access-control-allow-origin header is incorrect for requests to port 443

Bug Report
The access-control-allow-origin header is set to two values when you hit https://dockstore.org/api and https://staging.dockstore.org. It's set to the client's host plus *.
It should only be set to one value, per MDN.
Interestingly, it correctly works if you hit the 8443 endpoint.
Expected behaviour
This is working correctly when the port is 8443.
Request URL: https://staging.dockstore.org:8443/api/ga4gh/v2/metadata
Request Method: OPTIONS
...
access-control-allow-origin: http://localhost:4200

Actual behaviour
When going against port 443, there are two values:
Request URL: https://staging.dockstore.org/api/users/user/extended
Request Method: OPTIONS
...
access-control-allow-origin: http://localhost:4200, *

Steps to reproduce the behaviour

Run a local instance of the UI, changing dockstore.model.ts to:

  static readonly HOSTNAME = 'https://staging.dockstore.org';
  static readonly API_PORT = '443';

Open Dev tools, navigate to localhost:4200, and see the response header for the OPTIONS call.

This is blocking update on the Firecloud side to use the more robust 443 port

Yes this is working, no longer seeing "access-control-allow-origin: http://localhost:4200, *". Changed to "access-control-allow-origin: http://localhost:4200"


IRGen: fix enum bit packing on big-endian platforms.

This change modifies spare bit masks so that they are arranged in
the byte order of the target platform. It also modifies and
consolidates the code that gathers and scatters bits into enum
values.
All enum-related validation tests are now passing on IBM Z (s390x)
which is a big-endian platform.

@swift-ci Please test.

Build failed
Swift Test OS X Platform
Git Sha - 302e0ea57cd82697894e41238651ff1c713c77fa

@swift-ci Please test.

Build failed
Swift Test Linux Platform
Git Sha - 302e0ea57cd82697894e41238651ff1c713c77fa

Build failed
Swift Test OS X Platform
Git Sha - 302e0ea57cd82697894e41238651ff1c713c77fa

@swift-ci Please test.

@jckarter Sorry for the size of this PR. I might try and split it up a bit further but I'm not sure how much more is worth doing. What do you think? This is the last change needed to get enums working on big-endian systems.
I've put a couple of comments in the review in places where I'm not sure if the changes I have made are correct. Let me know your thoughts.
Are there any places where you think it might make sense to add more tests?
Thanks a lot.

My main concerns:

On Darwin, we can't change the layouts of things that might be public ABI, so I would try to preserve the existing behavior as much as possible. (Eventually we may be able to improve the layout algorithm in ABI-breaking ways, but it would need to be controlled by compiler version, and that's a lot of infrastructure to build just for this.)

The existing implementation tries hard not to create non-power-of-two integer types in LLVM IR, because from past experience, they cause a lot of pain in backend crashes, miscompiles, or bad code. It looks like this patch, perhaps accidentally, reintroduces nonstandard integer sizes in the generated code.

@swift-ci Please test.

Build failed
Swift Test OS X Platform
Git Sha - 384a168fc06ff709f2e6a5337bf370dd98489209

Build failed
Swift Test Linux Platform
Git Sha - 384a168fc06ff709f2e6a5337bf370dd98489209

@jckarter

On Darwin, we can't change the layouts of things that might be public ABI, so I would try to preserve the existing behavior as much as possible. (Eventually we may be able to improve the layout algorithm in ABI-breaking ways, but it would need to be controlled by compiler version, and that's a lot of infrastructure to build just for this.)

I don't think there are any changes to the ABI here (well, the little-endian ABI anyway!), I've tried to ensure the layout stays the same. In this latest patch I've refactored multi-payload completeFixedLayout to make it much closer to the original if that helps confidence.

The existing implementation tries hard not to create non-power-of-two integer types in LLVM IR, because from past experience, they cause a lot of pain in backend crashes, miscompiles, or bad code. It looks like this patch, perhaps accidentally, reintroduces nonstandard integer sizes in the generated code.

Understood. I've modified the code in the EnumPayload emitScatter/Gather passes so that they don't generate new types (that might not be sized to a power-of-2). This has reduced the number of codegen test changes significantly.
Thanks again!

Thanks! Yeah, it's a bit clearer how the new implementation corresponds to the old now, I appreciate it. LGTM.


Type information doesn't always line-wrap

Why is the first type definition one long line, and the second one nicely line wrapped?

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/6395077-type-information-doesn-t-always-line-wrap?utm_campaign=plugin&utm_content=tracker%2F332399&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F332399&utm_medium=issues&utm_source=github).

Closed by #434


ENH Various fixes for PHP 8.1 compatibility

Issue https://github.com/silverstripe/silverstripe-framework/issues/10250
PHP 8.1 change the default behaviour of failed mysql statements from 'return false' to 'throw new mysqli_sql_exception()` https://php.watch/versions/8.1/mysqli-error-mode
Travis install failure on the --prefer-lowest job will be fixed by https://github.com/silverstripe/silverstripe-travis-shared/pull/36

I gather the thinking here is just that we're swapping out the raw php exception to one more in line with the exceptions that are likely already being caught elsewhere in our code? This feels like something that at least needs a brief mention in changelogs, since we're now throwing an exception where previously we did not (developers would either just get a warning, or get a mysqli_sql_exception already depending on their mysqli error more config).
Also how does this react with things like pstgres or pdo?
I note the below:

This change is similar to PDO extension changing its error reporting mode to Exceptions in PHP 8.0.

Does this mean there's been an exception thrown by PDO in php 8.0 this whole time? Is it the same exception we're catching here, or a different one?

I gather the thinking here is just that we're swapping out the raw php exception to one more in line with the exceptions that are likely already being caught elsewhere in our code?

Yes

Also how does this react with things like pstgres or pdo? / Does this mean there's been an exception thrown by PDO in php 8.0 this whole time? / Is it the same exception we're catching here, or a different one?

I don't know.
This particular issue surfaced when doing dev/build flush=1 on an empty database for kitchen-sink in CI, on graphql3 Controller::flush() - somewhere in this it tried to query a non-existent table.  The false return meant it just continued, though the mysqli_sql_exception caused a hard to diagnose failure.  This only happened on recipe-kitchen-sink in CI, it did not happen on installer in CI, so I'd regard this as a bit of an edge case
I don't think we shouldn't let postgres/pdo block this just yet, though I'll create a new issue to investigate to see if further work needs to be done.

Sweet. Given that pdo and postgres are slightly separate and there's an issue created to investigate that, I'm happy to move forward with this approach. I think it's good, would you mind just adding a quick sentence on the changelogs so people know they might need to start catching this exception in places they previously didn't need to?

I've updated the code so that it calls $this->databaseError() which itself throws DatabaseException
I don't think this change really needs a changelog update.  MySQL explicitly throwing errors in PHP 8.1 is independent of Silverstripe.
I think it's correct to NOT "backport" this behaviour to Silverstripe running older versions of PHP.

MySQL explicitly throwing errors in PHP 8.1 is independent of Silverstripe.
Except that we're making changes in Silverstripe to account for the new thrown exception.

After taking a closer look I think I agree that it doesn't need to be added to the changelogs - but I also wonder if we should just be setting $success to false instead of throwing an error? It's not hugely likely that someone is calling this method directly, but it is public... I'm on the fence about it now.

Have updated to set $success = false on exception.  It probably make very little difference in practice due to the thrown DatabaseException, though there's no harm it setting it to false and clearly it was not successful

@silverstripe/core-team can we get a third opinion on this please? I think this is fine but it is a (very low risk) breaking change.
Anyone who already has mysqli_report(MYSQLI_REPORT_ERROR|MYSQLI_REPORT_STRICT) will now have a different exception than they had previously, and anyone who upgrades from a previous php version who hasn't changed that config will get an exception they hadn't previously gotten.
It will almost exclusively affect developers who are calling prepareStatement() directly, which is not terribly likely but is possible.
I think if we just pop a sentence in the changelog like "as of php 8.1, failed mysql statements throw an mysqli_sql_exception by default (https://php.watch/versions/8.1/mysqli-error-mode) - in some cases we may catch that and throw a DatabaseException instead where previously this would have failed silently" then that covers us. But it also calls to attention the fact that we're not necessarily being consistent with this (not every interaction with mysql is wrapped like this I think).

I tried to read the convo but not sure I fully get what the options here are. Is it

do nothing and deal with the original mysql exception in the code calling the prepareStatement method
catch the exception and throw a SS-custom db exception instead
catch the exception but NOT throw a SS-custom exception?

If we're trying to be as PHP 8.1 as possible, I'd say do 1, and add a short mention to changelog.

When we call prepare statement internally, are we then catching these errors and handling them as we would normally, or would we see application layer database calls or those made through the ORM throwing too with this change?
I think if it only throws for people calling prepareStatement directly, that's a fine change, but if these exceptions could be encountered by developers not doing anything different, then we should probably not throw it. I have a feeling the community response to new exceptions being thrown and a whole lot more try/catch blocks around ORM calls is not going to be what they are looking for in an upgrade to PHP 8.1
I'd also make the argument that if the only time these would now be thrown is direct use of the method because our internal code is just catching them all anyway, then what's the point in throwing it at all if we implicitly silence it everywhere anyway?
So, my vote would be to err on the side of keeping the current behaviour and just swallowing the error as we currently do.

So, my vote would be to err on the side of keeping the current behaviour and just swallowing the error as we currently do.

Keep in mind that upgrading to PHP 8.1 isn't the only way to get the mysqli_sql_exception thrown - people on PHP 7.4 could have it thrown right now depending on their configuration. so "just swallowing the error" would still be a change in that case. Basically no matter what we do here something will change for someone.

Oh right, I see. Not so straightforward, then!
Given this is an explicit change in behaviour in php and not explicit change in our implementation, I think I'd be happy with either approach, but I'd still probably lean slightly towards swallowing the exceptions (it feels like the framework's job to put one try/catch in rather than expecting developers to litter their code with it) and we are then taking active steps to try to maintain some consistent behaviour across PHP versions (again, arguably one of the jobs of a framework).

Just trying to wrap my head around this. I take it no one is arguing that there's a legitimate use case where properly written code will call prepareStatement and would expect it to fail. Basically, if you call prepareStatement right now and get a false it means something is broken ... e.g. Your DB hasn't been built or you've mangled your SQL.
Given the above assumption, I don't think we would be breaking anything that's no already broken by throwing an Exception. So we're mostly arguing about developer experience. My instinct in those situation would be to let Exception bubble up so devs can become aware of the problem. I suspect that's probably why PHP decide to start throwing an Exception in this situation.
My instinct would be merge this.
If we're concerned that this will break someone's code somehow, maybe do nothing and point the figure at PHP8.1 when they start complaining.
Swallowing the exception wouldn't be terrible, but that's my least preferred option.
It's worth pointing out that this is a super marginal use case ... I suspect the 5 blokes on this card are the only people that will ever come across it.

Given that there are no strong opinions against this approach, and the general consensus is that this is okay, I'm going to accept this. I'll merge it this afternoon.

@emteknetnz There are new conflicts - can you please resolve those before I merge?

For anyone looking at this in the future, the conflicts mentioned above came from an alternative approach to resolving the same problem - see https://github.com/silverstripe/silverstripe-framework/commit/511b3bb060cb2962e79e6a034eea818b6c890ba4#diff-9b2f2c197e0cd13a273016f609eebbf671ae5db75396ae73cba64635dd7b75ba


Allow item-specific custom actions via scripts

Submitted by Discord user.
There's no custom actions on items! And there should be. Because so many games have logic tied to items. Some can even be possible to be activated from the inventory!

consume food/potion/other consumable
apply item to another item
turn item into other items
open item's own inventory

For that, ItemType should store a script that can override methods:

input_inside_inventory(item : ItemStack, event : InputEvent, inventory_view : InventoryView, item_stack_view : ItemStackView) -> bool, which is called when an input occurs on an ItemStackView holding an item of the type;
input_into_world(item : ItemStack, event : InputEvent, drop_at_node : Node) -> bool, which is called before an input that would drop the item into the world. drop_at_node is the node set in the Grabbed Stack node, normally the player character;
input_onto_inventory(item : ItemStack, event : InputEvent, inventory_view : InventoryView?, inventory_cell_under : Vector2) -> bool, which is called when an input occurs while an item of the type is grabbed. InventoryView can be null.

All must return true if the input has been handled - which can, for example, prevent item grabbing and dropping.

⚡ Custom actions with items are now doable
There are now signals that GrabbedItemStackView has that allow handling input onto inventories and items. Allows interception of the input, like when a ctrl-left-click would normally use the left-click action, but you want to do something else instead.
Although a system that lets the user give a script to each item would still be more discoverable.

@WithinAmesia I ask you to stop spamming reactions under every post

@WithinAmesia I ask you to stop spamming reactions under every post

Do they send emails or notifications? Big positivity time. Everything going well? Your stuff super cool ya. Big fall study time ya? Is there a skill systems like Runescape, people like those systems too lol number go up time.


"To Build" python 3 support

To build
Clone the blog
git clone https://github.com/arulrajnet/attila-demo
cd attila-demo
git submodule update --init --recursive
git fetch --recurse-submodules
git pull --recurse-submodules

fabric commands
Commands do not work with Python 3
fab help
fab build
fab serve

Is there a way to build without using the fab commands? Thanks!

Yes. You can do without using fab
To build
pelican -s pelicanconf.py

To Serve
pushd output; python -m SimpleHTTPServer; popd

Then http://localhost:8000

You can also use this Makefile

@JoshZastrow Hope above solves your issue.


The configuration parameter in Kernel_Layer.Network_stack.TCP_Syncookies is incorrect

The configuration parameter in Kernel_Layer.Network_stack.TCP_Syncookies is incorrect.
On the page https://github.com/trimstray/the-practical-linux-hardening-guide/wiki/Network-stack#tcp-syncookies, the configuration parameter is that of source-packet-routing and not tcp_syncookies, as mentioned in the OpenSCAP document.
Link: https://static.open-scap.org/ssg-guides/ssg-rhel7-guide-C2S.html#xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_tcp_syncookies

Fixed. My mistake - you're right! Thanks!


KYLO-2322 Support testing Redshift connections

DatabaseType.java enum updated to support REDSHIFT.
jdbcUrlIdentifier tested and compliant to redshift documentation
validationQuery and limitFormat tested:

I branched from release/0.9.1

SonarQube analysis reported 5 issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 DatabaseType.java#L42: Define a constant instead of duplicating this literal "select 1" 10 times.
 DatabaseType.java#L42: Define a constant instead of duplicating this literal "SELECT {0} FROM {1}.{2} LIMIT {3}" 8 times.
 DatabaseType.java#L11: This block of commented-out lines of code should be removed.
 DatabaseType.java#L112: Remove the declaration of thrown exception 'java.lang.IllegalArgumentException' which is a runtime exception.
 DatabaseType.java#L126: Remove the declaration of thrown exception 'java.lang.IllegalArgumentException' which is a runtime exception.

I don't see the unit test error on my local. Please, advice so I can fix any issues passed unnoticed

Thanks for the PR.  Please resubmit it as a merge request to master.   We don't change code in release branches, rather release branches are created from master at time of release.


Multiple images in one page

Description
This pull address the following user request. request
AFFECTED UI LINK:
Note: All other features work as usual.
New Feature: Add multiple images in one page.

Template Selection: Users can choose from a set of predefined templates that dictate how images are organised on each page. Available templates include:

1x2 (Two per page): Two images will be arranged on each page. (from left to right)
2x2 (Four per page): Four images will be arranged on each page. (from left to right)
2x3 (Six per page): Six images will be arranged on each page. (from left to right)

Handling Fewer Images: If fewer images are selected than the number of slots in the chosen template, the extra slots will be left empty. Only the selected images will be displayed.

Size and Spacing: The size and spacing of images will be automatically adjusted according to the selected template, maintaining the aspect ratio of each image. Users will not need to make any manual adjustments, as the templates will optimize the layout to fit the specified number of images per page.

Closes #(1400)
Exemple:
UI:

Output for 1x2 ( 1 row two colomn ):

Checklist:

[x] I have read the Contribution Guidelines
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings

Love the idea,
I noticed in your screenshot 2 images produced 1 page with image but also made one blank page?
I also think instead of having the templates defined like this
the grid layout done by our
https://stirlingpdf.io/split-pdf-by-sections
would be better suited

Yep look good to me also , I did not know we had this feature. I'll do the changes.
The blank page is because i uploaded the wrong foto.


Create more complete example of using grate in a container (k8s, etc)

How could one use grate in a Kubernetes setting?

Init container?
etc

Maybe @wokket s examples are enough. Verify 😄

You're on your own here mate, I have no desire to play in the k8s space for this stuff...  we run live migrations in k8s, but literally just kubectl run --restart=never an image built like the samples...

I have a tiny bit of experience with Service Fabric and i know we have hosted python containers in there. I could have a look how we do it for that and maybe create an exampld based on that?

Thanks a lot, @DjKillerMemeStar ! I'd appreciate that. I don't think the main issue is hosting grate in a container, though, but how you should/would actually use it in a Kubernetes setting. Would you create an init container? Would you create a background service that watches a folder for changes? Something totally different?
Do you have any thoughts on this? Maybe the question is too generic, and the use cases will vary a lot depending on each and every one's surrounding bits and bobs?

I don't really see a point in hosting grate yourself. It's just install on the build server any way you like and run it. This seems like a way easier way to do it. Ofcourse, people/situations differ so i'm not sure.
Maybe the question could be rephrased to beter explain what you mean. It's more of a "why would you use grate in a container" then a how in my eyes. Could ofcourse be wrong here 😄.

I had a project where the build server (AzDo) didn't have access to the Sql Server (firewalled/PrivateLink/something weird???) but the k8s cluster obviously did have access.  As noted above, we'd build the container like the sample and just kubectl run a one-off instance from the pipeline.

Ow yeah, makes sense, sorry bout that!
We just use our own agents so bypass any firewall restrictions etc, but that is ofcourse not possible for everyone.
From that standpoint i don't see anything wrong with your approach of an one-off instance.

I'm just thinking a bit further on this one. It might seem like I'm trying hard to create a use case for something that isn't, but, if you compare to, say EF migrations, where the migration is performed on application startup, would it make sense to create an example where grate is used in an init container, mounting the database scripts in a volume there, and running them on startup, before the actual application container starts?
Or am I beating a dead horse here?

I can see the comparison with EF Migrations (which fwiw I don't like for various reasons, hence being here).
A sample for a migrarion style workflow would obviously be useful if that's a workflow you want to push, via either

init containers (which I have no experience with), or
referencing grate via nuget (which I think RH had support for?? I never used it) and running a migration on app start?

There is the init container pattern described here: https://andrewlock.net/deploying-asp-net-core-applications-to-kubernetes-part-7-running-database-migrations/#combining-jobs-and-init-containers-to-handle-migrations


Incorrect hardcoded value of 0x8 in sqrt function (should be 0x4)

The hardcoded value here is wrong.
0x8 = 1<<3 but it should be 1<<2 i.e. 0x4
I'm not sure how smart solc is (whether it will unroll loops if one cranks the optimization runs sufficiently high - I haven't tried it yet), but all of this could be avoided by

using the 1 << shift syntax
writing the entire thing as a loop (same with the 7x code repetition below)

Hi @nonergodic, thanks for opening this issue.
Would you mind explaining why we should use 0x4 instead of 0x8?
Re solc - as far as I remember, hardcoding the operations like I did was faster than using a for loop. But that was with the compiler that was available in 2021. It might be different now, I'm not sure.

Would you mind explaining why we should use 0x4 instead of 0x8?
Because your own comment says:
// Set the initial guess to the least power of two that is greater than or equal to sqrt(x).
But if x is 4,5,6, or 7, the code will have result = 1 as the initial guess, which is less than sqrt(x) for those values.

It's probably not much of a concern because getting the initial guess right to this level is a waste of effort when you run the subsequent iteration for 7 steps regardless (i.e. you can probably safely get rid of the last few comparisons and shifts and replace it with a simple add (i.e.:
    xAux >>= 8;
    result <<= 4;
}
if (xAux >= 0x10) {
    xAux >>= 4;
    result <<= 2;
}
if (xAux >= 0x8) {
    result <<= 1;
}```
can probably be wholesale replaced by just
`result += 1<<4;
)
but having the wrong value in there gives rise to bad code regardless. (An even more gas efficient implementation could even keep track of how many iterations are actually required while determining the initial value and then jump to the point in the code where it will only execute the iteration for that number of steps (thought that requires jumping to a label + step*bytecodeOffset and is hence pretty black magic)).

(Unrelated tangent: You're also using >= comparison, which might also be unnecessarily gas inefficient (there are only GT and EQ opcodes) depending on what optimizations solc is capable of... after all a >= hardocdedConstant is the same as A > hardcodedConstanst-1)

there are other libraries that make the same mistake:
https://github.com/abdk-consulting/abdk-libraries-solidity/blob/d8817cb600381319992d7caa038bf4faceb1097f/ABDKMath64x64.sol#L727 (I opened an issue with them too)

notably, OpenZeppelin gets it right (though likely still somewhat gas inefficient):
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/74738721dc9cfa820687f6b700d2583b16a21c0d/contracts/utils/math/Math.sol#L196

Thanks for explaining! Makes sense. It looks like @Amxx's PR addresses this issue.
I think that the reason I haven't caught this in the tests is that I did not pass 4, 5, 6 or 7 as an input in the tests I've written for the sqrt function.
The good news is that {4,5,6,7} in the number format used by PRBMath are tiny values, i.e. {4e-18, 5e-18, 6e-18, 7e-18}. The results were prone to have precision errors nonetheless, and they shouldn't have been a concern for most users.
Re >= vs > tangent - thanks for your suggestion, I opened issue for it: https://github.com/paulrberg/prb-math/issues/99.

A couple of additional remarks:

Looking at the code more closely, the comment is also (and still) wrong:

// Set the initial guess to the least power of two that is greater than or equal to sqrt(x).

What it should say is:
Set the initial guess to the largest power of two that is smaller than or equal to sqrt(x). (again, compare with OpenZeppelin)

The good news is that {4,5,6,7} in the number format used by PRBMath are tiny values.

The issue wasn't just for these values though, but also for all their left shifted variants. i.e. if you were to start out with e.g. 6 left shifted by 4 (i.e. 96 = 0x60), you'd compare with 0x10, find that 0x60 is larger, hence right shift xAux by 4 to 0x06 and left shift result by 2 from 1 to 4.
And then you'd be back to the original situation where 6 is being compared to 0x08, and hence you'd end up with an initial guess of 4.
Notice thought that even after the fix, you'll only end up with an initial guess of 8 and sqrt(96) > 9, so 8 is still not a power of 2 that is greater than or equal to sqrt(x).

The (likely) reason why this issue didn't pop up during testing (and is of little consequence to users) is that it doesn't matter for small values because Heron's iteration is run 7x times anyway and so even a bad initial guess will converge to the right result.
So incorrect results can only arise for large numbers (i.e. close to the upper range of uint256) and in that case a bad initial guess might give you less precision in the lower digits after 7 iterations and it's highly unlikely that anyone will care about the last couple of digits in a number that covers ~36 orders of magnitude:
From here:

Let's go to the largest size there is: the visible universe. The radius of the universe is about 46 billion light years. Now let me ask a different question: How many digits of pi would we need to calculate the circumference of a circle with a radius of 46 billion light years to an accuracy equal to the diameter of a hydrogen atom (the simplest atom)? The answer is that you would need 39 or 40 decimal places.

I cannot thank you enough for taking the time to report and explain this!
I created an issue to track the fix for the comment: https://github.com/paulrberg/prb-math/issues/103

The issue wasn't just for these values though, but also for all their left shifted variants.

Oh, but of course.

The (likely) reason why this issue didn't pop up during testing (and is of little consequence to users) is that it doesn't matter for small values because Heron's iteration is run 7x times anyway and so even a bad initial guess will converge to the right result.

Makes sense.


SystweakSoftware.RightBackup version Right Backup

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

@OfficialEsco, it passed due to a match between the folder structure and the version. I agree this does not look like a package version we want in the repository (assuming "Right Backup" is not a proper version for this package).


POC: Move package:web access to separate package

:scroll: Description

Evaluate if we can move package:web access to it's own library

:bulb: Motivation and Context

Provide a path to support compilation via WASM without bumping Dart/Flutter SDKs in main sentry package
Relates to #2104
:green_heart: How did you test it?
:pencil: Checklist

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

:crystal_ball: Next steps

@buenaflor This might just work, i build with WebAssembly and triggered an issue. Before, I set some sample values in the separate package.
Dummy values in package:

Code
Removed all dependencies that hindered building for WebAssembly in the sample app. Removed a flutter event processor so that the web values would be taken as fallback.
flutter build web --wasm
flutter pub global activate dhttpd
cd build/web
dart pub global run dhttpd '--headers=Cross-Origin-Embedder-Policy=credentialless;Cross-Origin-Opener-Policy=same-origin'

Result
https://sentry-sdks.sentry.io/issues/5503776648/?project=5428562&query=is%3Aunresolved+issue.priority%3A[high%2C+medium]&referrer=issue-stream&statsPeriod=1h&stream_index=0

did some quick tests and works well on dart 3.2.0 and flutter 16.0


Compatibility with first person player model mod

Hello, I am currently using this mode (version 1.19.2) with first-person player model mod (version 1.19.2), however when in first person I've noticed an issue where my head blocks my view when looking down, up, or sideways. Could you make this compatible or add a feature where the head animation can be disabled?

I also have the same problem. There is a possible solution here.

I also have the same problem. There is a possible solution here.


Adapt fermionic drivers to produce a SecondQuantizedSumOp

Migrated from Enterprise Github.
Creator: @mrossinek
All fermionic drivers need to be adapted to produce a SecondQuantizedSumOp rather than a QMolecule. As a good starting point, the following may be helpful to transform what is currently stored in a QMolecule into a FermionicSumOp:
base_ops = []

one_body_ints = qmol.one_body_integrals
for idx in itertools.product(range(len(one_body_ints)), repeat=2):
    coeff = one_body_ints[idx]
    if not coeff:
        continue
    label = ['I'] * len(one_body_ints)
    base_op = FermionicOperator(label, coeff=coeff)
    for i, op in [(idx[0], '+'), (idx[1], '-')]:
        label_i = label.copy()
        label_i[i] = op
        base_op *= FermionicOperator(''.join(label_i))
    base_ops.append(base_op)

two_body_ints = qmol.two_body_integrals
for idx in itertools.product(range(len(two_body_ints)), repeat=4):
    coeff = two_body_ints[idx]
    if not coeff:
        continue
    label = ['I'] * len(two_body_ints)
    base_op = FermionicOperator(label, coeff=coeff)
    # mind the chemists' notation of the two-electron integrals!
    for i, op in [(idx[0], '+'), (idx[2], '+'), (idx[3], '-'), (idx[1], '-')]:
        label_i = label.copy()
        label_i[i] = op
        base_op *= FermionicOperator(''.join(label_i))
    base_ops.append(base_op)

fer_op = FermionicSumOp(base_ops)

[ ] CP2KDriver
[ ] FCIDumpDriver
[ ] GaussianDriver
[ ] HDF5Driver
[ ] Psi4Driver
[ ] PyQuanteDriver
[ ] PySCFDriver

Creator: @mrossinek
Some thought on the above snippet:

we should generalize this to also work for n-body terms (like Mario Motta did recently in this PR: https://github.com/Qiskit/qiskit-aqua/pull/1483)
the above may be easier if we use the physicist' notation for the integrals/coefficients
we should probably implement the above as a utility method in the FermionicOperator class
if we do so, we can do the transformation to physicist' notation internally (and allow the user to disable it through a kwarg)

Creator: @mrossinek
Some thought on the above snippet:

we should generalize this to also work for n-body terms (like Mario Motta did recently in this PR: https://github.com/Qiskit/qiskit-aqua/pull/1483)
the above may be easier if we use the physicist' notation for the integrals/coefficients
we should probably implement the above as a utility method in the FermionicOperator class
if we do so, we can do the transformation to physicist' notation internally (and allow the user to disable it through a kwarg)


How to Spy On a Mocked Thing?

Hello! Thanks for making this nice module! I'm wondering how I can "spy on" a mocked module so that I can make assertions about how it was called.
Suppose I am trying to mock the request-promise libary which is normally called with request.get, here's my mockery code:
mockery.registerMock('request-promise', {
      get: () => {
        return {
          statusCode: 200,
          body: {
            foo: "barracuda"
          },
        };
      },
    });

    mockery.enable({
      warnOnReplace: false,
      warnOnUnregistered: false,
    });

I would like to assert that request.get was called with the correct params. I tried setting up a sinon spy as usual, it didn't seem to work. :/
requestSpy = sinon.spy(request, 'get')

Is there any recommended way to do this with mockery?
Thanks! 🙏

Um... yeah I don't think you can do that with this lib. Anyone else can prove me wrong, please do. Try using this library: https://www.npmjs.com/package/proxyquire

Do sinon stuff after require, e.g. see https://github.com/mawie81/electron-window-state/blob/master/test.js#L37
So, for your case
const request = require('request-promise');
requestSpy = sinon.spy(request, 'get');


Categorical variables

There is an implementation of categorical variables in 0.2.X branch. It should be merged to master and add also the appropriate tests.

Just checked the tests on imbalanced-learn's SMOTENC test module. All the tests are already in G-SMOTE's test suite, this issue can be closed.


The underlying expr of a trailing decltype return type is not selected

a trailing return type
int x;
auto s() -> decltype(^x); // put cursor around x, clangd thinks we are at the function `s`, rather than the `x`.

It's unclear to me which editor feature / LSP message is misbehaving here.

Unclear at first glance which AST node is supposed to own the trailing return type, I think it's not part of the FunctionType (Loc).
With no function body, the FunctionDecl doesn't even cover it, which is clearly wrong.
This should reproduce even without decltype e.g. -> int I'd guess.
@HighCommander4 this is SelectionTree, so almost everything: go to def, hover, rename, etc.


fix wrong condition

[] read the CONTRIBUTING guidelines
[] raised a GitHub issue or discussed it on the projects chat beforehand
[] added unit tests
[] added integration tests
[] updated documentation if needed
[] updated CHANGELOG.md

Closing this for now, reopen or rebase if desired


Feature request: Support for Camilladsp 3.0.0 config format

Hey,
I did some tests with CDSP 3.0.0 beta and noticed that the configuration file format changed and ezbeq throws therefore errors: "SetConfig failed : Error"
Looking at the differences I noticed that pipeline section of 3.0.0 has "channels" and not "channel" and numbers are now with a preceding "-".
Would be great if both formats could be supported.
Regards
Michael

would be even better if config format only changed for meaningful reasons :)
post back when 3.0 is final and I'll look at it, not doing anything til then

3.0.0 beta (or next30) offers to apply same filters to multiple channels. Therefore the config format changed.
Apparently two versions work here when I tested it. Square brackets and also "- number":
pipeline:
- bypassed: null
  channels: []
  description: bla
  names:
  - test
  type: Filter
- bypassed: null
  description: mixi
  name: testing
  type: Mixer
- bypassed: null
  channels: [8, 9]
  description: blub
  names:
  - test
  type: Filter
processors: null
title: 18i20 CamillaDSP 3.0

pipeline:
- bypassed: null
  channels: []
  description: bla
  names:
  - test
  type: Filter
- bypassed: null
  description: mixi
  name: testing
  type: Mixer
- bypassed: null
  channels:
  - 8
  - 9
  description: blub
  names:
  - test
  type: Filter
processors: null
title: 18i20 CamillaDSP 3.0

Those are both standard yaml so they're not different in that sense, the more compact one is called flow style
https://www.yaml.info/learn/flowstyle.html

One more thought about filter location:
Current implementation of ezbeq for Camilladsp puts them at the outputs. In case someone is mixing full range speakers and LFE speakers (or x-overs) these filters need to be applied to all relevant channels to not screw up phase and therefore causing cancellations.
Some flexible way would be nice to enable also ezbeq filters located at the inputs.
This would reduce the amount of filters in these cases. E.g. When implementing x-overs the tweeter channels also need these filters because of the phase shift caused by additional ezbeq filters in their low frequency channels counterparts.

Can you provide an example config file laid out with and without filters added pls

Hi,
made an example config with 10 BEQ filters and four speakers with some x-overs:

I put the id string in the description field so the pipeline overview does not get messed up by very long BEQ names. Maybe this could be implemented this way?
In principle the BEQ1-BEQ10 filters could stay in the configuration and just the "bypassed:" attribute needs to be set to "true" or vice versa. This would make the overview look like this:

(The overview looks a little buggy because the BEQ symbols should look bypassed and the delay symbols left of the mixer should be visible...)
Maybe parsing the config would be also easier if you just need to search for BEQ1 - BEQ10 in the config, change their attributes or to bypass individual BEQs set them to gain like I did in this example:
18i20 5.yml.txt
In case you do not have a working multi channel test environment I would be happy to help testing.

the reason I appended the filters to the end of the pipeline was partly simplicity as then you don't need to any configuration to work out where to insert it
in this case, the pipeline is a list of filters so a simple, but user unfriendly and brittle, way to do that would be to make you specify the index to insert at (which is simple if you put it at the beginning or the end as that would be 0 or unspecified) but could be ugly in the case of a complex pipeline with many stages and where the beq goes in the middle somewhere (no clue how likely that is though)
one other Q, can there be 1 and only 1 pipeline? my recollection is you can have multiple but not sure if that still holds (if it was ever true)

Afaik there is only one pipeline possible:
https://github.com/HEnquist/camilladsp/tree/next30?tab=readme-ov-file#pipeline
There may be multiple mixers with filters and processors in between.


Add CHANGES.md

Pull Request Test Coverage Report for Build 157

0 of 0   changed or added relevant lines in 0 files are covered.
24 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-2.05%) to 75.584%

Files with Coverage Reduction
New Missed Lines
%

src/mssql_error.ml
6
66.67%

src/client.ml
18
84.06%

Totals

Change from base Build 153:
-2.05%

Covered Lines:
291

Relevant Lines:
385

💛  - Coveralls


Bug: Sidenav item not getting highlighted for tech switcher non-default paths

Looks like isCurrent in treeNode.tsx is not working as expected
context: https://prisma-company.slack.com/archives/C5Z9TH6N9/p1630529422025100

Can confirm this is now fixed 👍


Consider changing Windows warning to an info printout

https://github.com/Chocobo1/setup-ccache-action/blob/acabebed13c5e47f5023d0def2702873445bd0f0/src/main.ts#L120
IMO, this should be an info printout, not a warning. I'd like to be able to just use this action in a job that runs on all OSes, and have it be a no-op where not supported, rather than using conditionals to avoid the warning.
The warning creates an alert annotation in the workflow. For example: https://github.com/arvidn/libtorrent/actions/runs/1274732824
In the "PR checks" part of the actions UI, these annotations are surfaced with an exclamation mark -- See https://github.com/arvidn/libtorrent/pull/6484/checks
It appears that warnings are generally used where action/intervention is required.

IMO, this should be an info printout, not a warning. I'd like to be able to just use this action in a job that runs on all OSes, and have it be a no-op where not supported, rather than using conditionals to avoid the warning.

I'm leaning to keep it as a warning as it provides stronger indications than a normal log print: for now it really shouldn't be active on Windows platform. IMO opt-out explicitly for an action that is unsupported on some platform instead of relying on fallback no-op is something I consider a good practice.

It appears that warnings are generally used where action/intervention is required.

Well "github actions" themselves seems to use it for mere communications: For example in your provided link (https://github.com/arvidn/libtorrent/actions/runs/1274732824) they showed a message/warning about upgrading to macOS-11 in the future. IMO this is just an info that doesn't necessarily needs user intervention.

I thought the macOS-11 warning was a good example of an actionable alert. The workflow references macos-latest, which will change soon, so stuff could break. If the user wants to preemptively avoid breakage, that's a possible cause for action on the alert.
The windows warning isn't really actionable though.  The only cause for action is to get rid of the warning itself.
As a user, I understand that the ccache action is a noop on windows. Lots of steps are noops in various conditions. I think having if: ${{ runner.os != "Windows" }} on a noop step in my workflow is clutter, and workflows clutter very easily, which hurts readability, so I want to aggressively reduce clutter when possible.

As a user, I understand that the ccache action is a noop on windows.

It is something I would like to reserve it as an implementation detail that nobody should be relying on: The noop is NOT a feature but a fallback for the careless user (therefore the follow-up warning).
Maybe I'll change my mind in the future but I'll like to keep it as-is for now.


VerifyError: Error #1014: Class mx.core::DebuggableWorker could not be found.

Hi,
I tried using the pure as3 branch, but still got this error. Isn't this a Flex related class?
Cheers,
Timo

Hi,
Yes it is, you need to create a flex as3 only project,  it will include only the core classes you will need,  apparently only thiw one,  another option is to monkey patch this class into your project.
HTH
Envoyé avec Outlook pour Android
On Thu, Oct 1, 2015 at 7:09 AM -0700, "timoisalive"<EMAIL_ADDRESS>wrote:
Hi,
I tried using the pure as3 branch, but still got this error. Isn't this a Flex related class?
Cheers,
Timo

Reply to this email directly or view it on GitHub:
https://github.com/doublefx/easyWorker/issues/10

Ok, thanks, I thought it didn't need Flex at all..
One more question, is this technique compatible with the iOS concurrency requirements also?

I hadn't got the opportunity to try against ios yet but except if you can point out something that shows the workers work differently on it,  I could try blindly to adapt it.
Envoyé avec Outlook pour Android
On Fri, Oct 2, 2015 at 12:03 AM -0700, "timoisalive"<EMAIL_ADDRESS>wrote:
Ok, thanks, I thought it didn't need Flex at all..
One more question, is this technique compatible with the iOS concurrency requirements also?

Reply to this email directly or view it on GitHub:
https://github.com/doublefx/easyWorker/issues/10#issuecomment-144939620

The AIR 19 release notes reads:
Everything remains coherent to AIR Android except for differences in loading of swf and passing byte array to worker.

As dynamically loading a ‘remote‘ SWF that contains ActionScript code doesn't work. Remote swf have to be passed to worker as stripped swf.
Embedding SWFs(having ABC code) using [Embed] tag will not work on iOS.

I assume this is not a problem in easyWorker though...
I ended up using the standard way to create workers for now at least, the missing Flex classes stopped me trying out easyWorker.. :)


No keyboard input

I cloned "part12" and built using the standard versions of everything. It works fine except key presses aren't registered. I did a little debugging and the keyboard interrupt is never triggered as far as I can tell. The timer interrupt is triggered normally. I'm using QEMU 7.1.90 on a win10 machine. My host keyboard is a pretty ordinary Norwegian layout USB keyboard. I tried adding "-k no" to the qemu command line, but that made no difference. Any suggestions?

Thanks for reporting! I think this is the first time that someone had this problem, so I'm not sure what's the issue. Maybe it's a bug in QEMU, have you tried a slightly older QEMU version?

I use a Russian keyboard. Never had any issues. Let me look into this


AvatarGroup and Avatar use unstructured markup

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
Currently, AvatarGroup and Avatar generate
s for markup, which is not semantic/structured.

Expected behavior 🤔
Using a list would better structure the list and its members for screen reader users:

Steps to reproduce 🕹
import { Avatar, AvatarGroup, } from '@mui/material';

<AvatarGroup total={totalCount}>
  {membersSample.map((member, index) => (
    <Avatar key={index} user={member} />
  ))}
</AvatarGroup>

Context 🔦
This was flagged during an accessibility review of our application. Other MUI components, such as Typography let you override the HTML component (i.e. component="h2"), but AvatarGroup does not.
It would be good to (a) use
 and
 as the defaults and (b) allow overriding of the component when needed.
Your environment 🌎

npx @mui/envinfo
  System:
    OS: macOS 12.5.1
  Binaries:
    Node: 18.7.0 - /opt/homebrew/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 8.15.0 - /opt/homebrew/bin/npm
  Browsers:
    Chrome: 104.0.5112.101
    Edge: Not Found
    Firefox: 101.0
    Safari: 15.6.1
  npmPackages:
    @emotion/react: ^11.9.3 => 11.9.3
    @emotion/styled: ^11.9.3 => 11.9.3
    @mui/base:  5.0.0-alpha.91
    @mui/icons-material: ^5.8.4 => 5.8.4
    @mui/lab: ^5.0.0-alpha.92 => 5.0.0-alpha.92
    @mui/material: ^5.9.2 => 5.9.2
    @mui/private-theming:  5.9.1
    @mui/styled-engine:  5.8.7
    @mui/system:  5.9.2
    @mui/types:  7.1.5
    @mui/utils:  5.9.1
    @mui/x-data-grid: ^5.7.0 => 5.7.0
    @types/react:  17.0.40
    react: ^17.0.2 => 17.0.2
    react-dom: ^17.0.2 => 17.0.2
    typescript:  4.7.4

This issue is related to default accessibility (the markup) of the Avatar, AvatarGroup. Another issue is the workaround via component that is not working in AvatarGroup which should be a separate issue. Let's separate them:
The markup benchmark

https://chakra-ui.com/docs/components/avatar/usage#avatargroup (uses role="group")
https://mantine.dev/core/avatar/#avatargroup (same as Material UI)
https://developer.microsoft.com/en-us/fluentui#/controls/web/facepile (uses ul)
Let's wait for 👍 and consider adding it in v6.

For the workaround problem, I will create another issue.


[material-ui][docs] Add Connect-related content (@danilo-leal)

Cherry-pick of #40848

@danilo-leal here's the first cherry pick, we'll have to create the#41763 one after this one is merged


(Enhancement) Add mention of 10.7.0-32 software update

Since there are many brand new 3DS hacking noobs out there that are using this guide or are going to in the future, mentioning that the 10.7 update exists and still supports the 10.6 entry points (ninjhax and OoT3Dhax with or without Powersaves) along with the 10.4+ sysupdater application might be helpful for those users.

Added


Add README for Python interpreter

BUG=b/256650563

LGTM. One comment is that most python users may not be familiar with Bazel. People (like old me) may get confused why python code need to be compiled. However this will not be an issue after we get the PyPi package. In the future we should consider create a Colab tutorial to walk through the essential features, which fit the appetite of python users.

Thanks for reviewing! Agree that a colab would be nice in the future.


Return type definition of Kafka.structured seems incorrect

Describe the Bug
The types for return values from Kafka.structured(cloudEventInstance) seem to be incorrect. The returned object has the following structure if viewed using logs or a debugger:
{
  key: 'fubar',
  value: '{"id":"ef233aa0-00a0-4b5a-9886-f8ff7566ef50","time":"2022-04-14T20:26:32.291Z","type":"foo","source":"bar","specversion":"1.0","partitionkey":"fubar","data":{"hello":"world}}',
  headers: { 'content-type': 'application/cloudevents+json; charset=utf-8' },
  body: '{"id":"ef233aa0-00a0-4b5a-9886-f8ff7566ef50","time":"2022-04-14T20:26:32.291Z","type":"foo","source":"bar","specversion":"1.0","partitionkey":"fubar","data":{"hello":"world}}',
  timestamp: '1649967992291'
}

However, the types come from CE.Message<string>. This results in the following intellisense structure being suggested:
{
  body: unknown,
  headers: CE.Headers
}

It seems as though the headers key is correct, but the body is incorrect, and other keys are missing.
Steps to Reproduce

Create a CloudEvent, e.g new ce.CloudEvent({ type: 'foo', source: 'bar', data: { hello: 'world' }, partitionkey: 'foobar' }
Pass it to, e.g Kafka.structured(theEvent)
Attempt to access the timestamp, value, or key. These are not known properties on the return value.
Try to use the body and you find it is incorrectly typed as unknown

Expected Behavior
I would have expected the types to reflect the Object in the Describe the bug section, e.g:
{
  key: string|undefined
  value: string,
  headers: CE.Headers,
  body: string,
  timestamp: string
}

Is this an invalid assumption to make? Passing the result of Kafka.structured(cloudEventInstance) object to a Kafka client such as KafkaJS requires casting the object to access the necessary properties to satisfy the TS compiler. It seems like this casting should be unnecessary.
Additional context
I'm using version 6.0.1 of the cloudevents module. The image below might help provide some context.

After looking a little more at this today, it seems as though the Binding might need to support a generic(s) to pass the necessary structure(s) down to the Serializer? Currently the more specific structures are lost, and the type end up using the plain Message instead of the more specific KafkaMessage.

Yep I think I'm seeing the same issue, but in the reverse.
When consuming a Kafka message, I want to convert it back into an abstract CloudEvent. I can use Kafka.toEvent which takes the general Message type. The Message interface can be seen below.
export interface Message<T = string> {
    headers: Headers;
    body: T | string | Buffer | unknown;
}

This is a bit confusing because Kafka.toEvent is bound to deserializeKafkaMessage which checks for a value property on the message parameter. But we need to pass in a Message which doesn't have this property! Same goes for the key.
This means in order to actually generate a valid CloudEvent from the incoming Kafka message I'm forced to cast the argument. Without casting an Error is raised.
const myCloudEvent: CloudEventV1<string> = Kafka.toEvent({
  headers,
  key,
  value,
  body,
} as Message);

Happy to help out if there is consensus this could be improved, I just can't tell if it's me misinterpreting how the SDK was designed or not.

@FelixHarvey @evanshortiss thank you for your detailed descriptions of the issues you are seeing with the SDK - and I would welcome any contributions you have towards improvement. The interfaces are a bit clumsy.
The Binding interface is what is causing all of this trouble, I think. https://github.com/cloudevents/sdk-javascript/blob/d9ee0e05d1b38c84314d3e0535b17c25470d95a5/src/message/index.ts#L25-L30
I want this to be generic so that various protocols such as HTTP and Kafka, which have differing implementations can all behave similarly when serializing and deserializing CloudEvent messages. The Serializer and Deserializer interfaces that Binding exposes are meant to be the generic API. https://github.com/cloudevents/sdk-javascript/blob/d9ee0e05d1b38c84314d3e0535b17c25470d95a5/src/message/index.ts#L63-L79
However, the result is what you are seeing now. There is some amount of type casting that is inevitable. If you have ideas or suggestions to improve this situation, I'd be more than happy to talk about them.

I am facing the same issue. I implemented a workaround by casting to any and then to Message.
import { Message } from 'kafkajs';
import { Kafka as CloudEventsKafka } from 'cloudevents';

const message = CloudEventsKafka.structured(cloudEvent) as any as Message;


Gradle sync issues: ERROR: Cause: invalid type code: 6C

I have installed Android Studio 3.4.2 (the latest stable one), with all tools updated to the latest stable version.
Project import can't be finished causer Gradle sync issue:
ERROR: Cause: invalid type code: 6C
I tried Invalidate and Restart but it does not help. How to compile project?

You should remove flag Only Sync the Active Variant in Android Studio setting, and it become ok


Create an Search... button behind browse button

Issue type

[ ] bug
[x] enhancement

Overview description
Behind the Browse button should be a Search... button as for other CLI tools, in NetBeans (Node, npm, gulp, bower, etc.)
Steps to reproduce

Go to options
Go to HTML5/JS
Go to Bower
See Search... button
Click on button
If cli was found, it will set the path. Please see my plugin for this logic: https://github.com/Chris2011/NBAngularCLI/blob/master/src/net/chrizzly/netbeans/plugins/nbangularcli/ui/options/AngularCliOptionsPanel.java#L125-L132

Actual results
Expected results
Search button to search for the CLI
Your environment (NetBeans and plugin version, e.t.c.)
NetBeans 8.2, NetBeans textlint support 0.2.0.

I would like to make a PR somehow next week. Or do you want to do it by your own?

I don't think that this is a needed feature absolutely. Don't create a PR.

 Also it will be a consistent behavior as for other tools inside NetBeans, like bower, grunt, gulp, etc. But ok, it is up to you.


Custom pretty select input

We'd like to have the PrettySelect's input be customizable. Currently is hard-coded to an input that is either editable or read-only.
Additionally, we are going to see how it works with having PrettyText be the default text box.

@jdeal some further context. For part of this (or a future PR), I'm going to want to include the ability to insert fields when typing a custom value into a pretty select. The styling is different on those, however, because we'll want to hide the menu except when click the new menu option. I'm not sure if that informs which kind of split is better for the PrettyTextHelper (put choices in the field wrapper or choices in the helper itself), but it's another something to consider.


when clone library and load it, android studio give error

when clone repository my android studio give following error:
Plugin [id: 'com.android.library'] was not found in any of the following sources:

Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
Plugin Repositories (plugin dependency must include a version number for this source)

That is because I have been using Android Studio 4.1. You have to change build.gradle for Android Studio 4.0.


Enrich user-agent with runtime context

Description
This PR adds more information to the User Agent related to the runtime environment.
The current UserAgent contains this information:
{Platform}/{PlatformVersion} cosmos-netstandard-sdk/{Direct Version}
For example: Windows/10.0.18362 cosmos-netstandard-sdk/3.1.3
Now, we will have:
{Platform}/{PlatformVersion} cosmos-netstandard-sdk/{Direct Version} {SDK Version}-{Framework}{RuntimeArchitecture} {ClientId}
For example:
Windows/10.0.18362 cosmos-netstandard-sdk/3.1.3 3.1.0-.NET Core 4.6.27617.04 X64 <some-unique-identifier>
The {ClientId} is generated from DateTime.UtcNow.Ticks
Type of change
Please delete options that are not relevant.

[X] New feature (non-breaking change which adds functionality)

Closing issues
Closes #586

Add an entry in changelog.md

/azp Run


Floating action button

Hi,
as Metro-UI is Mobile First, it may be great having Floating action button like in Core_CSS : https://coreui.net/docs.html#floatingaction
Especially multi action button, its look'n'feel very nice and usefull in mobile app.
Do u think it may be possible in future ?
Thanks for your great working.

Waooh nice !
Thanx :)

added in 4.2.10


compile failed.

程序包org.elasticsearch.xcontent不存在

Please check the maven configuration and confirm whether the elasticsearch package has been downloaded.

Please check the maven configuration and confirm whether the elasticsearch package has been downloaded.

The spring-boot-starter-parentversion used in the current project is 2.7.8. and The elasticsearch version in 2.7.8 is 7.17.8.
noticeable，org.elasticsearch.xcontent.XContentType is removed from elasticSearch ver 7.17.3.so, should we consider useing a more suitable version？ such as 2.7.0？

org.elasticsearch.xcontent.XContentType is removed from elasticSearch ver 7.17.3.

org.elasticsearch.xcontent.XContentType exists in elasticsearch 7.17.8, https://github.com/elastic/elasticsearch/blob/v7.17.8/libs/x-content/src/main/java/org/elasticsearch/xcontent/XContentType.java

程序包org.elasticsearch.xcontent不存在

I had the same problem and it was fixed after deleting org\elasticsearch\elasticsearch\7.17.8 in the local repository.

Please check the maven configuration and confirm whether the elasticsearch package has been downloaded.

The spring-boot-starter-parentversion used in the current project is 2.7.8. and The elasticsearch version in 2.7.8 is 7.17.8. noticeable，org.elasticsearch.xcontent.XContentType is removed from elasticSearch ver 7.17.3.so, should we consider useing a more suitable version？ such as 2.7.0？

Thanks for your feedback, we will upgrade the version of Elasticsearch to the latest.

Please check the maven configuration and confirm whether the elasticsearch package has been downloaded.

The spring-boot-starter-parentversion used in the current project is 2.7.8. and The elasticsearch version in 2.7.8 is 7.17.8. noticeable，org.elasticsearch.xcontent.XContentType is removed from elasticSearch ver 7.17.3.so, should we consider useing a more suitable version？ such as 2.7.0？

@yuehan-mm  Thanks for your feedback, we will upgrade the version of Elasticsearch to the latest, and you can considerate @wForget 's  solution, just clean the elasticearch package locally in your repository

+1 same problem


Doctrine call MongoCursor::rewind when I try get singleResult from Query

Hi, I found some strange issue, when I try to get single record from DB, by code:
$this
	->createQueryBuilder()
	->field('field1')->equals('value1')
	->getQuery()
	->getSingleResult();

then Cursor::toArray, convert cursor to array by iterator_to_array, and iterator_to_array call MongoCursor::rewind (it's not good for perfomance).

Do you have evidence that the query is actually being executed multiple times? Or is the concern just that we're invoking a couple of extra cursor methods?
Cursor::getSingleResult() does reset the cursor before and after executing it, but rewind() should only be called once. The iterator_to_array() behavior should be no different than iterating with foreach and breaking after the first iteration, since we're limiting the reset set to one document.
At the driver level, ['MongoCursor::findOne()`](https://github.com/mongodb/mongo-php-driver/blob/071165f6053b4b6945fe0bdd370d958d62c5c49a/collection.c#L1352) is effectively doing the same thing as [`MongoCursor::rewind()`](https://github.com/mongodb/mongo-php-driver/blob/071165f6053b4b6945fe0bdd370d958d62c5c49a/cursor.c#L1001), followed by `valid()` and `current()`.
Doctrine MongoDB's query builder works against a cursor, which allows it work nicely with the cursor provided for ODM (when hydration is required). For that reason, we don't have a code path that shortcuts to MongoCollection::findOne().


Add context about service API for IoT Hub identity export/import

Update iot-hub-devguide-identity-registry.md to add context around using the service API for exporting and importing identities into an IoT Hub.

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

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


Implement keystone authentication webhook

This pull request brings implementation of keystone authentication webhook.
Please pay attention that build process is clumsy now (one has to enter a lot of data manually). That will be changed in the nearest future.

Did you think about tests? I can recommend to use travic-ci for basic checks: compilation, golint, etc.

Yep we need the tests and travis especially for another repo (feathers-authentication-keystone). However there is no travis yet. I need to figure out how it works etc.
I believe the tests will be introduces in a separate pr.


Remove tmp from links

Description of the change

Description here

Type of change

[ ] Bug fix (non-breaking change that fixes an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Related issues

Fix #1

Checklists
Development

[ ] Lint rules pass locally
[ ] The code changed/added as part of this pull request has been covered with tests
[ ] All tests related to the changed code pass in development

Code review

[ ]  This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached
[ ] "Ready for review" label attached to the PR and reviewers mentioned in a comment
[ ] Changes have been reviewed by at least one other engineer
[ ] Issue from task tracker has a link to this pull request

LGTM! As expected the sidebar links won't work but once we:

remove the existing destination and get-started folders and
rename the folders (tmp-destinations -> destinations, tmp-get-started -> get-started)

we should be good to go 🥇


Add a License to the Repository

I noticed that this repository does not have a license. Would you consider adding a license to clarify the terms under which others can use the code?

Thanks for the remainder. License updated.


Use abstract invvectors

Since Inv, GetData, and Reject all do essentially do the same thing (sending InventoryVectors), abstract this functionality to an abstract class and extend it.

Travis is balking on network tests this evening, merging this regardless