Requesting organization

For a CDS service provider, it is necessary to know which organization (or client) and potentially sub-organization is requesting the service. For example, it may be that a given client purchased only a subset of CDS Service’s capabilities and CDS Service needs this information to properly handle the request. Another example is that the client could be a cloud-based EMR, which encompasses many practices, each with their own organizational structure.
We believe it would be beneficial to add a required organization field to the the CDS service request which would provide the FHIR id of the organization (or sub organization) requesting CDS.
There are at least a few other ways to provide this information, but each has a downside:

FhirServer Url can include an identifier that indicates which organization (or hospital or practice, etc) is requesting the service. The primary issue with this approach is that the CDS service has to parse out the relevant identifier, thereby hardcoding assumptions about how the Url is structured. If those assumptions are ever violated, the process breaks down.

Context could reference the relevant FHIR resources, such as Organization to establish the context. However, the spec and examples currently focus the context on the triggering orders.

Service URL could include a prefix which identifies the organization. However with sub-organizations and sub-sub-organizations this could become unwieldy.

The distinction between an organization that hosts an EHR versus the organization where a patient receives care has also been a challenge in our organization, especially for affiliated clinics that use our EHR, but do not share subscriptions to the same CDS resources.
The infobutton standard makes that distinction. There are two parameters: organization provides and ID of the requestor organization, while careSetting provides the identifier of the patient care setting (e.g., a specific clinic, a specific hospital). This approach would work well for us, but not all EHR vendors implemented the careSetting parameter.


Upgrade to latest Rust (no breaking changes)

This changes the phantom type AudioFormatNum slightly to facilitate impl selection after recent breaking changes in Rust. It does not appear to break the external API.
Also fixes a rename in one of the examples.
Closes #249.

Strictly said, it breaks the external API, but only the part that breaks because of Rust.
Looks good to me!

Strictly said, it breaks the external API, but only the part that breaks because of Rust.
Looks good to me!

@bvssvni I meant that it doesn't break the user API, since this trait appears to be only used for this phantom type here. And not breaking the user API is what matters to me. :wink:

@bvssvni I meant that it doesn't break the user API, since this trait appears to be only used for this phantom type here. And not breaking the user API is what matters to me. :wink:

Great!


Option to auto-merge despite failing non-required CI checks

Hello!
I searched and couldn't find anything along these lines, other than #2132.
I'm not sure whether to classify this as a bug or a feature, but I guess per the documentation this is expected behavior:

For all of the options below Dependabot will wait until all your status checks pass before merging.

As mentioned by some folks in #2132, we use a number of different status checks on GitHub, some of which are required, because they are required, and some of which are not required, because they, well, are not required. I understand the conservative default behavior of not auto-merging PRs with a failing non-required check, but the inability to override this behavior is adding quite a bit of friction to our workflow.
In summary, when one or more non-required checks (as configured by GitHub branch protection rules) fail and all required checks pass, Dependabot comments with:

One of your CI runs failed on this pull request, so Dependabot won't merge it.

and refuses to auto-merge the PR. My request is to allow toggling this behavior, at the organization level and/or at the repo level, to disregard failing non-required CI checks with respect to allowing auto-merge.
Thank you!

Sort of related to this, I have an optional check that's tied to an approval step in CircleCI.

Dependabot will not merge on approval (using @dependabot squash and merge) as long as this optional check is incomplete.
It seems it would be preferable for dependabot to merge once all required checks have passed (if any exist) or once all check have passed if none are required.

👋 Hey there! Sorry for the glacially slow response... we've been a bit buried.
This issue is pretty old, from old Dependabot-preview before it was integrated with GitHub. With the new Dependabot native, we unfortunately are not going to be supporting native auto-merge for the reasons outlined here. However, there is a documented workaround if you wish to setup auto-merge yourself.
I'm going to close, as essentially this issue isn't relevant anymore since the old way of doing automerge doesn't exist.

Sorry to dig up an old issue, but "using @dependabot squash and merge doesn't result in a merge" is a different issue from auto-merge, isn't it? I see it saying

Dependabot will merge this PR once CI passes on it, as requested by @bewuethr.

and then never merge, even when all checks have passed.
Is there a better place to bring this up? This repo, or GitHub community discussions perhaps?


How can i selected text use mouse when i view the pdf document? anybody  ?

thanks!

This is a duplicate of #62. Please see that ticket.


implement FormulaTranslator::visitSingleAssignSubstitution(...)

FormulaTranslator is lacking an implementation of visitSingleAssignSubstitution(...)

If we implement this method, then we should rename the class (e.g. Z3Translator).
The implementation already exists in ModelChecker::doModelCheck.

I think this should be a separate translator, see my comment in #23

I suggest to either close this issue or move it to testing and assign it to @dohan

visitSingleAssignSubstitution has been implemented in MachineToZ3Translator


Pagination, Eslint & Context refactor

closes #7
This PR additionally refactors business logic into two context hooks, one pertaining to Bundles & Tokens
The idea is that since bundles are clusters of blocks, token flow data & any nested block related data, that it would be managed there.
Consuming or interpreting transactions, tokens, balances or balance related events would be managed in the tokens context
Additionally components have been broken out into smaller .tsx components.To make better use of the context hook data being accessable throughout the app, a move towards TS interfaces for data has been made.
Functionally nothing has changed other than some logic for sniffing out if there are more bundles to paginate through
Improvement notes
A simple, can next page, approach has been taken but loading multiple pages and reducing calls can be improved from here

There seems to be an issue between the CSS being served when running yarn dev & when building the project. I suspect that the bundle module css file is being skipped when the build is being run though unable to verify.
There are tailwind classes that aren't being included in the build css despite being used in the markup, I suspect that tailwind might have a treeshaking build step that might be missing the additional modules though still need to validate that


senator menendez senate url has a www

this fixes issue #267
--timball

closed in 696d3807ff8703c205e059cec90ea56cff4ad299. didn't need to update historical urls.


Merge up to October 4th

Please select one of the following

[ ] I am removing an existing difference between facebook/react-native and microsoft/react-native-macos :thumbsup:
[ ] I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos :thumbsup:
[x] I am making a fix / change for the macOS implementation of react-native
[ ] I am making a change required for Microsoft usage of react-native

Summary:
Last merge I'll do for a bit, but I wanted to see if I could get that magic "0 commits behind". Nothing interesting to report in this merge,  save https://github.com/facebook/react-native/commit/0a48a72236806b0eae1f61dca5c03ba321732296 where I deleted some deprecated snapshot tests.
Changelog:
[INTERNAL] [CHANGED] - Merge up to October 4th
Test Plan:
CI should pass

Closing for now, I'll get my screen cap later.


add login functionality

Build the backend functionality to make a secure login possible.

Fixed (#2)

Provide documentation of feature


Fix ClassCastException caused by 2.x's filter in some condition

What is the purpose of the change
When upgrading from dubbo 2.x to 3.x, we have many projects and need to call provider service using 2.x filter and return RpcResult in some case.
So it's better to compatible of RpcResult when 3.x consumer calling 2.x provider
Brief changelog
Fix ClassCastException caused by 2.x's filter in some condition and compatible of RpcResult in dubbo version 2.x
Verifying this change
I test on my local env

Checklist

[x] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Add some description to dubbo-website project if you are requesting to add a feature.
[ ] GitHub Actions works fine on your own branch.
[ ] If this contribution is large, please follow the Software Donation Guide.

@wegod I have try to help you fix the test cases :)

Codecov Report

Merging #12286 (3964118) into 3.2 (cbc2040) will decrease coverage by 4.44%.
The diff coverage is 69.23%.

:exclamation: Current head 3964118 differs from pull request most recent head 0b7bb7b. Consider uploading reports for the commit 0b7bb7b to get more accurate results

@@             Coverage Diff              @@
##                3.2   #12286      +/-   ##
============================================
- Coverage     69.35%   64.91%   -4.44%
- Complexity        2       14      +12
============================================
  Files          1606     1434     -172
  Lines         66229    60142    -6087
  Branches       9718     8857     -861
============================================
- Hits          45932    39044    -6888
- Misses        15851    17011    +1160
+ Partials       4446     4087     -359

Impacted Files
Coverage Δ

...le/src/main/java/com/alibaba/dubbo/rpc/Result.java
11.11% <0.00%> (ø)

...e/src/main/java/com/alibaba/dubbo/rpc/Invoker.java
40.90% <66.66%> (ø)

...src/main/java/com/alibaba/dubbo/rpc/RpcResult.java
66.66% <66.66%> (ø)

...le/src/main/java/com/alibaba/dubbo/rpc/Filter.java
100.00% <100.00%> (ø)

... and 3036 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@wegod I have try to help you fix the test cases :)

Thanks very much.
Right now I'm using 3.1.10.  Will this branch merge into 3.1.11 or 12?

@AlbumenJ My test is done, I found new change in Filter.java and CompatibleResult.java that's better than my first code change.
All case works in both provider side and consumer side, no matter dubbo2.x or 3.x is provider or consumer.

@wegod I have try to help you fix the test cases :)

Thanks very much. Right now I'm using 3.1.10. Will this branch merge into 3.1.11 or 12?

