[5.7] Enable Pusher logging

Enable logging in Pusher >= 3.0.0 (PSR compatible). It respects user debug setting.

Why do we need to check for Pusher >= 3.0.0? We already recommend that as the minimum version in the documentation?

Changed it to just use a log variable from the Pusher driver configuration in your config/broadcasting.php file:


kubectl shows localized messages even though LC_MESSAGES=C

Is this a BUG REPORT or FEATURE REQUEST? (choose one): bug report
Kubernetes version (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.1", GitCommit:"d4ab47518836c750f9949b9e0d387f20fb92260b", GitTreeState:"clean", BuildDate:"2018-04-12T14:26:04Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Environment:

Cloud provider or hardware configuration: N/A
OS (e.g. from /etc/os-release): Arch Linux
Kernel (e.g. uname -a): Linux hostname 4.16.7-1-ARCH #1 SMP PREEMPT Wed May 2 21:12:36 UTC 2018 x86_64 GNU/Linux
Install tools: curl

kubectl --help prints some messages localized to German even though I explicitly forbade that in my locale settings.
$ env | grep $'LC\nLANG'
LANG=de_DE.UTF-8
LANGUAGE=
LC_MESSAGES=C
$ kubectl set --help
Configure application resources

These commands help you make changes to existing application resources.

Available Commands:
  env            Update environment variables on a pod template
  image          Aktualisiere das Image einer Pod-Template
  resources      Aktualisiere Resourcen requests/limits auf Objekten mit Pod-Templates
  selector       Setze den Selektor auf einer Resource
  serviceaccount Update ServiceAccount of a resource
  subject        Update User, Group or ServiceAccount in a RoleBinding/ClusterRoleBinding

Usage:
  kubectl set SUBCOMMAND [options]

Use "kubectl <command> --help" for more information about a given command.
Use "kubectl options" for a list of global command-line options (applies to all commands).

:clap:
/remove-lifecycle stale

/sig cli
/area kubectl
/kind bug
/priority P3

It looks like kubectl currently only supports the LANG  env var, it makes perfect sense to me to allow to set LC_MESSAGES to override just messages [1]. However, I'm not sure if we want to support LC_ALL and LANGUAGE env vars as well to more closely follow this priority order.
I've decided to implement only LC_MESSAGES for now in https://github.com/kubernetes/kubernetes/pull/69500
[1] BTW, kubectl doesn't support other categories of locales, at the moment.


frontend/conversions: show BTC as active currency in sats mode

In BTC accounts with sats mode enabled, displaying two amounts in sats is redundant. This commit addresses this by ensuring that when sats mode is enabled for BTC accounts, the active currency is displayed as BTC. BTC is now displayed in this setting as the active currency on the send page and during the transaction review process.

superseded by https://github.com/BitBoxSwiss/bitbox-wallet-app/pull/2682, closing.


Parsing performance...

Hey @josdejong :wave:
figured you might be interested: https://github.com/leeoniya/uDSV/tree/main/bench#nested-objects
hopefully i didnt leave any big stones unturned :sweat_smile:
cheers!

O wow, uDSV is indeed much faster than csv42, I did a small test to try it out myself. That's impressive. That makes me very curious of course how you achieved that. It's a lot of fun to try to optimize this, isn't it 😁 ?
Reading the readme of uDSV, it explains "this project is to handle the 99.5% use-case", makes me immediately wonder what this non supported 0.5% is, in order to understand whether I can use the library for my use-cases or not. Maybe you can add some explanation about that?
I had a look at the source code to understand why uDSV is fast, and I think I can see two main reasons:

uDSV parses the first 10 rows (by default) to identify the type of each row, and then can optimize parsing the values straight into the identified types. So the assumption here is that the CSV data is homogeneous. That is indeed often the case in practice so it's smart to utilize that knowledge. I personally would not turn that behavior on by default but let the user explicitly configure this to prevent surprises. Maybe it is an idea to change the maxRows option of inferSchema into an option isHomogeneous so users may better understand what the option is about.

uDSV uses new Function(...) to generate an optimized parser after collecting information about the rows and their types. I think that that is your secret sauce, making the library so fast, right?
I'm not sure if you're aware, but using new Function(...) or eval(...) can introduce security issues. As far as I can see you don't guard against that at the moment (I haven't examined the code thoroughly though, maybe you have taken care of it). Suppose that uDSV runs in a nodejs server that allows users to upload a CSV. An attacker can prepare a smart column name containing bad JavaScript (code injection), and get this code executed on the nodejs server. That way the attacker can execute arbitrary commands in nodejs, giving full access to the server. I've learned this hard way 😅.
I think in the case of uDSV it is possible to guard against malicious code injection by validating and limiting or escaping the column names. Still, it is something you need to be really careful with, with every change you do. And even when the code is secure, in some companies and JavaScript environments there are Content Security Policies (CSP) in place that forbid usage of new Function() and eval().
Nowadays my rule of thumb is to simply not use new Function. In most cases the improved performance is not worth the security risks, the more complicated code, and the usage limitations due to security policies (and the time and frustration of consumers of my library debugging CSP issues). It is up to you of course, and the performance improvement is significant so it is interesting. It maybe helpful to add some information in the Readme about the usage of new Function, both to prevent surprises and to let the users know you've aware of the risks and have taken measures.

Sorry for the long reply. I really love to see some healthy competition here, and since it's open source we can learn from each other. I unfortunately can't use uDSV for my use-cases because of the two reasons above, but if a better library comes along I'm always open to use that instead 😄. At least you got me thinking about whether I can implement a new option isHomogeneous, utilizing that knowledge to further optimize parsing 🤔 .

what this non supported 0.5% is

one could argue that the nested objects is part of it 😅. the non supported case is pretty much just handling of malformed CSVs. sadly i think this is probably more than 0.5% in real life.

Maybe it is an idea to change the maxRows option of inferSchema into an option isHomogeneous so users may better understand what the option is about.

maybe i'll rename it to inferLimit or something. in my mind a CSV is homogenous by definition, so maybe non-homogenous CSVs are part of that unsupported 0.5%.
indeed, strict CSP headers would prevent the use of parser.typed* methods, though the core parsing pass should still work to produce tuples. (d3-dsv has the same notice, btw). i think adding a regexp or callback option to the schema should make it pretty easy to sanitize the keys (e.g. wrap the keys in backticks and disallow backticks via regexp in the column headers). imo the performance benefit here too juicy to not use dynamically compiled fns :)
thanks for the thoughtful / through reply! i'll add some configurable guards to the Function generator and add a note to the readme.

btw, i noticed that PapaParse + flat only flattens to one level, so is not actually comparing apples to apples. maybe im using it wrong? didnt spend too much time on it when learning the apis of 25 parsers 😮💨
benchmarks are hard :(

i think this closes the only two injection holes: https://github.com/leeoniya/uDSV/commit/3e9964252ab6350fe86fc465a2c3c7f1794f0373

btw, i noticed that PapaParse + flat only flattens to one level, so is not actually comparing apples to apples. maybe im using it wrong?

If that is the case I should correct the benchmarks.
I did a test and flatten actually does do deep nesting:
import flat from 'flat'
import Papa from 'papaparse'
import { inspect } from 'util'

const users = [{ test: 'abc', level1: { level2: { level3: { level4: 'ok' } } } }]
console.log('# users')
console.log(inspect(users, { depth: null }))
// [
//   {
//     test: 'abc',
//     level1: { level2: { level3: { level4: 'ok' } } }
//   }
// ]

const flatUsers = users.map(flat.flatten)
console.log('# flat users')
console.log(flatUsers)
// [ { test: 'abc', 'level1.level2.level3.level4': 'ok' } ]

const csv = Papa.unparse(flatUsers)
console.log('# csv')
console.log(csv)
// test,level1.level2.level3.level4
// abc,ok

const parsedFlatUsers = Papa.parse(csv, { header: true }).data
console.log('# parsed flat users')
console.log(parsedFlatUsers)
// [ { test: 'abc', 'level1.level2.level3.level4': 'ok' } ]

const parsedDeepUsers = parsedFlatUsers.map(flat.unflatten)
console.log('# parsed deep users')
console.log(inspect(parsedDeepUsers, { depth: null }))
// [
//   {
//     test: 'abc',
//     level1: { level2: { level3: { level4: 'ok' } } }
//   }
// ]

Note that to make sure the libraries actually produce the same outputs, I wrote some validation logic that runs before the benchmark: https://github.com/josdejong/csv42/blob/main/benchmark/validate.ts
Now, comparing csv42 with papa+flat still feels a bit like comparing different things to me because papaparse doesn't support nested objects by itself and needs the additional step via flat. My thinking was from an end user point of view, to get CSV data parsed into nested objects you need these two steps. Such a solution is also the answer for these kind of questions on StackOverflow. Most important to me is that both solutions have the same output (assuming the case that a nested object is the desired output for a user).

i think this closes the only three injection holes: leeoniya/uDSV@4e7472a

Sounds good! I'll have a look

i think this closes the only three injection holes: leeoniya/uDSV@4e7472a

It looks good, I expect that using JSON.stringify should guard against code injection. I'm not an expert though.


[Feature Request] Enable node attributes to be edited

As a way to test and tweak models, it would be interesting to add the ability to edit nodes and then send those changes back to the server for recompilation.

Hmm... I'm not sure we want to scope creep into editing but let's see. @yijie-yang, any thoughts?

Thank you for your suggestion, @madcampos! The idea of editing node attributes in Model Explorer is interesting. Could you share more about your workflow for testing and tweaking models? For instance, we typically make changes directly to the model and use Model Explorer to visualize and verify those changes. What specific benefits do you envision from editing within the visualization tool instead of directly in the model? Your insights would be valuable in understanding how we can enhance this feature.

The idea is to provide a feedback loop to users, similar to a REPL. Where it shows on Model Explorer places where changes can be made, and this would provide a UI for changing those values.
What can be changed is informed by the model, it would have metadata about what fiends can be changed and constraints to those fields like a list of candidate values or min and max values.
When edits are made, then the user would send a command back to the server to regenerate the model with the applied changes.
Adding @vprajapati-tt to the conversation as he can provide more insight and details.

Thanks for your insights! I think the idea of allowing users to edit the model via the UI and then recompiling it based on those changes is great.
To better understand your needs, could you clarify a couple of points?

What specific types of metadata do you need to edit? For example, other than node attributes, there are input/output shapes or data types, and graph level modification like adding/deleting nodes, or splitting the graph?
Which framework are you currently using for your models (e.g., LiteRT, TensorFlow, PyTorch, JAX)? This will help us prioritize our focus.

Thanks!

Thanks for looping me in Marco, let me try to take on these questions.

The editable properties we foresee would primarily involve node attributes (by extension: the shape attribute could also be in question (?)). Re-ordering the nodes, adding/deleting, and general graph level manipulation is not in the scope of the changes we seek to implement. That being said, I would refer to my point below on the "responsibility" that model-explorer could take in implementing these changes.

For our current extension in development, we are using our own MLIR dialect and manipulating that module to apply our modifications to node attributes. The goal for these changes is to make them extensible enough to allow for other sorts of extensions to leverage it to their advantage. For this purpose, I'm thinking it would probably involve a system where the changes and their handling are the responsibility of an extension which wants to allow for this functionality. This adapter must have commands that would provide the editable fields in a graph, and apply these modifications (when entered) to return a new graph back to model-explorer. Our method of changing the model itself will definitely not be universal, and many different extensions will have different approaches to this problem.

The proposed changes would ideally only implement the frontend changes and infrastructure in the adapter framework to allow for this functionality (should the extension developer desire). I think if model-explorer is left as a tool that is purely a "renderer", a graph-level manipulation can occur in the extension, and it is merely reflected in model-explorer as a new graph for the user to visualize the impact of their modification.
The goal is not to create a pile of complex logic in model-explorer to handle this functionality, but rather form a contract between the adapter & model-explorer such that this functionality is accessible to developers. As an example, this contract could involve the addition of the following commands in an adapter that seeks editing functionality:

Providing a ModelExplorerGraph that has the information on what node attributes can be manipulated, and with what values (as Marco described above)
Receiving planned changes to these NodeAttributes to return a new ModelExplorerGraph which has these changes applied to it.

I would love to hear your thoughts and input on this, and I'm happy to hear you're considering it!

Hi @vprajapati-tt , thanks for your detailed response. I'm working with @yijie-yang to explore model surgery opportunities in Model Explorer.
Instead of recording user changes on Model Explorer UI and send it through a list of commands to update the MLIR in your adaptor, how about the idea of sending the whole updated Model Explorer graph along with the original model to adapter and let your adapter reconstruct a new MLIR module from it?

Hey @chunnienc, the reason I proposed that method was in case there are adapter developers who require a more complex method of updating / changing the IR that they're working with. Reconstructing MLIR is a relatively trivial problem, but adding custom reconstruction logic for a more involved IR could be a higher barrier of entry into the tool compared to utilizing the same translation logic into a ModelExplorerGraph with an updated IR.
Of course, the tool and it's intricacies are understood best by your team. I would leave all implementation details depending on the many stakeholders involved, these are just my thoughts on ease-of-use changes for adapter developers.


Logs not shown for Cloud Function nodejs10 runtime

Environment details

OS: Cloud Function
Node.js version: 10.15.x
npm version:
@google-cloud/logging-winston version:0.11.1

Steps to reproduce

Create a custom logger using logging-winston as transport
Deploy the cloud function on nodejs10 runtime
Logs are not shown in Stackdriver Log viewer

While trying to migrate from Cloud function nodejs8 to nodejs10 runtime, I found out that logs are not shown in Stackdriver Log viewer. If I change the runtime back to nodejs8, it's working as intended.
Let me know if I should create an issue in Cloud Function's issue tracker on https://issuetracker.google.com

Related: https://github.com/googleapis/nodejs-logging-bunyan/issues/291, with the root cause in https://github.com/googleapis/nodejs-logging-bunyan/issues/291#issuecomment-484607243.
We're working with the Cloud Functions team to get this resolved /cc @steren.

@steren this is blocked on the Cloud Functions side. I don't have permissions to open an issue against Cloud Functions on https://issuetracker.google.com. Can open a bug on that side?

We have an internal tracking bug (131353611)

@steren is there a public version of the bug so that @MatthieuLemoine can follow along on progress?

This GitHub issue? I do not see the advantage of creating one more issue.

Hi there, this problem seems fixed in https://github.com/googleapis/google-auth-library-nodejs/pull/748 which is available as of google-auth-library v4.2.6, right?
I confirmed that it is working correctly in my following environment.
Google Cloud Function with nodejs10
@google-cloud/logging-winston version: 1.1.1
Thank you so much for working on this issue :)

@MatthieuLemoine some details i added here might help you work around the issue for now.
https://github.com/googleapis/nodejs-logging-bunyan/issues/291#issuecomment-526758642

@MatthieuLemoine @soldair I've gone ahead and closed this issue, because it sounds like we addressed it in a patch to google-auth-library-nodejs; please feel free to reopen if you're continuing to bump into issues.


Small error in ionQ demo

The following code in the estimating job cost
target = IonQ(workspace=workspace, name="ionq.qpu")
cost = target.estimate_cost(circuit, num_shots=500)

print(f"Estimated cost: {cost.estimated_total}")

should be
target = workspace.get_targets(workspace=workspace, name="ionq.qpu")
cost = target.estimate_cost(circuit, num_shots=500)

print(f"Estimated cost: {cost.estimated_total}")

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

ID: 73cb1ff5-4460-2c01-d55c-e24ba98bfae6
Version Independent ID: 2158cd2b-59ba-253d-4f14-27089d65bb55
Content: Submit provider-formatted quantum circuits to Azure Quantum - Azure Quantum
Content Source: articles/quickstart-microsoft-provider-format.md
Service: azure-quantum
Sub-service: qdk
GitHub Login: @guenp
Microsoft Alias: guenp

I can just change it

Hi @rryoung98
Thank you for your feedback, and sorry for the delay response. We´ll fix that.


[KOGITO-3864] - KogitoInfra got delete when refering KogitoRuntime/KogitoSupportingService delete

…gitoSupportingService delete
Jira issue : https://issues.redhat.com/browse/KOGITO-3864
Many thanks for submitting your Pull Request :heart:!
Please make sure your PR meets the following requirements:

[x] You have read the contributors' guide
[x] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[x] Pull Request contains a link to the JIRA issue
[x] Pull Request contains a description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket
[x] Your feature/bug fix has a unit test that verifies it
[x] You've tested the new feature/bug fix in an actual OpenShift cluster
[x] You've added a RELEASE_NOTES.md entry regarding this change

Seems good! The finalizers from Supporting and Runtime services seems pretty much the same thing to me, can't see reuse some of those functions?

yes..there method of addFinalizer and handleFinalization are almost similiar. I was not clear where I should put those methods so that both of controllers could call those method.

addFinalizer and handleFinalization

I had moved addFinalizer and handleFinalization to kogito_service.go file so that both finalizer can reuse it

/jenkins test

@spolti can you take a final look?
/jenkins test


[错误]

OpenIM Server Version
3.8.1
Operating System and CPU Architecture
macOS (AMD)
Deployment Method
Source Code Deployment
Bug Description and Steps to Reproduce
//openIM
implementation 'io.openim:android-sdk:3.8.1@aar'
implementation 'io.openim:core-sdk:3.5.1-alpha.7@aar'
Screenshots Link
No response

#76

How to solve this problem?

This issue has no detail about the error and no correct format. We cannot know the problem reported in the current issue. Please submit a new issue with you problem.


about function _check_value

Hi,
I checked my system's output and, there are some ambiguous issues.
Below is my system's message
[User] Are there any 4 stars available ? It should be a guesthouse type hotel. I ' m looking for a place to stay in the centre part of town .
[Syst] i have two guesthouses in the centre of town. one is cheap and the other is moderately priced. do you have a preference?
[SYS_DA] hotel-inform-price-moderately priced
[SYS_DA] hotel-inform-choice-two
[SYS_DA] hotel-inform-price-cheap
[SYS_DA] hotel-inform-area-centre of town
[SYS_DA] hotel-inform-type-guesthouses
[SYS_DA] hotel-inform-choice-other
[SYS_DA] hotel-select-none-none
[SYS_DA] is printed at the function "add_sys_da" in evaluator/multiwoz.py and this is what user simulator NLU(my case, MILU) understood.
MILU can't parse "moderately priced" into "moderate" in price case, but also parse "centre of town" into "centre".
The problem is when inform_F1 and _check_value is invoked,
https://github.com/ConvLab/ConvLab/blob/0b38aba96268068e20995ccedf62209a75922fbb/convlab/evaluator/multiwoz.py#L199
_check_value return "False", because it only allows "moderate" and "centre" (not moderately priced and centre of town).
I think they are correct. Could you allow those case?
Code suggestion is like,
elif key == "pricerange":
....for candidate in ["cheap", "expensive", "moderate", "free"]:
........if candidate in value:
............return True
....return False
The "area" case also be changed same way.
Thank you.

@jeonggwanlee  Thanks for raising the issue! The code change you suggested definitely works in your examples, but pure sub-string match has the risk of mismatching when 'value' is a more complicated string.  The existing (NLU) models are the baselines we provide for your convenience, and have their own limitations. We highly encourages users building your model and contribute to ConvLab. Hope this resolves your question. Thanks.

Thank you for replying! @jincli
I got that risk...!
I participated in the DSTC8 Track 1 actually.
In that challenge, can the designer modify the user simulator part? because there's limitation from user simulator part. So if the designer can change the user simulator part, they can accomplish better success rate.
But, To evaluate all participants model conveniently, it's normal to fix the user simulator part, isn't it?

@jeonggwanlee  Our final evaluations consist of end2end evaluation based on the existing user simulator and human evaluation. If you change your user simulator, it might affect your final end2end evaluation. Surely, if your suggestion of user simulator change is good enough, it might help increase the performance in human evaluation. Please let us know how you would like to do the change (maybe send a PR), and we will consider it in our future release.

@jincli Thank you for replying!
Until now, I have not tried to change the user simulator part. If I have some idea, I make suggestion in this github page.


Support Unittest for Linux workflow

What problem does this PR solve?
Support Unittest for Linux workflow
Issue Number:
Problem Summary:
What is changed and the side effects?
Changed:
Side effects:

Performance effects(性能影响):

Breaking backward compatibility(向后兼容性):

Check List:

Please make sure your changes are compilable(请确保你的更改可以通过编译).
When providing us with a new feature, it is best to add related tests(如果你向我们增加一个新的功能, 请添加相关测试).
Please follow Contributor Covenant Code of Conduct.(请遵循贡献者准则).

会有失败的case

这个PR还需要吗？

这个PR还需要吗？

先留着吧，gcc的ut有点问题，还没合入master @zyearn


Optimizing flows, validation and fixing bugs

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 54.484%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1847

Relevant Lines:
3390

💛  - Coveralls


How to change stripe publishable key dynamically?

I want to change stripe key dynamically.
Right now its getting configured in config.
I want to change it using StripeElements which is injected in controllers.
angular.config(function (StripeElementsProvider) {
StripeElementsProvider.setAPIKey(STRIPE_API_PUBLISHABLE_KEY)
})
How can I do that ?

You'd have to create a new instance of the the Stripe object.
You can't do that with the way this library works, because the key is passed to the Stripe constructor during application bootstrap, and the created instance is used from then on.


[FileShare]how to delete many? (File Share Batch Delete)

Tried one liner but didn't work.
Expected:
az storage share delete --account-name 'myacc' --name $(az storage share list --account-name 'myacc' --query "[?(name!='kubernetes-dynamic-pvc-keeper')].name" -o tsv)

but delete seems to only take one. so my workaround
for storage_pvc in $(az storage share list --account-name 'myacc' --query "[?(name!='kubernetes-dynamic-pvc-keeper')].name" -o tsv)
do
	az storage share delete --account-name 'myacc' --name $storage_pvc
	#echo $storage_pvc
done

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

ID: 9ae881ef-ad75-32e6-6e64-6b526a2d9a5d
Version Independent ID: 99971e2e-9ff6-f865-07f7-61efbcb16021
Content: az storage share
Content Source: src/azure-cli/azure/cli/command_modules/storage/_help.py
Service: storage
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

we will consider toadd this as a service feature

we will consider toadd this as a service feature

Hi @TiloGit, I know it has been quite a long time since you opened this issue, but it seems this is something where we need service support. To that end, if you still are looking for something like this to be part of the SDK/CLI, then please consider submitting this feedback to the Storage service team via upvoting or creating a new idea at https://aka.ms/AzStorageFeedback.
This will help the service team gauge interest and prioritize new features. If the feature becomes available in the service, it will be promptly added to the SDK.
On that, I'm going to close out this Issue in favor of submitting feedback directly to the service team.


Convert old accordions to Bootstrap

Issue #1557
This is the initial conversion of listnavs that @skateman can follow. @skateman , @martinpovolny or @dclarizio , please review.
Before:

After:

This is the initial conversion of listnavs that @skateman can follow. @skateman , @martinpovolny or @dclarizio , please review.

I've done a very quick review and it looks quite good, just some indentation issues.
@epwinchell i suggest you to use the haml-lint gem to find indentation and other issues. You can integrate it to your editor or just run it from the root directory of the repo like this:
haml-lint -i RuboCop rubocop.yml <haml file>


c2cpg: remove the global lock

Background info:
Eclipse CDT copies (physically and transitively) all of the content from included header files into the resulting Eclipse CDT AST. Before this PR, we simply took that as is and generated a CPG for all of that.
Implications:
Thus, we had to take care of duplicated content (e.g., if the same header file is included into multiple different *.c files). We did that by checking the contents filename, line, and column number. That needed to happen inside a global lock as we are iterating over all input files in parallel. To no one's surprise, this was the big performance bottleneck in c2cpg. Generating stable names also proved difficult.
Approach taken in this PR:
We now filter out all nodes with a different origin filename than the one associated to the AST we are currently traversing. That's easy because Eclipse CDT copies all the content from included header files to a top-level location (IASTTranslationUnit#getDeclarations). With that, Eclipse CDT is still able to resolve macros, types, and all the other interesting stuff that comes with header files.
Benefits of this PR:

Massive performance increase as there is no global lock anymore.
Generating stable names is much easier as we do not have to check for duplicated content (which used to shift around when iterating files in parallel).
We can now enable scanning for system header files by default. Without this PR here a simple #include<stdio.h> results in half of your systems C header files being part of the CPG. Now that stuff is only used for CDTs internal type resolving and macro resolution which is exactly what we want.

TODO:
Needs more testing on real-world applications. VLC or Firefox source code is perhaps a valuable target, especially w.r.t. performance and memory consumption.

Nice! Yeah, please test on a bunch of real world examples and see if we can in fact enable scanning of system headers by default again.

Results for CPG generation (c2cpg standalone, -Xmx48G, with system header files)

vlc: 162mb CPG, 2.802.919 nodes, 1:21 mins

Results for CPG generation (c2cpg standalone, -Xmx48G, without system header files)

vlc: 125mb CPG, 2.152.722 nodes, 0:26 mins

Without this PR (and with the same maximum heap settings) c2cpg did not even finish on my machine when running c2cpg with system header files. It ran into eternal GC collection and eventually got killed.
Nevertheless, I will switch off the inclusion of system header files by default like it was before so we do not change the default behavior to not confuse people.


Datastore counts exists queries for annotated queries

Based on a setting in the annotation. The query itself can only be a regular query that selects columns and such.

Can be done at the same time as #1031 or after it.
The reason is that without #1031 we must assume the user puts in a GQL query that returns entities instead of keys when it's actually natural for the user to use a key GQL query. Therefore it is most natural to support key queries when doing this. @meltsufin FYI

Why does it matter whether it's keys or entities? It's a collection of something that has a size that we care about. I'm probably missing some more context.

I never said it was impossible, but as I said if we don't support keys queries but we do support counts/exists queries then I think the user would be unpleasantly surprised that a keys query causes the program to crash, but if you're OK with it in the interim then I have no objections.

What do you mean by key queries vs count/exists queries? I thought Datastore only supports key queries.

I meant that if the user gives a GQL query "SELECT key FROM blahblah"  (instead of SELECT * FROM...) it will return QueryResult<Key> instead of QueryResult<Entity>, which cannot be converted to POJOs.

Why do we need to convert to POJOs? We only need the size of the query result to answer count and exists queries.

For count and exists, we should definitely skip conversion and only look at the raw result set. If our current design doesn't permit this, we should take a closer look at how to fix it.

@meltsufin I don't think we're actually saying contrary things. Take a look
at the linked PR; I think it's doing what you expect.
On Mon, Sep 24, 2018 at 9:50 AM Mike Eltsufin<EMAIL_ADDRESS>wrote:

For count and exists, we should definitely skip conversion and only look
at the raw result set. If our current design doesn't permit this, we should
take a closer look at how to fix it.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/spring-cloud/spring-cloud-gcp/issues/1031#issuecomment-423981198,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ab7p8Qwb-NdyWw6FylwXjN8rQuCVYS08ks5ueOMOgaJpZM4WuOs7
.


Fix range of color scale in 2D plots

When comparing 2D distributions of different processes, it is sometime beneficial to use the same z-axis range on both of them (makes the comparison easier). Currently, this is not possible since the z-axis is derived on a per-histogram basis and the range settings aren't accessible to the user.
It would be nice to change this, i.e. give the PlotVariables2D task an additional option to set the z-axis range. Additionally, we could also think about giving the PlotVariables2DPerProcess task an option to fix the scale automatically, e.g. check the histograms in the current task call, derive the maximum z-range and use that for all calls of PlotVariables2D for the different processes

Hi @pkausw, the zlim parameter introduced in #238 will allow you setting the z-axis as required.
However, I feel like the second request to automatically fix the scale is not really possible to implement in the current task structure, since it would require some cross-communication between different cf.PlotVariables2D tasks.
Are you satisfied with the changes from #238 or shall we keep this issue open?

Hey @mafrahm
you're right, this new feature does include the first part of the request of this feature. However, I do think that the automization between processes should be possible.
In my mind, the PlotVariables2DPerProcess task is basically a wrapper task that has all the required information available. With the changes introduces in #238 , we'd just need some logic that extracts the value ranges for the requested variables for the different processes, calculates the min/max values based on that and then set the z-axis in the individual PlotVariables2D tasks accordingly.
Maybe this is wrong though, so feel free to correct me! If it is possible, then I would leave this issue open to keep track of the development.

Has this issue been resolved, or should be add a "wontfix(fornow)" label?

Hi @pkausw, I will close this issue, since there is currently no way to implement the requested feature with our workflow.


{% feeds %} tag should use double quotes in link tag

The generated link tag uses single quotes
<link href='/ddddd/feed/' title='Posts - Bla Bla' rel='alternate' type='application/atom+xml'>

and Atom throws a warning for the generated page saying double quotes should be used. Same for the CSS and JS tags.

I've fixed this. I'll bundle this with a release that fixes https://github.com/octopress/asset-pipeline/issues/11 tonight hopefully.


Update README.md to include rescript-use-antd

I've added a new rescript to NPM that adds support for antd, which requires some trickery with less-loader. Here's the source repo - it has full integration testing.
Thanks, I'm loving rescripts!

@RcKeller awesome!!!!


Show a "View Branch in Editor" button for PRs

Description
Add a button to PRs that allow you to quickly open VS Code for the branch being reviewed on github.dev.
I find it useful when reviewing big PRs to take a look at a specific branch in the web editor, so I don't have to download the branch locally.
For any given branch in a repo, you can simply open the VS Code web editor provided by GitHub with this URL structure:
https://github.dev/{username}/{repo}/tree/{branch}

Example editor on Django: https://github.dev/django/django/tree/stable/4.1.x
Screenshot

Example URL
https://github.com/django/django/pull/15730

If we add this, it should probably be in the "Code" dropdown. The PR header is already sufficiently crowded as it is.

If we add this, it should probably be in the "Code" dropdown. The PR header is already sufficiently crowded as it is.

I think if we hide it too much nobody will use and discover it.

I think if we hide it too much nobody will use and discover it.

Avoiding UI clutter comes first imo, especially for relatively niche features such as this one.
We can help a bit with discoverability by featuring it in the corresponding release. It's also up to users to read the docs.

Its coming soon directly from GH, its called code spaces.


core: Add synchronous API for commands

Summary
I think it's better to support both sync and async for commands. Especially for commands that are just CPU-bound tasks, this will be quite useful.
Checklist

[x] cargo fmt
[x] cargo clippy
[x] cargo test
[x] updated CHANGES.md