According to the roadmap, 3.1.x is only for security fix now. We can only maintian one branch due to limited working time (:


Market event reconstruction

Market event reconstruction based on historical market data would be useful for testing automated trading algorithms.

Genesis Replicator implements a similar concept based on real-time market data from Coinbase Pro.

Closing this as the idea was implemented in Genesis instead.


fbp: allow to omit ports if only one exists

While manually writing FBP it is inconvenient to type the port name if the node provides a single port, namely this:
_(gpio/reader) OUT -> IN _(console)

could be expressed more concisely as:
_(gpio/reader) -> _(console)

+1 for this issue too.
But I have some comments about it:

Nodes have error output ports, so we should be implicit for nodes that a single port, except error ports.
If another port is added to the node, we break the node API. And that is not happening with current version of fbp.

I suggest to make OUT and IN ports implicit. So independently of the number of ports a node have, we use IN/OUT ports if no port is explicitly selected.

On Tue, 08 Mar 2016 05:09:59 -0800, Otávio wrote:

+1 for this issue too.
But I have some comments about it:

Nodes have error output ports, so we should be implicit for nodes that a single port, except error ports.
If another port is added to the node, we break the node API. And that is not happening with current version of fbp.

I suggest to make OUT and IN ports implicit. So independently of the number of ports a node have, we use IN/OUT ports if no port is explicitly selected.

And what to they map to? And what type do they have?

he means if out output port is specified, you assumed "OUT", if there is a port with such name. It's an "alias".

I don't like that too much, actually
Imo explicit is better than implicit. Also you're creating one extra way to write the same thing.
I don't think it makes it much easier to read.
Port names should be descriptive and help users to understand what should be feed to nodes and what should be the outcomes.

-1 for this as well.


Put "specials" to the end of the seasons list

Summary
Small change, but I'd suggest putting "specials" to the end of the seasons list, they're usually something that is watched when there are no seasons left to watch, if at all. The first thing the person should see in the list is the first season to watch because that's the most important thing. Apps like stremio sort it at the end also.
Thanks 🙏!
Please confirm the following

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.

Available on Release 1.6.12


[Question] Modify playable characters names

Hi, first off, I want to thank you devoted fans for your work on this patch and the fan translation.
As someone who played the game prior to this release I can say it truly improves the performance and loading times. And the fan translation is well done, using the NES version as a basis was a good idea/call. After all, inferior performance and loading times aside, it can be considered the definite 8-bit version of FFI thanks to the bug-fixes, better graphics and audio (those remixes are pretty great).
Regarding my question, as I said, I played this game in Japanese first and therefore wanted to try my save with the fan translation. As I expected, after inserting the user disk, the save loaded just fine but the names were all garbled. So, my question is, maybe during your work with the game you guys found the memory addresses of the playable characters names and the respective character table? or created any other tool to modify this? I'd like to modify my party's names in English and Japanese and that's why I'm asking.
I would really appreciate any help you can provide me, thank you.

Thanks :) I only created the performance patch, not the English translation, so I don't know everything about the naming of the players. Even so, it wasn't hard to find the locations of the names on the user disk.
If you use a hex-editor you'll find the names in the following locations:
0x01402h-0x01405h
0x01442h-0x01445h
0x01482h-0x01485h
0x014C2h-0x014C5h
The names aren't stored using ASCII encoding :(
The upper case characters use from hex-codes 0x08A (0x08A = A, 0x08B = B, ...).
The lower case characters use from hex-codes 0x0A4 (0x0A4 = a, 0x0A5 = b, ...).
Numbers use hex-codes from 0x080 (0x080 = 0, 0x081 =1, ...)
Hope this helps!

Thank you!, that was really helpful, just what I needed.
I didn't expect that editing the User disk would be so straightforward, but luckily looks like Square didn't care about checksums back when they ported FFI to the MSX. I did exactly what you mentioned and was able to edit the names with the addresses and the character table you shared. Thanks again, cheers :)


Type annotations are not recognized with --translate_amd_modules

This issue was imported from Closure Compiler's previous home at http://closure-compiler.googlecode.com
The link to the original issue is:
https://code.google.com/p/closure-compiler/issues/detail?id=842

Hello,
I have the same issue (but this time I'm using process_common_js_modules), but I guess the reason is the same. From previous description on code.google:
I think the problem is just that those things actually have different names.

E.g. Bar is really called Bar$$module$lib$Bar (Check the unobfuscated compiled source to make sure).

In theory we could hack something up to make the name a little prettier.
E.g. require('./lib/Bar').Bar

but not much more.

Because of this issue there is no way to use custom types for type checks if you are using translate_amd_modules or process_common_js_modules and maybe rewrite_es6_modules).
Java is not my main language, but if you can point where and how I can fix this - I would be happy to resolve it.

This pass does rewriting similar to what is needed:
https://github.com/google/closure-compiler/blob/5c3faf517e8b31fa5cea5c7ca86d215e31f09a01/src/com/google/javascript/jscomp/ScopedAliases.java
The basic process is controlled by this method:
https://github.com/google/closure-compiler/blob/c804f50534cd6a8c82f59297a0820fecf3c8d9e7/src/com/google/javascript/jscomp/Compiler.java#L1539
Is that sufficient to get you started, there are similiarly named files with tests.


Fix cudart header detection for conda

The assumption of 0 <= len(wheel_dir_count) <=1 is no longer valid as we now support loading from conda packages: https://github.com/cupy/cupy/blob/d717917e1d72c4318fcdcb73b4c9b29fbda176ff/cupy/_environment.py#L476-L479
xref #8519

/test mini


Repairing MacOs build on develop

Description
develop -> master is failing to compile in MacOs: https://github.com/hyperledger/iroha/pull/3960
That is why I need to repair the compilation. It looks that GTest is not compilling for MacOS because compiler is now newer than before (newer compiler usually is more strict). Newer compiler signals some things as warnings, but GTest has -Werror compilation flag. So the solution is to create patch for vcpkg port of gtest to remove the flag (how to create patch is here: https://stackoverflow.com/questions/72588408/vcpkg-how-to-edit-package-file-when-compilation-fails-when-installing-package).
I don't know if the commit will repair the problem, we need to wait for CI to check:D.

Linked issue

Closes #{issue_number}

Benefits
We will be able to upgrade main branch with changes from develop

Checklist

[ ] I've read CONTRIBUTING.md
[ ] I've used the standard signed-off commit format (or will squash just before merging)
[ ] All applicable CI checks pass (or I promised to make them pass later)
[ ] (optional) I've written unit tests for the code changes
[ ] I replied to all comments after code review, marking all implemented changes with thumbs up

It is not ready yet. I need some way to run:

but I unfortunately can not find the option anywhere, could somebody help?
It will be great if somebody runs also:

it is waiting about 12 hours:)

@safinsaf I hope that this PR (https://github.com/hyperledger/iroha/pull/3977) is fix for: https://github.com/hyperledger/iroha/pull/3960, but to make sure we need to enable checks:

Those checks seems to be enabled only when we want to merge something into main branch, but we need to enable them also for other branches. Unfortunately I'm not CI expert and I can't find where it is enabled only for main. Could You help, please?

It looks that everything works expect for building on MacOs:

DCO:D.

When I check details about Building on MacOS I see that building dependencies is fixed (what was problem here: https://github.com/hyperledger/iroha/pull/3960):

Unfortunately Iroha is not building on MacOS (interesting thing is that on Linux it is building). Details of compilation failures:

I see three solutions (I don't know if they will help):

Try to downgrade protobuf (it was upgraded here: https://github.com/hyperledger/iroha/pull/3862)
Can we change compiler on MacOs from clion to gcc10?
Try to fix on MacOS with current configuration - but I don't have MacOs, so I can not try that way.

We have problem, because it is not that easy to fix its, according to possible solutions from another post (https://github.com/hyperledger/iroha/pull/3977#issuecomment-1765862908):

Downgrading protobuf is not working, so I'll revert reverting commit (https://github.com/hyperledger/iroha/pull/3977/commits/fc4ebec33c5f68d9eb3835dfb07f7d59d7108c40)
Changing compiler into g++-10 on MacOs - didn't help.

I noticed that compilation problems are in iroha-lib (what was done during last year internship project): https://github.com/hyperledger/iroha/pull/3977#issuecomment-1765862908
So I decided - let's check if after commenting them everything is going to compile. Unfortunately we faced linkage error:

We can come back to clang compiler and maybe it will pass:)

I noticed that compilation problems are in iroha-lib (what was done during last year internship project): https://github.com/hyperledger/iroha/pull/3977#issuecomment-1765862908
So I decided - let's check if after commenting them everything is going to compile. Unfortunately we faced linkage error:

We can come back to clang compiler and maybe it will pass:)

Summary (it looks that we fixed with @safinsaf), but the solution is not best possible.
MacOS build was failing, because dependencies were not compiling. So I've created path for VCPKG GTest port and dependencies are building. Another problem was compilation of internship project to create iroha-lib in C++ inside the main repository. As I see probably it never compiled for MacOS (but I can be wrong). The current problem with compilation is connected with examples for the iroha-lib (details of compilation error: https://github.com/hyperledger/iroha/pull/3977#issuecomment-1765862908), unfortunately changing compiler didn't help. So I added some kind of dirty hack - I've added conditional compilation in CMake of the iroha-lib (if(NOT APPLE) compile). Now everything passes.
Unfortunately I can't fix this better way, because I don't have MacOS.
So the question for somebody who is deciding about future of Iroha 1 - can we leave like that?


Readme Updates

Cleaning up the readme, scenarios, manifest and referrers spec markdown files.

Make sure to squash-merge or clean up commits before merging.


ibis example project

This demonstrates how ibis can be embedded within a sqlmesh project. The project is largely the same as the default init project, with the addition of ibis_full_model.py which is a Python model that uses ibis to replicate the model created by full_model.sql

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

Have we tested this with Airflow?

Have we tested this with Airflow?

i don't think it's necessary, it's just an example project.


🐛 Improve the error message for quote types

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Retiarii] mnist/test.py: Error on trainer.fit

NNI version: latest

I tried to run CLI mode on nni/test/retiarii_test/mnist/test.py by adding some code blow, but error raised:

trainer.fit(NET) : TypeError: __init__() missing 1 required positional argument: 'hidden_size'
trainer.fit(base_model) :  RuntimeError: mat1 and mat2 shapes cannot be multiplied (100x800 and 128x10)

Modify base_model = Net(128) to base_model = Net(800) seems to be able to run.
More importantly, I noticed nn.LayerChoice is not take effect in the CLI mode (without RetiariiExperiment). The output on fc1 is the same as input.
Is there any way to change mnist.test to CLI mode?
Regards,

Hi, do you mean that CLI mode uses nnictl? Retiarii currently does not support nnictl, and RetiariiExperiment is required if you want to use Retiarii. If you want to use nnictl, you can use the old NAS version, https://nni.readthedocs.io/en/stable/NAS/Overview.html .

Modify base_model = Net(128) to base_model = Net(128) seems to be able to run.

And what is this mean?

Thanks for your reply.
I mean run this demo in command line mode, not running webserver or nnicli.
I uploaded modified script in https://github.com/duchengyao/nni/blob/master/test/retiarii_test/mnist/test.py

Hi, what's the reason you don't want to use the webserver? all kind of launching nni experiment ways will start webserver.
@ultmaster please help if we can use trainer without RetiariiExperiment?

Yes you can. The main reason is that the base model is just a "base model". It's very possible that the base model is not a runnable-model before running any mutation and thus cannot be trained. If you want to debug a trainer (I believe it's called evaluator now), sure you can use trainer.fit. But keep in mind that this API is meant to be internal and subject to change in 1-2 releases.

It's convenience to visualize parameters, metrics of NAS on webserver, but the webserver prevents me from understanding how the algorithm works.
I'm interested in your new algorithm retiarii, and tried to understand its implementation at the code level. When I read the code, some threads unrelated to the algorithm confused me. If there is a way to run MNIST demo directly without web server, it will be very helpful to me.
BTW, following retiarii/experiment/pytorch.py, webserver is not required on oneshot nas algorithm?

For your first point, if we make the strategy running in the main thread, will it be more straightforward to you?
For your second point, oneshot experiment is just simply running trainer.fit without messy multi-trial issues. Therefore webserver is not needed.

It will be great helpful to me if the strategy is running in the main thread.
Thanks for your reply ^_^

@ultmaster  is it available now？

For your first point, if we make the strategy running in the main thread, will it be more straightforward to you?
For your second point, oneshot experiment is just simply running trainer.fit without messy multi-trial issues. Therefore webserver is not needed.

Not really. As we have a lot of features going on, looks like it will take 1-2 months, probably longer.


Add memory extractors for pod and node level

Description:
1. Added memory extractor at pod and node level
2. Add unit tests for memory extractor
3. use cpu and memory extractor for k8s windows

Have you done testing beyond unit testing for this PR? Can you document that? Maybe show a screenshot or terminal dump of stuff working


Does NimCX require nim v1.9.1?  Latest stable is 1.6.10

The nimble file has now been updated so you can try to install .
The library is usually test compiled  against latest devel , but it also works for stable version.
It compiled on Debian based systems (Ubuntu,Parrot,Zorin) and also on a recent openSUSE Tumbleweed.

Thank you!


window.plugins.flashlight.isSwitchedOn(); return false if flashlight was turn on by the android button

The plugin isn't able to identify correctly if the flashlight in on or off.
If I turn on the flashlight by the android button or widget, the function will always return false.
It only returns true if I use window.plugins.flashlight.switchOn(); to turn on

I have a similar problem on iOS, if the light was turned on by another app this .isSwitchedOn() returns false. This is because the .isSwitchedOn() method returns the internal status of the light, assuming it will always be turned on/off using this plugin.
The solution is to query the light status for every call to .isSwitchedOn().

I have similar issue, isSwitchedOn() return false always until I execute toggle() function. If I never run any other function than isSwitchedOn() then it always returns false.
Any update @Clankey @john-doherty  @EddyVerbruggen @IagoSRL @cooper1388

@akashbiz Please don't ping people. Instead, take a look at the code and try to come up with a solution.


Change logic for "max_row" count

sheet.max_row just take count from description of file. But, sometimes, we have rows with some functionality, formulas, styles. And max_row count it too. In this PR, I've added counting rows by iterating it.

Thank you @reggin
I added tag 0.5.7 for this change

@arodiss thanks for tag.


Rework enumeration

Implicit static members should be handled like regular static members

Enum as static variable still doesn't work. Descriptor need to handle these separately, since the object reference actually changes when a enum variable is modified.


parametrize benchmark tests based on test data in csv; enable switchi…

…ng between public test data in this repo and private test data; decryption process of the private test data

Good work; merging :)