Maybe some additional context for the recent changes: I've realized that only the input sender of the component can always be unwrapped (and therefore doesn't need to return Result). The input receiver lives in the runtime of the component so sending should never fail. However, output receiver can simply be dropped by detach and commands are not bound to the lifetime of the component except for their oneshot versions. Factories always process the output to be able to forward to the parent component which make sending outputs from factories safe.
So I've decided to make senders return Result by default. Sending inputs (or outputs from factories) is save and is unwrapped by Relm4. Everything else must handle the Result because there's no guarantee that the receiver is alive.

Makes sense. Though, unwrapping still seems like the wrong behavior to encourage, since if it fails it will crash the program. We might want to provide two variants: an output variant that just drops (or logs) the error if the send fails, and a try_output that returns a Result that lets the caller handle it specially if needed.
I'm guessing that most callers don't care if the sending fails?

It's a tricky question. I've realized that most components have the only purpose of sending output messages. In other words, it is surely a programming error if you detach them. In this case I think panicking (or some other kind of error) is the desired behavior.
Then there are component like SimpleComboBox that have both options: Either you listen to messages or you access its state directly. In this case you want to ignore sending errors.
The same could be said about commands. Sometimes you want to panic because a send error indicates that something weird is happening (for example when a component should have a static lifetime).
I've also thought about adding a method that drops the error (and emits a log message). But then I though, that the returned Result already covers all possible use cases. You can have a hard error to prevent accidental misuse of components, you can ignore the error or even print a log message.
I don't think however, that silently dropping the error by default is a good option. But maybe we can add convenience methods for this...


Interactable.StateManager.SetStateOff() not work

Describe the bug
Interactable.StateManager.SetStateOff() not work
To reproduce

Get the PressableButtonHoloLens2 prefab's componet : Interactable;
Manual set the state

Expected behavior
Change the button's state
Your setup (please complete the following information)

Unity Version [e.g. 2019.4.13f1]
MRTK Version [e.g. v2.4]

Target platform (please complete the following information)

PC

Additional context
Add any other context about the problem here.

Hey @guodan, this should be resolved in the MRTK 2.6 update that's coming up.

Hey @guodan, this should be resolved in the MRTK 2.6 update that's coming up.

We appreciate your feedback and thank you for reporting this issue.
Microsoft Mixed Reality Toolkit version 2 (MRTK2) is currently in limited support. This means that Microsoft is only fixing high priority security issues. Unfortunately, this issue does not meet the necessary priority and will be closed. If you strongly feel that this issue deserves more attention, please open a new issue and explain why it is important.
Microsoft recommends that all new HoloLens 2 Unity applications use MRTK3 instead of MRTK2.
Please note that MRTK3 was released in August 2023. It features an all new architecture for developing rich mixed reality experiences and has a minimum requirement of Unity 2021.3 LTS. For more information about MRTK3, please visithttps://www.mixedrealitytoolkit.org.
Thank you for your continued support of the Mixed Reality Toolkit!


`` build failure on x86_64-linux as of 0fc9fca9

Issue description
Build of `` failed on x86_64-linux as of 0fc9fca9c8d43edd79d33fea0dd8409d7c4580f4. This is currently breaking python39Packages.tensorflow-datasets.
error: builder for '/nix/store/dc48n6sdr06azz2mpfbszi36wplligwr-source.drv' failed with exit code 1;
       last 10 log lines:
       > Warning: Problem : HTTP error. Will retry in 1 seconds. 3 retries left.
       >   0 55124    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
       > curl: (22) The requested URL returned error: 502
       > Warning: Problem : HTTP error. Will retry in 2 seconds. 2 retries left.
       >   0 55124    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
       > curl: (22) The requested URL returned error: 502
       > Warning: Problem : HTTP error. Will retry in 4 seconds. 1 retries left.
       >   0 55124    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
       > curl: (22) The requested URL returned error: 502
       > error: cannot download source from any mirror
       For full logs, run 'nix log /nix/store/dc48n6sdr06azz2mpfbszi36wplligwr-source.drv'.
error: 1 dependencies of derivation '/nix/store/1vf2yz81y3n4gh3n42c016w3jwrqvjwl-aws-c-http-0.6.28.drv' failed to build
error: 1 dependencies of derivation '/nix/store/s9v00jgic10qazhg0iwc6a27ix6cw87v-aws-crt-cpp-0.18.9.drv' failed to build
building '/nix/store/ax599998b912dqw6dsbysph5h3lwj1w8-tensorflow-deps-merged.drv'...
error: 1 dependencies of derivation '/nix/store/xc39fbgj6sgyprcfgw4ylkqvhi5y6h95-aws-sdk-cpp-1.9.294.drv' failed to build
error: 1 dependencies of derivation '/nix/store/w0ifhqnghmgs677finymjc1xdmcpcfd5-arrow-cpp-9.0.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/dcjbpx8dgjkdikfmiai2pwfbzxq3v5p2-python3.9-pyarrow-9.0.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/8bcsjgid8xrwdrimw8hjsw03yld4zlx6-python3.9-apache-beam-2.40.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/mk111p6hlbw9q6qkx2mfb1qsqzp3shij-python3.9-dask-2022.10.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/4fixhp23j920zqxxvkpggi27ydcrv6zk-python3.9-tensorflow-datasets-4.6.0.drv' failed to build

full build log
python39Packages.tensorflow-datasets maintainers cc: @ndl
maintainers cc:
Other cc: n/a
Steps to reproduce

Checkout nixpkgs at commit 0fc9fca9c8d43edd79d33fea0dd8409d7c4580f4
Run nix-build -A

Technical details
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.0-1024-azure, Ubuntu, 22.04.1 LTS (Jammy Jellyfish), nobuild`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.12.0`
 - nixpkgs: `/nix/store/hnh1xvqmg0gb1jg0d3knsri76392jwpx-source`

Misc.
This issue was automatically generated by nixpkgs-upkeep.

CI workflow that created this issue.
Internal tags: -3082164213385835198<PHONE_NUMBER>967588157

closing this as a network error


Add a lint when defining default values for optional parameters

Default values for optional parameters

break forwarding in ugly ways,
pollute interfaces in confusing ways,
become part of the signature of the method so that it affects subclasses, and
don't play nice with non-nullability.

Therefore, some people choose to not use them. It would be nice to have a lint to catch places where they are accidentally used.

I believe @munificent and @nex3 have thoughts on this – only for bool args, if I remember correctly.
It's documented somewhere...

That's right. The default value of a boolean parameter is inherently part of a method's public API in a way that it's not for other types, so it makes sense for it to be reified in the signature.

The default value of a boolean parameter is inherently part of a method's public API in a way that it's not for other types

I recall that this is true, but I don't remember why bools are special. Can you remind me?

Because there are only two options, the caller always has to make an explicit decision about whether they want the flag to be enabled or disabled, regardless of whether they explicitly pass it or not. This means that there's no reason for the caller to want to explicitly pass "default" rather than true or false; they inherently have to make the decision in terms of enabling or disabling the flag.

What about cases where a boolean parameter is being forwarded?
foo({bool param}) => bar(param: param);

bar({bool param}) {
  ...
}

Here, using a default value in bar would break foo's forwarding and force it to have a default value too.

foo() is still explicitly deciding what the default behavior will be for its call to bar(). It makes sense for that explicitness to be reified in its signature as well.

foo() is still explicitly deciding what the default behavior will be for its call to bar().

How? Note that bar() doesn't have a default value so the null will be handled in the body of bar(). If you were to change bar() from:
bar({bool param}) {
  param ??= true;
  ...
}

to:
bar({bool param}) {
  param ??= false;
  ...
}

Wouldn't that change the effective default value without having to touch foo()?

That's actually a really good example of why it's good to use explicit defaults. In your example, when bar()'s default changes, not only is that a breaking change to the API of bar(), it transitively becomes a breaking change to the API of foo() as well. If foo() used an explicit default, it would be insulated from that breaking change.
Booleans are special here because the difference between true and false is so substantial—changing from one to the other makes whatever behavior the boolean controls do the complete opposite thing. Other types' defaults usually mean stuff like "apply to the whole thing" or "use an empty instance", but booleans inherently represent decisions that users make, and making those decisions explicit promotes clarity and stability.

I think that the default value of a named parameter is a significant part of the interface of the enclosing method no matter which type it has: Actual arguments are used to select a specific variant of the range of behaviors that a given method may exhibit, and using a default value is just as significant as giving that value explicitly. So default values should be part of the documentation.
But the tricky part is that default values are method implementation specific, i.e., an overriding method implementation can choose different default values.
You could try to fix this and say "the effect of choosing the default value is a significant part of the interface", and then require that the different default values chosen in a set of implementations of the same method in a subclass hierarchy must have "the same semantics". But if you need to know which class is the runtime type of x before you can decide which argument value e you have to use in x.foo(arg: e) in order to get a specific effect then we have completely destroyed the encapsulation of the implementation that subtype polymorphism is supposed to give us. So that's not acceptable.
In other words, the default values of parameters should always be part of the interface, and they should never be allowed to change in a subclass or subtype.
We can always choose a less strict set of rules, say, to make it a hint if the default value for a given optional parameter diverges in a subtype graph, but I believe that the strict point of view that "it's an interface matter" is a good place to start.

About the 'breaks forwarding' problem: Don't we just need mandatory named arguments for that?

In other words, the default values of parameters should always be part of the interface, and they should never be allowed to change in a subclass or subtype.

Exactly right. And in Dart, that means you have to repeat the default value in the subclass, which I think violates the basic DRY principle.

About the 'breaks forwarding' problem: Don't we just need mandatory named arguments for that?

No, those would be nice, but that's orthogonal. Let's say there's some function like:
int increment(int n, [int by = 1]) {
  return n + by;
}

This code is directly being called and we're happy with its API, including the fact that by is optional. But I also want to write my own function that forwards to it:
int loggedIncrement(int n, [int by]) {
  var result = increment(n, by);
  print("incremented to $result");
  return result;
}

This doesn't work. (In fact, it will throw an exception because increment() assumes by will not be null.) Instead, you should define increment() like so:
int increment(int n, [int by]) {
  by ??= 1;
  return n + by;
}

Or you have to jump through weird hoops in loggedIncrement():
int loggedIncrement(int n, [int by]) {
  var result;
  if (by == null) {
    result = increment(n);
  } else {
    result = increment(n, by);
  }
  print("incremented to $result");
  return result;
}