Align receipt with execution apis

Description:
Move uints back to hex strings
Signed-off-by: Danno Ferrin<EMAIL_ADDRESS>Related issue(s):
Fixes #302
Notes for reviewer:

Checklist

[ ] Documented (Code comments, README, etc.)
[ ] Tested (unit, integration, etc.)

Codecov Report

Merging #332 (ac65081) into main (334345b) will increase coverage by 0.04%.
The diff coverage is 25.00%.

@@            Coverage Diff             @@
##             main     #332      +/-   ##
==========================================
+ Coverage   62.44%   62.48%   +0.04%
==========================================
  Files           9        9
  Lines         868      869       +1
  Branches      141      141
==========================================
+ Hits          542      543       +1
  Misses        288      288
  Partials       38       38

Impacted Files
Coverage Δ

packages/relay/src/lib/eth.ts
64.25% <ø> (ø)

packages/relay/src/lib/model.ts
83.00% <25.00%> (+0.17%)
:arrow_up:

Continue to review full report at Codecov.

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


Allow setting custom heater duty via web interface

Request from Nick:

For some testing that I’m doing + the solid-solid PCM it seems like we could do with lower heater duty cycles than 10%. Would it be time consuming to add a few more buttons, or even some sort of slide scale/input to give many more options? I think for some of the tests going as low as 1%.

We implemented this feature yesterday at UTS and deployed on all three Beaglebones there.
There is now a text box for a custom duty level, and an "Apply" button to apply it. Values between 0.0 and 1.0 are accepted, and converted to a 0-255 value in JavaScript.


BatchParser error in ExportImportSqlConfig.ps1

Migrating SQL Server Configuration
Start-SqlMigration : Configuration migration reported the following error Exception calling "ExecuteNonQuery" with "1" argument(s): "Could not load file or assembly 'Microsoft.SqlServer.BatchParser, Version=<IP_ADDRESS>, Culture=neutral,
PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified."

Not an issue with the script, but rather Windows.


[Firefox] ::placeholder pseudo-element and :placeholder-shown pseudo-class have been unprefixed

https://www.fxsitecompat.com/en-CA/docs/2016/placeholder-pseudo-element-and-placeholder-shown-pseudo-class-have-been-unprefixed/

This'll be updated when we update our Autoprefixer.


Toma dev

Please merge these changes

I checked out your branch and tried to run it on my mac.  I get the error trying to call the webook.

Is that you Ken?  (see my note in the zoom chat)

On Jun 29, 2021, at 1:26 PM, kens-aais @.***> wrote:
I checked out your branch and tried to run it on my mac. I get the error trying to call the webook.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/openidl-org/openidl-main/pull/16#issuecomment-870818570, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADXTGN7X6Q3K4D5LYKD7EKDTVIF45ANCNFSM47QTS6PQ.


Redis: SELECT command is not supported ?

Title: Redis: SELECT command Is not supported ?
Description:
Hi community,
I want to use envoy proxy by specifying redis database number.
However, when using envoy proxy, if you specify more than DB No.1, unsupported command 'select' error will occur.
And SELECT command is not listed in redis.rst#supported-commands.
Do you plan to support it in the future?

The Result of go-redis with envoy
// main.go

package main

import (
	"log"

	"github.com/go-redis/redis/v8"
)

func main() {
	for dbNumber := 0; dbNumber <= 16; dbNumber++ {
		client := redis.NewClient(&redis.Options{
			Network: "tcp",
			Addr:    "localhost:10000", // envoy proxy
			DB:      dbNumber,
		})
		if err := client.Get(client.Context(), "key").Err(); err != nil {
			if err == redis.Nil {
				log.Printf("DB:%d Key was not found", dbNumber)
			} else {
				log.Printf("DB:%d %v", dbNumber, err)
			}
		}
	}
}

// Execution result =>
2022/11/22 23:02:56 DB:0 Key was not found
2022/11/22 23:02:56 DB:1 unsupported command 'select'
2022/11/22 23:02:56 DB:2 unsupported command 'select'
2022/11/22 23:02:56 DB:3 unsupported command 'select'
2022/11/22 23:02:56 DB:4 unsupported command 'select'
2022/11/22 23:02:56 DB:5 unsupported command 'select'
2022/11/22 23:02:56 DB:6 unsupported command 'select'
2022/11/22 23:02:56 DB:7 unsupported command 'select'
2022/11/22 23:02:56 DB:8 unsupported command 'select'
2022/11/22 23:02:56 DB:9 unsupported command 'select'
2022/11/22 23:02:56 DB:10 unsupported command 'select'
2022/11/22 23:02:56 DB:11 unsupported command 'select'
2022/11/22 23:02:56 DB:12 unsupported command 'select'
2022/11/22 23:02:56 DB:13 unsupported command 'select'
2022/11/22 23:02:56 DB:14 unsupported command 'select'
2022/11/22 23:02:56 DB:15 unsupported command 'select'
2022/11/22 23:02:56 DB:16 unsupported command 'select'

The Result of go-redis without envoy
// main.go

package main

import (
	"log"

	"github.com/go-redis/redis/v8"
)

func main() {
	for dbNumber := 0; dbNumber <= 16; dbNumber++ {
		client := redis.NewClient(&redis.Options{
			Network: "tcp",
			Addr:    "localhost:6379", // redis container
			DB:      dbNumber,
		})
		if err := client.Get(client.Context(), "key").Err(); err != nil {
			if err == redis.Nil {
				log.Printf("DB:%d Key was not found", dbNumber)
			} else {
				log.Printf("DB:%d %v", dbNumber, err)
			}
		}
	}
}

// Execution result =>
2022/11/22 23:09:12 DB:0 Key was not found
2022/11/22 23:09:12 DB:1 Key was not found
2022/11/22 23:09:12 DB:2 Key was not found
2022/11/22 23:09:12 DB:3 Key was not found
2022/11/22 23:09:12 DB:4 Key was not found
2022/11/22 23:09:12 DB:5 Key was not found
2022/11/22 23:09:12 DB:6 Key was not found
2022/11/22 23:09:12 DB:7 Key was not found
2022/11/22 23:09:12 DB:8 Key was not found
2022/11/22 23:09:12 DB:9 Key was not found
2022/11/22 23:09:12 DB:10 Key was not found
2022/11/22 23:09:12 DB:11 Key was not found
2022/11/22 23:09:12 DB:12 Key was not found
2022/11/22 23:09:12 DB:13 Key was not found
2022/11/22 23:09:12 DB:14 Key was not found
2022/11/22 23:09:12 DB:15 Key was not found
2022/11/22 23:09:12 DB:16 ERR DB index is out of range

The result of python redis with envoy
import redis

r = redis.Redis(host="localhost", port=10000, db=1)
r.get("key")

// Execution result =>
redis.exceptions.ResponseError: unsupported command 'SELECT'

cc @weisisea @mattklein123

SELECT is not supported for redis cluster and for similar reasons I'm not sure how it would be implemented for non-redis cluster sharded connections. Feel free to propose a design.

Thank you for your reply!
I was able to understand the policy, so it's okay for now.


update from main

Sorry, I was trying to merge your branch into my branch and I got confused 😢

Sorry, I was trying to update my fork and I got confused 😢

No worries man, it happens 🙂


How was your models trained?

Does your released model trained using the temporal annotations, or just the video level labels?
Thanks.

The challenge models are trained with activity instances clipped according to the temporal annotations.
If you are looking for approach using only video level label, please check out our CVPR17 paper
UntrimmedNets for Weakly Supervised Action Recognition and Detection.

Thanks.


WebVR in mobile systems black screen in requestPresent

Description:
Greetings,
We have a very weird bug with the WebVR implementation in our System. We are trying to use webvr-polyfill library (https://github.com/immersive-web/webvr-polyfill) with our system and works great in HTC VIVE and WebVR Simulator Extension for Google Chrome. the issue is trying to call : window.vrDisplay.requestPresent([{ source: this.renderer.domElement }]); in Mobiles ( IPhone 7 IOS and Samsung Galaxy S8 Android) The screen stay black and the debug not throw any error in the console when we debug the Android device with google chrome remote debugging. when I quit the WebVR (Button calling window.vrDisplay.exitPresent();) There's error that never was presented. We think that there's some library that can be conflicting, we are using Zepto, MMDParser, ThreeJS, Tween, Stats (fps). Also we are importing Lodash. I quit the libs and still not working. I don't know If I miss any library or configuration but is working for my HTC Vive.
Hopefully you can give me a good way to proceed
Best Regards
Additional Information:

webvr-polyfill version:  v0.10.6
Browser name/version/release channel: Google Chrome Mobile /  67.0.3396.87
Operating System: IOS 11.4

Hello!
Thanks for answer, this is the link : http://ec2-34-208-138-249.us-west-2.compute.amazonaws.com:7900/home.html
Stay black, I don't get it. in divided mode, cardholder, not showing and not executing requestPresent.

I can recreate this on Chrome 67 with WebVR disabled. That being said, not sure what the issue is. I'd recommend reducing things in the scene to see what's causing it

This is happening for me with android devices (no problems on iOS). Any news on this ?

With other scenes rendering OK, if there's an isolated test case of what in the scene is causing this, I can take a look


[event-hubs] adds loadBalancingOptions and greedy load balancing strategy

Fixes #6108 and implements #9140
Description
The change adds loadBalancingOptions to the EventHubConsumerClient options passed to the constructor. These options allow the user to configure the load balancing behavior when the client is using a CheckpointStore.
Breakdown of loadBalancingOptions
There are 3 fields in loadBalancingOptions:

strategy: this can be set to either "greedy" or "balanced".
updateIntervalInMs: Controls the frequency with which the client checks if the distribution of partitions across clients is balanced.
partitionOwnershipExpirationIntervalInMs: Controls how long a PartitionOwnership can be unmodified (claimed) before it is considered expired.

Options 2 and 3 will likely be set together (e.g. if the updateIntervalInMs is increased, then the partitionOwnershipExpirationIntervalInMs will likely need to be increased as well, otherwise the client might not get a change to reclaim a PartitionOwnership before it is considered expired.
Balanced strategy
This was the default strategy used before this change. Each updateIntervalInMs, the client will claim 1 partition until the partitions are evenly distributed across clients.
Greedy strategy
With this strategy, each updateIntervalInMs, the client will determine how many partitions it will need for all partitions to be evenly distributed across clients and claim them all.
PartitionLoadBalancer vs LoadBalancingStrategy
Previously, we had a PartitionLoadBalancer interface with 2 implementations: GreedyPartitionLoadBalancer  and FairPartitionLoadBalancer .
With this change, I've redefined PartitionLoadBalancer as LoadBalancingStrategy and created 3 implementations: BalancedLoadBalancingStrategy, GreedyLoadBalancingStrategy, and UnbalancedLoadBalancedStrategy (open to other names for this one).
The FairPartitionLoadBalancer is roughly the same as the BalancedLoadBalancingStrategy. The main difference is that the BalancedLoadBalancingStrategy only returns the new partition to claim, whereas the FairPartitionLoadBalancer also returned all the partitions the client already owned.
The GreedyPartitionLoadBalancer is roughly the same as the UnbalancedLoadBalancingStrategy. Both of these will just return all the partition ids they're handed (they do no actual load balancing).
The GreedyLoadBalancingStrategy is brand new as part of this feature. It is similar to the BalancedLoadBalancingStrategy, except instead of returning just 1 partition, it returns all the partitions that are needed to get the client to a balanced state.
Why don't LoadBalancingStrategies return partitions already owned by the client?
This turned out to be unnecessary because the client already knows which partitions it owns. It also makes it easier to ensure that when we claim the partitions, we claim the ones we don't already own first (which decreases the likelihood that another client claims it first).

/azp run js - eventhubs-client - tests

/azp run js - eventhubs-client - tests

/azp run js - eventhubs-client - tests

/azp run js - eventhubs-client - tests

/azp run js - eventhubs-client - tests

The single test failure in event hubs looks like it might just be a flaky test. I saw it failed once on Friday off of master (so without the changes from this PR). The core test failure looks like a flaky keyvaults test, which this PR definitely does not touch.

/azp run js - eventhubs-client - tests

/check-enforcer reset

/check-enforcer override


CLI tool returns non-zero exit code when input is correctly formatted

From scalariform --help:

--test, -t Check the input(s) to see if they are correctly formatted, return a non-zero error code if not.

However, it seems to be doing the opposite:
$ scalariform --test Formatted.scala
[OK]     Formatted.scala

$ echo $?
1

$ scalariform --test Unformatted.scala
[FAILED] Unformatted.scala

$ echo $?
0

#74 should fix this

Seems you're right. Thanks!


UAT Bug- regulated operation fields that shouldn't show up

Describe the Bug:
field do not match wireframe reference
Steps to reproduce the behaviour:

select Reporting Operation as purpose of registration
I can then select a Regulated Product, this does not match the wireframe for this process. Wireframe does not have Regulated Product Names option.

Screenshots:

Additional information:
Browser: MS Edge
Additional Context
User story: As an External User, for a Reporting or Reporting-only operation, I will only fill out the necessary fields for this registration purpose type.
Link to UAT ticket: https://teams.microsoft.com/l/entity/com.microsoft.teamspace.tab.planner/mytasks?tenantId=6fdb5200-3d0d-4a8a-b036-d3685e359adc&webUrl=https%3A%2F%2Ftasks.teams.microsoft.com%2Fteamsui%2FpersonalApp%2Falltasklists&context={"subEntityId"%3A"%2Fv1%2Fplan%2FbyyJUkJggkaPhsw6jAP-oWUAGWDg%2Ftask%2FVI7NGf7xEEO_59fFAV7CQWUAHtfF"} -

Thanks @TammieV-BCG - this is a known bug and already has a ticket for it. #2337
cc: @andrea-williams


Status bar indicator doesn't reflect current focus

Testing #174707
It's unclear how these settings play with ctrl+m as a user. Additionally, when focus is in the editor the status bar indicates correctly if tab moves focus, but in the terminal it doesn't.

/duplicate https://github.com/microsoft/vscode/issues/174924


PHP Notice: Undefined offset: 10 in src/Randomizer.php on line 60

Steps to reproduce:
Randomizer::generate();
Expected result:
any random text with punctuation
Actual result:
PHP Notice: Undefined offset: 10 in src/Randomizer.php on line 60
Package version:
v0.0.2
Composer version:
1.9.0
PHP version:
7.3.9

Fixed in https://github.com/ohchiko/randomizer/commit/660834c0456a44abf87312cabed91a5652d00b87


fix: unauthenticated Access to /rate URL

closes #46
This PR addresses a security vulnerability where the /rate URL was accessible without requiring user authentication. The issue allowed unauthorized users to access /rate page.

Thank you 👍  I will test after lunch


[SPARK-11074] Automatically create event log dir.

This commit changes EventLoggingListener to try to automatically create the
event log directory when it doesn't exist (previously, it exited with an exception
when the directory didn't exist).

Merged build triggered.

Merged build started.

Test build #43598 has started for   PR 9082 at commit ba7d157.

AFAIK the argument for not doing this was that the directory might not be created with the properly restricted permissions. @vanzin knows more of the context here.

Test build #43598 has finished for   PR 9082 at commit ba7d157.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/43598/
Test PASSed.

Merged build finished. Test PASSed.

Yeah there was more discussion on the JIRA.  My perspective was that if the user is unhappy with the permissions, they can always change it after the fact, and as much as possible, Spark should "just work" without the user needing to set things like the log directory up. @vanzin's perspective is that the log directory doesn't belong to the application, so the application shouldn't create it.

they can always change it after the fact

Except with this patch the user doesn't have any idea when the directory was created in the first place. They'll only know that something needs to be done when they get an error.

Spark should "just work"

It just works today. You need to enable something that is disabled by default to get into the situation you're trying to fix. And the fix is a simple "make sure the directory exists before trying to tell Spark to write to it". Kinda like every other tool does, btw. (try touch /tmp/doesnotexist/foo)


backward incompatible change in github.com/xitongsys/parquet-go

% go build
# github.com/chrislusf/gleam/plugins/file/parquet
../../go/pkg/mod/github.com/chrislusf/gleam@v0.0.0-20201128110619-d48afd638bae/plugins/file/parquet/parquet_file_reader.go:8:2: imported and not used: "github.com/xitongsys/parquet-go/types"
../../go/pkg/mod/github.com/chrislusf/gleam@v0.0.0-20201128110619-d48afd638bae/plugins/file/parquet/parquet_file_reader.go:73:29: undefined: ParquetTypeToGoType

it seems in v1.6.0 that functions was removed.
Doing go get -u<EMAIL_ADDRESS>solves the problem for me, but it would be better if gleam had some go.mod file
@xitongsys breaking API Changes should be done in a v2 version, doing it in v1 will break every thing. please see https://blog.golang.org/v2-go-modules

@xitongsys could you please help (again) on updating the parquet APIs? It will be nice not to be fixed to an old version.

@xitongsys could you please help (again) on updating the parquet APIs? It will be nice not to be fixed to an old version.


"execution exceeded timeout" on iPhone 3

I'm trying html2canvas to run in Safari for iPhone (iPhone; U; CPU iPhone OS 3_1_3)  but I always obtain this timeout error during the page parsing by the prototyped function "parsing". In particular I obtain this error after about 35 recursive calls.
I tried inserting some setTimeout or setInterval, but I obtain lots of other errors and I'm not able to get the image

What page are you trying to render? Is it local?

I have pasted html code from http://giove.isti.cnr.it/ in a local page. In desktop browsers it's all perfectly working, on this iPhone I have inserted a check to stop the recursion after 35 times, so I obtain an image, but with some wide empty spaces...
I'll test it on an IPhone 4 as soon as possibile and also in an Android!

Any chance you could try running it, having the page hosted on a server (local server or online)? There are AJAX issues loading content locally, and although it shouldn't timeout as you described, it is the first thing that comes to my mind as a cause.


Support for batchGet API

Hi, is there going to be support for batchGet?
We need that because we have 200+ worksheets to grab from, and google is triggering its API rate limit errors. BatchGet supports grid ranges which would tremendously help to reduce our API calls.
It would be really helpful to have that, cheers!

@theoephraim Thanks for considering this, however, it's been a while and I no longer remember the details of my now-abandoned project.
But I think it'll still be a good addition to have for the library. I guess a 1:1 match with the query and path parameters is a good start.


Default error page with server app

When using tomcat, undertow or netty, we should add a default error page similar to what generator-jhipster provides

As always the problem is is to have a decent UI for that, still lacking contributors able to do that

we could take the same page in generator-jhipster, it will be better than nothing
And I think it's an easy ticket

It would be really missleading since on the information on this page don't work at all for JHLite

same page, with some update/changes of course, don't worry ;)

Hello guys,
I'm up for that issue :). I'm quite new to jhipster & jhipster-lite so I'm gonna need some help please :).
To be clear, the goal is to replace this screen :

When I tried to generate a project without frontend with generator-hipster, I got that screen, I'm not sure if, based on your discussion above that this the target for jh-lite too :

Thanks

I think it's a good start, to use the same page in generator-jhipster
so yes ! let's do it and use this same page :)


WIP: Fix Django 4 deprecations

Description of changes

Code Checklist

[ ] I have added tests
[ ] I have provided documentation

Visual changes

Before

After

Solid at least one full minute saved on running tests in CI @henrikskog by doing it in parallell


[DISCUSSION] Adopting JSON-like format as next-generation model format

As discussed in #3878 and #3886 , we might want a more extendable format for saving XGBoost model.
For now my plan is utilizing the JSONReader and JSONWriter implemented in dmlc-core to add experimental support for saving/loading model into Json file.  Due to the fact that related area of code is quite messy and is dangerous to change, I want to share my plan and possibly an early PR as soon as possible so that someone could point out my mistakes earlier(there will be mistakes), and we don't make duplicated work. :)
@hcho3

@trivialfis Are we thinking of something like dump_model(dump_format='json'), except that we'd be able to both read and write the new model format? (JSON dump is currently write-only)

@hcho3 Save() and Load(), with dmlc::JSONwriter * instead of dmlc::stream* as parameter.

@trivialfis Awesome! We can add it as a plug-in.

@hcho3 My plan is we replace the old binary Save and Load in a few releases, so currently I'm trying to patch to code directly.  When it's done, XGBoost will save to json by default, as long as we keep the old binary Load function in the code, new releases of XGBoost can still read old binary format.  WDYT?

@hcho3 Good idea.  This way we don't even need to change the interface.

@trivialfis Cool. I'll look forward to your pull request.

I'd argue for text models, because binary models introduce long-term compatibility and maintenance burden, case in point, and recently there have been requests for adding additional parameters to the model that cannot be satisfied easily, I think we might be breaking compatibility. [1] and I remember users asking for the number of samples in each leaf.
A JSON model would make it much easier to extend, having a binary specification with explicit versions would also help greatly, see e.g. DataSketches. Other options like exporting/importing to JPMML or ONNX (not sure if they support decision trees) could be left for other repositories.

because binary models introduce long-term compatibility and maintenance burden

Depends on design. Usually developers make the format extendable enough using tag-size-contents pattern or just checking version.

cannot be satisfied easily because of backward compatibility,

Then I guess we should design a new binary format with extendability in mind and deprecate the old one. We will have to have some schema anyway, so no need to use generic-purpose formats like BSON/msgpack.

Other options like exporting/importing to JPMML or ONNX (not sure if they support decision trees) could be left for other repositories.

onnx supports decision trees, but it is a generic-purpose format optimized for arbitrary computation graphs
And I have some troubles with building it.

I had someone tell me that XGBoost model has endian compatibility issue. Models trained with little-endian machine cannot be loaded onto big-endian machine. Endian compatibility is one reason to favor text based format (as long as we stick to UTF-8)

Also note that LightGBM uses INI-like format for model serialization.

Endian compatibility is one reason to favor text based format (as long as we stick to UTF-8)

Endian-compatibility is not a big problem - we can just say that little endian should be used and transform endian on serialization. Or we can just save the endian in format and transform if it doesn't match machine endianness.

@KOLANICH That's a fair point. I think a good way to proceed is to have multiple parser plugins implemented and then hold a beauty content to choose the best alternative for serialization format. The criteria are

It should be performant.
It should not introduce dependencies that makes compilation too difficult.
It should be easy to extend without breaking backward compatibility (models given by old XGBoost should be able to load onto new XGBoost).
It should be independent of endianness and architecture of machines.
It should be compact (as in byte size of the serialized model).

Personally, I'd eliminate Protocol Buffers from consideration. I've tried it in another project (dmlc/treelite) and it takes a long time to compile from source.

I ended up re-implementing a Json library due to it's too hard to get dmlc::JSONReader working (Writer is fine).
As for other formats, the simple facts are:

We have different models and I want to remain the possibility of adding new ones.
Only the model itself knows how to save/load its internal data.
There are unlimited number of formats.

So a Json representation can be both a middle and an end format.  One can transform its memory representation however they like.  This can also be viewed as a reason for re-implementing a Json library, since the one in dmlc doesn't has a concrete data structure(it's a reader and loader with a stream, not exactly a data structure).

@hcho3 I kept the binary model and it's still default.  I thought about the performance issue, and it turns out there are 3-party specifications for binary form of JSON.  Just search "binary Json" should return a lot.

@trivialfis Thanks for the pointer. BSON looks like a good choice for binary encoding of JSON, given its permissive license (Apache 2.0) and support from MongoDB.
Also, Microsoft/LightGBM#1083 uses multi-threading to speed up serialization of large models. I'll leave more details comments in #3930 about potential use of OpenMP for serializing trees in parallel.

@trivialfis MessagePack also looks like a good one as well.

Okay, I will focus the discussion in this issue rather than #3930 .  My proposal is

Implement a format independent data structure storing our models in memory during serialization as the middle form.  Copied from #3930 :

During serialization, we will have a middle form of our models. In this PR, it's the Json class, which can be easily translated into our actual models with all parameters and model specific data preserved. Adding new parameters/models/data won't cause trouble since the class that make the changes will know how to deal with the changes by itself. While the old binary dump doesn't have such representation, to add new field, one have to hack the learner model parameter in a very careful way, and there's no way to propagate loaded data except for string parameters to other classes.
As for how the Json class is stored in disk doesn't effect Json class itself, you can traversal Json's nodes tree and obtain a complete different output format, say BSON. What I meant, specifically, is this Json class.

#3930 is already a working example (albeit Linux only currently with MSVC not building), you can use the patch from it to generate a json file to see how's it look like and room for improvement.

Let's first introduce plain utf-8 text Json as the end format, then consider other formats later.  From this, we can see how's it working, if it's worth the effort, possibility of new troubles or whether the extendibility is indeed improved.  Since once we have a middle form representation, implementing other formats are just items on the check list.  Anyone who feel the need can implement it.

Implement a format independent data structure storing our models in memory during serialization as the middle form

In other words, we want nested key-value stores as intermediate representation. We don't need full JSON for this purpose. Let me try to come up with a simpler alternative by tomorrow.
The idea is to 1) have all components generate nested key-value stores and 2) have the serializer convert it into the end format, such as JSON. This design ensures that we can easily switch the end format later (JSON -> MSGPACK). For 2), we can use a 3rd-party library.