That doesn't scale well to multiple optional parameters—you end up needing the combinatorial explosion of different calls.
The core problem is that Dart makes a semantic distinction between "passed null" and "did not pass a value", but the latter has no first-class representation in the language. Where JS has undefined, we have nothing. Getting rid of undefined is great, but our optional parameter semantics still have the same behavior, you just can't abstract over it any more.

This doesn't work. (In fact, it will throw an exception because increment() assumes by will not be null.)

Well, that's wrong already. Nothing prevents you from passing null as the actual by parameter - it's assignable to an int parameter after all. The fact that another method does the calling doesn't change that - your original loggedIncrement method has undefined behavior when by is null.
Default behavior for omitted optional parameters is part of a function's contract. That doesn't necessarily mean that it's part of the function's signature - much of a contract isn't part of the signature, like "index value must be in the range 0 .. list.length" where the signature is just int.
You can break a contract in a sub-class in many ways, and we can't stop you from that. I personally don't think default values belong in a function signature. The slight added security it gives you to get warnings if a subclass changes the value doesn't outweigh the complexity it introduces - changing the internal representation of the default value, or changing it to using a different code path if the parameter is omitted (often happens for function parameters) becomes a breaking API change when it doesn't need to be.
I don't think named boolean parameters are special. Any problem they have also goes for any other optional parameters - the user needs to know the behavior when you omit the parameter. That's part of the contract - but it's only the behavior that matters, not the actual value ending up inside the function.
If we have non-nullable types, you can make the named boolean parameter have type bool! and then you have to pass the parameter, it can't be omitted. (I guess optional positional parameters need to have nullable types or default values).
So, I'd prefer to remove default values from function signatures. I don't mind if we keep the default values as part of function declarations - it's one way to implement the desired behavior, even if it isn't also the way to document it.

So, I'd prefer to remove default values from function signatures.

+1!
I'm curious to see how many optional parameters people would still use if Dart supported overloading. My hunch is that the latter would cover many cases where users have to resort to optional params today.

@munificent I think overloading works fine for simple cases where a single parameter at the end is optional, but what if there are 3 optional parameters? That would require lots of overloads already.
non-nullable types for parameters with default values seems the best option to me.

non-nullable types for parameters with default values seems the best option to me.

I have no problem with having that option, as long as the default value isn't part of the function signature - it's just a shorthand for having a nullable formal parameter with an implicit initialization, giving a non-nullable variable in the function body.
That means that a default parameter is an implementation detail, not an externally visible part of the function signature, just like being async is. I think we can make that work reasonably well.
Then we can even change the requirements on the default value to be an initialization expression that is executed every time the function gets a null argument, like bool! localFlag = parameterFlag ?? initializerExpression;. If it's part of the function implementation, it doesn't have to be constant (but it obviously still can be, it just makes initialization quicker).

.. you have to repeat the default value in the subclass .. [violating DRY]