@hcho3 Nice.

@trivialfis BTW, good job with RTTI. I find it educational and edifying. This will come in handy for the nested key-value store I'm designing.

additional burden of type checking and error handling

@KOLANICH To be this is a feature, not a bug. Right now, the parser will happily read whatever the binary stream will provide. We do have some sanity checks (num_node should not be negative etc) but there are many holes. With the new proposal

generic-purpose schemaless serialization, but our data is schemeful, and it depends on native compiled code

But we want to be able to add new fields in the future without breaking backward compatibility. I am choosing JSON (or its binary encoding), because I don't want to deal with the hassle of custom-designing binary format.

@hcho3 Nice and thanks, if you were to carry out the implementation, I will try to see if it's possible to merge some parts of #3930 into the whole restructuring, it's already a working parser/dumper with a full blown key-value structure.  Please keep me posted. :)
@KOLANICH It all comes down to less fuss in the future.  Personally I want to spend more time on algorithms instead of these structuring bug fixing backward compatibility drama.  So I will prefer any idea that brings less headache for future.

With the new proposal, we're forced to handle errors.

But the set of errors would be much wider. Now the errors you have to process are range checking, but with a generic-purpose format you will have to check for types, names (assumming that the format is designed the way to put burden of range checking on serialization lib), that types match names and their order (for a binary format this comes for free, you just parse what you expect).
For me range-checking looks like an easier task than that.

ut with a generic-purpose format you will have to check for types, names (assumming that the format is designed the way to put burden of range checking on serialization lib), that types match names and their order (for a binary format this comes for free, you just parse what you expect).

That's the good thing of having a algorithmic structure, please see #3930 , all the checks are seamlessly built into the structure.  Anything wrong will be caught.  For example, if you have the wrong type, you won't be able to convert it into actual value since the type information is encoded into the structure by RTTI implementation.

But the set of errors you will have to check for would be much wider.

Not really. Each class will look for a list of names (raise error if a name is not found), and then check if the found items are right types. And the order of fields doesn't matter, as JSON is un-ordered.

And the order of fields doesn't matter, as JSON is un-ordered.

It's true, if we parse the format entirely first, and then use it as a key-value storage, but it has some overhead related to search. There is another approach, when parsing is done on the fly and our function is called on each record, then the arguments would likely be processed in the order they are enumerated in the file. The argument about ordering has been accepted.

@KOLANICH

but it has some overhead related to search
Most implementation of std::map is red black tree, searching is performed in O(logn).  In XGBoost each nested level should contain less than 10 entries, with this known bounded n <= 10, it's actually O(1).  The overhead is a non-issue.

when parsing is done on the fly and our function is called on each record

That will be a whole rewrite of XGBoost.  Dealing with large data blob, the better approach is to utilize B-Tree like data format, for example hdf5.  We don't need to concern about it ourselves.

@trivialfis And we can use std::unordered_map for greater efficiency: http://supercomputingblog.com/windows/ordered-map-vs-unordered-map-a-performance-study/

@hcho3 Great.  I can try to drop the Json::Dump, Json::Load and Json::Null tomorrow.  See if it fits.

Given that we already have a binary format. I think it is fine to just go ahead and support a json version. The two version are likely going to be sufficient

For storing trees, my recommendation would be not storing them as nested data structure, instead store them as adjacency list just like the nnvm graph format. It should not hard to convert back and forth

@tqchen A prototype is available at #3930.

store them as adjacency list

I'd like to hear your reasoning about using adjacency list instead of nested dictionaries.

@tqchen Can you elaborate a little bit on using graph instead of tree?

The main reason for using adj-list instead of nesting tree is the ease for parsing and edit, because as the tree went deeper(say 20 depth), it is really visually see through the tree and do editing on them. Many of the visualization libraries also depend on the adj-list structure.
The general idea of adj list is that we mark nodes as ids, and record child id of each node. So we will have things like follows(index is not really necessary):
[
  {"index": 0, "children" : [1, 2]},
  {"index": 1, "children" : [4, 5]},
]

This kind of structure is easy to edit, and there is no problem of nested parsing which can create trouble in deep nests.

As you may have noticed the current in-memory data structure itself is already adj-list structure(with its cleft, cright field as integer), so it is actually easier to adopt this structure in json as well

since the binary format is already compact, json format is mainly aimed at readability, so maybe we do not have to this specialization. Notably, having a clear field allows parsing from another language easy and readable(e.g. js). If we want to have a compact blob with json, just zip it or use binary format.

@tqchen In current prototype, the nodes from decision trees are stored in array, which means it's flat.
The main reason for introducing JSON format is make saving parameters easier.  The current binary form disallow changes in storing parameters.  And accroding to @hcho3 , endien is also an issue in binary format.

The endian issue should be solved already if we store vector of floats, see https://github.com/dmlc/dmlc-core/pull/406
I totally support using json format, though I guess we might not need third party json libaries, dmlc/json.h might work just fine. See https://github.com/dmlc/tvm/blob/master/src/lang/reflection.cc#L398

The main reason for introducing JSON format