Indeed; it would be a breaking change, but we could say that the default value for a given parameter is implicitly preserved in overriding versions of the enclosing method. (So we'd have a notion of a default default ;-). We could have an explicit default default marker (maybe [int by = super]) in order to avoid the breaking change.
With the increment and loggedIncrement example, we could also get better support for correct forwarding:
int increment(int n, [int by = 1]) {
  return n + by;
}

@forward(#increment)
int loggedIncrement(int n, [int by]) {
  var result = increment(n, by); // Hints!
  print("incremented to $result");
  return result;
}

The hints given at the invocation of increment are based on the information that all invocations of increment inside loggedIncrement are intended to be forwarding invocations, i.e., they should always pass all arguments, and the default should match up (ah, maybe we can have [int by = forward] as well ;-). So there wouldn't be any omitted arguments (based on the static knowledge about increment, which should be sufficient exactly because of this type of rules). So we'll have a safe forwarding invocation when the tools are happy.
OK, @forward(#increment) doesn't work well for invocations on different receivers (which would be an important case), so there's a need to come up with a more general idea than just "specify the selector of the forwardee". Conversely, for non-forwarding invocations it is not reasonable to assume that all parameters must always be passed (they wouldn't need to be optional), so we do need some kind of special flag to get this special kind of check. But that's a separate subproblem.
This definition was mentioned as well. It is interesting for a reason that I haven't seen anyone mention explicitly (forgive me if I missed it):
int increment(int n, [int by]) {
  by ??= 1;
  return n + by;
}

This idea makes null a universal "no value given" marker (requiring us to take care that it doesn't mean other things as well). That makes it easy to pass "no value given" around from one optional argument to the next one, implicitly or explicitly, and get the default value using ??= at the end. This is especially convenient when we wish to give a subset of a list of optional positional arguments (where others have tried things like foo(1, , 3) to indicate that the 2nd argument should have the default value, but we can now use foo(1, null, 3)). So this idea has several interesting properties.
But still, we could have explicit syntax for the default value (foo(1, default, 3) might work), and we could maintain the default parameter value mechanism as a part of the signature of the associated method and get safe forwarding as well as informative signatures.
Oh, and static overloading?: Just say no!! ;-)

This idea makes null a universal "no value given" marker (requiring us to take care that it doesn't mean other things as well).

I think that would be awesome. Assigning a meaning to null apart from "optional value not available" is usually a hack. A nullable variable of type Foo should mean "zero or one of Foo". If it means something more complicated than that, it's going to be harder to maintain and likely error-prone.
That matches optional parameters exactly.
I am not convinced that maps should allow null as key or value :)

There is one little quirk here, though: If a null valued parameter means "this value was not provided" then we get a conflict in the situation where the parameter itself uses null to mean "please put the message "this value was not provided" into your configuration/database/whatever". In other words, it's not hard to come up with situations where this "not provided" signal can be sent to multiple targets.

We have that already now, and most of the time we accept this.
The only exception is new List(null) where we go through some workarounds to make this throw.
We can't set the optional value to an integer there since that would make the list fixed-length.
It turns out that with constructor forwarding we had a warning-free way to do this correctly in Dart, but it is a hack (and I wouldn't be surprised if we can't do it in strong-mode anymore). I actually think that we just treat the list-constructor specially now in the dart2js and probably the VM.

The test package does use the ability to tell the difference between passing no arguments and passing null at the moment to wrap functions transparently. However, if we were guaranteed that no functions anywhere differed between those two cases, we could also get away with not telling the difference.


Add DTF and CTF calculation as HRIR transformation

Directional transfer functions (DTFs) and common transfer function (CTF) according to Middlebrooks (1999) and Majdak et al. (2010). See Matlab implementation at ARI.

Middlebrooks and Majdak et al.


Added support for Image corner radii in Android

Split out from PR #4252 - @kmagiera I've made the changes to how the radii arrays are allocated, is the approach I've taken correct? also it looks like ImageStylePropTypes are needed so I left them in for the moment. I suppose this pull request will only be valid if iOS supports image corner radii, but at least it's here if/when needed. Attached an image of how it handles the existing case:

I'm not convinced we should add and maintain this code in the core given it's sort of an edge-case feature, and Android only. Would you be up for releasing a separate image module that supports this for people who need this feature?

@mkonicek - as I mentioned in Discord, and I think you agree with me now -- this exists on iOS and web and this is a good step forward for parity.

Hi, thanks for considering this pull request, please let me know if I need to update to resolve any conflicts since I originally submitted it - also if necessary I can look to move this into separate image module as suggested.

Would be great if you could squash and rebase your changes in top of master - so that we can see if the tests are passing

Just a few minor comments inline and it's good to go. Thanks @mattds for your patience :)

It's a pleasure, will make the changes mentioned now.

Looks good, just waiting for @brentvatne response on that inline comment

Thanks, this is going to be very useful :) borderRadius was kind of limited as is.

@mkonicek would you mind taking a look at this pull request? It's been a while since the last commit was reviewed.

@brentvatne replied: https://github.com/facebook/react-native/pull/5197#discussion_r56948731
Will let @kmagiera review this one.

@facebook-github-bot shipit


Upgrade of codelizer.com website

I think we can upgrade the codelizer.com website :

Update npm Packages in package.json (angular 4.X, codelizer 3.X, tslint, ...)
Update rules used for the editor
Maybe change the example in the editor
... Any ideas ?

I'll be glad to have the newest version of all dependencies in the demo app.
Since the support of external templates/styles, codelyzer is more coupled to node and it will require more work to bundle it as a browser app.
This is something which needs to be done anyway and will require extracting the low-level APIs into a host class (similar to the hosts of the language service of TypeScript).

Following the feature request process that lodash has, I'm closing the issue and adding votes needed label.
Later we can prioritize the feature requests by popularity and include them in a future release.


Proposed Updates to Scoring Pipelines README.md

Proposed style, grammar, flow changes.

@anjalisood @ling-yao  ... please review my changes and provide feedback. Who owns this repo?


fix: rollback overview tab for collections

This PR resolves [bug fix]
Description
Rollback the overview tab for collections

PR Checklist

[ ] I have tested my changes on iOS and Android.
[ ] I hid my changes behind a feature flag, or they don't need one.
[ ] I have included screenshots or videos, or I have not changed the UI.
[ ] I have added tests, or my changes don't require any.
[ ] I added an app state migration, or my changes do not require one.
[ ] I have documented any follow-up work that this PR will require, or it does not require any.
[ ] I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

overview tab fixes - egdbear

Need help with something? Have a look at our docs, or get in touch with us.

This PR contains the following changes:

Dev changes (overview tab fixes - egdbear)

  Generated by :no_entry_sign: dangerJS against 25dccdbf7ea46fcb0d989650f23940e6ea4f53a6


{ibus,fcitx5}-rime: support user provided RIME data packages

Description of changes
Provide a generic option i18n.inputMethod.rime.packages to specify rime data packages used by fcitx5-rime and ibus-rime.
With this PR, third-party rime data packages like iDvel/rime-ice can be easily packaged and used with ibus-rime and fcitx5-rime.
Also, the rime-data package can be refactored to be fine-grained. Currently, nixpkgs only provide a single rime data package called rime-data, which contains all official rime data (maintained by the RIME GitHub organization). While the Arch Linux community repository provides fine-grained packages like rime-luna-pinyin, rime-double-pinyin, and rime-cangjie etc.
Changes:

Add a new option i18n.inputMethod.rime.packages. The option itself does not do anything. But It will be used by the fctix5 module and the ibus module to install rime data.
Add a new option i18n.inputMethod.rime.enableDefaultRimeData for compatibility and out-of-box experience. This option replaces i18n.inputMethod.fcitx5.enableRimeData.
Update the fcitx5 module to use the new option. Provide NIX_RIME_DATA_DIR environment variable in the wrapper instead of adding it to environment.variables. The new method should be more robust.
Patch ibus-rime to support the NIX_RIME_DATA_DIR environment variable (like #167032). And update the ibus module as the fcitx5 module.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

@Vonfry

moving NIX_RIME_DATA_DIR to the fcitx5 and ibus wrapper

I have done this. Could you please review it again?

Tested with ibus on GNOME and fcitx5 on KDE using this flake.
https://gist.github.com/linyinfeng/fad9e88e02c36197ba82a373758ff258
Currently, rime-ice and rime-data have overlap files and cannot be used together, so I tried to package some fine-grained RIME packages in my nur-packages repository for testing.

I think you must write the changelog into release-note

I think you must write the changelog into release-note

Now I have added release notes for this change to this file.

@ofborg eval

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1941

Tested all works as expected, lgtm.

I strongly prefer #224042 over this. NIX_RIME_DATA_DIR is already causing too much trouble for me since #167032. It's hard to update unless reboot (relogin not always work for NixOS). It's impure. It's hard to debug when something went wrong (eg. systemd user services isolates envvars).
Environment variables should be considered harmful.

https://github.com/NixOS/nixpkgs/pull/224042 has been merged. So I close this one in favor of https://github.com/NixOS/nixpkgs/pull/224042 .


Migrate to travis-ci.com (low priority)

As of May 2018, Travis CI has been restructuring their handling of open-source projects. Projects on travis-ci.org are being migrated to travis-ci.com. See https://docs.travis-ci.com/user/migrate/open-source-on-travis-ci-com/
We should opt-in to migrate ours. We'd get some nice features like deploy keys. Should be mostly painless -- I think the only thing we'll need to update is the build badge URL in the README. We may temporarily lose build history, but I think that should still be accessible through travis-ci.org

@enielse Bump on this issue. travis-ci.org will be going read-only on Dec 31 2020: https://docs.travis-ci.com/user/migrate/open-source-repository-migration#q-what-will-happen-to-travis-ciorg-after-december-31st-2020

Closed with migration to GitHub Actions

Closed with migration to GitHub Actions


[vcpkg-scripts] shorten source dir to avoid max path limitations better.

Gives windows users an additional 12 characters.

other stuff which could be done:

shorten src to just s
only use the hash (kind of annoying if the portfile downloads from multiple sources; having only the end of SOURCE_BASE was already annoying.)
hash the triplet to defined 6 chars for the working dir. (that was my problem in this case since x64-win-llvm-release is longer then the default x64-windows triplet. So users have to be aware of the fact that the triplet should be as short as possible. On the other hand this would hurt finding the correct build folder)

For some ports, it might help to copy the source to each build dir and build in-source.

For some ports, it might help to copy the source to each build dir and build in-source.

requires changes to vcpkg-cmake to allow for in source builds and adjust the paths accordingly.

I cancelled PR build because the fleet is very behind right now and if we want to make this change we probably want to quibble about details anyway

@vicroms @JavierMatosD @data-queue @ras0219-msft and I talked about this today.
@ras0219-msft is concerned about changes that save a small number of characters in a way that might make buildtrees more confusing without actually fixing the problem might not be a worthwhile tradeoff.
@BillyONeal thinks nobody cares about the buildtrees format so we should be free to make changes there.
@ras0219-msft argues that if that is true we should be talking about a more complete change to e.g. hoist src entirely out of the individual port directories.
@ras0219-msft wants a statement about the concrete use cases that we are fixing by making a change like this, such as "qtwebengine does not build without setting --x-buildtrees-root ever but now works as long as VCPKG_ROOT is N characters". He does not like this outcome but concedes that he could be convinced to make the change if the pros outweigh potential confusion.
@vicroms would like to try lifting the sources all the way up (and agrees that the format of buildtrees doesn't matter)
There is a spectrum here where shorter paths are going to be better for this use case but making them shorter removes helpful context.
@vicroms The vcpkg edit and --editable experience does make me hesitant to remove everything.

@ras0219-msft wants a statement about the concrete use cases that we are fixing by making a change like this, such as "qtwebengine does not build without setting --x-buildtrees-root ever but now works as long as VCPKG_ROOT is N characters". He does not like this outcome but concedes that he could be convinced to make the change if the pros outweigh potential confusion.

The problem was that I could not even build qtwebengine using --x-buildtrees-root=E:/b/ without --editable since my triplet was x64-win-llvm-release which is just 9 characters longer than the default x64-windows triplet (or 1 character longer than the equivalent x64-windows-release triplet). If you want to remove the /src subdir I would be fine with that since it is not really needed. qtwebengine uses cmake as a build system so You see stuff like:
<working_dir>/some/sub/path/../../../../src/name-hash/some/sub/path. So if <working_dir> together with /src/name-hash and the relative path correction /../../../../ gets too long this becomes a problem.
If you want to move outside of buildtree_root/port/ you also need to move the working dir since otherwise you just pay with additional ../ corrections

@BillyONeal thinks nobody cares about the buildtrees format so we should be free to make changes there.

I care a bit about it. Stuff should at least be easily findable and distinguishable.

"qtwebengine does not build without setting --x-buildtrees-root ever but now works as long as VCPKG_ROOT is N characters".

I think that requires dropping /src. Then it might just work within Drive:/vcpkg/buildtrees/
I mean you could also be more radical and move to only 4 characters ?

@ras0219-msft wants a statement about the concrete use cases that we are fixing by making a change like this, such as "qtwebengine does not build without setting --x-buildtrees-root ever but now works as long as VCPKG_ROOT is N characters".

+1.

@BillyONeal thinks nobody cares about the buildtrees format so we should be free to make changes there.

I care a bit about it. Stuff should at least be easily findable and distinguishable.

+1.
Probably it is more relevant to more active contributors.

You see stuff like:
<working_dir>/some/sub/path/../../../../src/name-hash/some/sub/path.

And that's why it can helps to have very close to build, like in-source, .. relative build, or s and b.
Maybe instead of copying the source into the current build dir, it would help to copy the current source into a s in CURRENT_BUILDTREES_DIR so that the path collapses to
<working_dir>/some/sub/path/../../../../s/some/sub/path

And that's why it can helps to have very close to build, like in-source, .. relative build, or s and b.
Maybe instead of copying the source into the current build dir, it would help to copy the current source into a s in CURRENT_BUILDTREES_DIR so that the path collapses to
<working_dir>/some/sub/path/../../../../s/some/sub/path

Could a symlink be used to shorten the paths on the command line?

Could a symlink be used to shorten the paths on the command line?

symlink to where?

For example from <vcpkg_root>/buildtrees/s1 -> <vcpkg_root>/buildtrees/<port>/src/here-src-6-8b9bc1db6f.clean and from <vcpkg_root>/buildtrees/br -> <vcpkg_root>/buildtrees/<port>/<triplet>-rel


carousel styles breaks if more then 4 items are shown

The layout of carousel items is controlled with CSS, and breaks in case more than 4 items per slide are shown.

QA Passed


Fix testing deployments silently affecting production too

Currently, when deploying to testing, we load the new django app docker image as cpmonitor:latest. We then tag it and restart the testing env.
However, by loading it as cpmonitor:latest, the new image will also automatically be run in production as soon as production is just restarted! This is because we simply reference the image to run as cpmonitor.
Suggested solution: reference the image in the compose file as something like cpmonitor:$env, so we're sure deploying to testing will never affect production.

Good find!


Added CLI arguments & fixed issues

Added support for the collection name as a command line argument so the user doesn't have to keep going back into the file to change the collection name. This includes updating the README to reflect this change in usage.
I also implemented the fix for issue #8 based on the answer given by @NtekShadow (this includes the header issue mentioned later in the thread).

Awesome job!


Summary export permission denied

When passing the flag --summary-export results.json then an error is raised:
level=error msg="failed to create summary export file" error="open results.json: permission denied"

The result is that no summary file is created.
Example of step:
uses<EMAIL_ADDRESS>with:
  filename: scenarios/${{ github.event.inputs.scenario }}.js
  flags: --summary-export ${{ github.event.inputs.scenario }}.results.json

The expected result is that the flag works like on a local environment, and the result.json file is created and can further be exported using actions/download-artifact@v2
uses: actions/upload-artifact@v2
with:
  name: ${{ github.event.inputs.scenario }}.results.json
  path: ${{ github.event.inputs.scenario }}.results.json

A possible root cause is that the k6 docker image set the USER in the Dockerfile, what is not recommended as per Github Action documentation.

Hey,
Thank you for your report! I'll have a look at this. Contrary to GitHub's own recommendation, it's generally a bad practice to run anything in docker as root. I'll get back to you once I have more details.
Best,
Simme

Happy New Year @simskij
Any update on this issue?
If you have any suggestion for a workaround, I'll be happy to give it a try.

Happy New Year @simskij
Any update on this issue?
If you have any suggestion for a workaround, I'll be happy to give it a try.

Hi @edno,
This should be fixed as of v0.2.0, which I just released.
Best,
Simme

Hi @edno,
This should be fixed as of v0.2.0, which I just released.
Best,
Simme

Confirmed. It works as expected 😃

Confirmed. It works as expected 😃


Change data path from config file

Hi,
please add a variable to the config file to change the default "data/" path to another.
Now the path is only changed with edit all of these files:

\app\constants.php
\app\Core\FileCache.php
\app\Model\File.php
\app\ServiceProvider\LoggingProvider.php

PS: \app\constants.php is bypassed if the "DB_FILENAME" defeined in config.php

You can already change the location of data stored in data by using those constants:

DEBUG_FILE
FILES_DIR
DB_FILENAME

The class FileCache is not used actually.
I could also add another constant like DATA_DIR...


problem: 343. Integer Break

Problem #343(Integer Break | Dynamic Programmin, Math)

Given an integer n, break it into the sum of k positive integers, where k >= 2, and maximize the product of those integers.
Return the maximum product you can get.
Example 1:
Input: n = 2
Output: 1
Explanation: 2 = 1 + 1, 1 × 1 = 1.
Example 2:
Input: n = 10
Output: 36
Explanation: 10 = 3 + 3 + 4, 3 × 3 × 4 = 36.
Constraints:

$2 <= n <= 58$

Hey, @godkingjay can you assign the issue to me?


Fix issue 19544 - Can't call inputRangeObject on ranges not supported by …

…moveFront
The range algorithms moveFront, moveBack, and moveAt do not accept all
valid input ranges, bidirectional ranges, and random-access ranges,
respectively. Their inclusion as methods of the InputRange,
BidirectionalRange, and RandomAccessFinite interfaces previously caused
InputRangeObject, which implements those interfaces, to fail to compile
when instantiated with certain valid input, bidirectional, and
random-access ranges.
These methods should not have been included in their respective
interfaces to begin with, but removing them now would break existing
code. Instead, as a workaround, InputRangeObject now implements these
methods by throwing an exception if the wrapped range does not support
them.

On the other hand, this is a change in behaviour so cc @atilaneves

Shouldn't this throw an assert instead? Throwing new Exception can lead to difficult debugging when working with @nogc, right? It'll show an error saying that @nogc cannot be used with GC, but that could either be because the function is valid and its dependency uses GC or because it isn't valid but it throws with new.
noreturn moveXXX()
{
	static if (compiles, _range.moveXXX())
		return _range.moveXXX();
	else
		assert(0, "...");
}

That is a possibility, but with a disadvantage: We'd need a separate mechanism for the user to check beforehand whether moveFront would fail the assert. And we're dealing with classes after all - classes are not typically used without the GC. And if someone still needs to do so, they can simply catch(Exception) assert(0);

Well, yeah point taken. Probably not worth the hassle maybe. BTW, InputRange.moveFront can be used with @nogc, you just have to manually override the attributes.
import std;

class Foo(E) : InputRange!E
{
    @nogc @property E front() { return E.init; }
    @nogc E moveFront() { return E.init; }
    @nogc void popFront() {}
    @nogc @property bool empty() { return 0; }
    @nogc int opApply(scope int delegate(E)) { return 0;}
    @nogc int opApply(scope int delegate(size_t, E)) { return 0; }
}

void main() @nogc
{
    scope Foo!int foo = new Foo!int;
    auto f2 = foo.inputRangeObject;
    cast(void) f2.moveFront();
}

BTW, InputRange.moveFront can be used with @nogc, you just have to manually override the attributes.

You can do that for the child class, but I meant the abstract InputRange.

CI failure was a network issue; force-pushing to restart.

Force-pushing again to pick up https://github.com/dlang/ci/pull/448.

@atilaneves This technically introduces a new public symbol (UnsupportedMethod), though it's only an Exception subclass.


making the radio button a touch target for the thread select screen

textile is great! i've honestly waiting for something like this to bubble up and am excited to see how usable it is even for not p2p heads like me :)
this PR fixes something i ran into when initially poking around in the app, where tapping on the radio button in the "Thread select" view for an image wouldn't select the corresponding thread. hopefully uncontroversial, but let me know if there's anything i should do differently

Awesome, thanks for the PR @saranrapjs! Looking at the code now, I think there's a (more) simple fix. Will insert a couple comments.


git ship: when multiple authors, allow user to select which to set as the author

Instead of picking the author of the majority of commits, only automatically set the author if its the same for all commits, otherwise allow the user to pick which author.
Interface could be:

open editor to list of authors and list there commits
user deletes the all but a single line containing the author they want to select

I propose something simple like
Please uncomment the account for the final commit:
Jim (7 commits)
# Jack (3 commits)
# Johnny (1 commit)

Where the user with the most commits is pre-selected.

Yeah I hadn't thought out the exact UI yet but something like that look great.

Why not just use stdin? That's pretty standard for stuff like this IMO.
Also I think email would be useful to display as well if one was attached to the commit
Choose the account for the final commit:
1. Jim S<EMAIL_ADDRESS>(7 commits)
2. Jack<EMAIL_ADDRESS>      (3 commits)
3. Johnny M.                      (1 commit)

Enter committer number (1-3): █

Cool, a definitive +1 on showing emails. What is stdin though? How would we read this in bash?

You can just use read to read from stdin
echo -n 'Enter committer number (1-3): '
read committer

# $committer is now the users' selection

Sounds good to me. Given that we really only need one data point here, this seems like the simplest solution.


Add Azure Embedded SDK for C to Releases Page

The Embedded SDK for C needs to be added to the releases page.
https://github.com/Azure/azure-sdk-for-c

@jongio Is there work remaining on this item?

It's resolved with your PR right?

Yes, once you approve.  Wasn't sure if this was that or if you had bigger plans

This is complete.


Token expiration

Is it possible to configure? No mention on the docs page.
I have some unwanted behaviour: my frontend shows you are logged in whereas in fact the token is already expired and backend sends 401 Unauthorized.
See example (upper left corner - credentials and logout button):

This seems like a strange behaviour, if not a bug.
P.S. I used command dotnet new angular -o <output_directory_name> -au Individual from this ASP.NET Core version.

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

ID: 21cb7455-3305-9316-5440-bdc22947a82d
Version Independent ID: 137d4b94-7b26-3911-b22d-42c754a95fc1
Content: Introduction to authentication for Single Page Apps on ASP.NET Core
Content Source: aspnetcore/security/authentication/identity-api-authorization.md
Product: aspnet-core
Technology: aspnetcore-security
GitHub Login: @javiercn
Microsoft Alias: scaddie

Related question: is it possible to use refresh tokens here?

@javiercn, sorry to bother, but could you please share your thoughts?

This should work, if not. Its either something is not configured right on the templates or the underlying library has a bug. As far as I understand the library is properly configured.

@javiercn here's a more appropriate example:

Steps to reproduce:

Register and login via Identity Server
Wait some time
Try to access data from [Authorize] controller

Has this issue been resolved in preview7?
...I am unable to recreate this issue in this preview...

@Svetomechc  It seems that the app fails to renew the token as you mentioned.

@Michaelwan777 indeed it does! Hope this gets resolved before ASP.NET Core 3.0 stable release.

Has anyone figured out a work around for this?

@asad-c, nope, I just redirect to login page if that happens.

I encountered the same issue and would like to see if someone could look into this issue. Thanks.

I couldn't wait for this to get resolved so had to create the individual projects myself (Angular client, API and IdentityServer) and it's working as expected.

Care to share any details/pointers how you resolved this?

Care to share any details/pointers how you resolved this?

For me to get this to work was a combination of the IdentityServer quickstart tutorials:
https://identityserver4.readthedocs.io/en/latest/quickstarts/0_overview.html
And the following Pluralsight course:
https://app.pluralsight.com/library/courses/openid-and-oauth2-securing-angular-apps/table-of-contents
The IdentityServer docs give an example of a vanilla JavaScript client, but the Pluralsight course shows how to implement an Angular client.

@asad-c a bit tiresome if you ask me, compared to dotnet new angular -o <output_directory_name> -au Individual. Also, I thought they'd change Implicit Flow to Authentication Code Flow with 3.0 release, but they haven't. Oh well, I guess this template is deserted.

@Svetomechc The template uses authorization code + pkce

@javiercn you're right, I looked at the wrong place - forgot that the authorization code was in Microsoft.AspNetCore.ApiAuthorization.IdentityServer package, not in the template itself.
Still, the problem in this issue stands.

@Svetomechc does this happen in production as well?

@berik, no, it currently doesn't happen in production for me. But it's been popping out iframes like crazy, some 20-ish of them.

It does happen in production to me. Svetomechc, how did you configure your production differently other than setting the environment to production?

@caihongxu there are a lot of modifications to my production code (for example I use MongoDB for storing users), so I can't list them all, especially because I have no idea what worked around* token expiration.
*though I'm still waiting for the fix proper, as 20+ iframes for authorization slows down my application at startup pretty heavily

In fact, it happens to me as well,
After I deploy a new version, and I relogin, I get 401 error for every request I send using the new token.
For a strange reason, it happens only on production, and not in development mode.
If anyone has succeeded to figure this out, I would really appreciate his help.

@yakeer this happens to me to, by the way, and I haven't found a solution. But I've found a workaround:

authorize.interceptor.ts
import { Injectable } from '@angular/core';
import { HttpInterceptor, HttpRequest, HttpHandler, HttpEvent, HttpErrorResponse } from '@angular/common/http';
import { Router, ActivatedRoute } from '@angular/router';
import { Observable, throwError } from 'rxjs';
import { mergeMap, catchError } from 'rxjs/operators';
import { AuthorizeService } from './authorize.service';
import { AppRoutes } from '../app-routes';

@Injectable({
  providedIn: 'root'
})
export class AuthorizeInterceptor implements HttpInterceptor {
  constructor(private authorize: AuthorizeService, private router: Router, private activatedRoute: ActivatedRoute) { }

  intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    return this.authorize.getAccessToken()
      .pipe(mergeMap(token => this.processRequestWithToken(token, req, next)));
  }

  // Checks if there is an access_token available in the authorize service
  // and adds it to the request in case it's targeted at the same origin as the
  // single page application.
  private processRequestWithToken(token: string, req: HttpRequest<any>, next: HttpHandler) {
    if (!!token && this.isSameOriginUrl(req)) {
      req = req.clone({
        setHeaders: {
          Authorization: `Bearer ${token}`
        }
      });
    }
    const pathname = window.location.pathname;
    return next.handle(req).pipe(catchError(err => {
      if (err instanceof HttpErrorResponse) {
        if (err.url.includes('Identity/Account/Login') && !pathname.includes(AppRoutes.authorizationLogin)) {
          this.router.navigate([AppRoutes.authorizationLogin], { queryParams: { ReturnUrl: pathname } });
        }
      }
      return throwError(err);
    }));
  }

  private isSameOriginUrl(req: any) {
    // It's an absolute url with the same origin.
    if (req.url.startsWith(`${window.location.origin}/`)) {
      return true;
    }

    // It's a protocol relative url with the same origin.
    // For example: //www.example.com/api/Products
    if (req.url.startsWith(`//${window.location.host}/`)) {
      return true;
    }

    // It's a relative url like /api/Products
    if (/^\/[^\/].*/.test(req.url)) {
      return true;
    }

    // It's an absolute or protocol relative url that
    // doesn't have the same origin.
    return false;
  }
}

For refresh token not working, are you using a persistent store for Identity Server's operational data? If not, then it's just the in-memory store, which means the refresh tokens would disappear when the process restarts.
https://identityserver4.readthedocs.io/en/latest/reference/ef.html#operational-store-support-for-authorization-grants-consents-and-tokens-refresh-and-reference

@joshpearce of course I am. https://github.com/matteofabbri/AspNetCore.Identity.Mongo in particular. The issue is not specific to the store, though. It remains if I switch over to EF Core and SQLite / SQL Server.

@joshpearce thank you. This solved my issue.
I've added
.AddOperationalStore(options =>
                {
                    options.ConfigureDbContext = builder =>
                        builder.UseSqlServer(connectionString,
                            sql => sql.MigrationsAssembly("Infrastructure"));
                     // Change "Infrastructure" to "typeof(Startup).GetTypeInfo().Assembly.GetName().Name;"
                    // this enables automatic token cleanup. this is optional.
                    options.EnableTokenCleanup = true;
                    options.TokenCleanupInterval = 30; // interval in seconds
                })

And whole picture
public void ConfigureServices(IServiceCollection services)
        {
            var connectionString = Configuration.GetConnectionString("DefaultConnection");
            services.AddDbContext<ApplicationDbContext>(options =>
                options.UseSqlServer(connectionString));
            services.AddDefaultIdentity<ApplicationUser>()
                .AddEntityFrameworkStores<ApplicationDbContext>();

            services.AddIdentityServer()
                .AddOperationalStore(options =>
                {
                    options.ConfigureDbContext = builder =>
                        builder.UseSqlServer(connectionString,
                            sql => sql.MigrationsAssembly("Infrastructure"));
                    // this enables automatic token cleanup. this is optional.
                    options.EnableTokenCleanup = true;
                    options.TokenCleanupInterval = 30; // interval in seconds
                })
                .AddApiAuthorization<ApplicationUser, ApplicationDbContext>();

            services.AddAuthentication()
                .AddIdentityServerJwt();

            services.AddControllersWithViews();
            services.AddRazorPages();
            services.AddSpaStaticFiles(configuration => { configuration.RootPath = "ClientApp/build"; });
        }

@berik are you sure the problem has disappeared after that?

@Svetomechc for the first time, i've left running localhost for overnight and next morning it was working. Today I've repeated same action, but it started not working. So it didn't solve the issue :(

@berik that's what I suspected :c

I have great respect for the work done in this project template, but I feel like anyone considering oidc-client instead of just old fashion session cookies for a web app, even an SPA, needs to think long and hard about whether they really need it. The surface area for subtle auth failure bugs is greatly increased by adding all the client-side logic, and I've never understood the benefits.
Here we're talking about leaving a browser open for hours. You've got background tabs going to sleep and OS's going into power save state working against your auth logic. The user doesn't care about any of this. They just want to either be logged in or out, not partially logged in, wondering how to get the app back working.
Auth is a mess right now. Logging into the Azure Portal sometimes involved four seconds straight of redirects. Then when you log out, they tell you you're probably logged out, but it's best to close the browser to make sure
We write web apps for Radiology, and availability is the number one requirement. I would not introduce oidc-client to our apps.

Moved to master issue: Authentication and authorization for SPAs #16406

Update: I think I addressed this by adding the following line in Startup.cs:
            services.Configure<JwtBearerOptions>(                 IdentityServerJwtConstants.IdentityServerJwtBearerScheme,                 options =>                 {                     options.TokenValidationParameters.ValidateIssuer = false;                     options.TokenValidationParameters.ValidateLifetime = false;                 });
Specifically the ValidateLifetime = false line. My token hasn't expired since then.


Improve negative BCD decoding

commit 2f9fa5c introduced handling of F as a negative BCD value. Unfortunately most of the user doesn't benefit from this change. This PR tries to improve the situation.

LGTM


Installation fails on dependency tensorflow?

I'm not too familiar with the python ecosystem, so forgive me if I'm missing something obvious.
I'm trying to install subsync system-wide, and getting the following error:
$ sudo pip3 install subsync
Collecting subsync
...
Collecting tensorflow==1.5.1 (from subsync)
  ERROR: Could not find a version that satisfies the requirement tensorflow==1.5.1 (from subsync) (from versions: 1.13.0rc1, 1.13.0rc2, 1.13.1, 1.14.0rc0, 1.14.0rc1, 2.0.0a0, 2.0.0b0)
ERROR: No matching distribution found for tensorflow==1.5.1 (from subsync)

Obviously tensorflow 1.5.1 exists in the pypi repos; I don't know if this is a python2 vs python3 issue, but manually installing 1.5.1 fails with the same error.
Is there maybe something wrong with the way I have pip configured? Is it a viable option to upgrade the version of tensorflow that subsync depends on?

Hi there! Thanks for filling an issue.
So I had to squint for a bit to figure out what was going on, because this tool shouldn't have a tensorflow dependency. It turns out that there is a name collision -- there is this subsync which is not yet available in the pypi repos (I'll have to figure out a new name -- see also #36), and there is someone else who already got there first with a similar tool (I haven't checked it out yet, so if you get it working please let me know how it does!)
If you try the following line instead:
pip3 install git+https://github.com/smacke/subsync
It should install without a hitch -- please let me know how it works for you!

🤦 I'll see myself out now.
(Thanks btw!)


chore(main): release 0.0.10

:robot: I have created a release beep boop
0.0.10 (2024-05-17)
Other

migrate from spectrocloud-labs to validator-labs (#167) (4a51c11)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/validator-labs/validator-plugin-oci/releases/tag/v0.0.10 :sunflower:


Feat: use iceberg data file statistics to speed up count query

Is your feature request related to a problem? Please describe.
Each iceberg datafile metadata contains a record_count field and we can use this information to speed up count query like select count(*) from iceberg_table.
First, we need to recognize the count star query and generate a special plan.
The special plan executor only needs to scan the iceberg data file meta data and sum up the record_count.
Describe the solution you'd like
No response
Describe alternatives you've considered
No response
Additional context
No response

wait iceberg mor rafactor


Nuxt/Vuex TypeError: Cannot read property 'state' of undefined

Reproduction
https://codesandbox.io/s/festive-gauss-5knqo?file=/pages/index.vue

Steps to reproduce the behavior

add computed state with mapState from vuex store.
use computed variable in template

Expected behavior
Can work with existing Nuxt+Vuex project
Actual behavior
Nuxt return error

Additional information

You need to tell pinia not to disable Vuex:
// nuxt.config.js
export default {
  buildModules: [
    '@nuxtjs/composition-api',
    ['pinia/nuxt', { disableVuex: false }],
  ],
  // ... other options
}

I forgot to add it to the docs so I'm pushing it to the docs 🙂


Alpha to coverage doesn't work in Compatibility Renderer

Tested versions
Tested in Godot 4.3 Stable (arch linux)
System information
Godot v4.3.stable unknown - Manjaro Linux #1 SMP PREEMPT_DYNAMIC Thu Oct 10 19:03:24 UTC 2024 - X11 - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 3060 (nvidia; 560.35.03) - Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz (6 Threads)
Issue description
When enabling the alpha anti-aliasing settings in a standard material or custom shader with MSAA enabled, no change shows when in the compatibility renderer, bumping up to the mobile renderer shows proper alpha anti-aliasing with alpha to coverage or alpha to coverage and 1
This is extremely unfortunate as the compatibility renderer is currently preferred for standalone XR use cases (inlcuding webXR) and heavy aliasing caused by alpha test materials is visually distracting and intrusive in VR.
Ideally the alpha to coverage could be properly supported in the compatibility renderer so that it could be used for these cases. Even better would be to make sure it works for WebXR as well (where performance targets are even tighter and the use of textured alpha planes is vital to making anything that will look good and perform at a decent level)
Steps to reproduce
enable 4x MSAA for 2d and 3d in project settings
set to compatibility renderer
create multiple intersecting planes with a material with transparency as such

set editor to half resolution to better see anti-aliasing effects
notice that there is heavy aliasing
switch to mobile renderer
notice aliasing is now solved properly through alpha to coverage
Minimal reproduction project (MRP)
see above. If you are unable to reproduce I can trim down my project and include here.

@marstaik
@clayjohn
I believe you guys are the resident experts on the A2C implementation
@BastiaanOlij
@dsnopek
perhaps you will know what to do on the VR side of things

Alpha to Coverage was never implemented in the compatibility renderer.
I haven't looked into the details, but I suspect it could be added at some point, but someone needs to investigate if the relevant features are available in OpenGL 3.3/ ES 3.0.

To my knowledge, alpha to coverage only exists in desktop OpenGL 3.3, not OpenGL ES 3.0.


Update to 0.0.5 of the three-gpu-pathtracer.

The purpose of this PR is to make some minor changes so that the react wrapper works with the latest three-gpu-pathtracer (0.0.5).
There have been some changes to how the environment map is handled which I haven't fleshed out here.

@FarazzShaikh any chance of getting latest version merged in? :)

@richardanaya im working on it but haven’t had much time to

Excited! Thank you so much
On Mon, Feb 20, 2023 at 11:47 AM Faraz Shaikh @.***>
wrote:

@richardanaya https://github.com/richardanaya im working on it but
haven’t had much time to
—
Reply to this email directly, view it on GitHub
https://github.com/pmndrs/react-three-gpu-pathtracer/pull/3#issuecomment-1437483376,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACHZGRAKIDRKMMAPVNBQRTWYPC5HANCNFSM55BM42OA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Closing as the lib has been rewritten for the latest version of the Pathtracer (0.0.13) with a new API.

Exciting!


Provide clarification between WebSQL and SQLite

Short description of what this resolves:
Changes proposed in this pull request:

Ionic Version: 1.x / 2.x
Fixes: #

thanks!


common read storage trait

closes anoma/namada#166
based and depends on #1093

moved to https://github.com/anoma/anoma/pull/1245


Add sample of webRequest API.

Electron has supported webRequest API as chrome's webrequest.
A good reference is from https://developer.chrome.com/extensions/samples#search:webrequest

Yes, it's very good idea and important API. 🏷 😃

?


Switch to using OpenJDK/OpenJ9 from AdoptOpenJDK

As per #3, this switches from pulling the Oracle JDK builds to using OpenJDK/OpenJ9 docker images built by AdoptOpenJDK.net.

Already covered by #8