IMHO is compatibility: JSON libraries are present for almost every lang, so we get an almost free (in terms of programmer's effort) parser and serializer, but Kaitai is currently limited to some of the most popular languages and doesn't support serialization currently at all.

@KOLANICH The named keys are essential to allow for future addition of parameters. For me, this is the by and large the most important motivation for using JSON for saving models. Compatness can be achieved by using binary encoding of JSON (to be added later).
@tqchen I'll look into using DMLC JSON parser.

Minimum dependency is indeed important and I want to emphasize it. Because nothing is free and we need to make sure the project can be easily ported into various platforms. Most of json libraries assume schema-less model, which adds overhead. In our case, we do have a schema in the model, in which case dmlc's json parser is sufficient to do the job

Given that format is something that will affect the usage quite a lot, maybe let us open an RFC on the json format proposal? We need to properly document it anyway @trivialfis @hcho3 thanks for taking lead in this

Sure, I’ll draft a RFC in next few days. I think I have a good idea about how to achieve the desired goals without introducing 3rd party dependency.
I will close this issue once the RFC is up.

Closing this now. The RFC document is available at #3980.


Provide some mechanism to reread an image from disk

Description:

Currently, the only way to update an image is to reload the project. If the user has a project file open, and is using a graphics editor to change the image, it would be helpful if there was a way to indicate that the image should be reloaded from disk.

I'm adding this to the 1.1 milestone because it's going to make previews confusing if the Mockup panel is showing an old image and a preview window is showing the current image. I still don't know where to add the refresh image command, but we really need to come up with something...

Triaging this to a 1.x release -- needs to be fixed, but not enough to hold up the 1.1 release.


ptch: add x-upsert header to upsert duplicate object

What kind of change does this PR introduce?
feature
What is the current behavior?
Closes #21
Currently insert throws a duplicate key error when trying to insert an key that already exists.
What is the new behavior?
Adds a x-upsert header to the insert object api, which upserts the object when the value of the header is true.
Screen recording

Hey Ankit, this looks good!
There seems to be a type error and can you add tests for the upsert mode too?

There seems to be a type error and can you add tests for the upsert mode too?

I think upgrading the postgrest-js should fix it. Adding tests for the upsert mode.

I think upgrading the postgrest-js should fix it.

Ah cool, lets upgrade postgrest-js also in this PR then.

Ah cool, lets upgrade postgrest-js also in this PR then.

Should I upgrade it to the latest version, from the repo I see v0.32.0?

Yup, that version should be fine. I don't think there were any breaking changes.

The tests are failing for some reason. Not related to the test suites though.

I ran the tests locally and they seem to be fine @ankitjena. I will debug why the Github actions are failing separately. Thanks for your contribution ❤

Also @inian Should I create a issue in storage-js repo to support this, for next steps

Do you want to help with this too Ankit? https://github.com/supabase/storage-js/issues/7#issuecomment-864812487

Do you want to help with this too Ankit? supabase/storage-js#7 (comment)

Sure do


Allow setting runtimeClass for devworkspace pods

Description

A new field in the DWOC to set runtime class for all devworkspace pods:
config:
  workspace:
    runtimeClassName: 'myruntimeclass'

If this is set in the DWOC, devworkspaces that use the DWOC should have their pod use the myruntimeclass runtime class
Additional context

Related issue: https://github.com/eclipse-che/che/issues/23032

Fixed by https://github.com/devfile/devworkspace-operator/pull/1303


Model choices from field queryset

Followup of #305 against master.

After another proof reading I'm really suprised it works. But that did totally open my eyes, we can hack a registered autocomplete from form fields after all, it doesn't look very safe, what happens if an autocomplete is used in two different form fields ?

self.autocomplete.model_field = self

What would be pretty neat for v3 though, would be to get completely rid of Autocomplete classes and rely on form fields instead. But that means finding a good way to get the form field back in the AutocompleteView ...


Python 3.6 "no module named settings"

Installed with pip. Raises ModuleNotFound on import.

Thank you @micaiahparker.


TRTL: configuration and logging

This PR implements a robust trtl configuration and configures trtl logging for service startup. It also generalizes some of the logging utilities and adds tests for them. Comments inline with the code.

Codecov Report

Merging #206 (c84557d) into main (6b4f707) will increase coverage by 0.66%.
The diff coverage is 72.72%.

:exclamation: Current head c84557d differs from pull request most recent head b65c3a0. Consider uploading reports for the commit b65c3a0 to get more accurate results

@@            Coverage Diff             @@
##             main     #206      +/-   ##
==========================================
+ Coverage   28.12%   28.79%   +0.66%
==========================================
  Files          45       47       +2
  Lines        5333     5345      +12
==========================================
+ Hits         1500     1539      +39
+ Misses       3575     3546      -29
- Partials      258      260       +2

Impacted Files
Coverage Δ

pkg/gds/config/config.go
78.26% <ø> (+11.59%)
:arrow_up:

pkg/gds/service.go
9.37% <0.00%> (-2.75%)
:arrow_down:

pkg/trtl/replica.go
10.52% <0.00%> (ø)

pkg/trtl/config/config.go
63.33% <44.44%> (+63.33%)
:arrow_up:

pkg/trtl/trtl.go
57.14% <61.53%> (+3.95%)
:arrow_up:

pkg/utils/logger/level.go
100.00% <100.00%> (ø)

pkg/utils/logger/logger.go
100.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


L3ToSBGNPDConverter.java with predefined layout

@ozgunbabur
Hello Ozgun,
I'm working with the L3ToSBGNPDConverter.java trying to find a way to use pre-determined points to position the layouts as an alternative to the Chilay layout that is currently being applied in the createSBGN() method. I would like to ask you a few questions on this and how you might go about doing it.
I would really appreciate your opinion and if you have some time to chat my email is<EMAIL_ADDRESS>Thanks for the consideration,
Peter

Great, we've talked already here in UofT. Let's switch to group emails for further discussing this matter.
I am closing this issue, for it's not a technical issue, idea or bug.


Add The BBC as a UK publisher

This adds The BBC as a UK news publisher.
I did find an issue for this, it was marked completed but seems the publisher was never added: https://github.com/flairNLP/fundus/issues/441
Do let me know if I have missed anything. I'm looking forward to hearing any feedback you might have or ideas for improvement.

@olaughter Thanks a lot for adding the BBC to Fundus!


Implement usize type, using u32 for miden

Description
This PR adds a usize type that is a u64 for the Fuel VM, a u32 for the Miden VM, and panics for the EVM (😄 -- sorry. Not sure if I can just make it 256 bits without rewiring some other parts of the compiler to use a bigint, and I felt that was out of the scope of what I was doing).
I don't see an issue for a usize type but it was mentioned to me as needing to be done.
Checklist

[ ] I have linked to any relevant issues.
[x] I have commented my code, particularly in hard-to-understand areas.
[ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book).
[x] I have added tests that prove my fix is effective or that my feature works.
[ ] I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
[ ] I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
[ ] I have requested a review from the relevant team or maintainers.

I'm still not convinced we need a usize type in Sway.  Can you give some examples of when a Sway developer would need to use it, or which libraries/APIs would require it?  We already have a u32 type, as well as the u64.

Yep, I understand how usize works traditionally, but I was a C++ dev for a long time and I reckon a variable sized type is an anti-feature.  I really want to make sure it's necessary before we make it a built-in type.
On the one hand, if I'm writing platform-independent code, for various blockchains, I should be either aware of each target and use the right types (e.g., u32 when it is appropriate) or I'm unaware and expect code to work on any target then I should use the smallest type that will fit the data, like u32 or u16 for small numbers.
Or perhaps the next step, after introducing usize do we need to replace all of the uses of u64 which are currently in the standard libraries, within reason?  If this was the case I doubt we should call it usize as that's mostly an anachronism from C, it should be just uint or native or something.
And there are other options.  Sway currently defaults to u64 for unknown Numeric constants, but it might be feasible for this to be u32 for Miden.  Also, there are IR passes which can analyse the use of integers and demote types automatically.  So if analysis can determine that a u64 value never actually uses more than 32 bits then a u32 can be used instead.  Considering most blockchains have quite limited VMs, the arithmetic need for a whole 64-bit number is practically non-existent.  Sway chose u64 by default originally because the architectures running the Fuel VM will all be 64-bit and so it might as well also have 64bit values, not because 64 bits is necessary for arithmetic.
So pinging @mohammadfawaz and @jjcnn for your thoughts?

On the one hand, if I'm writing platform-independent code, for various blockchains, I should be either aware of each target and use the right types (e.g., u32 when it is appropriate) or I'm unaware and expect code to work on any target then I should use the smallest type that will fit the data, like u32 or u16 for small numbers.

In Sway's case, the platforms are wildly different. The EVM has 256 bit native numbers, and Miden has 32. This would mean that generic code would be, for no reasons other than organizationally, limited to 1/8th its capacity. In smart contract programming, I believe that notion is too low-level for the programmer to have to consider.

Or perhaps the next step, after introducing usize do we need to replace all of the uses of u64 which are currently in the standard libraries, within reason? If this was the case I doubt we should call it usize as that's mostly an anachronism from C, it should be just uint or native or something.

That would be the next step. I didn't mean to take a stance on naming, I was just following Rust. But after this type is introduced, it would make sense to use it throughout the existing standard library.

And there are other options. Sway currently defaults to u64 for unknown Numeric constants, but it might be feasible for this to be u32 for Miden. Also, there are IR passes which can analyse the use of integers and demote types automatically. So if analysis can determine that a u64 value never actually uses more than 32 bits then a u32 can be used instead. Considering most blockchains have quite limited VMs, the arithmetic need for a whole 64-bit number is practically non-existent. Sway chose u64 by default originally because the architectures running the Fuel VM will all be 64-bit and so it might as well also have 64bit values, not because 64 bits is necessary for arithmetic.

Would adding a front end type annotation for Numeric and using that instead be sufficient here? It accomplishes the same goal. To be frank, it is almost the same as this usize type, but with the distinction happening in the inference system instead of prior to that.

Sway currently defaults to u64 for unknown Numeric constants, but it might be feasible for this to be u32 for Miden.

This is something we should certainly do. For example, when writing let x = 5;, x should be a u32 when targeting MidenVM.
It seems to me that the debate here is whether we want to allow target-independent code or not, particularly interfaces or functions that take or return integers such as fn foo(a: usize) -> usize. @otrho do you think usize an anti-pattern in Rust as well?
@p0ry-g0n one thing to pay attention to is type unification for integers here. Sway has implicit casting of integer type (though that may change soon) and we may need to take care of usize in type unification by emitting the appropriate warnings. For example, upcasting usize to u64 should cause a warning when targeting MidenVM, but not for the FuelVM.

do you think usize an anti-pattern in Rust as well?

Yeah, it's supposed to represent the size of a pointer.  The only times I ever come across usize in Rust is as indices into slices or arrays and half the time I'm casting them from other integers.  If that's when we'd use them in Sway then it's fairly pointless as there aren't blockchains with more than 4G of linear memory, is there?  They could always just be cast to a native integer by the backend.
int and long int are different sizes in C depending on both the architecture and operating system and all it does it confuse things.  It makes it harder to write platform independent code.  That's why Rust has the bit size of the integers in the types themselves, i16, i32, etc., there's no ambiguity.  I really do wonder how far we'd get by defaulting to u32 for Numeric on Miden and/or fiddling with their use in IR and the backend.  I think the IR could demote them even to u63 99% of the time.

I've had a busy weekend, so I only started thinking about this last night. I might very well change my opinion later on, so suitable caveats apply. I should also stress that I speak from the longer-term perspective for MidenVM, whereas @p0ry-g0n is speaking from a shorter-term perspective due to the specific tasks that have been assigned to them.
First off: In designing a programming language I believe the programmer should not have to worry about anything other than business logic. In the ideal world this means there is no u32 or u64 - there is just uint, and the compiler makes sure that that behaves like an unsigned integer.
We do not live in an ideal world and we're not getting rid of u32 and u64, so the question boils down to "Given that the programmer does need to worry about the size of integer representations, what allows the programmer to think as little as possible about the underlying architecture?" I would argue that the answer is u32 and u64, because that specifically tells the user that this is the size, regardless of architecture.
Second: Is there a performance hit on FuelVM from using u32 over u64? And is there likely to ever be a performance hit on any target architecture?
Say that usize is added, and say that it translates to different sizes on different architectures, specifically u32 for MidenVM and u64 for FuelVM. A programmer who uses usize must be in a situation where an overflow won't happen in u32, because if it did then the program would behave differently on FuelVM and MidenVM (for no good business-logic reason that I can see). So why does the programmer not just use u32 instead of usize? That would ensure the same behavior across all platforms (including aborting due to 32-bit overflows on 64-bit architectures, should the programmer have made a mistake), at no performance cost.
There is definitely a case to be made for usize in C-style languages where you may want to do your own memory management, but I would question the sense in having those kinds of features in a smart contract language... :-)
Third: From a MidenVM point of view it probably won't make much of a difference what you end up deciding. My main worry is the performance hit we will get from u64 arithmetic, and the (smaller, but still worrying) performance hit we will get from overflow checks. We will almost certainly implement some sort of static analysis to determine which operations can be changed into field operations and which overflow checks can be eliminated, and I would be surprised if the difference in usize between architectures became an issue.
As long as usize becomes either u32 or field integers when targeting MidenVM, then I don't think we'll notice.

OK, I think I agree with all of the above @jjcnn. :slightly_smiling_face: When targeting the Fuel VM we promote all integers to a native u64 anyway (even u8, which was easier initially, but we'll change sometime soon).  I feel like most of the time the Miden backend could do similarly, except to more efficient types for that architecture.  The main problem is the assumption in the existing Sway standard library that u64 is cheap and fast.
So for this PR I feel like it should wait until we definitely have a genuine use-case, rather than adding it now assuming it will be required in the future.  Using library types or the appropriately sized builtin types and codegen manipulations may deem usize as unnecessary.

My two cents: I think dismissing usize as a convenience for programmers to avoid thinking about bit-widths is mischaracterizing its purpose. The usize type expresses a few key properties (in my mind):

It represents the desire for an unsigned integer type of unspecified width, but at least as wide as the pointer-width of the target. This is useful for indices and such where the range corresponds to the amount of memory available to the program. As @jjcnn mentioned, if your maximum addressable memory is only 4GB, you don't need 64-bit pointers, array indices, etc.
It behaves the same way on all targets with regards to overflow/underflow, only the boundaries change.
The fact that the width is unspecified means that the representation chosen by the backend can be optimal for the target (and even context). For Miden, this choice might vary between u32 and a field integer, depending on what the context is and what information is available via static analysis. There are certainly many cases where you want to control the representation, but plenty where you don't really care, or you specifically want what is most natural for the target.

That said, if usize/isize aren't the "default" integer types for indices and otherwise unspecified integral values, then the value is diminished a bit. Still, I would think there are more than a few source languages that would want to defer the choice of integer representation to the backend, rather than needing to specify a type when they may not be in a position to make the best choice there.

Say that usize is added, and say that it translates to different sizes on different architectures, specifically u32 for MidenVM and u64 for FuelVM. A programmer who uses usize must be in a situation where an overflow won't happen in u32, because if it did then the program would behave differently on FuelVM and MidenVM (for no good business-logic reason that I can see). So why does the programmer not just use u32 instead of usize? That would ensure the same behavior across all platforms (including aborting due to 32-bit overflows on 64-bit architectures, should the programmer have made a mistake), at no performance cost.

Because on a platform with more addressable memory, you want to be able to support using those additional resources without having to write the same function N times for N-many "native" bit-widths, or use conditional compilation, or be wasteful by using 64-bit values on targets that will never use the full range. Sure, if you know that regardless of what the target supports, the code needs a specific integer representation, then you'd use that rather than usize, but there are plenty of situations where you don't know that, or you know that the values that need to be represented are guaranteed to fit in whatever the native integral range for the target is (e.g. array indices).

As long as usize becomes either u32 or field integers when targeting MidenVM, then I don't think we'll notice.

I think that is the purpose of this PR, really, provide an integral type that specifically "allows" the compiler to choose which underlying type is used at runtime based on its own heuristics. In other words, it is safe to optimize usize by choosing the most efficient representation for the VM (i.e. a field integer), but you are much less free to do so with a specific bit-width, because you must assume that a specific bit-width was chosen for a reason (particularly in the case of 64-bit integers).
In any case, I see value in having such a type, but only if it has a natural place in the language. If it is treated like it shouldn't be used, or isn't used as a default integral type, then it probably isn't worth it. I'd really use Rust here as a reference moreso than C/C++, which are much more clunky in this regard (IMO).

So, we often use a silly mantra when designing Sway features -- WWRD?  (What would Rust do?)  And as mentioned above, usize in Rust seems to me to be used either for very low level FFI/unsafe type areas or more commonly as indices for slices or arrays.
If we agree that indexing is the primary use for usize then we can add it (and update any library functions or intrinsics to use it for indexing) and make it a fixed 32bit size.  I agree that 64-bit indexing is not something that we need on blockchain today, although perhaps you never know, in 10+ years Sway may still be used where this is a thing.
But OTOH, there's no point in making a new type which is just  a u32.  So is the simple solution just to assume all indexing in Sway is 32bit, via u32s?

I'm going to close this since the PR is getting stale, but if you feel like this really belongs in Sway, I think an RFC for it would be appropriate so people can evaluate the idea on the merits.


[HUDI-3131] fix ctas error in spark3.1.1 and 3.2.0

Tips

Thank you very much for contributing to Apache Hudi.
Please review https://hudi.apache.org/contribute/how-to-contribute before opening a pull request.

What is the purpose of the pull request
(For example: This pull request adds quick-start document.)
Brief change log
(for example:)

Modify AnnotationLocation checkstyle rule in checkstyle.xml

Verify this pull request
(Please pick either of the following options)
This pull request is a trivial rework / code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end.
Added HoodieClientWriteTest to verify the change.
Manually verified the change by running a job locally.

Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

@xushiyan please help to review this.

@YannByron HoodieLeafRunnableCommand is introduced in https://github.com/apache/hudi/pull/4270 for spark 3.2
How can we make fix for 0.10.1 where we don't include spark 3.2 support? I suppose we need a separate PR for 0.10.1 branch?

@YannByron HoodieLeafRunnableCommand is introduced in #4270 for spark 3.2
How can we make fix for 0.10.1 where we don't include spark 3.2 support? I suppose we need a separate PR for 0.10.1 branch?

I can submit another pr about this, when you checkout the branch 0.10.1.


Sleuth Tracing Ids in Access Logs

Describe the problem you'd like to have solved
I am currently using Spring Cloud Sleuth for distributed tracing and noticed that there is no traceId/spanId in the access logs. I think this would be a great feature as it allows you to match your app log and access log entries, which can make troubleshooting easier.
Describe the solution you'd like
Open for discussion, i'd be down to contribute once we found the desired solution ^^

Thank you for your suggestion!
I'm sorry, I'm not fluent in Spring Cloud Sleuth.
How can I retrieve traceId /spanId?
If you implement your own custom Appender, you may be able to solve it early.

Hey @akkinoc, sorry for the delayed response, i was on vacation ^^
Spring Cloud allows you to retrieve the TraceContext from the HttpServletRequest via:
final ServletRequestAttributes requestAttributes = new ServletRequestAttributes(request);
final TraceContext traceContext = (TraceContext) requestAttributes.getAttribute("org.springframework.cloud.sleuth.TraceContext", RequestAttributes.SCOPE_REQUEST);

// get tracing ids via
traceContext.traceId();
traceContext.spanId();
traceContext.parentId();

I'm not sure how it works when using the reactive stack though.
We're currently using custom DynamicConverter implementations to resolve tracing ids the same way as i decribed above. However, that only works with synchronous appenders. I think this is because the "TraceContext" is scoped to the request and asynchronous appenders can be executed after the request. Thus all request scoped beans would be already gone. I think you'd have to already resolve the tracing ids when the LogbackAccessEvent is created to fix that issue.

Thank you for the detailed information!
I created a sample project.
https://github.com/akkinoc/try-logback-access-spring-boot-starter-with-sleuth
It worked with the following patch.

Implement a web filter to store the attributes for logging by logback-access-spring-boot-starter.

@WebFilter
public class SleuthAttrsFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        // Stores Spring Cloud Sleuth attributes for logging by logback-access-spring-boot-starter
        TraceContext context = (TraceContext) request.getAttribute(TraceContext.class.getName());
        request.setAttribute(SleuthAttrsFilter.class.getName() + ".traceId", context.traceId());
        request.setAttribute(SleuthAttrsFilter.class.getName() + ".spanId", context.spanId());
        chain.doFilter(request, response);
    }

}

Register the web filter in your application.

@Bean
public FilterRegistrationBean<SleuthAttrsFilter> sleuthAttrsFilter() {
    SleuthAttrsFilter filter = new SleuthAttrsFilter();
    FilterRegistrationBean<SleuthAttrsFilter> bean = new FilterRegistrationBean<>(filter);
    bean.setDispatcherTypes(DispatcherType.FORWARD, DispatcherType.INCLUDE,
            DispatcherType.REQUEST, DispatcherType.ASYNC, DispatcherType.ERROR);
    return bean;
}

Refer to the attributes stored from "logback-access.xml".

<configuration>
    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%h %l %u [%t] "%r" %s %b [%reqAttribute{example.SleuthAttrsFilter.traceId}, %reqAttribute{example.SleuthAttrsFilter.spanId}]</pattern>
        </encoder>
    </appender>
    <appender-ref ref="console"/>
</configuration>

Please try this patch :)

Hello @akkinoc, thank you very much! I'll try the code you suggested, but I'm very sure this will work without any issues. Is there any chance that this functionality will be integrated directly in the starter or is it too big of an edge case?

Thank you for your reply.
I would like to consider supporting this feature in future versions!

I've updated the issue title as Spring Cloud Sleuth is no longer maintained and the tracing support has moved to micrometer tracing.
This is an updated version of the custom filter above:
import java.io.IOException;

import org.springframework.lang.Nullable;
import org.springframework.web.filter.OncePerRequestFilter;

import io.micrometer.tracing.Span;
import io.micrometer.tracing.TraceContext;
import io.micrometer.tracing.Tracer;
import jakarta.servlet.FilterChain;
import jakarta.servlet.ServletException;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import lombok.RequiredArgsConstructor;

@RequiredArgsConstructor
public class TracingAttributesFilter extends OncePerRequestFilter {

    @Nullable
    private final Tracer tracer;

    @Override
    protected void doFilterInternal(final HttpServletRequest request, final HttpServletResponse response, final FilterChain chain)
            throws ServletException, IOException {

        if (tracer != null) {
            final Span span = tracer.currentSpan();
            if (span != null) {
                final TraceContext traceContext = span.context();
                if (traceContext != null) {
                    request.setAttribute(TracingAttributesFilter.class.getName() + "traceId", traceContext.traceId());
                    request.setAttribute(TracingAttributesFilter.class.getName() + "spanId", traceContext.spanId());
                    request.setAttribute(TracingAttributesFilter.class.getName() + "parentId", traceContext.parentId());
                }
            }
        }

        chain.doFilter(request, response);
    }
}


Feat/oauth mvp test

@wshino can we fix the merge conflict here so we can merge

@wshino can we fix the merge conflict here so we can merge

@Divide-By-0 Sorry for the late reply. I fixed conflicts and failed tests.


Try to enable SharedArrayBuffers

Currently, Papyros performs one extra action when using service-workers, preventing this library from fully meeting the use case. If requests go to a certain domain (i.e. the main domain of the application), we add headers to try to enable SharedArrayBuffers anyway by adding the required headers. This allows running SharedArrayBuffers on servers that cannot be modified, such as GitHub pages. Do you think this would be useful to add to this library, by adding extra options to the ServiceWorker-channel?
Currently, this is implemented as follows here

The pain point of the service worker is getting it working in the first place. But if it's running and successfully intercepting requests (i.e. is able to add those headers) then the service worker channel should be working fine. In fact I think a working service worker channel may even be better than an atomics channel. So I don't think this would be a useful feature for this library.
So at the moment, I think the service worker adding headers is redundant in Papyros. But I don't think it should be removed because at some point I'd like to add (via a library) interrupting via SharedArrayBuffer.

The service worker channel would be working fine, but isn't it also slower/less efficient than using SharedArrayBuffers instead? Why do you think the service worker channel works better? It's currently not redundant in Papyros, as current deployment happens on GitHub pages where I like being able to try out the SharedArrayBuffers as well.
What do you mean with interrupting via SharedArrayBuffer? Are you going to combine service worker requests with a SharedArrayBuffer to interrupt those requests, or what exactly is the plan?


Completeness of the affects field.

field to capture if the affects field is complete wrt products/versions.

Likely three values:

list of affected vendors/products/versions is incomplete
list is complete with respect to currently supported products at the time of CVE publication.
list is complete and includes possibly end of life and future versions.


Using Hugo Pipes to build sass

I am trying to setup a new site on Netlify to build with SASS. I've used this page for a reference: https://gohugo.io/hugo-pipes/scss-sass/, however this doesn't seem to work. Is the SASS pipeline actually working or is this documentation wrong?

I am trying to setup a new site on Netlify to build with SASS. I've used this page for a reference: https://gohugo.io/hugo-pipes/scss-sass/, however this doesn't seem to work. Is the SASS pipeline actually working or is this documentation wrong?

This is what I added in the header:
{{ $styles := resources.Get “sass/test.sass” | toCSS }}
<link rel=”stylesheet” href=”{{ $styles.Permalink }}” media=”screen”>

and added an assets folder at the root, with sass/test.sass file

Please use https://discourse.gohugo.io/ for questions/troubleshooting. Also see  Hugo Documentation.


Invalid XPath error when adding XSLT mediator

Description:
When adding an XSLT mediator to a sequence. If we provide only the XSLT Schema key only without specifying a Source XPath as below(Note: expression mark is clicked and it can’t be un clicked).

It will add and xml element as mentioned below.
<xslt key="conf:FIX_XSLT.xslt" source="">
</xslt>

If we try to run the project. then it will give the below error.
ERROR {XSLTMediatorFactory} - Invalid XPath specified for the source attribute
If you remove the source="" attribute from the XSLT mediator configuration, it runs fine.
Suggested Labels:

Suggested Assignees:

Affected Product Version:
v0.9.24071803
OS, DB, other environment details and versions:
Steps to reproduce:
Related Issues:

The latest pre-release v1.0.1 has resolved the issue. Please reopen if the problem persists.